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