> From: Tim Deegan [mailto:t...@xen.org] > Sent: Thursday, January 08, 2015 8:43 PM > > Hi, > > > > Not really. The IOMMU tables are also 64-bit so there must be enough > > > addresses to map all of RAM. There shouldn't be any need for these > > > mappings to be _contiguous_, btw. You just need to have one free > > > address for each mapping. Again, following how grant maps work, I'd > > > imagine that PVH guests will allocate an unused GFN for each mapping > > > and do enough bookkeeping to make sure they don't clash with other GFN > > > users (grant mapping, ballooning, &c). PV guests will probably be > > > given a BFN by the hypervisor at map time (which will be == MFN in > > > practice) and just needs to pass the same BFN to the unmap call later > > > (it can store it in the GTT meanwhile). > > > > if possible prefer to make both consistent, i.e. always finding unused GFN? > > I don't think it will be possible. PV domains are already using BFNs > supplied by Xen (in fact == MFN) for backend grant mappings, which > would conflict with supplying their own for these mappings. But > again, I think the kernel maintainers for Xen may have a better idea > of how these interfaces are used inside the kernel. For example, > it might be easy enough to wrap the two systems inside a common API > inside linux. Again, following how grant mapping works seems like > the way forward. >
So Konrad, do you have any insight here? :-) Thanks Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
