[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |