[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |