From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= Subject: Re: [PATCH v2 1/2] libxl: add more cpuid flags handling Date: Wed, 28 Jun 2017 22:53:50 +0200 Message-ID: <20170628205350.GR1268@mail-itl> References: <1498644622-19753-1-git-send-email-marmarek@invisiblethingslab.com> <1498644622-19753-2-git-send-email-marmarek@invisiblethingslab.com> <30fc0923-2c8e-0b8d-4b18-4360debedf64@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2537037016676514878==" Return-path: In-Reply-To: <30fc0923-2c8e-0b8d-4b18-4360debedf64@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Andrew Cooper Cc: Ian Jackson , Wei Liu , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org --===============2537037016676514878== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="C/7QAxk31FAUhYUE" Content-Disposition: inline --C/7QAxk31FAUhYUE Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 28, 2017 at 07:16:18PM +0100, Andrew Cooper wrote: > On 28/06/17 11:10, Marek Marczykowski-G=C3=B3recki 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=C3=B3recki >=20 > Xen's canonical reference is include/asm-x86/cpufeatures.h from which > the hypervisor logic is derived. >=20 > > --- > > 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 m= axleaf maxhvleaf model nc > > proccount procpkg stepping > > =20 > > 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 mi= salignsse > > -mmx mmxext monitor movbe msr mtrr nodeid nx osvw osxsave pae page1gb p= at 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 to= poext 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 es= t extapic > > +f16c ffxsr fma fma4 fpu fsgsbase fxsr hle htt hypervisor ia64 ibs invp= cid > > +invtsc lahfsahf lm lwp mca mce misalignsse mmx mmxext monitor movbe mp= x msr > > +mtrr nodeid nx ospke osvw osxsave pae page1gb pat pbe pcid pclmulqdq p= dcm > > +perfctr_core perfctr_nb pge pku popcnt pse pse36 psn rdrand rdseed rdt= scp rtm > > +skinit smap smep smx ss sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm sv= m_decode > > +svm_lbrv svm_npt svm_nrips svm_pausefilt svm_tscrate svm_vmcbclean sys= call > > +sysenter tbm tm tm2 topoext tsc tsc-deadline tsc_adjust vme vmx wdt x2= apic xop > > +xsave xtpr > > =20 > > The xend syntax is a list of values in the form of > > 'leafnum:register=3Dbitstring,register=3Dbitstring' > > 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_l= ist *cpuid, const char* str) >=20 > 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).=20 > 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_li= st *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_li= st *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}, >=20 > sha at 29 >=20 > > + {"avx512cd", 0x00000007, 0, CPUID_REG_EBX, 28, 1}, > > + {"avx512er", 0x00000007, 0, CPUID_REG_EBX, 27, 1}, > > + {"avx512pf", 0x00000007, 0, CPUID_REG_EBX, 26, 1}, >=20 > clwb at 24 >=20 > > + {"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}, >=20 > I'm not sure having ospke able to be controlled in this way is useful.=20 > 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 =66rom toolstack point of view... >=20 > > + {"pku", 0x00000007, 0, CPUID_REG_ECX, 3, 1}, >=20 > umip at 2 >=20 > > + {"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_lis= t *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}, >=20 > Otherwise, all of the added values look to correct in their bit-positions. >=20 > ~Andrew --=20 Best Regards, Marek Marczykowski-G=C3=B3recki 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? --C/7QAxk31FAUhYUE Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJZVBdfAAoJENuP0xzK19cszCwH/0lep8xuAV2+eMbWklzoX3WR 2ACyTTKJC+kQkJAnsr2sr9gxpdugdWjjm/+JDQb+rqED/eUJjR3EIWjFNCa8HtmB uvCI6YEP230RaCoXISvkoYrW8bdVPwvsvb3ZNLNnJerj0D1LpfAFH4stIAszHioX RVBf/U+/tG5eHJ06d0Ii0y3GrtzDYFD+hwwNlO4M/J7HtQdvqWAIFEsrfhONwp8k PMC4eY2z4V7NOxQJP6ky0BuAvWghM+I+FgKrw8b4IGSES5g504jA7A59psCZm2SM kwClpZHkwFK5MbEcO2SOX1GiJHz9cASKQJSiAELVSwllDq9yUS3mszhqgiYOok4= =0EvE -----END PGP SIGNATURE----- --C/7QAxk31FAUhYUE-- --===============2537037016676514878== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============2537037016676514878==--