Xen project Mailing List

Re: [Xen-devel] [PATCH v2 1/2] libxl: add more cpuid flags handling

To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

From: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>

Date: Wed, 28 Jun 2017 22:53:50 +0200

Cc: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>, Wei Liu <wei.liu2@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxx

Delivery-date: Wed, 28 Jun 2017 20:54:30 +0000

List-id: Xen developer discussion <xen-devel.lists.xen.org>

On Wed, Jun 28, 2017 at 07:16:18PM +0100, Andrew Cooper wrote: > On 28/06/17 11:10, Marek Marczykowski-Górecki wrote: > > This is result of parsing cpu_map.xml from libvirt. > > The most important part is handling leaf 0x00000007, but while at it add > > other bits too. > > > > Signed-off-by: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx> > > Xen's canonical reference is include/asm-x86/cpufeatures.h from which > the hypervisor logic is derived. > > > --- > > docs/man/xl.cfg.pod.5.in | 20 ++++++++++++-------- > > tools/libxl/libxl_cpuid.c | 37 +++++++++++++++++++++++++++++++++++++ > > 2 files changed, 49 insertions(+), 8 deletions(-) > > > > Changes since v1: > > - set sub-leaf to 0 for leaf 7 > > > > diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in > > index 38084c7..51361c4 100644 > > --- a/docs/man/xl.cfg.pod.5.in > > +++ b/docs/man/xl.cfg.pod.5.in > > @@ -1464,14 +1464,18 @@ apicidsize brandid clflush family localapicid > > maxleaf maxhvleaf model nc > > proccount procpkg stepping > > > > List of keys taking a character: > > -3dnow 3dnowext 3dnowprefetch abm acpi aes altmovcr8 apic avx clfsh cmov > > -cmplegacy cmpxchg16 cmpxchg8 cntxid dca de ds dscpl dtes64 est extapic f16c > > -ffxsr fma4 fpu fxsr htt hypervisor ia64 ibs lahfsahf lm lwp mca mce > > misalignsse > > -mmx mmxext monitor movbe msr mtrr nodeid nx osvw osxsave pae page1gb pat > > pbe > > -pclmulqdq pdcm pge popcnt pse pse36 psn rdtscp skinit smx ss sse sse2 sse3 > > -sse4_1 sse4_2 sse4a ssse3 svm svm_decode svm_lbrv svm_npt svm_nrips > > -svm_pausefilt svm_tscrate svm_vmcbclean syscall sysenter tbm tm tm2 > > topoext tsc > > -vme vmx wdt x2apic xop xsave xtpr > > +3dnow 3dnowext 3dnowprefetch abm acpi adx aes altmovcr8 apic arat avx avx2 > > +avx512-4fmaps avx512-4vnniw avx512bw avx512cd avx512dq avx512er avx512f > > +avx512ifma avx512pf avx512vbmi avx512vl bmi1 bmi2 clflushopt clfsh cmov > > +cmplegacy cmpxchg16 cmpxchg8 cmt cntxid dca de ds dscpl dtes64 erms est > > extapic > > +f16c ffxsr fma fma4 fpu fsgsbase fxsr hle htt hypervisor ia64 ibs invpcid > > +invtsc lahfsahf lm lwp mca mce misalignsse mmx mmxext monitor movbe mpx msr > > +mtrr nodeid nx ospke osvw osxsave pae page1gb pat pbe pcid pclmulqdq pdcm > > +perfctr_core perfctr_nb pge pku popcnt pse pse36 psn rdrand rdseed rdtscp > > rtm > > +skinit smap smep smx ss sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm > > svm_decode > > +svm_lbrv svm_npt svm_nrips svm_pausefilt svm_tscrate svm_vmcbclean syscall > > +sysenter tbm tm tm2 topoext tsc tsc-deadline tsc_adjust vme vmx wdt x2apic > > xop > > +xsave xtpr > > > > The xend syntax is a list of values in the form of > > 'leafnum:register=bitstring,register=bitstring' > > diff --git a/tools/libxl/libxl_cpuid.c b/tools/libxl/libxl_cpuid.c > > index 24591e2..8bcdb29 100644 > > --- a/tools/libxl/libxl_cpuid.c > > +++ b/tools/libxl/libxl_cpuid.c > > @@ -100,11 +100,13 @@ int libxl_cpuid_parse_config(libxl_cpuid_policy_list > > *cpuid, const char* str) > > As some general points, it would be helpful to add newlines for clarity > between the CPUID_REG_* changes. It is weird being sorted by bit index > in descending order, although perhaps just me. It is weird for me too, but I didn't wanted to reformat the whole list. If there is no real reason for this order, I can change that too. > The structure really wants to be static const (so living in .rodata). > At the moment, it is being reconstructed on the stack by prologue code > every time the function is called. Good idea. > > {"clflush", 0x00000001, NA, CPUID_REG_EBX, 8, 8}, > > {"brandid", 0x00000001, NA, CPUID_REG_EBX, 0, 8}, > > {"hypervisor", 0x00000001, NA, CPUID_REG_ECX, 31, 1}, > > + {"rdrand", 0x00000001, NA, CPUID_REG_ECX, 30, 1}, > > {"f16c", 0x00000001, NA, CPUID_REG_ECX, 29, 1}, > > {"avx", 0x00000001, NA, CPUID_REG_ECX, 28, 1}, > > {"osxsave", 0x00000001, NA, CPUID_REG_ECX, 27, 1}, > > {"xsave", 0x00000001, NA, CPUID_REG_ECX, 26, 1}, > > {"aes", 0x00000001, NA, CPUID_REG_ECX, 25, 1}, > > + {"tsc-deadline", 0x00000001, NA, CPUID_REG_ECX, 24, 1}, > > {"popcnt", 0x00000001, NA, CPUID_REG_ECX, 23, 1}, > > {"movbe", 0x00000001, NA, CPUID_REG_ECX, 22, 1}, > > {"x2apic", 0x00000001, NA, CPUID_REG_ECX, 21, 1}, > > @@ -114,9 +116,11 @@ int libxl_cpuid_parse_config(libxl_cpuid_policy_list > > *cpuid, const char* str) > > {"sse4.1", 0x00000001, NA, CPUID_REG_ECX, 19, 1}, > > {"sse4_1", 0x00000001, NA, CPUID_REG_ECX, 19, 1}, > > {"dca", 0x00000001, NA, CPUID_REG_ECX, 18, 1}, > > + {"pcid", 0x00000001, NA, CPUID_REG_ECX, 17, 1}, > > {"pdcm", 0x00000001, NA, CPUID_REG_ECX, 15, 1}, > > {"xtpr", 0x00000001, NA, CPUID_REG_ECX, 14, 1}, > > {"cmpxchg16", 0x00000001, NA, CPUID_REG_ECX, 13, 1}, > > + {"fma", 0x00000001, NA, CPUID_REG_ECX, 12, 1}, > > {"cntxid", 0x00000001, NA, CPUID_REG_ECX, 10, 1}, > > {"ssse3", 0x00000001, NA, CPUID_REG_ECX, 9, 1}, > > {"tm2", 0x00000001, NA, CPUID_REG_ECX, 8, 1}, > > @@ -158,6 +162,38 @@ int libxl_cpuid_parse_config(libxl_cpuid_policy_list > > *cpuid, const char* str) > > {"de", 0x00000001, NA, CPUID_REG_EDX, 2, 1}, > > {"vme", 0x00000001, NA, CPUID_REG_EDX, 1, 1}, > > {"fpu", 0x00000001, NA, CPUID_REG_EDX, 0, 1}, > > + {"arat", 0x00000006, NA, CPUID_REG_EAX, 2, 1}, > > + {"avx512vl", 0x00000007, 0, CPUID_REG_EBX, 31, 1}, > > + {"avx512bw", 0x00000007, 0, CPUID_REG_EBX, 30, 1}, > > sha at 29 > > > + {"avx512cd", 0x00000007, 0, CPUID_REG_EBX, 28, 1}, > > + {"avx512er", 0x00000007, 0, CPUID_REG_EBX, 27, 1}, > > + {"avx512pf", 0x00000007, 0, CPUID_REG_EBX, 26, 1}, > > clwb at 24 > > > + {"clflushopt", 0x00000007, 0, CPUID_REG_EBX, 23, 1}, > > + {"avx512ifma", 0x00000007, 0, CPUID_REG_EBX, 21, 1}, > > + {"smap", 0x00000007, 0, CPUID_REG_EBX, 20, 1}, > > + {"adx", 0x00000007, 0, CPUID_REG_EBX, 19, 1}, > > + {"rdseed", 0x00000007, 0, CPUID_REG_EBX, 18, 1}, > > + {"avx512dq", 0x00000007, 0, CPUID_REG_EBX, 17, 1}, > > + {"avx512f", 0x00000007, 0, CPUID_REG_EBX, 16, 1}, > > + {"mpx", 0x00000007, 0, CPUID_REG_EBX, 14, 1}, > > + {"cmt", 0x00000007, 0, CPUID_REG_EBX, 12, 1}, > > + {"rtm", 0x00000007, 0, CPUID_REG_EBX, 11, 1}, > > + {"invpcid", 0x00000007, 0, CPUID_REG_EBX, 10, 1}, > > + {"erms", 0x00000007, 0, CPUID_REG_EBX, 9, 1}, > > + {"bmi2", 0x00000007, 0, CPUID_REG_EBX, 8, 1}, > > + {"smep", 0x00000007, 0, CPUID_REG_EBX, 7, 1}, > > + {"avx2", 0x00000007, 0, CPUID_REG_EBX, 5, 1}, > > + {"hle", 0x00000007, 0, CPUID_REG_EBX, 4, 1}, > > + {"bmi1", 0x00000007, 0, CPUID_REG_EBX, 3, 1}, > > + {"tsc_adjust", 0x00000007, 0, CPUID_REG_EBX, 1, 1}, > > + {"fsgsbase", 0x00000007, 0, CPUID_REG_EBX, 0, 1}, > > + {"ospke", 0x00000007, 0, CPUID_REG_ECX, 4, 1}, > > I'm not sure having ospke able to be controlled in this way is useful. > It is a fast-forward of CR4.PKE, which is gated on PKU below, and > handled entirely by Xen. Well, you can adjust any bit using old ("xend") syntax anyway, at least from toolstack point of view... > > > + {"pku", 0x00000007, 0, CPUID_REG_ECX, 3, 1}, > > umip at 2 > > > + {"avx512vbmi", 0x00000007, 0, CPUID_REG_ECX, 1, 1}, > > + {"avx512-4fmaps",0x00000007, 0, CPUID_REG_EDX, 3, 1}, > > + {"avx512-4vnniw",0x00000007, 0, CPUID_REG_EDX, 2, 1}, > > + {"perfctr_nb", 0x80000001, NA, CPUID_REG_ECX, 24, 1}, > > + {"perfctr_core", 0x80000001, NA, CPUID_REG_ECX, 23, 1}, > > {"topoext", 0x80000001, NA, CPUID_REG_ECX, 22, 1}, > > {"tbm", 0x80000001, NA, CPUID_REG_ECX, 21, 1}, > > {"nodeid", 0x80000001, NA, CPUID_REG_ECX, 19, 1}, > > @@ -187,6 +223,7 @@ int libxl_cpuid_parse_config(libxl_cpuid_policy_list > > *cpuid, const char* str) > > {"nx", 0x80000001, NA, CPUID_REG_EDX, 20, 1}, > > {"syscall", 0x80000001, NA, CPUID_REG_EDX, 11, 1}, > > {"procpkg", 0x00000004, 0, CPUID_REG_EAX, 26, 6}, > > + {"invtsc", 0x80000007, NA, CPUID_REG_EDX, 8, 1}, > > {"apicidsize", 0x80000008, NA, CPUID_REG_ECX, 12, 4}, > > {"nc", 0x80000008, NA, CPUID_REG_ECX, 0, 8}, > > {"svm_npt", 0x8000000a, NA, CPUID_REG_EDX, 0, 1}, > > Otherwise, all of the added values look to correct in their bit-positions. > > ~Andrew -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

Attachment: signature.asc
Description: PGP signature

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

©2013 Xen Project, A Linux Foundation Collaborative Project. All Rights Reserved.
Linux Foundation is a registered trademark of The Linux Foundation.
Xen Project is a trademark of The Linux Foundation.