diff options
author | Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> | 2014-01-03 10:20:18 -0500 |
---|---|---|
committer | Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> | 2014-01-06 10:44:21 -0500 |
commit | 6926f6d6109714aab7b26df7099b12555e36676f (patch) | |
tree | 48d0a61f2db6b3d75ff90f83d3726d975a0cce5b /fs/xfs/xfs_trace.c | |
parent | efaf30a3357872cf0fc7d555b1f9968ec71535d3 (diff) | |
download | talos-obmc-linux-6926f6d6109714aab7b26df7099b12555e36676f.tar.gz talos-obmc-linux-6926f6d6109714aab7b26df7099b12555e36676f.zip |
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>
Diffstat (limited to 'fs/xfs/xfs_trace.c')
0 files changed, 0 insertions, 0 deletions