[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6b833946-3932-11ef-173a-f1d29f4ec137@suse.com>
Date: Wed, 8 Feb 2023 16:19:42 +0100
From: Juergen Gross <jgross@...e.com>
To: "Michael Kelley (LINUX)" <mikelley@...rosoft.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"x86@...nel.org" <x86@...nel.org>
Cc: "lists@...dbynature.de" <lists@...dbynature.de>,
"torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>,
"H. Peter Anvin" <hpa@...or.com>,
Andy Lutomirski <luto@...nel.org>,
Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH 0/6] x86/mtrr: fix handling with PAT but without MTRR
On 08.02.23 16:08, Michael Kelley (LINUX) wrote:
> From: Juergen Gross <jgross@...e.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
Download attachment "OpenPGP_0xB0DE9DD628BF132F.asc" of type "application/pgp-keys" (3099 bytes)
Download attachment "OpenPGP_signature" of type "application/pgp-signature" (496 bytes)
Powered by blists - more mailing lists