From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [PATCH 3/4] KVM: x86: drop bogus MWAIT check Date: Thu, 4 May 2017 21:29:49 +0300 Message-ID: <20170504212650-mutt-send-email-mst@kernel.org> References: <20170503193733.13409-1-rkrcmar@redhat.com> <20170503193733.13409-4-rkrcmar@redhat.com> <638dd02c-102a-21d8-7a10-30a3ef3c357d@redhat.com> <20170504143328.GB26642@potion> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: Paolo Bonzini , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Alexander Graf , "Gabriel L. Somlo" To: Radim =?utf-8?B?S3LEjW3DocWZ?= Return-path: Received: from mx1.redhat.com ([209.132.183.28]:34236 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755761AbdEDS3v (ORCPT ); Thu, 4 May 2017 14:29:51 -0400 Content-Disposition: inline In-Reply-To: <20170504143328.GB26642@potion> Sender: kvm-owner@vger.kernel.org List-ID: 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