xen/pvh: Piggyback on PVHVM for grant driver (v4)
authorKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Fri, 3 Jan 2014 15:20:18 +0000 (10:20 -0500)
committerKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Mon, 6 Jan 2014 15:44:21 +0000 (10:44 -0500)
commit6926f6d6109714aab7b26df7099b12555e36676f
tree48d0a61f2db6b3d75ff90f83d3726d975a0cce5b
parentefaf30a3357872cf0fc7d555b1f9968ec71535d3
xen/pvh: Piggyback on PVHVM for grant driver (v4)

In PVH the shared grant frame is the PFN and not MFN,
hence its mapped via the same code path as HVM.

The allocation of the grant frame is done differently - we
do not use the early platform-pci driver and have an
ioremap area - instead we use balloon memory and stitch
all of the non-contingous pages in a virtualized area.

That means when we call the hypervisor to replace the GMFN
with a XENMAPSPACE_grant_table type, we need to lookup the
old PFN for every iteration instead of assuming a flat
contingous PFN allocation.

Lastly, we only use v1 for grants. This is because PVHVM
is not able to use v2 due to no XENMEM_add_to_physmap
calls on the error status page (see commit
69e8f430e243d657c2053f097efebc2e2cd559f0
 xen/granttable: Disable grant v2 for HVM domains.)

Until that is implemented this workaround has to
be in place.

Also per suggestions by Stefano utilize the PVHVM paths
as they share common functionality.

v2 of this patch moves most of the PVH code out in the
arch/x86/xen/grant-table driver and touches only minimally
the generic driver.

v3, v4: fixes us some of the code due to earlier patches.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
arch/x86/xen/grant-table.c
drivers/xen/gntdev.c
drivers/xen/grant-table.c