On 10/25/22 23:25, Sean Christopherson wrote:
0xb and 0x1f are already special cased because EDX is set to the X2APIC id.
KVM knows how to do that unlike the NodeId and CoreId.
But KVM doesn't properly support 0xB/0x1F. E.g. if usersepace regurgitates
KVM_GET_SUPPORTED_CPUID back into KVM_SET_CPUID2, all vCPUs will observe the same
x2APIC ID in EDX, and it will be a host x2APIC ID to boot.
KVM only handles the where userspace provides 0xB.1 (or 0x1F.1), the guest performs
CPUID with ECX>1,_and_ userspace doesn't provide the exact CPUID entry.
Ah, you're right - I confused it with the "undefined leaves" behavior here:
} else {
*eax = *ebx = *ecx = *edx = 0;
/*
* When leaf 0BH or 1FH is defined, CL is pass-through
* and EDX is always the x2APIC ID, even for undefined
* subleaves. Index 1 will exist iff the leaf is
* implemented, so we pass through CL iff leaf 1
* exists. EDX can be copied from any existing index.
*/
if (function == 0xb || function == 0x1f) {
entry = kvm_find_cpuid_entry(vcpu, function, 1);
if (entry) {
*ecx = index & 0xff;
*edx = entry->edx;
}
}
}
but KVM in principle could set EDX to the right value for 0xB and 0x1F,
the x2APIC ID is available for the kernel LAPIC case. 0x8000001e cannot
be fixed up the same way.
I suppose one could argue that KVM needs to communicate to userspace that KVM
emulates the edge case behavior of CPUID 0xB and 0x1F, but I would argue that KVM
communicates that by announcing a max basic leaf >= 0xB/0x1F.
I agree (or we could fix it up automagically if so inclined). Either
way it should be documented at the end of api.rst.
Paolo
