qemu-ppc
[Top][All Lists]
Advanced

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

Re: [Qemu-ppc] [PATCH] spapr: add "compat" machine option


From: Igor Mammedov
Subject: Re: [Qemu-ppc] [PATCH] spapr: add "compat" machine option
Date: Wed, 6 Nov 2013 12:36:16 +0100

On Tue, 05 Nov 2013 14:53:14 +0100
Andreas Färber <address@hidden> wrote:

> Am 05.11.2013 10:52, schrieb Paolo Bonzini:
> > Il 05/11/2013 10:16, Alexander Graf ha scritto:
> >>
> >> On 05.11.2013, at 10:06, Paolo Bonzini <address@hidden> wrote:
> >>
> >>> Il 30/09/2013 14:57, Alexey Kardashevskiy ha scritto:
> >>>>>> Why is the option under -machine instead of -cpu?
> >>>> Because it is still the same CPU and the guest will still read the real
> >>>> PVR from the hardware (which it may not support but this is why we need
> >>>> compatibility mode).
> >>>
> >>> How do you support migration from a newer to an older CPU then?  I think
> >>> the guest should never see anything about the hardware CPU model.
> >>
> >> POWER can't model that. It always leaks the host CPU information into the 
> >> guest. It's the guest kernel's responsibility to not expose that change to 
> >> user space.
> >>
> >> Yes, it's broken :). I'm not even sure there is any sensible way to do 
> >> live migration between different CPU types.
> > 
> > Still in my opinion it should be "-cpu", not "-machine".  Even if it's
> > just a "virtual" CPU model.
> 
> PowerPC currently does not have -cpu option parsing. If you need to
> implement it, I would ask for a generic hook in CPUClass set by
> TYPE_POWERPC_CPU, so that the logic does not get hardcoded in cpu_init,
> and for the p=v parsing logic to be so generic as to just set property p
> to value v on the CPU instance. I.e. please make the compatibility
> settings a static property or dynamic property of the CPU.
Seconded, that's what is on my to-do list for x86 once x86 properties series
is applied.

moreover, all hook has to do is to translate -cpu to a set of global options,
adding [CPUtype.foo, val] pairs to global option list. Then options will be
automatically applied to any new instance of CPUtype and there won't be any
need for accessing/storing cpu_model string during cpu creation and hotplug.

> 
> Maybe the parsing code could even live in generic qom/cpu.c, overridden
> by x86/sparc and reused for arm? Somewhere down my to-do list but
> patches appreciated...
> 
> Andreas
> 




reply via email to

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