mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Juergen Gross <jgross@suse.com>
To: "Michael Kelley (LINUX)" <mikelley@microsoft.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"x86@kernel.org" <x86@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH v3 03/12] x86/mtrr: support setting MTRR state for software defined MTRRs
Date: Mon, 27 Feb 2023 08:13:42 +0100	[thread overview]
Message-ID: <ef7510e0-958f-6c17-06c4-19e2506496ad@suse.com> (raw)
In-Reply-To: <BYAPR21MB16886880C8B115233F48C3CFD7AE9@BYAPR21MB1688.namprd21.prod.outlook.com>


[-- Attachment #1.1.1: Type: text/plain, Size: 5053 bytes --]

On 26.02.23 18:12, Michael Kelley (LINUX) wrote:
> From: Juergen Gross <jgross@suse.com> Sent: Thursday, February 23, 2023 1:33 AM
>>
>> When running virtualized, MTRR access can be reduced (e.g. in Xen PV
>> guests or when running as a SEV-SNP guest under Hyper-V). Typically
>> the hypervisor will reset the MTRR feature in CPUID data, resulting
>> in no MTRR memory type information being available for the kernel.
>>
>> This has turned out to result in problems:
>>
>> - Hyper-V SEV-SNP guests using uncached mappings where they shouldn't
>> - Xen PV dom0 mapping memory as WB which should be UC- instead
>>
>> Solve those problems by supporting to set a static MTRR state,
>> overwriting the empty state used today. In case such a state has been
>> set, don't call get_mtrr_state() in mtrr_bp_init(). The set state
>> will only be used by mtrr_type_lookup(), as in all other cases
>> mtrr_enabled() is being checked, which will return false. Accept the
>> overwrite call only for selected cases when running as a guest.
>> Disable X86_FEATURE_MTRR in order to avoid any MTRR modifications by
>> just refusing them.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>> V2:
>> - new patch
>> V3:
>> - omit fixed MTRRs, as those are currently not needed
>> - disable X86_FEATURE_MTRR instead of testing it
>> - provide a stub for !CONFIG_MTRR (Michael Kelley)
>> - use cpu_feature_enabled() (Boris Petkov)
>> - add tests for mtrr_overwrite_state() being allowed (Boris Petkov)
>> ---
>>   arch/x86/include/asm/mtrr.h        |  8 ++++++
>>   arch/x86/kernel/cpu/mtrr/generic.c | 43 ++++++++++++++++++++++++++++++
>>   arch/x86/kernel/cpu/mtrr/mtrr.c    |  9 +++++++
>>   arch/x86/kernel/setup.c            |  2 ++
>>   4 files changed, 62 insertions(+)
>>
>> diff --git a/arch/x86/include/asm/mtrr.h b/arch/x86/include/asm/mtrr.h
>> index f0eeaf6e5f5f..f1cb81330a64 100644
>> --- a/arch/x86/include/asm/mtrr.h
>> +++ b/arch/x86/include/asm/mtrr.h
>> @@ -31,6 +31,8 @@
>>    */
>>   # ifdef CONFIG_MTRR
>>   void mtrr_bp_init(void);
>> +void mtrr_overwrite_state(struct mtrr_var_range *var, unsigned int num_var,
>> +			  mtrr_type def_type);
>>   extern u8 mtrr_type_lookup(u64 addr, u64 end, u8 *uniform);
>>   extern void mtrr_save_fixed_ranges(void *);
>>   extern void mtrr_save_state(void);
>> @@ -48,6 +50,12 @@ void mtrr_disable(void);
>>   void mtrr_enable(void);
>>   void mtrr_generic_set_state(void);
>>   #  else
>> +static inline void mtrr_overwrite_state(struct mtrr_var_range *var,
>> +					unsigned int num_var,
>> +					mtrr_type def_type)
>> +{
>> +}
>> +
>>   static inline u8 mtrr_type_lookup(u64 addr, u64 end, u8 *uniform)
>>   {
>>   	/*
>> diff --git a/arch/x86/kernel/cpu/mtrr/generic.c b/arch/x86/kernel/cpu/mtrr/generic.c
>> index ee09d359e08f..40c59d522f57 100644
>> --- a/arch/x86/kernel/cpu/mtrr/generic.c
>> +++ b/arch/x86/kernel/cpu/mtrr/generic.c
>> @@ -8,10 +8,12 @@
>>   #include <linux/init.h>
>>   #include <linux/io.h>
>>   #include <linux/mm.h>
>> +#include <linux/cc_platform.h>
>>
>>   #include <asm/processor-flags.h>
>>   #include <asm/cacheinfo.h>
>>   #include <asm/cpufeature.h>
>> +#include <asm/hypervisor.h>
>>   #include <asm/tlbflush.h>
>>   #include <asm/mtrr.h>
>>   #include <asm/msr.h>
>> @@ -240,6 +242,47 @@ static u8 mtrr_type_lookup_variable(u64 start, u64 end, u64
>> *partial_end,
>>   	return mtrr_state.def_type;
>>   }
>>
>> +/**
>> + * mtrr_overwrite_state - set static MTRR state
>> + *
>> + * Used to set MTRR state via different means (e.g. with data obtained from
>> + * a hypervisor).
>> + * Is allowed only for special cases when running virtualized. Must be called
>> + * from the x86_init.hyper.init_platform() hook. X86_FEATURE_MTRR must be off.
>> + */
>> +void mtrr_overwrite_state(struct mtrr_var_range *var, unsigned int num_var,
>> +			  mtrr_type def_type)
>> +{
>> +	unsigned int i;
>> +
>> +	if (WARN_ON(mtrr_state_set ||
>> +		    hypervisor_is_type(X86_HYPER_NATIVE) ||
>> +		    !cpu_feature_enabled(X86_FEATURE_HYPERVISOR) ||
>> +		    (!cc_platform_has(CC_ATTR_GUEST_SEV_SNP) &&
> 
> With current upstream code, this test doesn't allow Hyper-V SNP vTOM VMs
> to do the overwrite, as current upstream vTOM code doesn't participate in the
> cc_platform_has() mechanism.  That's being reworked in a separate patch
> set.  Can you add this test to cover the SNP vTOM case?
> 
> 		    !hv_is_isolation_supported() &&
> 
> This is the same test used in __set_memory_enc_dec(), for example.  You'll
> have to add #include <asm/mshyperv.h>.  There's already a stub that returns
> 'false' so that everything works when building with CONFIG_HYPERV=n.

Yes, this was an open question. In case nobody objects, I'll do the
modification.

> Once my other patch set is accepted, I'll revise this to remove use of
> hv_is_isolation_supported() outside of Hyper-V specific code, and use
> the newer cc_platform_has() instead.

Thanks,


Juergen

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3149 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

  reply	other threads:[~2023-02-27  7:13 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-23  9:32 [PATCH v3 00/12] x86/mtrr: fix handling with PAT but without MTRR Juergen Gross
2023-02-23  9:32 ` [PATCH v3 01/12] x86/mtrr: split off physical address size calculation Juergen Gross
2023-02-23  9:32 ` [PATCH v3 02/12] x86/mtrr: optimize mtrr_calc_physbits() Juergen Gross
2023-02-23  9:32 ` [PATCH v3 03/12] x86/mtrr: support setting MTRR state for software defined MTRRs Juergen Gross
2023-02-26 17:12   ` Michael Kelley (LINUX)
2023-02-27  7:13     ` Juergen Gross [this message]
2023-02-23  9:32 ` [PATCH v3 04/12] x86/hyperv: set MTRR state when running as SEV-SNP Hyper-V guest Juergen Gross
2023-02-23  9:32 ` [PATCH v3 05/12] x86/xen: set MTRR state when running as Xen PV initial domain Juergen Gross
     [not found]   ` <a7897030-d420-a741-074a-6e21e7c1629b@oracle.com>
2023-02-27  7:12     ` Juergen Gross
2023-02-27 13:52       ` Boris Ostrovsky
2023-02-27 13:56         ` Juergen Gross
2023-02-23  9:32 ` [PATCH v3 06/12] x86/mtrr: replace vendor tests in MTRR code Juergen Gross
2023-02-23  9:32 ` [PATCH v3 07/12] x86/mtrr: allocate mtrr_value array dynamically Juergen Gross
2023-02-23  9:32 ` [PATCH v3 08/12] x86/mtrr: add get_effective_type() service function Juergen Gross
2023-02-23  9:32 ` [PATCH v3 09/12] x86/mtrr: construct a memory map with cache modes Juergen Gross
2023-02-23  9:32 ` [PATCH v3 10/12] x86/mtrr: use new cache_map in mtrr_type_lookup() Juergen Gross
2023-02-23 19:24   ` Michael Kelley (LINUX)
2023-02-24  5:48     ` Juergen Gross
2023-02-24  6:37   ` [PATCH v3.1 " Juergen Gross
2023-02-26 17:00     ` Michael Kelley (LINUX)
2023-02-27  7:11       ` Juergen Gross
2023-02-23  9:32 ` [PATCH v3 11/12] x86/mtrr: don't let mtrr_type_lookup() return MTRR_TYPE_INVALID Juergen Gross
2023-02-23  9:32 ` [PATCH v3 12/12] x86/mm: only check uniform after calling mtrr_type_lookup() Juergen Gross

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=ef7510e0-958f-6c17-06c4-19e2506496ad@suse.com \
    --to=jgross@suse.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mikelley@microsoft.com \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.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

all inboxes | Powered by JetHome®