All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Maxim Levitsky <mlevitsk@redhat.com>
Cc: kvm@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	x86@kernel.org,  Paolo Bonzini <pbonzini@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	 Dave Hansen <dave.hansen@linux.intel.com>,
	Borislav Petkov <bp@alien8.de>,
	linux-kernel@vger.kernel.org,  "H. Peter Anvin" <hpa@zytor.com>,
	Chao Gao <chao.gao@intel.com>
Subject: Re: [PATCH v3 1/4] KVM: x86: relax canonical check for some x86 architectural msrs
Date: Fri, 16 Aug 2024 15:02:02 -0700	[thread overview]
Message-ID: <Zr_MWkZwJHidWjlQ@google.com> (raw)
In-Reply-To: <Zr_JX1z8xWNAxHmz@google.com>

On Fri, Aug 16, 2024, Sean Christopherson wrote:
> On Thu, Aug 15, 2024, Maxim Levitsky wrote:
> How about this?
> 
> /*
>  * The canonicality checks for MSRs that hold linear addresses, e.g. segment
>  * bases, SYSENTER targets, etc., are static, in the sense that they are based
>  * on CPU _support_ for 5-level paging, not the state of CR4.LA57.
> 
> > + * size of whose depends only on CPU's support for 5-level
> > + * paging, rather than state of CR4.LA57.
> > + *
> > + * In addition to that, some of these MSRS are directly passed
> > + * to the guest (e.g MSR_KERNEL_GS_BASE) thus even if the guest
> > + * doen't have LA57 enabled in its CPUID, for consistency with
> > + * CPUs' ucode, it is better to pivot the check around host
> > + * support for 5 level paging.
> 
> I think we should elaborate on why it's better.  It only takes another line or
> two, and that way we don't forget the edge cases that make properly emulating
> guest CPUID a bad idea.
> 
>  * This creates a virtualization hole where a guest writes to passthrough MSRs
>  * may incorrectly succeed if the CPU supports LA57, but the vCPU does not
>  * (because hardware has no awareness of guest CPUID).  Do not try to plug this
>  * hole, i.e. emulate the behavior for intercepted accesses, as injecting #GP
>  * depending on whether or not KVM happens to emulate a WRMSR would result in
>  * non-deterministic behavior, and could even allow L2 to crash L1, e.g. if L1
>  * passes through an MSR to L2, and then tries to save+restore L2's value.
>  */
> 
> > +
> > +static u8  max_host_supported_virt_addr_bits(void)
> 
> Any objection to dropping the "supported", i.e. going with max_host_virt_addr_bits()?
> Mostly to shorten the name, but also because "supported" suggests there's software
> involvement, e.g. the max supported by the kernel/KVM, which isn't the case.
> 
> If you're ok with the above, I'll fixup when applying.

I take that back, I think we're going to need a v4 (see patch 3).

  reply	other threads:[~2024-08-16 22:02 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-15 12:33 [PATCH v3 0/4] Relax canonical checks on some arch msrs Maxim Levitsky
2024-08-15 12:33 ` [PATCH v3 1/4] KVM: x86: relax canonical check for some x86 architectural msrs Maxim Levitsky
2024-08-16 21:49   ` Sean Christopherson
2024-08-16 22:02     ` Sean Christopherson [this message]
2024-08-20 12:13     ` mlevitsk
2024-08-21 12:04       ` mlevitsk
2024-08-21 16:04         ` Sean Christopherson
2024-08-23 11:14           ` mlevitsk
2024-08-23 13:59             ` Sean Christopherson
2025-09-12 20:28               ` Jim Mattson
2025-09-16 20:47                 ` Sean Christopherson
2024-08-15 12:33 ` [PATCH v3 2/4] KVM: x86: add X86_FEATURE_LA57 to governed_features Maxim Levitsky
2024-08-15 12:33 ` [PATCH v3 3/4] KVM: nVMX: relax canonical checks on some x86 registers in vmx host state Maxim Levitsky
2024-08-16 10:40   ` mlevitsk
2024-08-16 22:03     ` Sean Christopherson
2024-08-20 12:19       ` mlevitsk
2024-08-15 12:33 ` [PATCH v3 4/4] KVM: SVM: fix emulation of msr reads/writes of MSR_FS_BASE and MSR_GS_BASE Maxim Levitsky
2024-08-16 22:04   ` Sean Christopherson
2024-08-24  0:07     ` Sean Christopherson

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=Zr_MWkZwJHidWjlQ@google.com \
    --to=seanjc@google.com \
    --cc=bp@alien8.de \
    --cc=chao.gao@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=mlevitsk@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.