[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] x86: mapping from Dom0 to DomU
>>> On 24.04.17 at 08:10, <andr2000@xxxxxxxxx> wrote: > On 04/21/2017 06:55 PM, Jan Beulich wrote: >>>>> On 21.04.17 at 15:04, <andr2000@xxxxxxxxx> wrote: >>> I am working on a zero-copy scenario for x86 >>> and for that I am mapping pages from Dom0 to DomU >>> (yes, I know there are at least security concerns). >>> >>> Everything is just fine, e.g. I can map grefs from Dom0 in DomU >>> with gnttab_map_refs, until I try to mmap those pages in DomU >>> with vm_insert_page and Xen starts to complain: >>> >>> (XEN) mm.c:989:d1v0 pg_owner 1 l1e_owner 1, but real_pg_owner 0 >>> (XEN) mm.c:1061:d1v0 Error getting mfn 20675a (pfn 1ac8de) from L1 entry >>> 800000020675a027 for l1e_owner=1, pg_owner=1 >>> >>> Can anybody please explain why the use-case I am trying to implement >>> is treated as error from Xen's POV and what would be the right way to >>> do so? >> Granted pages can be mapped only through the grant-table hypercall, > If this is gnttab_map_refs call you mean then, yes, > I do that to map grefs >> see public/grant_table.h's explanation of GNTMAP_host_map used >> with out without GNTMAP_contains_pte. > I know about these options and according to [1] I can use > option to map with "host virtual address", e.g. without > GNTMAP_contains_pte flag, because GNTMAP_contains_pte requires me to > provide machine address which I don't want. >> Other mapping attempts >> have to be refused, or else the accounting done by the grant table >> code would be undermined. > So, either I didn't understand what you mean or was not clear > to explain that I see no problem while mapping grefs with > gnttab_map_refs, but see the problem when vm_insert_page > is called to mmap the pages into user-space (vm_insert_page > internally does set_pte_at which it silently fails, but kernel > knows nothing about that because no error reported [2]). Indeed you seem to have misunderstood: _All_ mappings of the granted page need to be done using the grant table hypercalls, not just the initial one. set_pte() establishes a second mapping, and that does not use the grant table op. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |