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: "lists@nerdbynature.de" <lists@nerdbynature.de>,
"torvalds@linux-foundation.org" <torvalds@linux-foundation.org>,
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>,
Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH 0/6] x86/mtrr: fix handling with PAT but without MTRR
Date: Wed, 8 Feb 2023 16:19:42 +0100 [thread overview]
Message-ID: <6b833946-3932-11ef-173a-f1d29f4ec137@suse.com> (raw)
In-Reply-To: <BYAPR21MB16886C389C45912DB4EBA362D7D89@BYAPR21MB1688.namprd21.prod.outlook.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 1764 bytes --]
On 08.02.23 16:08, Michael Kelley (LINUX) wrote:
> From: Juergen Gross <jgross@suse.com> Sent: Monday, February 6, 2023 11:29 PM
>>
>> This series tries to fix the rather special case of PAT being available
>> without having MTRRs (either due to CONFIG_MTRR being not set, or
>> because the feature has been disabled e.g. by a hypervisor).
>>
>> The main use cases are Xen PV guests and SEV-SNP guests running under
>> Hyper-V.
>>
>> Patch 2 seems to be a little hacky, as it special cases only
>> memtype_reserve() and memtype_free(), but OTOH this doesn't seem to
>> be worse than in previous days, where PAT was disabled when MTRRs
>> haven't been available.
>>
>> My tests with Xen didn't show any problems, but I'm rather sure I
>> couldn't cover all corner cases.
>
> I tested this patch set with Hyper-V SEV-SNP guests, and ioremap_cache()
> is correctly mapping as WB.
>
> As an observation, with commit 90b926e68f50 it was nice to have
> the memtype entries created. I could check for any unexpected
> mappings in /sys/kernel/debug/x86/pat_memtype_list. With this patch
> set, we're back to not creating those entries.
I'm currently looking into the solution mentioned below. This might turn
out to be much cleaner.
>
> Michael
>
>>
>> The only cleaner solution I could think of would be to introduce MTRR
>> read-only access. It would theoretically be possible to get the actual
>> MTRR contents for the variable MTRRs from Xen, but I'm not sure this
>> is really the way to go.
>>
>> For the SEV-SNP case with Hyper-V I guess such a read-only mode could
>> be rather simple, but I'm really not sure this would cover all needed
>> corner cases (I'd basically say always "WB" in that case).
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 --]
prev parent reply other threads:[~2023-02-08 15:19 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-07 7:28 Juergen Gross
2023-02-07 7:28 ` [PATCH 1/6] x86/mtrr: make mtrr_enabled() non-static Juergen Gross
2023-02-07 7:28 ` [PATCH 2/6] x86/pat: check for MTRRs enabled in memtype_reserve() Juergen Gross
2023-02-07 8:49 ` Ingo Molnar
2023-02-07 9:12 ` Juergen Gross
2023-02-07 11:31 ` Borislav Petkov
2023-02-07 7:28 ` [PATCH 3/6] x86/mtrr: revert commit 90b926e68f50 Juergen Gross
2023-02-07 7:29 ` [PATCH 4/6] x86/mtrr: don't let mtrr_type_lookup() return MTRR_TYPE_INVALID Juergen Gross
2023-02-07 16:20 ` Linus Torvalds
2023-02-08 6:20 ` Juergen Gross
2023-02-08 15:42 ` Linus Torvalds
2023-02-07 7:29 ` [PATCH 5/6] x86/mm: only check uniform after calling mtrr_type_lookup() Juergen Gross
2023-02-07 11:42 ` Borislav Petkov
2023-02-07 11:54 ` Juergen Gross
2023-02-07 12:21 ` Borislav Petkov
2023-02-08 1:13 ` Kani, Toshi
2023-02-07 7:29 ` [PATCH 6/6] x86/mtrr: drop sanity check in mtrr_type_lookup_fixed() Juergen Gross
2023-02-08 15:08 ` [PATCH 0/6] x86/mtrr: fix handling with PAT but without MTRR Michael Kelley (LINUX)
2023-02-08 15:19 ` Juergen Gross [this message]
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=6b833946-3932-11ef-173a-f1d29f4ec137@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=lists@nerdbynature.de \
--cc=luto@kernel.org \
--cc=mikelley@microsoft.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--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®