Re: [PATCH v2] port/xen: map memory directly in privcmd PRIVCMD_MMAPBATCH

[Cherry G. Mathew <cherry%zyx.in@localhost>]

>>>>> "Roger" == Roger Pau Monne <roger.pau%citrix.com@localhost> writes:

    Roger> Manuel Bouyer wrote:
    >> On Tue, Jun 26, 2012 at 10:47:05AM +0100, Roger Pau Monne wrote:
    >>>> informations. I think qemu should instruct the kernel that
    >>>> things changed.
    >>> With the proposed patch, the kernel doesn't store the gfns
    >>> anymore, since the mapping is done directly, and no pagefault
    >>> handler is set.  So the information (or the lack of it) stored
    >>> by the NetBSD kernel is correct.
    >> 
    >> OK. As this is a mapping which isn't consuming dom0 memory I
    >> guess it doesn't matter much that this area is not paged. But I
    >> think PRIVCMD_MMAP and PRIVCMD_MMAPBATCH should behave the
    >> same. I don't like much the idea of a mapping in user area that
    >> is unknown to UVM though, can't you make qemu unmap and remap the
    >> area with the right information ?

    Roger> Yes, I agree, I will resubmit a patch that changes both
    Roger> PRIVCMD_MMAPBATCH and PRIVCMD_MMAP to direct mapping.

It just occurred to me that if all that's required is a fault-in ( to
trigger the bogus backing mapping fault handler ) at ioctl time, the
following patch (untested) should do the trick as a temporary shim.

It doesn't solve qemu's badness though.

Does it work ?

Cheers,

-- 
Cherry

*** privcmd.c.~1.43.~   Thu Jun 16 01:21:50 2011
--- privcmd.c   Wed Jun 27 05:10:26 2012
***************
*** 586,591 ****
--- 586,601 ----
                printf("uvm_map didn't give us back our vm space\n");
                return EINVAL;
        }
+ 
+       /* Wire in mapping */
+       error = uvm_fault_wire(map, newstart, newstart + size, prot, 0); 
+       if (error) {
+               if (obj)
+                       obj->uobj.pgops->pgo_detach(&obj->uobj);
+               return error;
+       }
+ 
+       
        return 0;
  }