Re: [PATCH v2] kvm: x86: emulate monitor and mwait instructions as nop

Gabriel L. Somlo
2014-06-04T19:24:09Z

On Wed, Jun 04, 2014 at 10:06:18PM +0300, Michael S. Tsirkin wrote:
> On Wed, Jun 04, 2014 at 01:07:21PM -0400, Gabriel L. Somlo wrote:
> > Ah, so kvm_vcpu_ioctl_set_cpuid() and friends, morally similar to
> > kvm_vcpu_ioctl_enable_cap() on ppc, except it turns on cpuid flags
> > instead of entire kvm capabilities.
> >
> > So we either have
> >
> > 1 always-on but masked-by-default monitor/mwait as
> > nop, and enable just the cpuid flag on demand via the
> > existing ioctl_enable_cap() mechanism (and I have to
> > check out the qemu parser for cpuid command-line flags),
> >
> > or
> >
> > 2 off-by-default monitor/mwait/cpuid-flag, enabled via
> > ioctl_enable_cap(), which would have to first be ported
> > to x86, and would require somewhat more extensive qemu
> > hackery to take advantage of.
> >
> > I think I sense a "path of least resistance" here, even though IMHO
> > #2 is still "The Right Thing To Do (TM)" :) :)
> >
> > Thanks,
> > --Gabriel
>
> I think it's worng.
> We really can't emulate mwait at the moment.
> All we manage to do is a work-around for broken guests.
>
> So let's not pretend that we can, just enable nop
> unconditionally and be done with it.
> Paolo already said it's OK with him, and I'll ack too.
>
> Otherwise you are giving bad information to well-behaved guests,
> so e.g. linux will try to use mwait. You don't want this.

That's why I suggested having it default to disabled, and only
allowing it to be turned on per VM, explicitly.

> The advantage is that if at some point CPUs can
> actually support mwait in VMs, at that point
> we will enable the CPUID bit, and userspace and guests
> will be able to detect that and rely on that bit
> to mean "mwait works and is efficient".

OK, that makes sense. Thanks for helping me finally get over it ;)

--Gabriel