> From: Paul Durrant [mailto:[email protected]] > Sent: Monday, March 4, 2019 4:44 PM > > > -----Original Message----- > > From: Tian, Kevin [mailto:[email protected]] > > Sent: 04 March 2019 03:01 > > To: Paul Durrant <[email protected]>; xen-devel (xen- > [email protected]) <xen- > > [email protected]> > > Subject: RE: standalone PCI passthrough emulator > > > > > From: Paul Durrant > > > Sent: Saturday, March 2, 2019 12:41 AM > > > > > > Hi, > > > > > > As the basis of some future development work I've put together a simple > > > standalone emulator to pass through a single type 0 PCI function to a > guest so > > > I'm posting here in case anyone else would like a give it a try. So far > > > I've > tested > > > with AMD FirePro S7150 and NVIDIA K1 GPUs and a Windows 10 guest, so > it > > > hasn't had that much debugging. > > > > How is it different from existing PCI passthrough support in Xen? What is > > exactly emulated here? > > > > Essentially it does no more than the current code in QEMU, but that code has > become very complex and hard to follow over the years. It's full of magic > mask values and I've found at least two pieces of completely dead code whilst > looking at it. So, I started this work to provide a small simple base on > which to > experiment with using VFIO, rather than the existent sysfs node accesses and > xenctrl calls.
Thanks for explanation. I took a quick look at current repo. Looks VFIO support is not added yet, correct? To enable VFIO in Xen, I suppose there will be several major changes: 1. enable your pvIOMMU driver in VFIO. and it needs to be a full-fledge flavor, i.e. supporting per-device remapping capability; 2. make VFIO aware of foreign pages when doing accounting at map/unmap operations; 3. what would Xen device passthrough look like then? Looks now it becomes a hybrid model with some passthrough roles delegated to Dom0 VFIO, while other roles like real IOMMU page table, interrupt handling, etc. are still kept inside Xen. > To answer your other question... It's config space that is emulated, as it > has to > be to deal with BAR address and interrupt translation. Note, there is also a > slight advantage in using multiple discreet emulators; emulated I/O can > proceed in parallel for multiple vcpus... emulation on behalf of Xen by QEMU > is still restricted by a single poll/select loop for all vcpus. > thanks to the introduction of ioreq server. :-) Thanks Kevin _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
