On Thu, May 04, 2017 at 04:33:28PM +0200, Radim Krčmář wrote:
> 2017-05-04 12:58+0200, Paolo Bonzini:
> > On 03/05/2017 21:37, Radim Krčmář wrote:
> >> The guest can call MWAIT with ECX = 0 even if we enforce
> >> CPUID5_ECX_INTERRUPT_BREAK; the call would have the exactly the same
> >> effect as if the host didn't have CPUID5_ECX_INTERRUPT_BREAK.
> >>
> >> The check was added in some iteration while trying to fix a reported
> >> OS X on Core 2 bug, but the CPU had CPUID5_ECX_INTERRUPT_BREAK and the
> >> bug is elsewhere.
> >
> > The reason for this, as I understood it, is that we have historically
> > not published leaf 5 information via KVM_GET_SUPPORTED_CPUID. For this
> > reason, QEMU is publishing CPUID5_ECX_INTERRUPT_BREAK. Then if:
>
> I see, it was added to QEMU in e737b32a3688 ("Core 2 Duo specification
> (Alexander Graf)").
>
> > - the host doesn't have ECX[0]=1 support
> >
> > - the guest sets ECX[0]
> >
> > you get a #GP in the guest. So wrong comment but right thing to do.
>
> That userspace didn't set CPUID.01H:ECX.MONITOR[bit 3], so a guest
> should get #UD instead, but MWAIT couldn't be expected to work.
>
> I think that the guest bug is very unlikely, so I'd get rid of the
> condition anyway ... we have also recently killed support for pre-Core 2
> hosts and AFAIK, all newer Intels have it.
That's a strange approach. If other software followed the same logic,
it would say all newer intels have MWAIT support without
checking the MWAIT leaf :)
> (Not so sure about AMDs, which share the same problem, so we do need to
> do more than just comment it better in any case.)
--
MST
