From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 16A63ECE58C for ; Wed, 9 Oct 2019 22:41:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E72F5218AC for ; Wed, 9 Oct 2019 22:41:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1570660895; bh=luGiKPn3ZU8w68DlafUoK10zfzRgHpkeep6teIAuOgQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=FHdcvo2pb7sVM7ESC/juAoWOIx9xu1VdTJzEk757KdgAayXnb0ygme9XojyOzGVlA JIGZS0+Ek2pKgvLFJDh7aJp/6pus2kD0euLAiiAq+c/1qnyRQ1p66Bjvmaj7w+OvkQ +2dHLwiZzuJiQgNZK9cw0IoKp0WpAOJsLdnjRPiY= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732422AbfJIWlb (ORCPT ); Wed, 9 Oct 2019 18:41:31 -0400 Received: from mail.kernel.org ([198.145.29.99]:58870 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731763AbfJIWlb (ORCPT ); Wed, 9 Oct 2019 18:41:31 -0400 Received: from localhost (unknown [167.220.2.234]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 57856206A1; Wed, 9 Oct 2019 22:41:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1570660890; bh=luGiKPn3ZU8w68DlafUoK10zfzRgHpkeep6teIAuOgQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Rc+irKPrpeqwQXpHSoFE706kLoxQRqfJ4NCeM0WtUSQT+q5uICxdJzogjbqxY5P3j JkMocUaDBVj+nyR0jXTypZNF+enLHpy30f3R84LqUesXoViZZzLzsvuR7mK8KX6St2 5xJzqjsa/nm2GLyP0YOcVKzcyNj0mNo7z2JFWBmg= Date: Wed, 9 Oct 2019 18:41:29 -0400 From: Sasha Levin To: Paolo Bonzini Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org, Jim Mattson , Marc Orr , Peter Shier , Jacob Xu , Sean Christopherson , kvm@vger.kernel.org Subject: Re: [PATCH AUTOSEL 4.19 08/26] kvm: x86: Improve emulation of CPUID leaves 0BH and 1FH Message-ID: <20191009224129.GX1396@sasha-vm> References: <20191009170558.32517-1-sashal@kernel.org> <20191009170558.32517-8-sashal@kernel.org> <5fcb0e38-3542-dd39-6a1c-449b4f9f435e@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <5fcb0e38-3542-dd39-6a1c-449b4f9f435e@redhat.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Wed, Oct 09, 2019 at 10:58:35PM +0200, Paolo Bonzini wrote: >On 09/10/19 19:05, Sasha Levin wrote: >> From: Jim Mattson >> >> [ Upstream commit 43561123ab3759eb6ff47693aec1a307af0aef83 ] >> >> For these CPUID leaves, the EDX output is not dependent on the ECX >> input (i.e. the SIGNIFCANT_INDEX flag doesn't apply to >> EDX). Furthermore, the low byte of the ECX output is always identical >> to the low byte of the ECX input. KVM does not produce the correct ECX >> and EDX outputs for any undefined subleaves beyond the first. >> >> Special-case these CPUID leaves in kvm_cpuid, so that the ECX and EDX >> outputs are properly generated for all undefined subleaves. >> >> Fixes: 0771671749b59a ("KVM: Enhance guest cpuid management") >> Fixes: a87f2d3a6eadab ("KVM: x86: Add Intel CPUID.1F cpuid emulation support") >> Signed-off-by: Jim Mattson >> Reviewed-by: Marc Orr >> Reviewed-by: Peter Shier >> Reviewed-by: Jacob Xu >> Cc: Sean Christopherson >> Cc: Paolo Bonzini >> Signed-off-by: Paolo Bonzini >> Signed-off-by: Sasha Levin >> --- >> arch/x86/kvm/cpuid.c | 83 +++++++++++++++++++++++++------------------- >> 1 file changed, 47 insertions(+), 36 deletions(-) > >This is absolutely not stable material. Is it possible for KVM to opt >out of this AUTOSEL nonsense? Sure, I've opted out KVM and removed all KVM patches from this series: c1fac4516a61d kvm: vmx: Limit guest PMCs to those supported on the host 75b118586ec81 kvm: x86, powerpc: do not allow clearing largepages debugfs entry 06cd1710feaed KVM: VMX: Set VMENTER_L1D_FLUSH_NOT_REQUIRED if !X86_BUG_L1TF c89fc5c082aa6 KVM: x86: Expose XSAVEERPTR to the guest 1eec6b4068e2e kvm: x86: Use AMD CPUID semantics for AMD vCPUs 5c56e6ba0afc8 kvm: x86: Improve emulation of CPUID leaves 0BH and 1FH 94a3c6f010bd2 kvm: x86: Fix a spurious -E2BIG in __do_cpuid_func 79a7ad6330bc5 KVM: arm/arm64: vgic: Use the appropriate TRACE_INCLUDE_PATH -- Thanks, Sasha