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

Re: [Xen-devel] standalone PCI passthrough emulator


  • To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>, "xen-devel (xen-devel@xxxxxxxxxxxxxxxxxxxx)" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
  • Date: Tue, 5 Mar 2019 02:44:47 +0000
  • Accept-language: en-US
  • Delivery-date: Tue, 05 Mar 2019 02:45:10 +0000
  • Dlp-product: dlpe-windows
  • Dlp-reaction: no-action
  • Dlp-version: 11.0.400.15
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AdTQS6Y1dv+fSL+5RJ244xB0pQGEGgB6q/LwAAu5oWAAJZTyoA==
  • Thread-topic: standalone PCI passthrough emulator

> From: Paul Durrant [mailto:Paul.Durrant@xxxxxxxxxx]
> Sent: Monday, March 4, 2019 4:44 PM
> 
> > -----Original Message-----
> > From: Tian, Kevin [mailto:kevin.tian@xxxxxxxxx]
> > Sent: 04 March 2019 03:01
> > To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>; xen-devel (xen-
> devel@xxxxxxxxxxxxxxxxxxxx) <xen-
> > devel@xxxxxxxxxxxxxxxxxxxx>
> > 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
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®.