[PATCH 0/2] libxl: cpuid bits

[PATCH 0/2] libxl: cpuid bits

[Marek Marczykowski-Górecki]

This adds handling more cpuid bits by name. Mostly based on cpu_map.xml from
libvirt.
There are also some differences - looks like different naming in Intel and AMD
documentation (and sometimes also Linux). For example "pni" vs "sse3". Is it ok
to add those alternative names too? There is already such case for "sse4.1" / "sse4_1".

Marek Marczykowski-Górecki (2):
  libxl: add more cpuid flags handling
  libxl: fix osvm cpuid flag

 docs/man/xl.cfg.pod.5.in  | 20 ++++++++++++--------
 tools/libxl/libxl_cpuid.c | 39 ++++++++++++++++++++++++++++++++++++++-
 2 files changed, 50 insertions(+), 9 deletions(-)

-- 
2.7.4


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

[PATCH 1/2] libxl: add more cpuid flags handling

[Marek Marczykowski-Górecki]

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>
---
 docs/man/xl.cfg.pod.5.in  | 20 ++++++++++++--------
 tools/libxl/libxl_cpuid.c | 37 +++++++++++++++++++++++++++++++++++++
 2 files changed, 49 insertions(+), 8 deletions(-)

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..1cf7973 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)
         {"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, NA, CPUID_REG_EBX, 31,  1},
+        {"avx512bw",     0x00000007, NA, CPUID_REG_EBX, 30,  1},
+        {"avx512cd",     0x00000007, NA, CPUID_REG_EBX, 28,  1},
+        {"avx512er",     0x00000007, NA, CPUID_REG_EBX, 27,  1},
+        {"avx512pf",     0x00000007, NA, CPUID_REG_EBX, 26,  1},
+        {"clflushopt",   0x00000007, NA, CPUID_REG_EBX, 23,  1},
+        {"avx512ifma",   0x00000007, NA, CPUID_REG_EBX, 21,  1},
+        {"smap",         0x00000007, NA, CPUID_REG_EBX, 20,  1},
+        {"adx",          0x00000007, NA, CPUID_REG_EBX, 19,  1},
+        {"rdseed",       0x00000007, NA, CPUID_REG_EBX, 18,  1},
+        {"avx512dq",     0x00000007, NA, CPUID_REG_EBX, 17,  1},
+        {"avx512f",      0x00000007, NA, CPUID_REG_EBX, 16,  1},
+        {"mpx",          0x00000007, NA, CPUID_REG_EBX, 14,  1},
+        {"cmt",          0x00000007, NA, CPUID_REG_EBX, 12,  1},
+        {"rtm",          0x00000007, NA, CPUID_REG_EBX, 11,  1},
+        {"invpcid",      0x00000007, NA, CPUID_REG_EBX, 10,  1},
+        {"erms",         0x00000007, NA, CPUID_REG_EBX,  9,  1},
+        {"bmi2",         0x00000007, NA, CPUID_REG_EBX,  8,  1},
+        {"smep",         0x00000007, NA, CPUID_REG_EBX,  7,  1},
+        {"avx2",         0x00000007, NA, CPUID_REG_EBX,  5,  1},
+        {"hle",          0x00000007, NA, CPUID_REG_EBX,  4,  1},
+        {"bmi1",         0x00000007, NA, CPUID_REG_EBX,  3,  1},
+        {"tsc_adjust",   0x00000007, NA, CPUID_REG_EBX,  1,  1},
+        {"fsgsbase",     0x00000007, NA, CPUID_REG_EBX,  0,  1},
+        {"ospke",        0x00000007, NA, CPUID_REG_ECX,  4,  1},
+        {"pku",          0x00000007, NA, CPUID_REG_ECX,  3,  1},
+        {"avx512vbmi",   0x00000007, NA, CPUID_REG_ECX,  1,  1},
+        {"avx512-4fmaps",0x00000007, NA, CPUID_REG_EDX,  3,  1},
+        {"avx512-4vnniw",0x00000007, NA, 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},
-- 
2.7.4


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

[PATCH 2/2] libxl: fix osvm cpuid flag

[Marek Marczykowski-Górecki]

It's bit 9 not 10 (which is ibs).

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
---
 tools/libxl/libxl_cpuid.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/libxl/libxl_cpuid.c b/tools/libxl/libxl_cpuid.c
index 1cf7973..a4a69af 100644
--- a/tools/libxl/libxl_cpuid.c
+++ b/tools/libxl/libxl_cpuid.c
@@ -203,7 +203,7 @@ int libxl_cpuid_parse_config(libxl_cpuid_policy_list *cpuid, const char* str)
         {"skinit",       0x80000001, NA, CPUID_REG_ECX, 12,  1},
         {"xop",          0x80000001, NA, CPUID_REG_ECX, 11,  1},
         {"ibs",          0x80000001, NA, CPUID_REG_ECX, 10,  1},
-        {"osvw",         0x80000001, NA, CPUID_REG_ECX, 10,  1},
+        {"osvw",         0x80000001, NA, CPUID_REG_ECX,  9,  1},
         {"3dnowprefetch",0x80000001, NA, CPUID_REG_ECX,  8,  1},
         {"misalignsse",  0x80000001, NA, CPUID_REG_ECX,  7,  1},
         {"sse4a",        0x80000001, NA, CPUID_REG_ECX,  6,  1},
-- 
2.7.4


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

Re: [PATCH 1/2] libxl: add more cpuid flags handling

[Jan Beulich]

>@@ -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, NA, CPUID_REG_EBX, 31,  1},

