[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.



>>> On 10.12.14 at 02:14, <kevin.tian@xxxxxxxxx> wrote:
>>  From: Tim Deegan [mailto:tim@xxxxxxx]
>> 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.
> 
> In our case it's not because the security model is problematic. It's 
> because GPU virtualization is done in Dom0 while the memory virtualization
> is done in hypervisor.

Which by itself is a questionable design decision.

> We need a means to query GPFN->MFN so we can
> setup shadow GPU page table in Dom0 correctly, for a VM.
> 
>> 
>> 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?).
> 
> yes, IOMMU protect DMA accesses in a device-agnostic way. But in
> our case, IOMMU can't be used because it's only for exclusively
> assigned case, as I replied in another mail. And to reduce the hypervisor
> TCB, we put device model in Dom0 which is why a interface is required
> to connect p2m information.
> 
>> 
>> 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.
> 
> A please-map-this-gfn interface assumes the logic behind lies in Xen
> hypervisor, e.g. managing CPU page table or IOMMU entry. However
> here the management of GPU page table is in Dom0, and what we
> want is a please-tell-me-mfn-for-a-gpfn interface, so we can translate
> from gpfn in guest GPU PTE to a mfn in shadow GPU PTE. 

As said before, what needs to be put in the GPU PTE depends on
what the subsequent IOMMU translation would do to the address.
It's not a hard requirement for the IOMMU to pass through all
addresses for Dom0, so we have room to isolate things if possible.

Jan


_______________________________________________
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®.