From mboxrd@z Thu Jan 1 00:00:00 1970 From: Manish Jaggi Subject: Re: PCI Passthrough ARM Design : Draft1 Date: Wed, 17 Jun 2015 07:14:33 -0700 Message-ID: <558180C9.9020904@caviumnetworks.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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1434548605.13744.391.camel@citrix.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: Ian Campbell , Stefano Stabellini Cc: Vijay Kilari , Prasun Kapoor , "Kumar, Vijaya" , "xen-devel@lists.xen.org" , Julien Grall , Stefano Stabellini , "Kulkarni, Ganapatrao" , =?windows-1252?Q?Roger_Pau_Monn=E9?= List-Id: xen-devel@lists.xenproject.org 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 c) domU will not anytime update the BARs, if it does then it is a fault, till we decide how to handle it d) when domU queries BAR address from pci-back the virtual BAR address is provided. Option2: b) domU will not anytime update the BARs, if it does then it is a fault, till we decide how to handle it c) when domU queries BAR address from pci-back the virtual BAR address is provided. d) domU sends a hypercall to map virtual BARs, e) xen pci code reads the BAR and maps { virtual BAR : physical BAR } for domU Which option is better I think Ian is for (2) and Stefano may be (1) > Ian. > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel