From mboxrd@z Thu Jan 1 00:00:00 1970 From: Manish Jaggi Subject: Re: PCI Pass-through in Xen ARM: Draft 4 Date: Sun, 20 Sep 2015 01:54:04 +0530 Message-ID: <55FDC464.70003@caviumnetworks.com> References: <55CC668F.80104@caviumnetworks.com> <55F0D8FC.7050606@citrix.com> <55F8694B.6070904@cavium.com> <55F9675C.6070502@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55F9675C.6070502@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: Julien Grall , "Jaggi, Manish" , Xen Devel , Konrad Rzeszutek Wilk , =?UTF-8?Q?=e2=98=85_Stefano_Stabellini?= , Ian Campbell , "Daney, David" Cc: "Prasun.kapoor@cavium.com" , "Kumar, Vijaya" List-Id: xen-devel@lists.xenproject.org On Wednesday 16 September 2015 06:28 PM, Julien Grall wrote: > On 15/09/15 19:58, Jaggi, Manish wrote: >>> I can see 2 different solutions: >>> 1) Let DOM0 pass the first requester ID when registering the bus >>> Pros: >>> * Less per-platform code in Xen >>> Cons: >>> * Assume that the requester ID are contiguous. (Is it really a >>> cons?) >>> * Still require quirk for buggy device (i.e requester ID not >>> correct) >>> 2) Do it in Xen >>> Pros: >>> * We are not relying on DOM0 giving the requester ID >>> => Not assuming contiguous requester ID >>> Cons: >>> * Per PCI bridge code to handle the mapping >>> >> We can have (3) that when PHYSDEVOP_pci_add_device is called the sbdf >> and requesterID both are passed in hypercall. > The name of the physdev operation is PHYSDEVOP_pci_device_add and not > PHYSDEVOP_pci_add_device. Please rename it all the usage in the design doc. > > Although, we can't modify PHYSDEVOP_pci_device_add because it's part of > the ABI which is stable. > > Based on David's mail, the requester ID of a given device can be found > using base + devfn where base is the first requesterID of the bus. > > IIRC, this is also match the IORT ACPI spec. > > So for now, I would extend the physdev you've introduced to add an host > bridge (PHYSDEV_pci_host_bridge_add) to pass the base requesterID. The requester-ID is derived from the Node# and ECAM# as per David. I guess the ECAM and Node# can be derived from the cfg_addr. Each Ecam has a cfg_addr in Thunder, which is mentioned in the pci node in device tree. For thunder I think we don't need to pass requester-ID in the phydevop. > > We can think later to introduce a new physdev op to add PCI if we ever > require unique requesterID (i.e non-contiguous under the same bridge). > > Regards, > > --- > Julien Grall