Messages in this thread | | | Date | Wed, 8 Feb 2023 16:19:42 +0100 | Subject | Re: [PATCH 0/6] x86/mtrr: fix handling with PAT but without MTRR | From | Juergen Gross <> |
| |
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
[unhandled content-type:application/pgp-keys][unhandled content-type:application/pgp-signature] | |