From: Paul Durrant <Paul.Durrant@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: "Edgar Iglesias (edgar.iglesias@xilinx.com)"
<edgar.iglesias@xilinx.com>,
Stefano Stabellini <sstabellini@kernel.org>,
Anshul Makkar <anshul.makkar@citrix.com>,
Wei Chen <Wei.Chen@arm.com>, Steve Capper <Steve.Capper@arm.com>,
Andrew Cooper <Andrew.Cooper3@citrix.com>,
Jiandi An <anjiandi@codeaurora.org>,
Punit Agrawal <punit.agrawal@arm.com>,
Julien Grall <julien.grall@linaro.org>,
"alistair.francis@xilinx.com" <alistair.francis@xilinx.com>,
Shanker Donthineni <shankerd@codeaurora.org>,
xen-devel <xen-devel@lists.xenproject.org>,
"manish.jaggi@caviumnetworks.com"
<manish.jaggi@caviumnetworks.com>,
Campbell Sean <scampbel@codeaurora.org>
Subject: Re: [early RFC] ARM PCI Passthrough design document
Date: Fri, 10 Feb 2017 13:02:50 +0000 [thread overview]
Message-ID: <03972711cbee4e6daebb897ead85025b@AMSPEX02CL03.citrite.net> (raw)
In-Reply-To: <20170210125748.2636p25agqld5kg4@dhcp-3-221.uk.xensource.com>
> -----Original Message-----
[snip]
> > Neither NVIDIA vGPU nor Intel GVT-g are pass-through. They both use
> emulation to synthesize GPU devices for guests and then use the actual GPU
> to service the commands sent by the guest driver to the virtual GPU. So, I
> think they fall outside the discussion here.
>
> So in this case those devices would simply be assigned to Dom0, and
> everything
> would be trapped/emulated there? (by QEMU or whatever dm we are using)
>
Basically, yes. (Actually QEMU isn't the dm in either case).
> > AMD MxGPU is somewhat different in that it is an almost-SRIOV solution. I
> say 'almost' because the VF's are not truly independent and so some
> interception of accesses to certain registers is required, so that arbitration
> can be applied, or they can be blocked. In this case a dedicated driver in
> dom0 is required, and I believe it needs access to both the PF and all the VFs
> to function correctly. However, once initial set-up is done, I think the VFs
> could then be hidden from dom0. The PF is never passed-through and so
> there should be no issue in leaving it visible to dom0.
>
> The approach we where thinking of is hiding everything from Dom0 when it
> boots, so that Dom0 would never really see those devices. This would be
> done by
> Xen scanning the PCI bus and any ECAM areas. DEvices that first need to be
> assigned to Dom0 and then hidden where not part of the approach here.
That won't work for MxGPU then.
>
> > There is a further complication with GVT-d (Intel's term for GPU pass-
> through) also because I believe there is also some initial set-up required and
> some supporting emulation (e.g. Intel's guest driver expects there to be an
> ISA bridge along with the GPU) which may need access to the real GPU. It is
> also possible that, once this set-up is done, the GPU can then be hidden from
> dom0 but I'm not sure because I was not involved with that code.
>
> And then I guess some MMIO regions are assigned to the guest, and some
> dm
> performs the trapping of the accesses to the configuration space?
>
Well, that's how passthrough to HVM guests works in general at the moment. My point was that there's still some need to see the device in the tools domain before it gets passed through.
> > Full pass-through of NVIDIA and AMD GPUs does not involve access from
> dom0 at all though, so I don't think there should be any complication there.
>
> Yes, in that case they would be treated as regular PCI devices, no
> involvement
> from Dom0 would be needed. I'm more worried about this mixed cases,
> where some
> Dom0 interaction is needed in order to perform the passthrough.
>
> > Does that all make sense?
>
> I guess, could you please keep an eye on further design documents? Just to
> make sure that what's described here would work for the more complex
> passthrough scenarios that XenServer supports.
Ok, I will watch the list more closely for pass-through discussions, but please keep me cc-ed on anything you think may be relevant.
Thanks,
Paul
>
> Thanks, Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2017-02-10 13:03 UTC|newest]
Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-29 14:04 [early RFC] ARM PCI Passthrough design document Julien Grall
2016-12-29 14:16 ` Jaggi, Manish
2016-12-29 17:03 ` Julien Grall
2016-12-29 18:41 ` Jaggi, Manish
2016-12-29 19:38 ` Julien Grall
2017-01-04 0:24 ` Stefano Stabellini
2017-01-24 14:28 ` Julien Grall
2017-01-24 20:07 ` Stefano Stabellini
2017-01-25 11:21 ` Roger Pau Monné
2017-01-25 18:53 ` Julien Grall
2017-01-31 16:53 ` Edgar E. Iglesias
2017-01-31 17:09 ` Julien Grall
2017-01-31 19:06 ` Edgar E. Iglesias
2017-01-31 22:08 ` Stefano Stabellini
2017-02-01 19:04 ` Julien Grall
2017-02-01 19:31 ` Stefano Stabellini
2017-02-01 20:24 ` Julien Grall
2017-02-02 15:33 ` Edgar E. Iglesias
2017-02-02 23:12 ` Stefano Stabellini
2017-02-02 23:44 ` Edgar E. Iglesias
2017-02-10 1:01 ` Stefano Stabellini
2017-02-13 15:39 ` Julien Grall
2017-02-13 19:59 ` Stefano Stabellini
2017-02-14 17:21 ` Julien Grall
2017-02-14 18:20 ` Stefano Stabellini
2017-02-14 20:18 ` Julien Grall
2017-02-13 15:35 ` Julien Grall
2017-02-22 4:03 ` Edgar E. Iglesias
2017-02-23 16:47 ` Julien Grall
2017-03-02 21:13 ` Edgar E. Iglesias
2017-02-02 15:40 ` Roger Pau Monné
2017-02-13 16:22 ` Julien Grall
2017-01-31 21:58 ` Stefano Stabellini
2017-02-01 20:12 ` Julien Grall
2017-02-01 10:55 ` Roger Pau Monné
2017-02-01 18:50 ` Stefano Stabellini
2017-02-10 9:48 ` Roger Pau Monné
2017-02-10 10:11 ` Paul Durrant
2017-02-10 12:57 ` Roger Pau Monne
2017-02-10 13:02 ` Paul Durrant [this message]
2017-02-10 21:04 ` Stefano Stabellini
2017-02-02 12:38 ` Julien Grall
2017-02-02 23:06 ` Stefano Stabellini
2017-03-08 19:06 ` Julien Grall
2017-03-08 19:12 ` Konrad Rzeszutek Wilk
2017-03-08 19:55 ` Stefano Stabellini
2017-03-08 21:51 ` Julien Grall
2017-03-09 2:59 ` Roger Pau Monné
2017-03-09 11:17 ` Konrad Rzeszutek Wilk
2017-03-09 13:26 ` Julien Grall
2017-03-10 0:29 ` Konrad Rzeszutek Wilk
2017-03-10 3:23 ` Roger Pau Monné
2017-03-10 15:28 ` Konrad Rzeszutek Wilk
2017-03-15 12:07 ` Roger Pau Monné
2017-03-15 12:42 ` Konrad Rzeszutek Wilk
2017-03-15 12:56 ` Roger Pau Monné
2017-03-15 15:11 ` Venu Busireddy
2017-03-15 16:38 ` Roger Pau Monn?
2017-03-15 16:54 ` Venu Busireddy
2017-03-15 17:00 ` Roger Pau Monn?
2017-05-03 12:38 ` Julien Grall
2017-05-03 12:53 ` Julien Grall
2017-01-25 4:23 ` Manish Jaggi
2017-01-06 15:12 ` Roger Pau Monné
2017-01-06 21:16 ` Stefano Stabellini
2017-01-24 17:17 ` Julien Grall
2017-01-25 11:42 ` Roger Pau Monné
2017-01-31 15:59 ` Julien Grall
2017-01-31 22:03 ` Stefano Stabellini
2017-02-01 10:28 ` Roger Pau Monné
2017-02-01 18:45 ` Stefano Stabellini
2017-01-06 16:27 ` Edgar E. Iglesias
2017-01-06 21:12 ` Stefano Stabellini
2017-01-09 17:50 ` Edgar E. Iglesias
2017-01-19 5:09 ` Manish Jaggi
2017-01-24 17:43 ` Julien Grall
2017-01-25 4:37 ` Manish Jaggi
2017-01-25 15:25 ` Julien Grall
2017-01-30 7:41 ` Manish Jaggi
2017-01-31 13:33 ` Julien Grall
2017-05-19 6:38 ` Goel, Sameer
2017-05-19 16:48 ` Julien Grall
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=03972711cbee4e6daebb897ead85025b@AMSPEX02CL03.citrite.net \
--to=paul.durrant@citrix.com \
--cc=Andrew.Cooper3@citrix.com \
--cc=Steve.Capper@arm.com \
--cc=Wei.Chen@arm.com \
--cc=alistair.francis@xilinx.com \
--cc=anjiandi@codeaurora.org \
--cc=anshul.makkar@citrix.com \
--cc=edgar.iglesias@xilinx.com \
--cc=julien.grall@linaro.org \
--cc=manish.jaggi@caviumnetworks.com \
--cc=punit.agrawal@arm.com \
--cc=roger.pau@citrix.com \
--cc=scampbel@codeaurora.org \
--cc=shankerd@codeaurora.org \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).