RE: [Qemu-devel] Qemu Guest Tools

RE: [Qemu-devel] Qemu Guest Tools

[Nathan Kunkee]

>Message: 3
>Date: Thu, 03 Mar 2005 08:24:12 +0400
>From: Brad Campbell <brad@wasp.net.au>
>Subject: Re: [Qemu-devel] Qemu Guest Tools
>To: qemu-devel@nongnu.org
>Message-ID: <4226916C.8050706@wasp.net.au>
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>Jim C. Brown wrote:
> > 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?
> >
> >
> >>-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.
> >
> > Of course, any way to set the time in qemu guest w/o having to 
patch qemu
> > source is welcome.
>
>I run an ntp client inside windows.
Another way to fix this, and the next concern on vm save/load, is to develop 
an APM or ACPI device. There is a standard interface between the hardware 
and the OS, almost all OS's now support a version of APM or ACPI, and the OS 
knows to reinitialize various parts of the hardware after certain events. 
This would simplify the question of special instructions or unused IO port. 
In a way, it would allow the emulator to be treated like a laptop, where the 
user can tell it to suspend or sleep, and when to wake up again. Since the 
OS has a driver for APM, it would be aware of these events, reinitialize 
devices (RTC, NIC), and Qemu would not be responsible for as many internal 
details.

My humble $0.02 on the issue....
Nathan


[snip]
> >>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.)
> >
>
>This was my thought. Networking is not always available. A couple of IO 
ports would always be there.
>
>Regards,
>Brad
>--
>"Human beings, who are almost unique in having the ability
>to learn from the experience of others, are also remarkable
>for their apparent disinclination to do so." -- Douglas Adams

Re: [Qemu-devel] Qemu Guest Tools

[Herbert Poetzl]

On Fri, Mar 04, 2005 at 09:50:29PM -0600, Nathan Kunkee wrote:
> >Message: 3
> >Date: Thu, 03 Mar 2005 08:24:12 +0400
> >From: Brad Campbell <brad@wasp.net.au>
> >Subject: Re: [Qemu-devel] Qemu Guest Tools
> >To: qemu-devel@nongnu.org
> >Message-ID: <4226916C.8050706@wasp.net.au>
> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> >
> >Jim C. Brown wrote:
> > > 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?
> > >
> > >
> > >>-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.
> > >
> > > Of course, any way to set the time in qemu guest w/o having to 
> patch qemu
> > > source is welcome.
> >
> >I run an ntp client inside windows.
> Another way to fix this, and the next concern on vm save/load, is to 
> develop an APM or ACPI device. There is a standard interface between the 
> hardware and the OS, almost all OS's now support a version of APM or ACPI, 
> and the OS knows to reinitialize various parts of the hardware after 
> certain events. This would simplify the question of special instructions or 
> unused IO port. In a way, it would allow the emulator to be treated like a 
> laptop, where the user can tell it to suspend or sleep, and when to wake up 
> again. Since the OS has a driver for APM, it would be aware of these 
> events, reinitialize devices (RTC, NIC), and Qemu would not be responsible 
> for as many internal details.
> 
> My humble $0.02 on the issue....
> Nathan

cool, never saw such a messed up email before ...

is this a new Microsoft(TM,R)/Hotmail feature?

best,
Herbert

> 
> 
> [snip]
> > >>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.)
> > >
> >
> >This was my thought. Networking is not always available. A couple of IO 
> ports would always be there.
> >
> >Regards,
> >Brad
> >--
> >"Human beings, who are almost unique in having the ability
> >to learn from the experience of others, are also remarkable
> >for their apparent disinclination to do so." -- Douglas Adams
> 
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Qemu Guest Tools

[Oliver Gerlich]

Nathan Kunkee schrieb:

> Another way to fix this, and the next concern on vm save/load, is to 
> develop an APM or ACPI device. There is a standard interface between 
> the hardware and the OS, almost all OS's now support a version of APM 
> or ACPI, and the OS knows to reinitialize various parts of the 
> hardware after certain events. This would simplify the question of 
> special instructions or unused IO port. In a way, it would allow the 
> emulator to be treated like a laptop, where the user can tell it to 
> suspend or sleep, and when to wake up again. Since the OS has a driver 
> for APM, it would be aware of these events, reinitialize devices (RTC, 
> NIC), and Qemu would not be responsible for as many internal details.
>
> My humble $0.02 on the issue....
> Nathan

