Messages in this thread | | | Date | Tue, 19 Oct 2021 09:46:29 +0800 | Subject | Re: [PATCH v2 6/7] KVM: VMX: Check Intel PT related CPUID leaves | From | 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. >
| |