Re: [PATCH 1/3] KVM: VMX: Rename vmx_umip_emulated() to cpu_has_vmx_desc()

[Sean Christopherson <seanjc@google.com>]

On Fri, Mar 31, 2023, Robert Hoo wrote:
> Sean Christopherson <seanjc@google.com> 于2023年3月16日周四 01:50写道：
> >
> > Please fix your editor or whatever it is that is resulting your emails being
> > wrapped at very bizarre boundaries.
> >
> (Sorry for late reply.)
> Yes, I also noticed this. Just began using Gmail web portal for community mails.
> I worried that it has no auto wrapping (didn't find the setting), so manually
> wrapped; but now looks like it has some.
> Give me some time, I'm going to switch to some mail client.
> Welcome suggestions of mail clients which is suited for community
> communications, on Windows platform.🙂

Heh, none?  The "on Windows" is a bit problematic.  Sorry I can't help on this
front.

> > That leaves KVM's stuffing of X86_CR4_UMIP into the default cr4_fixed1
> > value enumerated for nested VMX.  In that case, checking for (lack of)
> > host support is actually a bug fix of sorts,
> 
> What bug?
> By your assumption below:
>     * host supports UMIP, host doesn't allow (nested?) vmx
>     * UMIP enumerated to L1, L1 thinks it has UMIP capability and
> enumerates to L2
>     * L1 MSR_IA32_VMX_CR4_FIXED1.UMIP is set (meaning allow 1, not fixed to 1)
> 
> L2 can use UMIP, no matter L1's UMIP capability is backed by L0 host's
> HW UMIP or L0's vmx emulation, I don't see any problem. Shed more
> light?
> 
> > as enumerating UMIP support
> > based solely on descriptor table
> 
> What "descriptor table" do you mean here?

There's a typo below.  It should be "exiting", not "existing".  As in "descriptor
table exiting", i.e. the feature that allows KVM to intercept LGDT and friends.

> > existing works only because KVM doesn't
> > sanity check MSR_IA32_VMX_CR4_FIXED1.
> 
> Emm, nested_cr4_valid() should be applied to vmx_set_cr4()?

No, what this is saying is that if a (virtual) CPU does support UMIP for bare
metal (from the host's perspective), but does NOT allow UMIP to be set in a VMX
guest's CR4, then KVM would end up advertising UMIP to L1 but would neither
virtualize (set in hardware) nor emulate UMIP for L1.

The blurb about KVM exploding is calling out that in this very, very theoretical
scenario, KVM will fail on the very first VM-Entry (if not before) as KVM uses the
host kernel's CR4 verbatim when setting vmcs.HOST_CR4, i.e. will fail the consistency
check on a "cannot be 1" bits being set in HOST_CR4.

> > E.g. if a (very theoretical) host supported UMIP in hardware but didn't
> > allow UMIP+VMX, KVM would advertise UMIP but not actually emulate UMIP.  Of
> > course, KVM would explode long before it could run a nested VM on said
> > theoretical CPU, as KVM doesn't modify host CR4 when enabling VMX.