2015-06-18 12:50-0300, Eduardo Habkost:
> On Thu, Jun 18, 2015 at 05:24:24PM +0200, Radim Krčmář wrote:
> > We already bump to level 7 if features there are requested, so do the
> > same for 0xD.
> >
> > Signed-off-by: Radim Krčmář <rkrc...@redhat.com>
>
> This breaks guest ABI and live-migration, as CPUID data is not part of
> the migration stream (although we have considered including it in the
> future).
>
> If we are going to add more special cases like this, we must provide a
> way to make QEMU honour an explicit "level" option from the config file
> or command-line.
Thanks, I'll drop this patch.
> I have considered introducing "min-[x]level" and "max-{x]level"
> properties to control automatic increasing of level/xlevel. The existing
> X86CPUDefinition.level field could just control min_level, while
> explicit "level=" on the command-line or config file would explicitly
> force a specific value. Probably setting "max-level" on machine-type
> compat code would be enough to restore the previous behavior.
We'd need to set min-level at least to 7, to capture the raising we do
now, but a feature in level between default and 7 would result in a
different behavior, so we need to make it much uglier :/
We can add 'compat-level' bit for old machine types and raise to highest
habited function otherwise, optionally with controls you described.
