On Fri, Oct 09, 2009 at 08:43:59AM +0200, Michael S. Tsirkin wrote: > 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<mst@xxxxxxxxxx> > > > >> > > > >>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. > How do you know it is not uncommon (or happens at all?) If BIOS is not shadowed it runs directly from ROM. Hard to use self-modifying code there. > We should fix qemu to re-read bios from flash. > Makes sense? > We have option_rom_setup_reset() already. Don't we use it for BIOSes too? > 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 > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
