All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: "Keir (Xen.org)" <keir@xen.org>, "Tim (Xen.org)" <tim@xen.org>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>,
	Paul Durrant <Paul.Durrant@citrix.com>,
	"Yu, Zhang" <yu.c.zhang@linux.intel.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: One question about the hypercall to translate gfn to mfn.
Date: Wed, 10 Dec 2014 10:11:17 +0000	[thread overview]
Message-ID: <1418206277.19809.48.camel@citrix.com> (raw)
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D126114D11@SHSMSX101.ccr.corp.intel.com>

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.

  reply	other threads:[~2014-12-10 10:11 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-09 10:10 One question about the hypercall to translate gfn to mfn Yu, Zhang
2014-12-09 10:19 ` Paul Durrant
2014-12-09 10:37   ` Yu, Zhang
2014-12-09 10:50     ` Jan Beulich
2014-12-10  1:07       ` Tian, Kevin
2014-12-10  8:39         ` Jan Beulich
2014-12-10  8:47           ` Tian, Kevin
2014-12-10  9:16             ` Jan Beulich
2014-12-10  9:51               ` Tian, Kevin
2014-12-10 10:07                 ` Jan Beulich
2014-12-10 11:04                 ` Malcolm Crossley
2014-12-10  8:50           ` Tian, Kevin
2014-12-09 10:51     ` Malcolm Crossley
2014-12-10  1:22       ` Tian, Kevin
2014-12-09 10:38 ` Jan Beulich
2014-12-09 10:46 ` Tim Deegan
2014-12-09 11:05   ` Paul Durrant
2014-12-09 11:11     ` Ian Campbell
2014-12-09 11:17       ` Paul Durrant
2014-12-09 11:23         ` Jan Beulich
2014-12-09 11:28           ` Malcolm Crossley
2014-12-09 11:29         ` Ian Campbell
2014-12-09 11:43           ` Paul Durrant
2014-12-10  1:48             ` Tian, Kevin
2014-12-10 10:11               ` Ian Campbell [this message]
2014-12-11  1:50                 ` Tian, Kevin
2014-12-10  1:14   ` Tian, Kevin
2014-12-10 10:36     ` Jan Beulich
2014-12-11  1:45       ` Tian, Kevin
2014-12-10 10:55     ` Tim Deegan
2014-12-11  1:41       ` Tian, Kevin
2014-12-11 16:46         ` Tim Deegan
2014-12-12  7:24           ` Tian, Kevin
2014-12-12 10:54             ` Jan Beulich
2014-12-15  6:25               ` Tian, Kevin
2014-12-15  8:44                 ` Jan Beulich
2014-12-15  9:05                   ` Tian, Kevin
2014-12-15  9:22                     ` Jan Beulich
2014-12-15 11:16                       ` Tian, Kevin
2014-12-15 11:27                         ` Jan Beulich
2014-12-15 15:22                       ` Stefano Stabellini
2014-12-15 16:01                         ` Jan Beulich
2014-12-15 16:15                           ` Stefano Stabellini
2014-12-15 16:28                             ` David Vrabel
2014-12-15 16:28                             ` Jan Beulich
2014-12-18 15:46             ` Tim Deegan
2015-01-06  8:56               ` Tian, Kevin
2015-01-08 12:43                 ` Tim Deegan
2015-01-09  8:02                   ` Tian, Kevin
2015-01-09 20:08                     ` Konrad Rzeszutek Wilk
2015-01-12 11:14                     ` David Vrabel
2014-12-11 21:29         ` Tim Deegan
2014-12-12  6:29           ` Tian, Kevin
2014-12-18 16:08             ` Tim Deegan
2014-12-18 17:01               ` Andrew Cooper
2015-01-05 15:49             ` George Dunlap
2015-01-06  8:42               ` Tian, Kevin
2015-01-06 10:35                 ` Ian Campbell
2014-12-12  7:30           ` Tian, Kevin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1418206277.19809.48.camel@citrix.com \
    --to=ian.campbell@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=Paul.Durrant@citrix.com \
    --cc=Xen-devel@lists.xen.org \
    --cc=keir@xen.org \
    --cc=kevin.tian@intel.com \
    --cc=tim@xen.org \
    --cc=yu.c.zhang@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.