Re: [Fwd: Some qemu+hurd questions]
Svante Signell, le Tue 02 Nov 2010 22:06:29 +0100, a écrit :
> On Mon, 2010-11-01 at 22:55 +0100, Samuel Thibault wrote:
> > Svante Signell, le Mon 01 Nov 2010 22:39:50 +0100, a écrit :
> > > On Mon, 2010-11-01 at 17:34 +0100, Samuel Thibault wrote:
> > > > Like Linux, Mach tries to use as much memory as possible to avoid Disk
> > > > I/O.
> > >
> > > OK, seems like I need more memory.
> > What makes you think so? qemu CPU emulation is _really_ slow compared
> > to native execution (even if q of qemu means quick, i.e. quicker than
> > e.g. bochs).
> Its just that all (512 MB) memory is used when running the Gnome
> desktop together with Hurd under qemu, and there is some swapping to
> disk going on.
Ah, you mean memory on your host machine, ok.
> > > > > Running the installed Hurd:
> > > > > qemu -m 256 -net nic,model=ne2k_pci -net user -hda hurd-install.qemu
> > > > >
> > > > > - Does qemu have a terminal where I can get a scrollbar, without it is
> > > > > very difficult to catch all output.
> > > >
> > > > Yes, you can use the -curses option to use text mode.
> > >
> > > In gnome-terminal -curses did not work! I did not get any echo of the
> > > commands written :(
> > Make sure your terminal is 80x25, not 80x24.
> Is this a QEMU bug? How should I know that I need 25 rows instead of 24?
Because that's the VGA standard. QEMU is not supposed to be able to
increase your xterm size.
> > > However, starting qemu from xterm -sb -rightbar seems to work.
> > > No graphical keys, like C-A-n etc commands worked!
> > Not really surprising, as they'll be eaten by X11 or the window manager
> > before being passed to qemu via the xterm tty. You can give a try to the
> > vnc way that Arne mentioned in another mail.
> Looks like I cannot run qemu in a window under X then with curses
?! curses is meant to make qemu fit _inside_ an xterm and not a separate
> One problem is still that when doing shutdown in the qemu window (same
> as the terminal window), the gnome/xterm window is unusable. How to
> get back to the terminal?
What do you exactly mean by "doing shutdown in the qemu window"? Typing
"halt" at the hurd shell? Mach will indeed not trigger the poweroff
mechanism so you have to kill qemu by hand from another terminal, yes,
or use alt-2 to switch to qemu's control console and type quit.
> > > Where to find kqemu? Did not find it in Debian.
> > It is there in Lenny at least.
> No longer available in squeeze.
That doesn't mean you can't take the lenny package and recompile :)
> > Err, GNU Mach is not able to use several CPUs, so it should be useless
> > to add more cores...
> OK, maybe an erroneous conclusion from my side. I thought qemu could use
> the two logical processors in the box, obviously not.
Qemu itself is not really multithreaded. Kvm, thanks to hardware
virtualisation happens to be able to let the guest run its virtual CPUs
in two separate threads. But here the Mach guest can't use several
virtual CPUs anyway.
> > > - Complaints at boot on /etc/motd being a dangling symlink, however:
> > > ls -l /etc/motd
> > > lrwxr-xr-x 1 root root 13 Oct 28 00:11 /etc/motd -> /var/run/motd
> > Probably a missing /var/run/motd generation in the init scripts, but
> > that'll be fixed by making Debian GNU/Hurd use Debian's usual SYSV
> > runlevel system.
> Looking forward to that improvement.
Well, that probably won't happen anytime soon or even later since we
already have a lot more important fixes to do and don't already have
manpower to do them. So if you don't take time to fix it yourself and
submit a patch, it'll probably not get fixed.
> - How to change resolution in qemu, with -vga cirrus, std, etc?
> Especially when running X in a window later on.
The usual qemu vs Xorg stuff. Try various combinations. IIRC Xorg can't
detect the cirrus memory size so you may have to set it by hand in
> - How do the graphical and non-graphic modes work?
Work in what? Remember that with the -curses, graphical mode can not be
displayed (since qemu then lives in the xterm).
> Maybe tythis is a qemu question, that should be addressed to their
> mailing lists.
Probably, yes, that's all xorg vs qemu things.