saving energy while working with qemu

As you know qemu always tends to use 100% of cpu. Qemu console is not available with -nographic option, so saving vm is not possible.

The good news is UNIX (and of course Linux) has a standard mechanism for freezing and unfreezing processes:

$ kill -STOP
(from another shell)

will stop  the process. It will still reside in the  memory (RAM or swap).
To continue process, from the shell where it was started, type

$ fg

There will be no echo, but the command will execute.
If there is an echo, the tty is probably messed up. It can be restored again with

$ stty -brkint -icrnl ixoff -imaxbel iutf8 -isig -icanon -iexten -echo

going further with OpenBIOS

No, I was wrong about the 80 characters limit. Found the correct place where it crashed, but the reasoning was wrong. Something was corrupting the stack, so success after patching ufsboot was incidental.

back to OpenBIOS

Since SS-5 OBP works pretty well, I think it's a good time to get back to OpenBIOS: it's free (as in speech), and can support more than 256 MiBs RAM.  Theoretically Ross's SPARCStation-20 OBP supports up to 2 GiB RAM, but frankly speaking I think having a more or less hardware-precise SS-5 is enough.

The very first experience has shown that bootblk loads ufsboot successfully, but then it hangs. I'm feeling myself getting back few months in the past. Back then I was debugging pretty much similar routines in the bootblk, but the main job was done by Mitch Bradley. I sort of hoped I skipped the necessity to learn the gory details of the UFS filesystem. Ok, back to school. ;-) . My very first long shot:

$ strings sun4m/ufsboot
...
 ['] find-device catch if 2drop true else current-device device-end then swap l!
...

Trying to find out whether this sentence works I found out that OpenBIOS doesn't support input lines longer than 80 characters! It would be interesting to find out whether it's just a console limitation, or the API too. If it's an API limitation it may be exactly the bug that prevents Solaris from booting.

Another observing:

0 > " /openprom" ['] find-device  ok
3 > . . . -29a594 9 -264cec  ok

• "ok" is not a prompt, but a response. I don't think it's important.
• It operates with signed hexadecimals. This looks pretty weird. Here comes the same question again: is this just a console representation, or another API bug.

Gonna check it with OpenBIOS developers.

SSH ciphers on emulated sparcs

Running X-applications on an emulated sparc over two ssh tunnels seemed quite slow, so I experimented a bit with different ciphers. Of course when you are connected from localhost to the very same localhost, a risk that a third party can sniff you connection is pretty low. So, obviously the most performing cipher would have been "no cipher". Unfortunately the ssh  bundled with Solaris 9 doesn't have this feature. I found an article where a few different ciphers where compared and wondered whether an emulated sparc cpu is closer to a real sparc or to the host cpu (in my case x86-64). It seems to be that the emulated system is acting rather like a host: arcfour is just a little bit more performant than blowfish:

cipher	throughput
3des	1.1MiB/s
aes128-cbc	1.89 MiB/s
blowfish	2.15MiB/s
arcfour	2.63MiB/s

Theoretical limit (dd if=/dev/zero of=junk bs=1024k count=100): 20.8MiB/s.
Yes, 2.63MiB/s is pretty lame. But hey, on the real hardware you'd get even less.

For now I'm adding

Host 10.0.2.*
  Ciphers arcfour

to my ~/.ssh/config

Tunneling qemu guest back and forth

Using the virtual guests sooner or later you need to have a way to transfer data between guest and host. If you just need to transfer files, it's relatively easy. There is a good document describing many possible ways of doing it in the qemu Puppy project.

But sometimes you want to pretend your virtual guest is a real machine: you want to log in into it, have multiple sessions, start GUI programs and so on. The easiest way to achieve it is use an ssh tunnel. This method is actually neither Solaris, nor qemu specific: you can do the same for exposing machines from your intranet to the outer world. How it works:

You start a ssh daemon (sshd) on your guest and on your host (or any other machine which will work as a representative for the guest). Then on your guest you say:

ssh -R 10022:localhost:22 hostuser@10.0.2.2

This opens a tunnel. If someone has an access to the host's port 10022 she can also login to your guest. So beware that your guest is exposed to the outer world after this point.

Now you can log in into your guest from the host using
ssh -X -p10022 guestuser@localhost
or from anywhere where your host is reachable using
ssh -X -p10022 guestuser@

The -X option is used to turn on X11 forwarding. From the sessions started like this you can run GUI applications.

It's also possible to transfer data via sftp:
sftp -o "port=10022" guestuser@localhost

Testing needed

While I'm busy with rewriting my Solaris 7 hack (which is also needed for Solaris 8 and 9), I'm looking for some help: I'd like to expore the y2k10 problem under qemu. Carey couldn't reproduce the problem on a real SPARCStation, so it may be a qemu nvram bug.
Currently needed /etc/system hack seems to be also nvram-related.

So, what I'm asking for:
boot Solaris 2.0 - 2.5.1 image with qemu option -rtc base=<dateTtime> where dateTtime is a string like  "2006-06-22T16:01:21". Try different dates and times. I.e:

./qemu-system-sparc -M SS-5 -m 256 -rtc base=2009-12-22T16:01:21
 -L  -bios ss5.bin -nographic  -hdb Solaris2.5.1.iso

...

ok boot disk1:d -vs 

Currently it looks like the system doesn't come up if the day of month is >20. 

At least for years 2009 and 2010.

The question is: do year, month, hours and seconds also play a role?

I.e. is it possible to boot when day is 22, with any year?
Is it not possible to boot when day is 22 and year is 2010 with any
month, hour and minutes settings?

Waiting for your feedback (you can write in English, German or Russian).