Cc: David Chinner <dgc@...>, <xfs@...>, Xen-devel <xen-devel@...>, Linux Kernel Mailing List <linux-kernel@...>, Mark Williamson <mark.williamson@...>, Morten Bøgeskov <xen-users@...>, <xfs-masters@...>
I see.
Hm. Could there be a call to shoot down any lazy mappings of a page, so
the Xen pagetable code could use it on any pagetable page? Ideally one
that could be used on any page, but only causes expensive operations
where needed.
In general the lazy unmappings won't worry Xen. It's only for the
specific case of allocating memory for pagetables. Xen can do a bit of
extra optimisation for cross-cpu tlb flushes (if the target vcpus are
not currently running, then you don't need to do anything), but they're
still an expensive operation, so the optimisation is definitely useful.
Not easily. Xen doesn't use shadow pagetables. Instead, it gives the
guest domains direct access to the real CPU's pagetable, but makes sure
they're always mapped RO so that the hypervisor can control updates to
the pagetables (either by trapping writes or via explicit hypercalls).
This means that when constructing a new pagetable, Xen will verify that
all the mappings of pages making up the new pagetable are RO before
allowing it to be used. If there are stray RW mappings of those pages,
pagetable construction will fail.
Aside from XFS, the only other case I've found where there could be
stray RW mappings is when using high pages which are still in the kmap
cache; I added an explicit call to flush the kmap cache to handle this.
If vmap and kmap can be unified (at least the lazy unmap aspects of
them), then that would be a nice little cleanup.
J
-