ACPI support in Qemu would be nice; but loadvm is useful for those guest 
OSes that don't support ACPI or sleep states. So in my opinion loadvm 
should not be replaced by ACPI, but it should be usable in those cases 
where ACPI or sleep states are not available (eg. Win9x, DOS).

Oliver

[Qemu-devel] Qemu Guest Tools

[olig9]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 411 bytes --]

Hello,
to enable copying of text between Qemu host and guest, I've started to write
some small apps called QGT (Qemu Guest Tools). A very early version is
available at http://www.oliver-gerlich.de/qemu/ . Please have a look at it
and tell me your opinion.

Oliver Gerlich

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

Re: [Qemu-devel] Qemu Guest Tools

[Joshua Kugler]

There is a program out there under the GPL called "multi platform clipboard," 
although it's not fully transparent.

http://www.idata.sk/~robo/mpcb/

I've used this, and it works nicely.  The site seems down at the moment, but 
there is more info here:

http://www.icewalkers.com/Linux/Software/511140/mpcb.html

Might help you along in your project.

On Tuesday 01 March 2005 14:07, olig9@gmx.de wrote:
> Hello,
> to enable copying of text between Qemu host and guest, I've started to
> write some small apps called QGT (Qemu Guest Tools). A very early version
> is available at http://www.oliver-gerlich.de/qemu/ . Please have a look at
> it and tell me your opinion.
>
> Oliver Gerlich

-- 
Joshua Kugler
CDE System Administrator
http://distance.uaf.edu/

Re: [Qemu-devel] Qemu Guest Tools

[Jim C. Brown]

On Wed, Mar 02, 2005 at 12:07:44AM +0100, olig9@gmx.de wrote:
> Hello,
> to enable copying of text between Qemu host and guest, I've started to write
> some small apps called QGT (Qemu Guest Tools). A very early version is
> available at http://www.oliver-gerlich.de/qemu/ . Please have a look at it
> and tell me your opinion.
> 
> Oliver Gerlich
> 
> -- 
> DSL Komplett von GMX +++ Superg?nstig und stressfrei einsteigen!
> AKTION "Kein Einrichtungspreis" nutzen: http://www.gmx.net/de/go/dsl
> 

This is promising, but I think it is badly named. This looks likes that it could,
in theory, work across actual networks. There is another program which can be
used to share clipboards across networks, and it can be used from within qemu.
It can support multple workstations at once and it supports more OSes.

Looks good for a first version though. What other features are you planning
to add?

The project shouldn't be called Qemu Guest Tools unless it requires qemu, IMHO.
(Guest tools have been discussed before, some ideas for communication to qemu
itself would be via 'special' qemu specific instructions or alloting an io port
to give commands to qemu (this is what VMware does). Some ideas that have been
proposed to use this communication for: host-guest clipboard, accelerated
graphics support (such as 3d), a sort of two-way user-net (allow the host and
other workstations to see the guest w/o going thru tuntap ... not sure how
this would work). The list can get quite fancy.)

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

Re: [Qemu-devel] Qemu Guest Tools

[Mark Williamson]

> Some ideas that have been proposed to use this communication for:
> host-guest clipboard, accelerated graphics support (such as 3d), a sort of
> two-way user-net (allow the host and other workstations to see the guest
> w/o going thru tuntap ... not sure how this would work). The list can get
> quite fancy.)

MS Virtual PC can do drag 'n' drop between the guest and the host.  Whilst 
this is obviously just a "nice to have" feature, it's still pretty cool and 
is actually useful into the bargain ;-)

Cheers,
Mark

Re: [Qemu-devel] Qemu Guest Tools

[Oliver Gerlich]

Jim C. Brown wrote:
> On Wed, Mar 02, 2005 at 12:07:44AM +0100, olig9@gmx.de wrote:
> 
>>Hello,
>>to enable copying of text between Qemu host and guest, I've started to write
>>some small apps called QGT (Qemu Guest Tools). A very early version is
>>available at http://www.oliver-gerlich.de/qemu/ . Please have a look at it
>>and tell me your opinion.
>>
>>Oliver Gerlich
>>
>>-- 
>>DSL Komplett von GMX +++ Superg?nstig und stressfrei einsteigen!
>>AKTION "Kein Einrichtungspreis" nutzen: http://www.gmx.net/de/go/dsl
>>
> 
> 
> This is promising, but I think it is badly named. This looks likes that it could,
> in theory, work across actual networks. There is another program which can be
> used to share clipboards across networks, and it can be used from within qemu.
> It can support multple workstations at once and it supports more OSes.
> 
> Looks good for a first version though. What other features are you planning
> to add?

