From: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
Wei Liu <wei.liu2@citrix.com>,
xen-devel@lists.xen.org
Subject: Re: [PATCH v2 1/2] libxl: add more cpuid flags handling
Date: Wed, 28 Jun 2017 22:53:50 +0200 [thread overview]
Message-ID: <20170628205350.GR1268@mail-itl> (raw)
In-Reply-To: <30fc0923-2c8e-0b8d-4b18-4360debedf64@citrix.com>
[-- Attachment #1.1: Type: text/plain, Size: 9434 bytes --]
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@invisiblethingslab.com>
>
> 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 #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2017-06-28 20:53 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-28 10:10 [PATCH v2 0/2] libxl: cpuid bits Marek Marczykowski-Górecki
2017-06-28 10:10 ` [PATCH v2 1/2] libxl: add more cpuid flags handling Marek Marczykowski-Górecki
2017-06-28 17:53 ` Wei Liu
2017-06-28 18:16 ` Andrew Cooper
2017-06-28 20:53 ` Marek Marczykowski-Górecki [this message]
2017-06-28 10:10 ` [PATCH v2 2/2] libxl: drop osvw cpuid flag Marek Marczykowski-Górecki
2017-06-28 17:55 ` [PATCH v2 0/2] libxl: cpuid bits Wei Liu
2017-06-29 23:12 ` Marek Marczykowski-Górecki
2017-06-30 10:21 ` Wei Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170628205350.GR1268@mail-itl \
--to=marmarek@invisiblethingslab.com \
--cc=andrew.cooper3@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).