[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] GNTTABOP_unmap_grant_ref doc



Hi,

I've been working on the Mirage (mini-OS + OCaml runtime) blkback implementation. It seems to be working much more happily now but I was a bit surprised by the GNTTABOP_unmap_grant_ref doc -- maybe I misread it.

In ./xen/include/public/grant_table.h it says

/*
 * GNTTABOP_unmap_grant_ref: Destroy one or more grant-reference mappings
 * tracked by <handle>. If <host_addr> or <dev_bus_addr> is zero, that
 * field is ignored. If non-zero, they must refer to a device/host mapping
 * that is tracked by <handle>
 * NOTES:
 *  1. The call may fail in an undefined manner if either mapping is not
 *     tracked by <handle>.
 *  3. After executing a batch of unmaps, it is guaranteed that no stale
 *     mappings will remain in the device or host TLBs.
 */

When I read
  "If <host_addr> or <dev_bus_addr> is zero, that field is ignored"
"The call may fail in an undefined manner if either mapping is not tracked by <handle>"

I thought, "great, I'll not bother tracking anything except the handle and set both fields to zero". However if I set host_addr to zero then my frontend complains bitterly

gnttab_stubs.c: WARNING: g.e. 53 still in use! (19)

If I store the host_addr and fill it in during the unmap, everything seems to work.

So did I misread the doc? Or did it mean exclusive-or i.e. you must fill in either one of these two fields? Or have I done something stupid elsewhere (always possible)?

If it turns out that I have misread the doc, I'll happily send a patch to improve the text (once I'm sure I understand what it should say...)

Thanks!
Dave

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.