Re: [Xen-devel] [PATCH v2 1/7] x86: slightly reduce Meltdown band-aid overhead

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 07.02.18 at 20:35, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 07/02/18 16:12, Jan Beulich wrote:
>> I'm not sure why I didn't do this right away: By avoiding the use of
>> global PTEs in the cloned directmap, there's no need to fiddle with
>> CR4.PGE on any of the entry paths. Only the exit paths need to flush
>> global mappings.
>>
>> The reduced flushing, however, implies that we now need to have
>> interrupts off on all entry paths until after the page table switch, so
>> that flush IPIs can't arrive with the restricted page tables still
>> active, but only a non-global flush happening with the CR3 loads. Along
>> those lines the "sync" IPI after L4 entry updates now needs to become a
>> real (and global) flush IPI, so that inside Xen we'll also pick up such
>> changes.
> 
> Actually, on second consideration, why does reenabling interrupts need
> to be deferred?
> 
> The safety of the sync_guest path (which previously entered Xen, did
> nothing, and exited again) relied on the entry part flushing global
> mappings for safety, as the return-to-xen path doesn't necessarily
> switch mappings.
> 
> However, the first hunk upgrading the "do nothing" to a proper global
> flush, covers that case.
> 
> I don't see anything else which affects the safety of taking TLB flush
> IPIs early in the entry-from-guest path.  What am I missing?

If a sync IPI arrives before we switch away from the restricted page
tables, the processor may re-fetch a global entry from those tables
through an L4 with the sync IPI is supposed to tell the processor to
get rid of (or modify). The subsequent CR3 write won't invalidate such
a TLB entry, and hence whatever we do internally may reference a
stale mapping.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel