[PATCH] x86/mm: avoid playing with directmap when self-snoop can be relied upon

[PATCH] x86/mm: avoid playing with directmap when self-snoop can be relied upon

[Jan Beulich]

The set of systems affected by XSA-345 would have been smaller is we had
this in place already: When the processor is capable of dealing with
mismatched cacheability, there's no extra work we need to carry out.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -795,6 +795,9 @@ static int update_xen_mappings(unsigned
     unsigned long xen_va =
         XEN_VIRT_START + ((mfn - PFN_DOWN(xen_phys_start)) << PAGE_SHIFT);
 
+    if ( boot_cpu_has(X86_FEATURE_XEN_SELFSNOOP) )
+        return 0;
+
     if ( unlikely(alias) && cacheattr )
         err = map_pages_to_xen(xen_va, _mfn(mfn), 1, 0);
     if ( !err )
@@ -802,6 +805,7 @@ static int update_xen_mappings(unsigned
                      PAGE_HYPERVISOR | cacheattr_to_pte_flags(cacheattr));
     if ( unlikely(alias) && !cacheattr && !err )
         err = map_pages_to_xen(xen_va, _mfn(mfn), 1, PAGE_HYPERVISOR);
+
     return err;
 }
 

Re: [PATCH] x86/mm: avoid playing with directmap when self-snoop can be relied upon

[Roger Pau Monné]

On Tue, Oct 20, 2020 at 03:51:18PM +0200, Jan Beulich wrote:
> The set of systems affected by XSA-345 would have been smaller is we had
> this in place already: When the processor is capable of dealing with
> mismatched cacheability, there's no extra work we need to carry out.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Roger Pau Monné <roger.pau@citrix.com>

I guess it's not worth using the alternative framework to patch this
up at boot in order to avoid the call in the first place?

Thanks, Roger.

Re: [PATCH] x86/mm: avoid playing with directmap when self-snoop can be relied upon

[Jan Beulich]

On 21.10.2020 17:23, Roger Pau Monné wrote:
> On Tue, Oct 20, 2020 at 03:51:18PM +0200, Jan Beulich wrote:
>> The set of systems affected by XSA-345 would have been smaller is we had
>> this in place already: When the processor is capable of dealing with
>> mismatched cacheability, there's no extra work we need to carry out.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Acked-by: Roger Pau Monné <roger.pau@citrix.com>

Thanks.

> I guess it's not worth using the alternative framework to patch this
> up at boot in order to avoid the call in the first place?

It being non-trivial (afaict) in cases like this one makes me
think that the price to do so would be higher than the gain
to be had. But I might be wrong ...

Jan