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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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.

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

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel