From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: PCI Passthrough ARM Design : Draft1 Date: Thu, 25 Jun 2015 13:21:28 +0100 Message-ID: <1435234888.32500.80.camel@citrix.com> References: <557549D7.5090407@caviumnetworks.com> <1433940302.30003.75.camel@citrix.com> <55788E1C.6080307@citrix.com> <1434012974.30003.127.camel@citrix.com> <55797011.2050209@citrix.com> <1434024157.30003.159.camel@citrix.com> <55804D21.8040703@citrix.com> <558058CA.9030806@caviumnetworks.com> <55806109.7040808@caviumnetworks.com> <1434548605.13744.391.camel@citrix.com> <558180C9.9020904@caviumnetworks.com> <1434551364.13744.403.camel@citrix.com> <558BB174.40204@caviumnetworks.com> <1435223510.32500.2.camel@citrix.com> <558BED2D.3080600@caviumnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <558BED2D.3080600@caviumnetworks.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Manish Jaggi Cc: Vijay Kilari , Stefano Stabellini , Prasun Kapoor , "Kumar, Vijaya" , "xen-devel@lists.xen.org" , Julien Grall , Stefano Stabellini , "Kulkarni, Ganapatrao" , Roger Pau =?ISO-8859-1?Q?Monn=E9?= List-Id: xen-devel@lists.xenproject.org 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. > 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@lists.xen.org > > http://lists.xen.org/xen-devel >