On 31.05.23 20:14, Borislav Petkov wrote:
On Fri, May 19, 2023 at 08:36:34PM +0200, Janusz Krzysztofik wrote:diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h index 15ae4d6ba4768..56466afd04307 100644 --- a/arch/x86/include/asm/pgtable.h +++ b/arch/x86/include/asm/pgtable.h @@ -654,8 +654,10 @@ static inline pmd_t pmd_modify(pmd_t pmd, pgprot_t newprot) #define pgprot_modify pgprot_modify static inline pgprot_t pgprot_modify(pgprot_t oldprot, pgprot_t newprot) { - pgprotval_t preservebits = pgprot_val(oldprot) & _PAGE_CHG_MASK; - pgprotval_t addbits = pgprot_val(newprot) & ~_PAGE_CHG_MASK; + unsigned long mask = _PAGE_CHG_MASK | _PAGE_CACHE_MASK; + + pgprotval_t preservebits = pgprot_val(oldprot) & mask; + pgprotval_t addbits = pgprot_val(newprot) & ~mask; return __pgprot(preservebits | addbits); }--This certainly needs Jürgen and he's on CC already, moving him to To:. Also, why isn't this a Xen-specific fix but you're keeping _PAGE_PAT for baremetal too, i.e., modifying the generic function?
As described in the commit message, this only works on bare metal due to the PAT bit not being needed for WC mappings. Making this patch Xen specific would try to cure the symptoms without fixing the underlying problem: _PAGE_PAT should be regarded the same way as the bits for caching mode (_PAGE_CHG_MASK). In case a WP or WT mapped memory area would be mmap()-ed on bare metal, the result would be a WC or UC mapped memory area in userland. This isn't as problematic as the case under Xen, but it still results in worse performance than necessary. IOW: Acked-by: Juergen Gross <jgross@xxxxxxxx> Juergen
Attachment:
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
