Re: [early RFC] ARM PCI Passthrough design document

[Stefano Stabellini <sstabellini@kernel.org>]

On Fri, 10 Feb 2017, Paul Durrant wrote:
> > -----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.

I understand and I think it is OK. Pretty much like you wrote, these are
not passthrough scenarios, they are a sort of hardware supported
emulated/PV graphics (for a lack of better term), so it's natural for
these devices to be assigned to dom0 (or another backend domain).


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

Thank you, Paul

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