Re: [Qemu-devel] Qemu Guest Tools

[Jim C. Brown]

On Wed, Mar 02, 2005 at 10:08:54PM +0100, address@hidden wrote:
> > 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.

I must eat my own words.

Last I checked, it was not possible to set the time in the guest (this was with
Windows 98SE). The clock would switch back immediately. Testing with linux guest
and modern qemu, this seems to have changed. Using hwclock, one can change the
time of the RTC.

So you can use ntp as a time keeper for the guest after all.

> > 
> > > -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.
> 

The bug being that qemu didn't update the RTC properly on a loadvm. Since there
was no way for the guest OS to change the time, qemu had to get it right
unconditionally.

However, if you can set it directly, then this would be a good use. You'd
want this as a continuous background process (daemon in Unix/Linux, TSR in DOS)
to make this update automatic.

> > 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...
> 

How do you know that port is being used by qemu, and not by e.g. some custom
http server?

One interesting side effect is that one could install the guest tools on a
real workstation and set up a fake server that responds to qemu guest commands.
I'm not sure if you want to allow this to be possible. (I also don't see why
anyone would bother with it ... but since the guest tools interact with the
guest on such a low level, who knows what they could be used for?)

> > > 
> > > 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.

The magic instruction set has the same advantages, plus it doesn't require
TCP/IP. Of course it can always be added later.

The real issue I have with using TCP/IP is that one can trick a qemu guest into
thinking its host is this other computer, or even trick the guest tools when
they are running on actual hardware.

> > 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.
> 

Now that I think of it, using TCP/IP to flesh out a suitable API/list of
guest commands (i.e. the qemu<->guest communication protocol semantics)
and then moving it over to use a more precise/reliable method of communication
(such as a qemu-specific io port) is probably a good idea. Might make 
development
go significantly faster.

A combination of methods may be best.

> I agree, hardware accelerated games in Qemu would be really nice :)
> But using TCP/IP for that will probably really be too slow...

I didn't suggest that! Honest!

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.