[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] standalone PCI passthrough emulator
> -----Original Message----- > From: Roger Pau Monne > Sent: 07 March 2019 17:41 > To: Paul Durrant <Paul.Durrant@xxxxxxxxxx> > Cc: xen-devel (xen-devel@xxxxxxxxxxxxxxxxxxxx) > <xen-devel@xxxxxxxxxxxxxxxxxxxx> > Subject: Re: [Xen-devel] standalone PCI passthrough emulator > > On Fri, Mar 01, 2019 at 04:41:25PM +0000, Paul Durrant wrote: > > 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. > > > > NOTE: there is a known issue where domains are left in zombie state on > > shutdown. This is likely > due to Xen not properly cleaning up MSI mappings, but I'm not yet sure of > that. > > > > Things that are missing: > > > > - Decent error paths (it won't cope well if IO/memory mapping hypercalls > > fail) > > - MSI-X support > > - Extended config space > > > > Hopefully I'll start to address these soon :-) > > Thanks, this is very interesting. > > I've been wondering whether it would be possible to unify this code > together with the current vPCI code in Xen, by creating a > common/libvpci library that would have the PCI emulation and likely a > set of hooks to interact with the real PCI config space and with the > guest p2m. Those hooks will obviously be different between the in-Xen > version and the user-space Linux version which could use sysfs or VFIO. > That sounds like a good idea. At one end we'd need a mechanism for feeding in the config accesses; which is IOREQ server for an out-of-xen instance and direct call for an in-xen instance. The other end, as you say, would a set of ops which would need to populated to handle mapping of ports or mem, or binding of interrupts. > I think both code bases are small enough at this point to perform such > unification, and leaving this for later is just going to cause more > pain. > Yes, the core is the same and there's no need to keep re-writing it. > I'm willing to work on this in a month, since right now I don't have > the time. Would you be OK with that? > Sure. I have plenty to be getting on with :-) Cheers, Paul > Roger. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |