Re: [Xen-devel] One question about the hypercall to translate gfn to mfn.

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> 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