Re: [Xen-devel] [PATCH 08/10] x86/cpuid: Handle leaf 0xb in guest_cpuid()

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 22.02.17 at 11:22, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 22/02/17 09:16, Jan Beulich wrote:
>>>>> On 20.02.17 at 12:00, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> Leaf 0xb is reserved by AMD, and uniformly hidden from guests by the 
> toolstack
>>> logic and hypervisor PV logic.
>>>
>>> The previous dynamic logic filled in the x2APIC ID for all HVM guests.  This
>>> is modified to respect the entire leaf being reserved by AMD, but is altered
>>> to include PV Intel guests, so they get more sensible values in their 
>>> emulated
>>> and faulted view of CPUID.
>> Don't we expose x2APIC to HVM guests even on AMD systems? In
>> which case we surely will want to also expose the x2APIC ID.
> 
> The x2apic feature bit is still listed as reserved in the latest AMD
> SDM, and I haven't seen a piece of hardware which supports it.

This doesn't seem to answer my question, as hardware behavior is
of no interest here (our emulation works on old Intel hardware too).
Just to be sure I've checked a HVM guest on an AMD box, and this
is what Linux reports:

<6>Enabling x2apic
<6>Enabled x2apic
<6>Switched APIC routing to physical x2apic.

> Also, x2apic or not, this leaf is documented as fully reserved, so we
> shouldn't be filling it in anyway.

While guests appear to do fine without, I think this is inconsistent
with providing x2APIC support. But as current behavior is the same,
we can as well leave this for the future.

>>> @@ -959,6 +950,14 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
>>>          }
>>>          break;
>>>  
>>> +    case 0xb:
>>> +        if ( p->x86_vendor == X86_VENDOR_INTEL )
>>> +        {
>>> +            /* Fix the x2APIC identifier. */
>>> +            res->d = v->vcpu_id * 2;
>>> +        }
>>> +        break;
>> Irrespective of the comment above, wouldn't the if() here better
>> look at the x2APIC feature flag of the domain?
> 
> Perhaps.  There isn't a formal link called out, but looking at the
> content, I am guessing that real hardware is consistent with their
> support of x2apic and the availability of this leaf?

I suppose so, at least they've got introduced together iirc.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel