On Tue, 18 Jan 2011, Daniel De Graaf wrote:
> >> @@ -224,7 +233,11 @@ static int map_grant_pages(struct grant_map *map)
> >> goto out;
> >>
> >> for(i=0; i < map->count; i++) {
> >> - gnttab_set_map_op(&map_ops[i], map->pginfo[i].pte_maddr, flags,
> >> + if (use_ptemod)
> >> + addr = map->pginfo[i].pte_maddr;
> >> + else
> >> + addr =
> >> (phys_addr_t)pfn_to_kaddr(page_to_pfn(map->pages[i]));
> >> + gnttab_set_map_op(&map_ops[i], addr, flags,
> >> map->pginfo[i].target.ref,
> >> map->pginfo[i].target.domid);
> >> }
> >
> > If I am not mistaken you are asking Xen to modify the virtual kernel
> > mappings of map->pages, but it is not enough to have correctly working
> > userspace mappings of map->pages: you need gnttab_map_refs to correctly
> > fix the p2m and add an entry to m2p_override too.
> > However in the last gntdev patch series I sent, requests with
> > !GNTMAP_contains_pte are not added to m2p_override and the p2m entries
> > of map->pages are not updated either.
> >
> > Therefore you probably need this (untested) patch to make it work:
> >
>
> It looks like this patch only applies if using gnttab_map_refs without
> GNTMAP_contains_pte on PV guests; my patch only uses !GNTMAP_contains_pte
> on HVM, so it doesn't need this change.
>
> I think this patch would be needed if we wanted to remove GNTMAP_contains_pte
> from the PV case, which might make the code cleaner (it would remove the
> dependency on the MM notifier, and allow multiple mmap() of the device in PV).
> I didn't want to change the working PV case when adding HVM support, so I
> left that code mostly alone.
Yes, you are right I was thinking at the PV case that it is not relevant
here.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home