Re: [PATCH v2 6/7] KVM: VMX: Check Intel PT related CPUID leaves

[Xiaoyao Li]

On 10/19/2021 1:26 AM, Sean Christopherson wrote:
> On Mon, Oct 18, 2021, Xiaoyao Li wrote:
> > On 10/18/2021 8:47 PM, Paolo Bonzini wrote:
> > > > > One option would be to bump that to the theoretical max of 15,
> > > > > which doesn't seem too horrible, especially if pt_desc as a whole
> > > > > is allocated on-demand, which it probably should be since it isn't
> > > > > exactly tiny (nor ubiquitous)
> > > > >
> > > > > A different option would be to let userspace define whatever it
> > > > > wants for guest CPUID, and instead cap nr_addr_ranges at
> > > > > min(host.cpuid, guest.cpuid, RTIT_ADDR_RANGE).
> > >
> > > This is the safest option.

I think I misunderstood it. sigh...

It's not architecture consistent that guest sees a certain number of 
RTIT_ADDR_RANGE from its CPUID but may get #GP when it accesses high index.

OK, you mean it's userspace's fault and KVM shouldn't get blamed for it. 
It seems reasonable for me now.

> > My concern was that change userspace's input silently is not good.
>
> Technically KVM isn't changing userspace's input, as KVM will still enumerate
> CPUID as defined by userspace.  What KVM is doing is refusing to emulate/virtualize
> a bogus vCPU model, e.g. by injecting #GP on an MSR access that userspace
> incorrectly told the guest was legal.  That is standard operation procedure for
> KVM, e.g. there are any number of instructions that will fault if userspace lies
> about the vCPU model.
>
> > prefer this, we certainly need to extend the userspace to query what value
> > is finally accepted and set by KVM.
>
> That would be __do_cpuid_func()'s responsibility to cap leaf 0x14 output with
> RTIT_ADDR_RANGE.  I.e. enumerate the supported ranges in KVM_GET_SUPPORTED_CPUID,
> after that it's userspace's responsibility to not mess up.