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 --]
next prev parent 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®