[v5,05/15] x86/hyperv: set MTRR state when running as SEV-SNP Hyper-V guest

Message ID 20230401063652.23522-6-jgross@suse.com
State New
Headers
Series x86/mtrr: fix handling with PAT but without MTRR |

Commit Message

Juergen Gross April 1, 2023, 6:36 a.m. UTC
  In order to avoid mappings using the UC- cache attribute, set the
MTRR state to use WB caching as the default.

This is needed in order to cope with the fact that PAT is enabled,
while MTRRs are not supported by the hypervisor.

Fixes: 90b926e68f50 ("x86/pat: Fix pat_x_mtrr_type() for MTRR disabled case")
Signed-off-by: Juergen Gross <jgross@suse.com>
Tested-by: Michael Kelley <mikelley@microsoft.com>
---
V2:
- new patch
---
 arch/x86/kernel/cpu/mshyperv.c | 4 ++++
 1 file changed, 4 insertions(+)
  

Comments

Michael Kelley (LINUX) April 2, 2023, 2:36 a.m. UTC | #1
From: Juergen Gross <jgross@suse.com> Sent: Friday, March 31, 2023 11:37 PM
> 
> In order to avoid mappings using the UC- cache attribute, set the
> MTRR state to use WB caching as the default.
> 
> This is needed in order to cope with the fact that PAT is enabled,
> while MTRRs are not supported by the hypervisor.
> 
> Fixes: 90b926e68f50 ("x86/pat: Fix pat_x_mtrr_type() for MTRR disabled case")
> Signed-off-by: Juergen Gross <jgross@suse.com>
> Tested-by: Michael Kelley <mikelley@microsoft.com>

I've tested the full v5 series in a Hyper-V SEV-SNP guest with vTOM.  All looks
good.  The following output appears in dmesg, which I think matches expectations:

[    0.004000] MTRR map: 0 entries (0 fixed + 0 variable; max 0), built from 0 variable MTRRs
[    0.004000] MTRRs set to read-only
[    0.004000] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT

The page attributes listed in /sys/kernel/debug/x86/pat_memtype_list are
"write-back" in the expected cases, and the "mtrr" x86 feature no longer appears
in the "flags" output of "lscpu" or /proc/cpuinfo.  /proc/mtrr does not exist, again
as expected.

> ---
> V2:
> - new patch
> ---
>  arch/x86/kernel/cpu/mshyperv.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
> index f36dc2f796c5..0a6cc3cf8919 100644
> --- a/arch/x86/kernel/cpu/mshyperv.c
> +++ b/arch/x86/kernel/cpu/mshyperv.c
> @@ -34,6 +34,7 @@
>  #include <clocksource/hyperv_timer.h>
>  #include <asm/numa.h>
>  #include <asm/coco.h>
> +#include <asm/mtrr.h>
> 
>  /* Is Linux running as the root partition? */
>  bool hv_root_partition;
> @@ -408,6 +409,9 @@ static void __init ms_hyperv_init_platform(void)
>  #ifdef CONFIG_SWIOTLB
>  			swiotlb_unencrypted_base =
> ms_hyperv.shared_gpa_boundary;
>  #endif
> +
> +			/* Set WB as the default cache mode. */
> +			mtrr_overwrite_state(NULL, 0, MTRR_TYPE_WRBACK);

The placement of this call needs to change due to a patch set I submitted and
that Boris has accepted into the 'tip' tree for the 6.4 merge window (so it's now
in linux-next).  The call should be placed in the function hv_vtom_init() in the
source file arch/x86/hyperv/ivm.c.  Anywhere in hv_vtom_init() is fine -- I would
suggest at the end.

Minor request: In a v6 of this patch set, please include me on all the patches in
the series so I can easily keep track of how it is progressing.

Michael

>  		}
>  		/* Isolation VMs are unenlightened SEV-based VMs, thus this check: */
>  		if (IS_ENABLED(CONFIG_AMD_MEM_ENCRYPT)) {
> --
> 2.35.3
  

Patch

diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index f36dc2f796c5..0a6cc3cf8919 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -34,6 +34,7 @@ 
 #include <clocksource/hyperv_timer.h>
 #include <asm/numa.h>
 #include <asm/coco.h>
+#include <asm/mtrr.h>
 
 /* Is Linux running as the root partition? */
 bool hv_root_partition;
@@ -408,6 +409,9 @@  static void __init ms_hyperv_init_platform(void)
 #ifdef CONFIG_SWIOTLB
 			swiotlb_unencrypted_base = ms_hyperv.shared_gpa_boundary;
 #endif
+
+			/* Set WB as the default cache mode. */
+			mtrr_overwrite_state(NULL, 0, MTRR_TYPE_WRBACK);
 		}
 		/* Isolation VMs are unenlightened SEV-based VMs, thus this check: */
 		if (IS_ENABLED(CONFIG_AMD_MEM_ENCRYPT)) {