public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Zhang Chen <chen.zhang@intel.com>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
	kvm@vger.kernel.org, Chao Gao <chao.gao@intel.com>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Borislav Petkov <bp@alien8.de>, Ingo Molnar <mingo@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [RFC PATCH 5/9] x86/bugs: Use Virtual MSRs to request hardware mitigations
Date: Wed, 14 Dec 2022 20:18:17 +0000	[thread overview]
Message-ID: <Y5oviY0471JytWPo@google.com> (raw)
In-Reply-To: <20221210160046.2608762-6-chen.zhang@intel.com>

On Sun, Dec 11, 2022, Zhang Chen wrote:
> From: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> 
> Guests that have different family/model than the host may not be aware
> of hardware mitigations(such as RRSBA_DIS_S) available on host. This is
> particularly true when guests migrate. To solve this problem Intel
> processors have added a virtual MSR interface

Is there any actual "processor" support here?  To me, this looks like Intel is
foisting a paravirt interface on KVM and other hypervisors without collaborating
with said hypervisors' developers and maintainers.

I get that some of the mitigations are vendor specific, but things like RETPOLINE
aren't vendor specific.  I haven't followed all of the mitigation stuff very
closely, but I wouldn't be surprised if there are mitigations now or in the future
that are common across architectures, e.g. arm64 and x86-64.  Intel doing its own
thing means AMD and arm64 will likely follow suit, and suddenly KVM is supporting
multiple paravirt interfaces for very similar things, without having any control
over the APIs.  That's all kinds of backwards.

And having to wait for Intel to roll out new documentation when software inevitably
comes up with some clever new mitigation doesn't exactly fill my heart with joy.

  parent reply	other threads:[~2022-12-14 20:30 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-10 16:00 [RFC PATCH 0/9] Intel SPEC CTRL virtualization support Zhang Chen
2022-12-10 16:00 ` [RFC PATCH 1/9] x86/speculation: Introduce Intel SPEC_CTRL BHI related definition Zhang Chen
2022-12-10 16:00 ` [RFC PATCH 2/9] KVM: x86: Add a kvm-only leaf for RRSBA_CTRL Zhang Chen
2022-12-14 21:33   ` Ricardo Neri
2022-12-15  2:59     ` Zhang, Chen
2022-12-10 16:00 ` [RFC PATCH 3/9] KVM: x86: Add a kvm-only leaf for BHI_CTRL Zhang Chen
2022-12-14 21:37   ` Ricardo Neri
2022-12-10 16:00 ` [RFC PATCH 4/9] x86/kvm/vmx: Virtualize Intel IA32_SPEC_CTRL Zhang Chen
2022-12-10 16:00 ` [RFC PATCH 5/9] x86/bugs: Use Virtual MSRs to request hardware mitigations Zhang Chen
2022-12-12 20:23   ` Pawan Gupta
2022-12-14  7:57     ` Zhang, Chen
2022-12-14 20:18   ` Sean Christopherson [this message]
2022-12-19 13:56     ` Chao Gao
2022-12-19 17:14       ` Sean Christopherson
2022-12-20 13:43         ` Chao Gao
2022-12-22 18:31           ` Sean Christopherson
2023-01-10  9:26             ` Zhang, Chen
2022-12-10 16:00 ` [RFC PATCH 6/9] kvm/x86: Add ARCH_CAP_VIRTUAL_ENUM for guest MSR_IA32_ARCH_CAPABILITIES Zhang Chen
2022-12-21  4:03   ` Yang, Weijiang
2022-12-29  2:58     ` Zhang, Chen
2022-12-29  7:02       ` Yang, Weijiang
2022-12-29  7:41         ` Zhang, Chen
2022-12-29  8:38           ` Yang, Weijiang
2022-12-29  9:56             ` Zhang, Chen
2022-12-10 16:00 ` [RFC PATCH 7/9] kvm/x86: Add MSR_VIRTUAL_MITIGATION_ENUM/CTRL emulation Zhang Chen
2022-12-10 16:00 ` [RFC PATCH 8/9] x86/kvm/vmx: Initialize SPEC_CTRL MASK for RRSBA Zhang Chen
2023-01-15 14:20   ` Chao Gao
2022-12-10 16:00 ` [RFC PATCH 9/9] x86/kvm/vmx: Initialize SPEC_CTRL MASK for BHI Zhang Chen

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=Y5oviY0471JytWPo@google.com \
    --to=seanjc@google.com \
    --cc=bp@alien8.de \
    --cc=chao.gao@intel.com \
    --cc=chen.zhang@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pawan.kumar.gupta@linux.intel.com \
    --cc=pbonzini@redhat.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