[lkml]   [2009]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH RFC] vm_unmap_aliases: allow callers to inhibit TLB flush
Nick Piggin wrote:
> Then what is the point of the vm_unmap_aliases? If you are doing it
> for security it won't work because other CPUs might still be able
> to write through dangling TLBs. If you are not doing it for
> security then it does not need to be done at all.

Xen will make sure any danging tlb entries are flushed before handing
the page out to anyone else.

> Unless it is something strange that Xen does with the page table
> structure and you just need to get rid of those?

Yeah. A pte pointing at a page holds a reference on it, saying that it
belongs to the domain. You can't return it to Xen until the refcount is 0.

>> (Xen does something like this internally to either defer or avoid many
>> expensive tlb operations.)
>>>> For Xen dom0, when someone does something like dma_alloc_coherent, we
>>>> allocate the memory as normal, and then swizzle the underlying physical
>>>> pages to be machine physically contiguous (vs contiguous pseudo-physical
>>>> guest memory), and within the addressable range for the device. In
>>>> order to do that, we need to make sure the pages are only mapped by the
>>>> linear mapping, and there are no other aliases.
>>> These are just stale aliases that will no longer be operated on
>>> unless there is a kernel bug -- so can you just live with them,
>>> or is it a security issue of memory access escaping its domain?
>> The underlying physical page is being exchanged, so the old page is
>> being returned to Xen's free page pool. It will refuse to do the
>> exchange if the guest still has pagetable references to the page.
> But it refuses to do this because it is worried about dangling TLBs?
> Or some implementation detail that can't handle the page table
> entries?

Right. The actual pte pointing at the page hold the reference. We need
to drop all the references before doing the exchange.

> Hmm. Let's just try to establish that it is really required first.

Well, its desireable anyway. The using IPI for any kind of tlb flushing
is pretty pessimal under Xen (or any virtual environment); Xen has a
much better idea about which real cpus have stale tlb state for which vcpus.

> Or... what if we just allow a compile and/or boot time flag to direct
> that it does not want lazy vmap unmapping and it will just revert to
> synchronous unmapping? If Xen needs lots of flushing anyway it might
> not be a win anyway.

That may be worth considering.


 \ /
  Last update: 2009-02-19 20:13    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean