qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] target-i386: n270 can MOVBE


From: Eduardo Habkost
Subject: Re: [Qemu-devel] [PATCH] target-i386: n270 can MOVBE
Date: Fri, 8 Feb 2013 13:58:58 -0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Fri, Feb 08, 2013 at 04:34:58PM +0100, Borislav Petkov wrote:
> On Fri, Feb 08, 2013 at 01:19:02PM -0200, Eduardo Habkost wrote:
> > "-machine pc-1.3 -cpu n270" (and older machine-types) needs to keep
> > MOVBE disabled, or you will break live migration.
> >
> > Personally I wouldn't mind declaring n270 as a non-migratable CPU
> > model. But libvirt supports n270, so it already expects n270 to expose
> > a stable ABI on each machine-type.
> 
> From looking at the code - and I've never looked at qemu code before
> last night - we could filter migration features in x86_cpu_realize()
> when called down the pc_init1() path.

x86_cpu_realize() is too late, as it would make "-cpu n270,-movbe" fail
to disable the feature. The features need to be be initialized properly
before cpu_x86_parse_featurestr(), on cpu_x86_register().

> 
> We simply need to look the QEMUMachine.is_default flag and leave the
> feature on only if pc-1.4 which sets the is_default thing.

is_default has nothing to do with it. If we enable MOVBE on pc-1.4,
pc-1.4 will need to keep MOVBE enabled forever, it doesn't matter if it
is the default machine-type or not.

> 
> Or is there a more preferred way to do that?

pc_init_pci_1_3() needs to ask the CPU code to disable MOVBE on n270.

As we don't have a decent method to do that today, we are using static
variables and compatibility-setup functions called from the machine init
function. See disable_kvm_pv_eoi() for example.

One day we will be able to do that using properties on the machine-type
compat_props tables, but we can't do that yet.

People can easily work around the lack of the feature today, using
"-cpu n270,+movbe", so I believe it is worth waiting a little bit and
fixing this on QEMU 1.5, when we will (hopefully) have a decent
compatibility system based on compat_props.

-- 
Eduardo



reply via email to

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