[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH RFC 0/8] x86/hvm, libxl: HVM SMT topology support
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |