[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

 


Rackspace

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