Further changes will rely on MSR entries being sorted, so add a test
to assert it.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Zapping leaf data for out of range leaves is just one half of it: To
avoid guests (bogusly or worse) inferring information from mere leaf
presence, also shrink maximum indicators such that the respective
trailing entry is not all blank (unless of course it's the initial
subleaf of a leaf that's not the final one).
This is also in preparation of bumping the maximum basic leaf we
support, to ensure guests not getting exposed related features won't
observe a change in behavior.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
... including serialisation/deserialisation logic and unit tests.
There is no current way to configure this MSR correctly for guests.
The toolstack side this logic needs building, which is far easier to
do with it in place.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The existing x86_cpuid_copy_to_buffer() does produce sorted results, and we're
about to start relying on this. Extend the unit tests.
As test_cpuid_serialise_success() is a fairly limited set of synthetic
examples right now, introduce test_cpuid_current() to operate on the full
policy for the current CPU.
Tweak the fail() macro to allow for simplified control flow.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Release-acked-by: Paul Durrant <paul@xen.org>
With the max base leaf using 0, this one should be using the extended
leaf counterpart thereof, rather than some arbitrary extended leaf.
Fixes: 588a966a57 ("libx86: Introduce x86_cpu_policies_are_compatible()")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
This helper will eventually be the core "can a guest configured like this run
on the CPU?" logic. For now, it is just enough of a stub to allow us to
replace the hypercall interface while retaining the previous behaviour.
It will be expanded as various other bits of CPUID handling get cleaned up.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Release-acked-by: Juergen Gross <jgross@suse.com>
Despite %.12s properly limiting the number of characters read from
ident[], gcc 9 (at least up to 9.2.0) warns about the strings not
being nul-terminated:
test-cpu-policy.c:64:18: error: '%.12s' directive argument is not a nul-terminated string [-Werror=format-overflow=]
64 | fail(" Test '%.12s', expected vendor %u, got %u\n",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
test-cpu-policy.c:20:12: note: in definition of macro 'fail'
20 | printf(fmt, ##__VA_ARGS__); \
| ^~~
test-cpu-policy.c:64:27: note: format string is defined here
64 | fail(" Test '%.12s', expected vendor %u, got %u\n",
| ^~~~~
test-cpu-policy.c:44:7: note: referenced argument declared here
44 | } tests[] = {
| ^~~~~
The issue was reported against gcc in their bugzilla (bug 91667).
Re-order array entries, oddly enough suppressing the warning.
Reported-by: Christopher Clark <christopher.w.clark@gmail.com>
Reported-by: Dario Faggioli <dfaggioli@suse.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Add x86 architecture support for a new processor: Hygon Dhyana Family
18h. To make Hygon initialization flow more clear, carve out code from
amd.c into a separate file hygon.c, and remove unnecessary code for
Hygon Dhyana.
To identify Hygon Dhyana CPU, add a new vendor type X86_VENDOR_HYGON
and vendor ID "HygonGenuine" for system recognition, and fit the new
x86 vendor lookup mechanism.
Hygon can fully use the function early_init_amd(), so make this common
function non-static and direct call it from Hygon code.
Add a separate hygon_get_topology(), which calculate phys_proc_id from
AcpiId[6](see reference [1]).
Reference:
[1] https://git.kernel.org/tip/e0ceeae708cebf22c990c3d703a4ca187dc837f5
Signed-off-by: Pu Wen <puwen@hygon.cn>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
[Rebase over 0cd074144c "x86/cpu: Renumber X86_VENDOR_* to form a bitmap" and
64933920c9 "x86/cpu: Drop cpu_devs[] and $VENDOR_init_cpu() hooks"]
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
When merging a levelled policy, stale out-of-range leaves may remain.
Introduce a helper to clear them, and test a number of the subtle corner
cases.
The logic based on cpuid_policy_xstates() is liable to need changing when XCR0
has bit 63 defined. Leave BUILD_BUG_ON()'s behind with comments in all all
impacted areas, which includes in x86_cpuid_policy_fill_native().
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
x86_cpuid_copy_to_buffer() currently serialises the full content of the
various subleaf unions. While leaves 4, 0xb and 0xd don't have a concrete
max_subleaf field, they do have well defined upper bounds.
Diffing the results of `xen-cpuid -p` shows the resulting saving:
@@ -1,5 +1,5 @@
Xen reports there are maximum 114 leaves and 1 MSRs
-Raw policy: 93 leaves, 1 MSRs
+Raw policy: 38 leaves, 1 MSRs
CPUID:
leaf subleaf -> eax ebx ecx edx
00000000:ffffffff -> 00000016:756e6547:6c65746e:49656e69
@@ -32,7 +32,7 @@ Raw policy: 93 leaves, 1 MSRs
MSRs:
index -> value
000000ce -> 0000000080000000
-Host policy: 93 leaves, 1 MSRs
+Host policy: 33 leaves, 1 MSRs
CPUID:
leaf subleaf -> eax ebx ecx edx
00000000:ffffffff -> 0000000d:756e6547:6c65746e:49656e69
which is mostly due to no longer writing out 64 leaves for xstate when (on
this CoffeeLake system) 8 will do.
Extend the unit tests to cover empty and partially filled subleaf unions.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
These will be extended with further libx86 work.
Fix the sorting of the CPUID_GUEST_NR_* constants, noticed while writing the
unit tests.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>