[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] One question about the hypercall to translate gfn to mfn.
At 18:10 +0800 on 09 Dec (1418145055), Yu, Zhang wrote: > Hi all, > > As you can see, we are pushing our XenGT patches to the upstream. One > feature we need in xen is to translate guests' gfn to mfn in XenGT dom0 > device model. > > Here we may have 2 similar solutions: > 1> Paul told me(and thank you, Paul :)) that there used to be a > hypercall, XENMEM_translate_gpfn_list, which was removed by Keir in > commit 2d2f7977a052e655db6748be5dabf5a58f5c5e32, because there was no > usage at that time. It's been suggested before that we should revive this hypercall, and I don't think it's a good idea. Whenever a domain needs to know the actual MFN of another domain's memory it's usually because the security model is problematic. In particular, finding the MFN is usually followed by a brute-force mapping from a dom0 process, or by passing the MFN to a device for unprotected DMA. These days DMA access should be protected by IOMMUs, or else the device drivers (and associated tools) are effectively inside the hypervisor's TCB. Luckily on x86 IOMMUs are widely available (and presumably present on anything new enough to run XenGT?). So I think the interface we need here is a please-map-this-gfn one, like the existing grant-table ops (which already do what you need by returning an address suitable for DMA). If adding a grant entry for every frame of the framebuffer within the guest is too much, maybe we can make a new interface for the guest to grant access to larger areas. Cheers, Tim. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |