[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.
> From: Ian Campbell [mailto:Ian.Campbell@xxxxxxxxxx] > Sent: Wednesday, December 10, 2014 6:11 PM > > On Wed, 2014-12-10 at 01:48 +0000, Tian, Kevin wrote: > > I'm not familiar with Arm architecture, but based on a brief reading it's > > for the assigned case where the MMU is exclusive owned by a VM, so > > some type of MMU virtualization is required and it's straightforward. > > > However XenGT is a shared GPU usage: > > > > - a global GPU page table is partitioned among VMs. a shared shadow > > global page table is maintained, containing translations for multiple > > VMs simultaneously based on partitioning information > > - multiple per-process GPU page tables are created by each VM, and > > multiple shadow per-process GPU page tables are created correspondingly. > > shadow page table is switched when doing GPU context switch, same as > > what we did for CPU shadow page table. > > None of that sounds to me to be impossible to do in the remoteproc > model, perhaps it needs some extensions from its initial core feature > set but I see no reason why it couldn't maintain multiple sets of page > tables, each tagged with an owning domain (for validation purposes) and > a mechanism to switch between them, or to be able to manage partitioning > of the GPU address space. here we're talking about multiple GPU page tables on top of a IOMMU page table. Instead of one MMU unit concerned here in remoteproc. > > > So you can see above shared MMU virtualization usage is very GPU > > specific, > > AIUI remoteproc is specific to a particular h/w device too, i.e. there > is a device specific stub in the hypervisor which essentially knows how > to implement set_pte for that bit of h/w, with appropriate safety and > validation, as well as a write_cr3 type operation. > > > that's why we didn't put in Xen hypervisor, and thus additional > > interface is required to get p2m mapping to assist our shadow GPU > > page table usage. > > There is a great reluctance among several maintainers to expose real > hardware MFNs to VMs (including dom0 and backend driver domains). > > I think you need to think very carefully about possible ways of avoiding > the need for this. Yes, this might require some changes to your current > mode/design. > We're open to changes if necessary. Thanks, Kevin _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |