qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH for-1.6] pc: fix up pc initialization


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH for-1.6] pc: fix up pc initialization
Date: Tue, 13 Aug 2013 18:18:18 +0300

On Tue, Aug 13, 2013 at 05:11:08PM +0200, Andreas Färber wrote:
> Am 13.08.2013 16:54, schrieb Paolo Bonzini:
> > Il 13/08/2013 16:11, Anthony Liguori ha scritto:
> >>>> Fix this up, clean up a trivial code duplication
> >>>> and add a comment explaining why we special-case 1.5
> >>>> with respect to pvpanic.
> >>>>
> >>>> Reported-by: Markus Armbruster <address@hidden>
> >>>> Signed-off-by: Michael S. Tsirkin <address@hidden>
> >> Thanks for catching this.  I'm a little disturbed by this.  I use git-am
> >> --3way specifically to avoid problems from fuzzing but I guess merge
> >> artifacts are possible.
> >>
> > 
> > I wonder if we shouldn't disable pvpanic in 1.5 too, one-off behavior is
> > ugly and likely no one will notice.
> 
> I had rejected the previous attempt to completely disable pvpanic device
> because it looked to me as if this compatibility aspect had been
> forgotten. I didn't imagine the resulting code to look as ugly though,
> with us "skipping" _1_5 to not have 1.5 overwrite has_pvpanic for 1.6+.
> 
> mst suggested to patch stable-1.5 to disable it there, too. I am not
> against but have doubts as to how well that works with migration, since
> 1.5.3 is still a bit off and I would expect 1.5.2 -> 1.6.0 migration to
> work without guest-visible changes... We could argue that having to use
> -M pc-i440fx-1.5 we can also expect users to add -device pvpanic;
> question would be how to convey that knowledge of
> if-you-use-pc-x.y-then-you-also-need-to-do-Z to users, which
> compat_props usually handle under the hood. We could misuse
> pvpanic.ioport=0 for that purpose until we have a better solution.
> 
> Regards,
> Andreas

Well, in this case then this boils down to 1.5.2 migration being buggy -
having a small race (migration during reset) which we can then close
with 1.5.3 .
I don't think anyone ever triggered this race in practice so I'm not
sure whether we should be too worried about this.


> -- 
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



reply via email to

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