[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [early RFC] ARM PCI Passthrough design document



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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.