[Top][All Lists]
[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
- Re: [Qemu-devel] Qemu Guest Tools, (continued)
RE: [Qemu-devel] Qemu Guest Tools, Nathan Kunkee, 2005/03/04