forked from xen-project/xen
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
x86/cpuid: support LFENCE always serialising CPUID bit
AMD Milan (Zen3) CPUs have an LFENCE Always Serialising CPUID bit in leaf 80000021.eax. Previous AMD versions used to have a user settable bit in DE_CFG MSR to select whether LFENCE was dispatch serialising, which Xen always attempts to set. The forcefully always on setting is due to the addition of SEV-SNP so that a VMM cannot break the confidentiality of a guest. In order to support this new CPUID bit move the LFENCE_DISPATCH synthetic CPUID bit to map the hardware bit (leaving a hole in the synthetic range) and either rely on the bit already being set by the native CPUID output, or attempt to fake it in Xen by modifying the DE_CFG MSR. This requires adding one more entry to the featureset to support leaf 80000021.eax. The bit is always exposed to guests by default even if the underlying hardware doesn't support leaf 80000021. Note that Xen doesn't allow guests to change the DE_CFG value, so once set by Xen LFENCE will always be serialising. Note that the access to DE_CFG by guests is left as-is: reads will unconditionally return LFENCE_SERIALISE bit set, while writes are silently dropped. Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> [Always expose to guests by default] Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> (cherry picked from commit e9b4fe2) x86/cpuid: do not expand max leaves on restore When restoring limit the maximum leaves to the ones supported by Xen 4.12 in order to not expand the maximum leaves a guests sees. Note this is unlikely to cause real issues. Guests restored from Xen versions 4.13 or greater will contain CPUID data on the stream that will override the values set by xc_cpuid_apply_policy. Fixes: e9b4fe2 ("x86/cpuid: support LFENCE always serialising CPUID bit") Reported-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com> (cherry picked from commit 111c8c3) tools/libxenguest: Fix max_extd_leaf calculation for legacy restore 0x1c is lower than any value which will actually be observed in p->extd.max_leaf, but higher than the logical 9 leaves worth of extended data on Intel systems, causing x86_cpuid_copy_to_buffer() to fail with -ENOBUFS. Correct the calculation. The problem was first noticed in c/s 3499044 "libxl: don't ignore the return value from xc_cpuid_apply_policy" but introduced earlier. Fixes: 111c8c3 ("x86/cpuid: do not expand max leaves on restore") Reported-by: Olaf Hering <olaf@aepfle.de> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> (cherry picked from commit 5fa174c) tools/guest: Fix comment regarding CPUID compatibility It was Xen 4.14 where CPUID data was added to the migration stream, and 4.13 that we need to worry about with regards to compatibility. Xen 4.12 isn't relevant. Expand and correct the commentary. Fixes: 111c8c3 ("x86/cpuid: do not expand max leaves on restore") Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com> (cherry picked from commit 820cc39)
- Loading branch information
Showing
9 changed files
with
90 additions
and
7 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters