x86/pv: Flush TLB in response to paging structure changes
authorAndrew Cooper <andrew.cooper3@citrix.com>
Mon, 19 Oct 2020 14:51:22 +0000 (15:51 +0100)
committerAndrew Cooper <andrew.cooper3@citrix.com>
Tue, 27 Oct 2020 17:39:11 +0000 (17:39 +0000)
commit16a20963b3209788f2c0d3a3eebb7d92f03f5883
tree5f919d213d93cf2c8a62f09024c33197aa189d9c
parent055e1c3a3d95b1e753148369fbc4ba48782dd602
x86/pv: Flush TLB in response to paging structure changes

With MMU_UPDATE, a PV guest can make changes to higher level pagetables.  This
is safe from Xen's point of view (as the update only affects guest mappings),
and the guest is required to flush (if necessary) after making updates.

However, Xen's use of linear pagetables (UPDATE_VA_MAPPING, GNTTABOP_map,
writeable pagetables, etc.) is an implementation detail outside of the
API/ABI.

Changes in the paging structure require invalidations in the linear pagetable
range for subsequent accesses into the linear pagetables to access non-stale
mappings.  Xen must provide suitable flushing to prevent intermixed guest
actions from accidentally accessing/modifying the wrong pagetable.

For all L2 and higher modifications, flush the TLB.  PV guests cannot create
L2 or higher entries with the Global bit set, so no mappings established in
the linear range can be global.  (This could in principle be an order 39 flush
starting at LINEAR_PT_VIRT_START, but no such mechanism exists in practice.)

Express the necessary flushes as a set of booleans which accumulate across the
operation.  Comment the flushing logic extensively.

This is XSA-286.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
xen/arch/x86/mm.c