Re: [RFC PATCH] Emulate MOVBE

2013-04-17 Thread Gleb Natapov
On Wed, Apr 17, 2013 at 12:42:30PM +0200, Paolo Bonzini wrote: > Il 16/04/2013 19:28, Gleb Natapov ha scritto: > > > This does highlight a weakness in CPU_GET_SUPPORTED_CPUID, but I think > > > this is not a problem in practice. > > > > > > With a management layer such as oVirt it's not a problem.

Re: [RFC PATCH] Emulate MOVBE

2013-04-17 Thread Paolo Bonzini
Il 16/04/2013 19:28, Gleb Natapov ha scritto: > > This does highlight a weakness in CPU_GET_SUPPORTED_CPUID, but I think > > this is not a problem in practice. > > > > With a management layer such as oVirt it's not a problem. For example, > > oVirt has its own library of processors. It doesn't c

Re: [RFC PATCH] Emulate MOVBE

2013-04-16 Thread Gleb Natapov
On Tue, Apr 16, 2013 at 01:47:46PM +0200, Paolo Bonzini wrote: > Il 10/04/2013 12:08, Gleb Natapov ha scritto: > >> > 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 fix

Re: [RFC PATCH] Emulate MOVBE

2013-04-16 Thread H. Peter Anvin
Note that "Atom" isn't a CPU but a line of CPUs. Sadly Qemu's N270 model is broken. Borislav Petkov wrote: >On Tue, Apr 16, 2013 at 01:47:46PM +0200, Paolo Bonzini wrote: >> Atom is not defined by QEMU; > >$ qemu-system-x86_64 -cpu ? > >... > >x86 n270 Intel(R) Atom(TM) CPU N270

Re: [RFC PATCH] Emulate MOVBE

2013-04-16 Thread Borislav Petkov
On Tue, Apr 16, 2013 at 01:47:46PM +0200, Paolo Bonzini wrote: > Atom is not defined by QEMU; $ qemu-system-x86_64 -cpu ? ... x86 n270 Intel(R) Atom(TM) CPU N270 @ 1.60GHz -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe

Re: [RFC PATCH] Emulate MOVBE

2013-04-16 Thread Paolo Bonzini
Il 10/04/2013 12:08, Gleb Natapov ha scritto: >> > 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

Re: [RFC PATCH] Emulate MOVBE

2013-04-10 Thread Gleb Natapov
On Wed, Apr 10, 2013 at 12:39:01PM +0200, Andre Przywara wrote: > On Wed, 10 Apr 2013 13:08:46 +0300 > Gleb Natapov 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

Re: [RFC PATCH] Emulate MOVBE

2013-04-10 Thread Andre Przywara
On Wed, 10 Apr 2013 13:08:46 +0300 Gleb Natapov 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 pur

Re: [RFC PATCH] Emulate MOVBE

2013-04-10 Thread Gleb Natapov
On Wed, Apr 10, 2013 at 12:17:21PM +0200, Borislav Petkov wrote: > On Wed, Apr 10, 2013 at 01:08:46PM +0300, Gleb Natapov wrote: > > 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

Re: [RFC PATCH] Emulate MOVBE

2013-04-10 Thread Borislav Petkov
On Wed, Apr 10, 2013 at 01:08:46PM +0300, Gleb Natapov wrote: > 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

Re: [RFC PATCH] Emulate MOVBE

2013-04-10 Thread Gleb Natapov
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. > What is the opin

Re: [RFC PATCH] Emulate MOVBE

2013-04-10 Thread Borislav Petkov
On Tue, Apr 09, 2013 at 05:04:06PM -0700, H. Peter Anvin wrote: > On 04/09/2013 05:03 PM, Borislav Petkov wrote: > > > > Note to self: this destroys the src operand but it shouldn't. Fix it > > tomorrow. > > > > I thought movbe was already in qemu just not on by default...? Yep, this went upstr

Re: [RFC PATCH] Emulate MOVBE

2013-04-10 Thread Andre Przywara
On Wed, 10 Apr 2013 01:46:02 +0200 Borislav Petkov wrote: > Hi guys, > > so I was trying to repro tglx's bug in smpboot.c and for some reason, > the most reliable way to trigger it was to boot an 32-bit atom smp > guest in kvm (don't ask :)). > > The problem, however, was that atom wants MOVBE

Re: [RFC PATCH] Emulate MOVBE

2013-04-09 Thread H. Peter Anvin
On 04/09/2013 05:03 PM, Borislav Petkov wrote: > > Note to self: this destroys the src operand but it shouldn't. Fix it > tomorrow. > I thought movbe was already in qemu just not on by default...? -hpa -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a m

Re: [RFC PATCH] Emulate MOVBE

2013-04-09 Thread Borislav Petkov
On Wed, Apr 10, 2013 at 01:46:02AM +0200, Borislav Petkov wrote: > +static int em_movbe(struct x86_emulate_ctxt *ctxt) > +{ > + char *valptr = ctxt->src.valptr; > + > + switch (ctxt->op_bytes) { > + case 2: > + *(u16 *)valptr = swab16(*(u16 *)valptr); > + break;

[RFC PATCH] Emulate MOVBE

2013-04-09 Thread Borislav Petkov
Hi guys, so I was trying to repro tglx's bug in smpboot.c and for some reason, the most reliable way to trigger it was to boot an 32-bit atom smp guest in kvm (don't ask :)). The problem, however, was that atom wants MOVBE and qemu doesn't emulate it yet (except Richard's patches which I used in