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: Herbert Poetzl
Subject: Re: [Qemu-devel] Qemu Guest Tools
Date: Sat, 5 Mar 2005 05:22:42 +0100
User-agent: Mutt/1.4.1i

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

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




reply via email to

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