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

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 03/03/16 12:23, Joao Martins wrote:
>
> On 03/03/2016 10:24 AM, Andrew Cooper wrote:
>> 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.
> I meant specifically with the approach of my series i.e. changing cpuid policy
> for HVM guests. PV guests cpuid is only trapped with CPUID_FAULTING so adding
> support for PV guests topology on this toolstack-based approach we would need to
> perhaps expose CPUID_FAULTING support somehow in physinfo so that the toolstack
> know when to safely set the guest topology.

My v1 series contained

http://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen.git;a=commitdiff;h=c1b38a3b3b77ebe4e801906a3f67db9faa4c8003

which was intended to provide this information for the toolstack.  It
got reviewed out in v2 due to a lack of a consumer, but I would prefer
to reintroduce it if possible.  I guess I will.

~Andrew

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