Leaf 7 requires the sub-leaf to be specified (i.e. 0 rather than NA).

Also, to answer you alias name question from the overview mail: sse4.1 and
sse4_1 seem like a reasonable alias pair to have, but I don't think we want
something like PNI (I'd guess most people don't even recall/know what at
least the P stands for),

Jan


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

Re: [PATCH 2/2] libxl: fix osvm cpuid flag

[Jan Beulich]

>>> Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> 06/28/17 3:09 AM >>>
>It's bit 9 not 10 (which is ibs).

Indeed, but shouldn't it rather be removed? We don't expose it from the
hypervisor at all anymore:

XEN_CPUFEATURE(OSVW,          3*32+ 9) /*   OS Visible Workaround */

(note the absence of any marker character immediately inside the comment).

Jan


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

Re: [PATCH 2/2] libxl: fix osvm cpuid flag

[Andrew Cooper]

On 28/06/17 07:09, Jan Beulich wrote:
>>>> Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> 06/28/17 3:09 AM >>>
>> It's bit 9 not 10 (which is ibs).
> Indeed, but shouldn't it rather be removed? We don't expose it from the
> hypervisor at all anymore:
>
> XEN_CPUFEATURE(OSVW,          3*32+ 9) /*   OS Visible Workaround */
>
> (note the absence of any marker character immediately inside the comment).

I don't believe we have ever actually offered OSVW to guests, despite
the pretence of being able to.  ISTR it was always clobbered before
being given to a guest.

Having said that, we should be advertising OSVW.  It's entire purpose is
to tell the OS that there is something it can do to manually work round
a specific erratum.  OTOH, making this migrate safe is liable to be very
complicated...

~Andrew

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

Re: [PATCH 2/2] libxl: fix osvm cpuid flag

[Marek Marczykowski-Górecki]

