Re: [Xen-devel] [PATCH RFC 0/8] x86/hvm, libxl: HVM SMT topology support

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 03/03/16 09:52, Joao Martins wrote:
>
>>>> In particular, I am concerned about giving the toolstack the ability to
>>>> blindly control the APIC IDs.  Their layout is very closely linked to
>>>> topology, and in particular to the HTT flag.
>>>>
>>>> Overall, I want to avoid any possibility of generating APIC layouts
>>>> (including the emulated IOAPIC with HVM guests) which don't conform to
>>>> the appropriate AMD/Intel manuals.
>>> I see so overall having Xen control the topology would be a better approach 
>>> that
>>> "mangling" the APICIDs in the cpuid policy as I am proposing. One good thing
>>> about Xen handling the topology bits would be for Intel CPUs with CPUID 
>>> faulting
>>> support where PV guests could also see the topology info. And given that the
>>> word 10 of hw_caps won't be exposed (as per your CPUID), handling the PV 
>>> case on
>>> cpuid policy wouldn't be as clean.
>> Which word do you mean here?  Even before my series, Xen only had 9
>> words in hw_cap.
> Hm, I used the wrong nomenclature here: what I meant was the 10th feature word
> from x86_boot_capability (since the sysctl/libxl are capped to 8 words only)
> which in the header files is word 9 on your series (previously moved from word
> 3). It's the one meant for "Other features, Linux-defined mapping", where
> X86_FEATURE_CPUID_FAULTING is defined.

Ah - so the word of synthetic values.

I don't see how the lack of that word makes policy handling any harder? 
All information in there is gathered from other sources.

~Andrew

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