qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Re: [PATCH 2/3] qemu: make cirrus init value pci spec c


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] Re: [PATCH 2/3] qemu: make cirrus init value pci spec compliant
Date: Fri, 9 Oct 2009 08:43:59 +0200
User-agent: Mutt/1.5.19 (2009-01-05)

On Thu, Oct 08, 2009 at 07:40:12PM +0100, Jamie Lokier wrote:
> Avi Kivity wrote:
> > On 10/08/2009 06:06 PM, Michael S. Tsirkin wrote:
> > >On Thu, Oct 08, 2009 at 05:29:29PM +0200, Avi Kivity wrote:
> > >   
> > >>On 10/08/2009 04:52 PM, Michael S. Tsirkin wrote:
> > >>     
> > >>>PCI memory should be disabled at reset, otherwise
> > >>>we might claim transactions at address 0.
> > >>>I/O should also be disabled, although for cirrus
> > >>>it is harmless to enable it as we do not
> > >>>have I/O bar.
> > >>>
> > >>>Note: need bios fix for this patch to work:
> > >>>currently pc-bios incorrently assumes that it does not
> > >>>need to enable i/o unless device has i/o bar.
> > >>>
> > >>>Signed-off-by: Michael S. Tsirkin<address@hidden>
> > >>
> > >>This needs to be conditional on the machine type.  Old machines must
> > >>retain this code for live migration to work (we need to live migrate the
> > >>bios, so we can't assume the bios fix is in during live migration from
> > >>older qemus).
> > >>     
> > >No, if you migrate from older qemu you will be fine as command
> > >is enabled there on init.
> > >   
> > 
> > Right.
> 
> No, I think Avi was right the first time.
> 
> Migrating from an older qemu will be fine at first, but at the next
> reset _following_ migration, it'll be running the old BIOS on a new
> qemu and fail.
> 
> -- Jamie

I think this just means that there's another bug.
On reset BIOS should be re-read from flash.
qemu instead keeps it in RAM, this means that if
guest corrupts it, or BIOS itself runs self-modifying
code (which is not uncommon btw), bad things happen.

We should fix qemu to re-read bios from flash.
Makes sense?

More long-term, we have duplication between reset and init
routines. Maybe devices really should have init and cleanup,
and on reset we'd cleanup all devices and then init them again?
There are cases where state needs to be persistent across
resets (VPD comes to mind) but these are rare,
and probably need to be backed by writing to file anyway?


-- 
MST





reply via email to

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