qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Qemu-devel] Qemu Guest Tools


From: Nathan Kunkee
Subject: RE: [Qemu-devel] Qemu Guest Tools
Date: Fri, 04 Mar 2005 21:50:29 -0600

>Message: 3
>Date: Thu, 03 Mar 2005 08:24:12 +0400
>From: Brad Campbell <address@hidden>
>Subject: Re: [Qemu-devel] Qemu Guest Tools
>To: address@hidden
>Message-ID: <address@hidden>
>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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]