Re: [PATCH] KVM: x86: Do not expose the host value of CPUID.8000001EH

[Paolo Bonzini]

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