public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Jim Mattson <jmattson@google.com>
Cc: Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@intel.com>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Jiaxi Chen <jiaxi.chen@linux.intel.com>,
	Kim Phillips <kim.phillips@amd.com>,
	Sean Christopherson <seanjc@google.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org, Dave Hansen <dave.hansen@linux.intel.com>,
	Ingo Molnar <mingo@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] x86: KVM: Add feature flag for AMD's FsGsKernelGsBaseNonSerializing
Date: Thu, 5 Oct 2023 19:14:43 +0200	[thread overview]
Message-ID: <b9a454c9-e8aa-02f0-29d5-57753d797cfb@redhat.com> (raw)
In-Reply-To: <CALMp9eR=URBsz1qmTcDU5ixncUTkNgxJahLbfyZXYr-2RkBPng@mail.gmail.com>

On 10/5/23 19:06, Jim Mattson wrote:
> On Thu, Oct 5, 2023 at 9:39 AM Paolo Bonzini<pbonzini@redhat.com>  wrote:
> 
>> I agree with Jim that it would be nice to have some bits from Intel, and
>> some bits from AMD, that current processors always return as 1.  Future
>> processors can change those to 0 as desired.
> That's not quite what I meant.
> 
> I'm suggesting a leaf devoted to single bit negative features. If a
> bit is set in hardware, it means that something has been taken away.
> Hypervisors don't need to know exactly what was taken away. For this
> leaf only, hypervisors will always pass through a non-zero bit, even
> if they have know idea what it means.

Understood, but I'm suggesting that these might even have the right 
polarity: if a bit is set it means that something is there and might not 
in the future, even if we don't know exactly what.  We can pass through 
the bit, we can AND bits across the migration pool to define what to 
pass to the guest, we can force-set the leaves to zero (feature 
removed).  Either way, the point is to group future defeatures together.

That said, these bits are only for documentation/debugging purposes 
anyway.  So I like the idea because it would educate the architects 
about this issue, more than because it is actually useful...

Paolo


  reply	other threads:[~2023-10-05 17:22 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-04  0:20 [PATCH] x86: KVM: Add feature flag for AMD's FsGsKernelGsBaseNonSerializing Jim Mattson
2023-10-04  0:57 ` Dave Hansen
2023-10-04  2:44   ` Jim Mattson
2023-10-04  3:27     ` Dave Hansen
2023-10-04  4:24       ` Jim Mattson
2023-10-04  7:58     ` Borislav Petkov
2023-10-04 20:29       ` Jim Mattson
2023-10-05 16:22       ` Jim Mattson
2023-10-05 16:35         ` Dave Hansen
2023-10-05 16:41           ` Jim Mattson
2023-10-05 16:51             ` Paolo Bonzini
2023-10-05 17:52             ` Dave Hansen
2023-10-05 16:38       ` Paolo Bonzini
2023-10-05 17:06         ` Jim Mattson
2023-10-05 17:14           ` Paolo Bonzini [this message]
2023-10-05 17:27             ` Jim Mattson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b9a454c9-e8aa-02f0-29d5-57753d797cfb@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jiaxi.chen@linux.intel.com \
    --cc=jmattson@google.com \
    --cc=kim.phillips@amd.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pawan.kumar.gupta@linux.intel.com \
    --cc=seanjc@google.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox