Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp3011108ybf; Mon, 2 Mar 2020 21:00:05 -0800 (PST) X-Google-Smtp-Source: ADFU+vtY9ujLCWKIg54CSfsGhieydZLRuFZ/OmkyrXL0dCFTPKDjP2DwUSRqDcwvSlN3l8qR/0pV X-Received: by 2002:a9d:6204:: with SMTP id g4mr2139214otj.94.1583211604883; Mon, 02 Mar 2020 21:00:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583211604; cv=none; d=google.com; s=arc-20160816; b=pqCgT9atJ5HIAhWEy4G22pSMWLtyTyn4abP1MVeK62tktTwytC6ptGN4H0uq2RtOBw c/KXNwkgTTBDG8+U0ZyV0n66aOHvHwh1MqU8UwhvYFc7SFR/3bUZP06eKpM1IhayAOQK A0tyvlc5YOzoMAtV2LGjjDqgIqhQMG2rzLKfMAZBzgYf/wKre3pBq5w8KmpGvq7be/n/ dqf+BYWxgorCa9+Jzs2XFRAetO3s+kUxQE6Iz4XO08X8Wuxr8jSoEnuUD/Yjx3xG+mn1 A8A78NR15cR8iCGMhJgwLwLGET74vWLyaA89CsggfCZab7v/+aRSj951hIMeq10T0r8a eBYg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=c8CBCKxcY5X/LZYDWyqZDof0La8VmJpwamfEZE12Lmw=; b=DU3Txgjx/1O3btUNs/QXBrC2pgklaC1HX5H9aHubxjQyK+P/PDlDT3y41PrzFB61q3 NT3rojlEGIkTE+rTG7cBkNMQvgDRyK/qVq8Ll2uP2YU2cXX+Fv9fg4zIZxX6I5JqkbHf 56PI8IBFWlL/KI2J98rvwcWeAiowjAQXoW8f0GZvuQq4JWSa3i0A4Y1HPNG3pWC/OiVU BCYMnUMlZ9SkW9e1/7OVWNPNNoAwiq4kJRK/8yndIPZd4efP1yWmY5xuiQQsQjbFmQvc ErREdFTOulwpqNpEUTDoRq6bbyEpdY/x3lEMWPFqqm5+NDrg7lD31vgjY9GODFeJSq5u lnXA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i20si7088837oie.119.2020.03.02.20.59.53; Mon, 02 Mar 2020 21:00:04 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727408AbgCCE6k (ORCPT + 99 others); Mon, 2 Mar 2020 23:58:40 -0500 Received: from mga03.intel.com ([134.134.136.65]:34653 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726928AbgCCE6j (ORCPT ); Mon, 2 Mar 2020 23:58:39 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Mar 2020 20:58:39 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,510,1574150400"; d="scan'208";a="232146450" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.202]) by fmsmga007.fm.intel.com with ESMTP; 02 Mar 2020 20:58:38 -0800 Date: Mon, 2 Mar 2020 20:58:38 -0800 From: Sean Christopherson To: Jim Mattson Cc: Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Joerg Roedel , kvm list , LKML , Jan Kiszka , Xiaoyao Li Subject: Re: [PATCH 2/6] KVM: x86: Fix CPUID range check for Centaur and Hypervisor ranges Message-ID: <20200303045838.GF27842@linux.intel.com> References: <20200302195736.24777-1-sean.j.christopherson@intel.com> <20200302195736.24777-3-sean.j.christopherson@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 02, 2020 at 08:25:31PM -0800, Jim Mattson wrote: > On Mon, Mar 2, 2020 at 7:25 PM Jim Mattson wrote: > > > > On Mon, Mar 2, 2020 at 11:57 AM Sean Christopherson > > wrote: > > > > > The bad behavior can be visually confirmed by dumping CPUID output in > > > the guest when running Qemu with a stable TSC, as Qemu extends the limit > > > of range 0x40000000 to 0x40000010 to advertise VMware's cpuid_freq, > > > without defining zeroed entries for 0x40000002 - 0x4000000f. > > > > I think it could be reasonably argued that this is a userspace bug. > > Clearly, when userspace explicitly supplies the results for a leaf, > > those results override the default CPUID values for that leaf. But I > > haven't seen it documented anywhere that leaves *not* explicitly > > supplied by userspace will override the default CPUID values, just > > because they happen to appear in some magic range. > > In fact, the more I think about it, the original change is correct, at > least in this regard. Your "fix" introduces undocumented and > unfathomable behavior. Heh, the takeaway from this is that whatever we decide on needs to be documented somewhere :-) I wouldn't say it's unfathomable, conceptually it seems like the intent of the hypervisor range was to mimic the basic and extended ranges. The whole thing is arbitrary behavior. Of course if Intel CPUs would just return 0s on undefined leafs it would be a lot less arbitrary :-) Anyways, I don't have a strong opinion on whether this patch stays or goes.