From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: PCI Pass-through in Xen ARM: Draft 4 Date: Wed, 16 Sep 2015 13:58:04 +0100 Message-ID: <55F9675C.6070502@citrix.com> References: <55CC668F.80104@caviumnetworks.com> <55F0D8FC.7050606@citrix.com> <55F8694B.6070904@cavium.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55F8694B.6070904@cavium.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: "Jaggi, Manish" , Xen Devel , Konrad Rzeszutek Wilk , =?UTF-8?B?4piFIFN0ZWZhbm8=?= =?UTF-8?B?IFN0YWJlbGxpbmk=?= , Ian Campbell , "Daney, David" Cc: "Prasun.kapoor@cavium.com" , "Kumar, Vijaya" List-Id: xen-devel@lists.xenproject.org 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. 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