[-- Attachment #1.1: Type: text/plain, Size: 1260 bytes --]

On Wed, Jun 28, 2017 at 11:16:33AM +0100, Andrew Cooper wrote:
> On 28/06/17 07:09, Jan Beulich wrote:
> >>>> Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> 06/28/17 3:09 AM >>>
> >> It's bit 9 not 10 (which is ibs).
> > Indeed, but shouldn't it rather be removed? We don't expose it from the
> > hypervisor at all anymore:
> >
> > XEN_CPUFEATURE(OSVW,          3*32+ 9) /*   OS Visible Workaround */
> >
> > (note the absence of any marker character immediately inside the comment).
> 
> I don't believe we have ever actually offered OSVW to guests, despite
> the pretence of being able to.  ISTR it was always clobbered before
> being given to a guest.
> 
> Having said that, we should be advertising OSVW.  It's entire purpose is
> to tell the OS that there is something it can do to manually work round
> a specific erratum.  OTOH, making this migrate safe is liable to be very
> complicated...

I don't have opinion on either approach here, but the current state is
clearly wrong. You've got two versions of the patch, choose one ;)

-- 
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

Re: [PATCH 2/2] libxl: fix osvm cpuid flag

[Andrew Cooper]

On 28/06/17 17:14, Marek Marczykowski-Górecki wrote:
> On Wed, Jun 28, 2017 at 11:16:33AM +0100, Andrew Cooper wrote:
>> On 28/06/17 07:09, Jan Beulich wrote:
>>>>>> Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> 06/28/17 3:09 AM >>>
>>>> It's bit 9 not 10 (which is ibs).
>>> Indeed, but shouldn't it rather be removed? We don't expose it from the
>>> hypervisor at all anymore:
>>>
>>> XEN_CPUFEATURE(OSVW,          3*32+ 9) /*   OS Visible Workaround */
>>>
>>> (note the absence of any marker character immediately inside the comment).
>> I don't believe we have ever actually offered OSVW to guests, despite
>> the pretence of being able to.  ISTR it was always clobbered before
>> being given to a guest.
>>
>> Having said that, we should be advertising OSVW.  It's entire purpose is
>> to tell the OS that there is something it can do to manually work round
>> a specific erratum.  OTOH, making this migrate safe is liable to be very
>> complicated...
> I don't have opinion on either approach here, but the current state is
> clearly wrong. You've got two versions of the patch, choose one ;)
>

I'd prefer this version of the patch, so it doesn't suddenly remove a
piece of libxl API, but it is up to Wei / Ian at the end of the day.

One option which was being discussed in the context of my CPUID (part 3)
work was to automatically this list of keywords.

~Andrew

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

Re: [PATCH 2/2] libxl: fix osvm cpuid flag

[Wei Liu]

On Wed, Jun 28, 2017 at 05:20:38PM +0100, Andrew Cooper wrote:
> On 28/06/17 17:14, Marek Marczykowski-Górecki wrote:
> > On Wed, Jun 28, 2017 at 11:16:33AM +0100, Andrew Cooper wrote:
> >> On 28/06/17 07:09, Jan Beulich wrote:
> >>>>>> Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> 06/28/17 3:09 AM >>>
> >>>> It's bit 9 not 10 (which is ibs).
> >>> Indeed, but shouldn't it rather be removed? We don't expose it from the
> >>> hypervisor at all anymore:
> >>>
> >>> XEN_CPUFEATURE(OSVW,          3*32+ 9) /*   OS Visible Workaround */
> >>>
> >>> (note the absence of any marker character immediately inside the comment).
> >> I don't believe we have ever actually offered OSVW to guests, despite
> >> the pretence of being able to.  ISTR it was always clobbered before
> >> being given to a guest.
> >>
> >> Having said that, we should be advertising OSVW.  It's entire purpose is
> >> to tell the OS that there is something it can do to manually work round
> >> a specific erratum.  OTOH, making this migrate safe is liable to be very
> >> complicated...
> > I don't have opinion on either approach here, but the current state is
> > clearly wrong. You've got two versions of the patch, choose one ;)
> >
> 
> I'd prefer this version of the patch, so it doesn't suddenly remove a
> piece of libxl API, but it is up to Wei / Ian at the end of the day.

Keeping it is better. It doesn't really make any difference to the guest
but some tools might complain if we remove it.

> 
> One option which was being discussed in the context of my CPUID (part 3)
> work was to automatically this list of keywords.
> 

"generate"?

And yes, I fully support this work. ;-)

> ~Andrew

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

Re: [PATCH 2/2] libxl: fix osvm cpuid flag

[Andrew Cooper]

On 28/06/17 18:51, Wei Liu wrote:
> On Wed, Jun 28, 2017 at 05:20:38PM +0100, Andrew Cooper wrote:
>> On 28/06/17 17:14, Marek Marczykowski-Górecki wrote:
>>> On Wed, Jun 28, 2017 at 11:16:33AM +0100, Andrew Cooper wrote:
>>>> On 28/06/17 07:09, Jan Beulich wrote:
>>>>>>>> Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> 06/28/17 3:09 AM >>>
>>>>>> It's bit 9 not 10 (which is ibs).
>>>>> Indeed, but shouldn't it rather be removed? We don't expose it from the
>>>>> hypervisor at all anymore:
>>>>>
>>>>> XEN_CPUFEATURE(OSVW,          3*32+ 9) /*   OS Visible Workaround */
>>>>>
>>>>> (note the absence of any marker character immediately inside the comment).
>>>> I don't believe we have ever actually offered OSVW to guests, despite
>>>> the pretence of being able to.  ISTR it was always clobbered before
>>>> being given to a guest.
>>>>
>>>> Having said that, we should be advertising OSVW.  It's entire purpose is
>>>> to tell the OS that there is something it can do to manually work round
>>>> a specific erratum.  OTOH, making this migrate safe is liable to be very
>>>> complicated...
>>> I don't have opinion on either approach here, but the current state is
>>> clearly wrong. You've got two versions of the patch, choose one ;)
>>>
>> I'd prefer this version of the patch, so it doesn't suddenly remove a
>> piece of libxl API, but it is up to Wei / Ian at the end of the day.
> Keeping it is better. It doesn't really make any difference to the guest
> but some tools might complain if we remove it.
>
>> One option which was being discussed in the context of my CPUID (part 3)
>> work was to automatically this list of keywords.
>>
> "generate"?

Oops.  Yes.

> And yes, I fully support this work. ;-)

It's not a fully-formed idea yet.  It wouldn't easily deal with
duplicate names, and won't deal with CPUID content other than the
feature flags known to Xen at build time.

I eventually want to be able to express things like cpuid="pmu=3" to
enable vPMU emulating version 3.

~Andrew

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