[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] PCI Passthrough ARM Design : Draft1
On Thu, Jun 25, 2015 at 01:21:28PM +0100, Ian Campbell wrote: > On Thu, 2015-06-25 at 17:29 +0530, Manish Jaggi wrote: > > > > On Thursday 25 June 2015 02:41 PM, Ian Campbell wrote: > > > On Thu, 2015-06-25 at 13:14 +0530, Manish Jaggi wrote: > > >> On Wednesday 17 June 2015 07:59 PM, Ian Campbell wrote: > > >>> On Wed, 2015-06-17 at 07:14 -0700, Manish Jaggi wrote: > > >>>> On Wednesday 17 June 2015 06:43 AM, Ian Campbell wrote: > > >>>>> On Wed, 2015-06-17 at 13:58 +0100, Stefano Stabellini wrote: > > >>>>>> Yes, pciback is already capable of doing that, see > > >>>>>> drivers/xen/xen-pciback/conf_space.c > > >>>>>> > > >>>>>>> I am not sure if the pci-back driver can query the guest memory > > >>>>>>> map. Is there an existing hypercall ? > > >>>>>> No, that is missing. I think it would be OK for the virtual BAR to > > >>>>>> be > > >>>>>> initialized to the same value as the physical BAR. But I would let > > >>>>>> the > > >>>>>> guest change the virtual BAR address and map the MMIO region > > >>>>>> wherever it > > >>>>>> wants in the guest physical address space with > > >>>>>> XENMEM_add_to_physmap_range. > > >>>>> I disagree, given that we've apparently survived for years with x86 PV > > >>>>> guests not being able to right to the BARs I think it would be far > > >>>>> simpler to extend this to ARM and x86 PVH too than to allow guests to > > >>>>> start writing BARs which has various complex questions around it. > > >>>>> All that's needed is for the toolstack to set everything up and write > > >>>>> some new xenstore nodes in the per-device directory with the BAR > > >>>>> address/size. > > >>>>> > > >>>>> Also most guests apparently don't reassign the PCI bus by default, so > > >>>>> using a 1:1 by default and allowing it to be changed would require > > >>>>> modifying the guests to reasssign. Easy on Linux, but I don't know > > >>>>> about > > >>>>> others and I imagine some OSes (especially simpler/embedded ones) are > > >>>>> assuming the firmware sets up something sane by default. > > >>>> Does the Flow below captures all points > > >>>> a) When assigning a device to domU, toolstack creates a node in per > > >>>> device directory with virtual BAR address/size > > >>>> > > >>>> Option1: > > >>>> b) toolstack using some hypercall ask xen to create p2m mapping { > > >>>> virtual BAR : physical BAR } for domU > > >> While implementing I think rather than the toolstack, pciback driver in > > >> dom0 can send the > > >> hypercall by to map the physical bar to virtual bar. > > >> Thus no xenstore entry is required for BARs. > > > pciback doesn't (and shouldn't) have sufficient knowledge of the guest > > > address space layout to determine what the virtual BAR should be. The > > > toolstack is the right place for that decision to be made. > > Yes, the point is the pciback driver reads the physical BAR regions on > > request from domU. > > So it sends a hypercall to map the physical bars into stage2 translation > > for the domU through xen. > > Xen would use the holes left in IPA for MMIO. > > I still think it is the toolstack which should do this, that's whewre > these sorts of layout decisions belong. At init - sure. But when the guest is running and doing those sort of things. Unless you want guest -> pciback -> xenstore -> libxl -> hypercall -> send ack on xenstore -> pciback -> guest. That would entail adding some pcibkack -> user-space tickle mechanism and another back. Much simpler to do all of this in xenpciback I think? > > > Xen would return the IPA for pci-back to return to the request to domU. > > >> Moreover a pci driver would read BARs only once. > > > You can't assume that though, a driver can do whatever it likes, or the > > > module might be unloaded and reloaded in the guest etc etc. > > > > > > Are you going to send out a second draft based on the discussion so far? > > yes, I was working on that only. I was traveling this week 24 hour > > flights jetlag... > > > > > > Ian. > > > > > > > > > _______________________________________________ > > > Xen-devel mailing list > > > Xen-devel@xxxxxxxxxxxxx > > > http://lists.xen.org/xen-devel > > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxx > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |