Re: uvm object page remove question

[Chuck Silvers <chuq%chuq.com@localhost>]

On Wed, May 13, 2020 at 08:20:15PM +0200, Manuel Bouyer wrote:
> Hello,
> for Xen I need some non-standard VM operation: the tools want to map
> some Xen objects for which we don't have a physical address.
> The map/unmap operations are done with hypercalls which does the
> page table update. In my implementation the tools ask the kernel to
> do this via a ioctl on /kern/xen/privcmds
> 
> When a tool wants to map one of these Xen object, it first does a
> mmap() to get some virtual space, and then an ioctl to map it.
> The ioctl allocates a uvm_object and uvm_map() it for the range.
> The pgo_fault() handler will map the VA to the Xen object using the
> dedictated hypercall; this works fine.
> 
> But I have a problem for unmap: when uvm wants to remove the mapping
> (either because the process called munmap() or because it exited),
> pmap_remove() will try to clear the page table entries for this
> special mapping, and Xen will kill the VM. This has to be done with
> the right hypercall.
> 
> I see 2 ways to fix this: add a pgo_remove() and have UVM call it,
> or intercept the pmap_remove() calls at the pmap level, and check
> the VA against our uvm_objects.
> 
> Is there something I missed to get a custom page remove for uvm ojbects ?
> what would be the best way to handle this ?

I don't think you're missing anything...
currently the kernel is always able to clear a PTE by simply writing a zero.

There are more cases to consider, eg. pmap_protect() on this magic mapping
would probably kill the VM too, since that will also try to modify the PTE.

Are all of these mappings single pages?  If not, does xen allow removing
one page of a magic mapping and leaving the rest in place?

Why does xen feel it necessary to kill the VM in these cases
where the guest is reducing its access to these magic pages?
This would be a lot easier to deal with if xen just let the guest
operate on these PTEs the same way it operates on other PTEs.

What are these magic mappings for, exactly?

Would it be practical to just map the magic mappings in the kernel
and then have the tools use ioctls to access the magic mappings?
That would avoid all of these problems.

-Chuck