Re: [RFC PATCH] Emulate MOVBE

[Gleb Natapov <gleb@redhat.com>]

On Wed, Apr 10, 2013 at 12:39:01PM +0200, Andre Przywara wrote:
> On Wed, 10 Apr 2013 13:08:46 +0300
> Gleb Natapov <gleb@redhat.com> wrote:
> 
> > On Wed, Apr 10, 2013 at 11:29:42AM +0200, Andre Przywara wrote:
> > > In a real world VendorSpecific should be replaced with something
> > > more meaningful. Depends on KVMs intention to emulate instructions,
> > > actually out of scope for a pure virtualizer.
> > > 
> > Something like EmulateOnUD.
> 
> Right.
> 
> > > What is the opinion from the KVM folks on this? Shall we start to
> > > emulate instructions the host does not provide? In this particular
> > > case a relatively simple patch fixes a problem (starting Atom
> > > optimized kernels on non-Atom machines).
> > We can add the emulation, but we should not start announcing the
> > instruction availability to a guest if host cpu does not have it by
> > default. This may trick a guest into thinking that movbe is the
> > fastest way to do something when it is not.
> 
> Good point. I'd also like to have a switch which enables this kind of
> "non-standard" behavior. Actually this should be requested by QEMU,
> right? So that a single guest can override the CPUID masking done by
> the kernel if it really really wants to.
>  
Right, the question is how kernel can tell QEMU that the cpuid bit is
supported but should not be set unless explicitly asked by an user.
 
> > > 
> > > (And if one can believe the AMD Fam16h SWOG [1], PS4^Wfuture AMD
> > > processors have MOVBE, so it's not even actually one CPU anymore).
> > If a host CPU has the instruction emulation is not needed unless the
> > instruction is used for MMIO access.
> 
> I meant to "emulate" such a CPU. -cpu ps4 ;-)
> 
Ah, OK.

--
			Gleb.