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

[Xiaoyao Li <xiaoyao.li@intel.com>]

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.
>