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

Re: [Xen-devel] [early RFC] ARM PCI Passthrough design document



On Fri, Jan 06, 2017 at 01:12:44PM -0800, Stefano Stabellini wrote:
> On Fri, 6 Jan 2017, Edgar E. Iglesias wrote:
> > On Thu, Dec 29, 2016 at 02:04:15PM +0000, Julien Grall wrote:
> > > Hi all,
> > > 
> > > The document below is an early version of a design
> > > proposal for PCI Passthrough in Xen. It aims to
> > > describe from an high level perspective the interaction
> > > with the different subsystems and how guest will be able
> > > to discover and access PCI.
> > > 
> > > I am aware that a similar design has been posted recently
> > > by Cavium (see [1]), however the approach to expose PCI
> > > to guest is different. We have request to run unmodified
> > > baremetal OS on Xen, a such guest would directly
> > > access the devices and no PV drivers will be used.
> > > 
> > > That's why this design is based on emulating a root controller.
> > > This also has the advantage to have the VM interface as close
> > > as baremetal allowing the guest to use firmware tables to discover
> > > the devices.
> > > 
> > > Currently on ARM, Xen does not have any knowledge about PCI devices.
> > > This means that IOMMU and interrupt controller (such as ITS)
> > > requiring specific configuration will not work with PCI even with
> > > DOM0.
> > > 
> > > The PCI Passthrough work could be divided in 2 phases:
> > >   * Phase 1: Register all PCI devices in Xen => will allow
> > >              to use ITS and SMMU with PCI in Xen
> > >         * Phase 2: Assign devices to guests
> > > 
> > > This document aims to describe the 2 phases, but for now only phase
> > > 1 is fully described.
> > 
> > Thanks Julien,
> > 
> > A question.
> > IIUC, Dom0 will own the real host bridge and DomUs will access a
> > virtual emulated one.
> > In the case of an ECAM compatible host bridge that only needs to
> > be initialized via a host bridge specific register sequence,
> > do I understand correctly that the amount of emulation would be
> > very small (just enough to fool the guest that the init sequence
> > passed). Beyond that we could have a generic ECAM emulator/mappings?
> 
> I think so.
> 
> 
> > How will we handle BAR setups?
> > Will we filter and make sure guests don't try to do funny stuff?
> > Perhaps Xen already has code for this (I'm guessing it does).
> 
> Yes, we'll have to filter guest accesses. There is already some code in
> Xen to do that, especially in regard to MSI and MSI-X setup.
> 

Thanks for clarifying!

I think the proposal looks good so far.

Cheers,
Edgar

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

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