Re: [Qemu-devel] Qemu Guest Tools

[olig9]

> On Wed, Mar 02, 2005 at 01:44:35PM +0100, Oliver Gerlich wrote:
> > Planned features are:
> > -Notification of guest when it is loaded with loadvm
> 
> Why?

Mainly for time synchronisation, I must admit.

> 
> > -Time synchronisation between host and guest (currently guest time is 
> > wrong when loadvm is used)
> 
> Technically this is a qemu bug and should be fixed in qemu.

Is it? I thought the problem was that most OSes query RTC time on startup
and then keep time internally, so if they are loaded, they don't know that
RTC time changed.

> 
> Of course, any way to set the time in qemu guest w/o having to patch qemu
> source is welcome.
> 
> > -drag and drop (Mark mentioned it, and it was also posted on the forum 
> > some days ago)
> 
> > -make mouse grabbing more comfortable
> 
> I am against mouse grabbing myself. I just use the no-sdl-grab patch and
> deal
> with a desyncing guest mouse pointer (sometimes I can work around it by
> turning mouse acceleration off in the guest).
> 
> > 
> > Copy/paste and time sync could be done by external programs (Joshua 
> > mentioned mpcb; ntp, ...).
> 
> I'm not sure if ntp would work for qemu guest. The way qemu works, guest
> changes
> to the RTC are overridden by qemu. Of course if the guest kept its own
> time
> independent of the hardware clock, that wouldn't be a problem.

Admittedly I don't know how different OSes handle this; I only know from
Linux that it keeps time internally (sync between RTC and internal time can
be done with hwclock), and I thought other OSes use the same technique.
Of course, I silently assumed that Qemu's RTC is working correctly :) only
that it doesn't help with today's OSes.

> 
> > But drag and drop requires access to the Qemu 
> > window, and loadvm notification requires some kind of integration with
> Qemu.
> 
> Both of which can not be done reliably through TCP/IP. (What if the guest
> has no network support? Or you are running Windows 98 in safe mode?)
> 

It can be done reliably only in the meaning that you have QGT loaded and
then QGT detects that the host closed the connection and tries to reconnect
five seconds later (this is already partially implemented, only the host
part of course doesn't know about loadvm commands yet :)
It doesn't work out-of-the-box for all systems, that's right.

> Futhermore, how will the guest tools know that they are really running
> under
> qemu?

They know if they can connect to a specific port on the host. I'm more
concerned about hostile (redmondian) OSes which don't like being started in
Qemu and which can detect this by connecting to the host...

> 
> > Currently it's indeed only a bad version of mpcb :) but I hope it will 
> > evolve in another direction (copy and paste being just a small part of 
> > its features).
> > 
> 
> Agreed. That would benefit everyone.
> 
> > 
> > I've decided against some special i/o port or such because I don't know 
> > anything about these things :) and because it would require a driver on 
> > the guest side (is that correct?).
> 
> Unfortuantly, yes. However, the magic instruction set would not. (You
> would
> probably need to reimplement a new one for each arch qemu supports/will be
> ported to though.)

Yes, the issue of writing a driver for each new OS made me see TCP/IP as a
quite good solution; the communication part should run on every OS which
supports BSD sockets (in worked nearly unmodified in Windows), so porting is
reduced to a simple userland application, without connection to external
protocols etc.

> 
> > TCP/IP drivers are available for many 
> > platforms, and I think if an OS doesn't support TCP/IP it doesn't really
> > matter if copy/paste doesn't work.
> > 
> 
> I disagree here (not about the copy/paste specificly, but for guest tools
> in general). Drag&drop would have no meaning for an OS that doesn't
> support
> a mouse, let alone a GUI, but certain things such as time sync and loadvm
> notification could be accessed and used universally.

Yes, you're right here. I mainly concentrated on copy/paste during QGT
development (which I thought would be useful for copying URLs from Linux to
IE and such things), but time sync etc. could be useful also on simpler OSes
like DOS.
I'll have a look at the current QGT networking API and see if it can be
generalized a bit more, so that it can be replaced with another way of
communication later.

> 
> > Accelerated graphics would be nice indeed, but shouldn't that be done in
> > a separate driver? Not sure if such an optional user-space application 
> > is the right place for this.
> 
> You are probably right about that. I was simply saying that an accelerated
> graphics driver for a qemu guest would need to talk to qemu directly in
> the
> same way the qemu guest tools would (send qemu little messages telling it
> to
> open an opengl window and draw this guy here, this other guy there, this
> gun
> up there, etc). On the other hand, they probably should not share the same
> channel, as that would be too slow.

I agree, hardware accelerated games in Qemu would be really nice :)
But using TCP/IP for that will probably really be too slow... Maybe if one
could write a graphics driver which (as a first start) would tell the guest
it supports OpenGL, and which then simply passes all OpenGL calls to the
host (and the guest OpenGL window is then just some other window on top of
Qemu's SDL window)... But I'll better leave working wonders to Fabrice and
concentrate on the tasks I've already started :)

> 
> > 
> > After all, QGT should just be a collection of those features that cannot
> > be integrated into a hardware+driver (which is generally a cleaner way).
> > 
> 
> Agreed.
> 
> > 
> > Thanks for your input,
> > Oliver Gerlich
> > 
> > 
> > 
> > _______________________________________________
> > Qemu-devel mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/qemu-devel
> > 
> 
> -- 
> Infinite complexity begets infinite beauty.
> Infinite precision begets infinite perfection.
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

It's good to hear some other ideas and opinions about what's important.

Oliver Gerlich

PS: nearly forgot to mention that there were "technical problems" with my
webspace... I've moved QGT to http://wolfpackally.wo.funpic.de/qemu/qgt/ ,
if you couldn't download it before, it should work now.

-- 
DSL Komplett von GMX +++ Supergünstig und stressfrei einsteigen!
AKTION "Kein Einrichtungspreis" nutzen: http://www.gmx.net/de/go/dsl