Planned features are:
-Notification of guest when it is loaded with loadvm
-Time synchronisation between host and guest (currently guest time is 
wrong when loadvm is used)
-drag and drop (Mark mentioned it, and it was also posted on the forum 
some days ago)
-make mouse grabbing more comfortable

Copy/paste and time sync could be done by external programs (Joshua 
mentioned mpcb; ntp, ...). But drag and drop requires access to the Qemu 
window, and loadvm notification requires some kind of integration with Qemu.
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).

> 
> The project shouldn't be called Qemu Guest Tools unless it requires qemu, IMHO.
> (Guest tools have been discussed before, some ideas for communication to qemu
> itself would be via 'special' qemu specific instructions or alloting an io port
> to give commands to qemu (this is what VMware does). Some ideas that have been
> proposed to use this communication for: host-guest clipboard, accelerated
> graphics support (such as 3d), a sort of two-way user-net (allow the host and
> other workstations to see the guest w/o going thru tuntap ... not sure how
> this would work). The list can get quite fancy.)
> 

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

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.

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


Thanks for your input,
Oliver Gerlich

Re: [Qemu-devel] Qemu Guest Tools

[Mark Williamson]

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

The code could always be hacked later to (optionally) use a magic IO port, as 
long as the base functionality is there, if anyone has an interest in doing 
so.

Cheers,
Mark

Re: [Qemu-devel] Qemu Guest Tools

[Jim C. Brown]

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?

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

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.

> 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?)

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

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

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

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

> 
> 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
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

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

Re: [Qemu-devel] Qemu Guest Tools

[olig9]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 6626 bytes --]

> 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
> > Qemu-devel@nongnu.org
> > http://lists.nongnu.org/mailman/listinfo/qemu-devel
> > 
> 
> -- 
> Infinite complexity begets infinite beauty.
> Infinite precision begets infinite perfection.
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> 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

Re: [Qemu-devel] Qemu Guest Tools

[Jim C. Brown]

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

Re: [Qemu-devel] Qemu Guest Tools

[Brad Campbell]

Jim C. Brown wrote:
> 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?
> 
> 
>>-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.
> 
> Of course, any way to set the time in qemu guest w/o having to patch qemu
> source is welcome.

I run an ntp client inside windows.

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

I was thinking about a little guest app to keep them in sync. This is how win4lin does it and it 
works very well. It is dead easy to do under windows as mouse manipulation from userspace is a 
doddle, don't know about linux though.

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

It does. I use anachron for windows.

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

This was my thought. Networking is not always available. A couple of IO ports would always be there.

Regards,
Brad
-- 
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams

Re: [Qemu-devel] Qemu Guest Tools

[Jim C. Brown]

On Thu, Mar 03, 2005 at 08:24:12AM +0400, Brad Campbell wrote:
> Jim C. Brown wrote:
> >
> >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).
> 
> I was thinking about a little guest app to keep them in sync. This is how 
> win4lin does it and it works very well. It is dead easy to do under windows 
> as mouse manipulation from userspace is a doddle, don't know about linux 
> though.
> 

Does it move the guest pointer back to the spot where the host pointer is (in
which case disabling mouse accerleration would be better) or does it let win4lin
know where the guest pointer is so the host pointer can be moved to that position?

The latter would be ideal, but short of guest-to-host communication there is no
way to be completely sure where the mouse pointer is (tho you can be pretty sure
most of the time).

> >
> >>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.)
> >
> 
> This was my thought. Networking is not always available. A couple of IO 
> ports would always be there.

Actually, I think that magic instructions might be better. It doesn't require
a special guest driver and thus it would be easier to develop the tools. IO
ports would be easier to standardize however.

Detecting whether or not they're running in qemu is also a cinch: if they aren't
they get an "illegal instruction" error.

> 
> Regards,
> Brad
> -- 
> "Human beings, who are almost unique in having the ability
> to learn from the experience of others, are also remarkable
> for their apparent disinclination to do so." -- Douglas Adams
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

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