From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: PCI Pass-through in Xen ARM - Draft 2. Date: Thu, 9 Jul 2015 09:08:26 +0100 Message-ID: <559E2BFA.3050903@citrix.com> References: <55903F12.7010908@caviumnetworks.com> <55911E66.2040009@citrix.com> <5598C6CD.2040207@caviumnetworks.com> <559A5BE4.1060707@citrix.com> <559A61FB.9070707@caviumnetworks.com> <559A6A4C.1090401@citrix.com> <559B7B4C.7080003@caviumnetworks.com> <559B8B64.9030800@citrix.com> <559B91DB.8030408@caviumnetworks.com> <1436268295.25646.162.camel@citrix.com> <559E1F0D.4050604@caviumnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <559E1F0D.4050604@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 , Ian Campbell Cc: Prasun Kapoor , "Kumar, Vijaya" , Stefano Stabellini , "Kulkarni, Ganapatrao" , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org Hi Manish, On 09/07/2015 08:13, Manish Jaggi wrote: >> >> If this was a domctl there might be scope for accepting an >> implementation which made assumptions such as sbdf == deviceid. However >> I'd still like to see this topic given proper treatment in the design >> and not just glossed over with "this is how ThunderX does things". > I got your point. >> Or maybe the solution is simple and we should just do it now -- i.e. can >> we add a new field to the PHYSDEVOP_pci_host_bridge_add argument struct >> which contains the base deviceid for that bridge > deviceId would be same as sbdf. As we dont have a way to translate sbdf > to deviceID. I think we have to be clear in this design document about the different meaning. When the Device Tree is used, it's assumed that the deviceID will be equal to the requester ID and not the sbdf. Linux provides a function (pci_for_each_dma_alias) which will return a requester ID for a given PCI device. It appears that the BDF (the 's' of sBDF is only internal to Linux and not part of the hardware) is equal to the requester ID on your platform but we can't assume it for anyone else. When we have a PCI in hand, we have to find the requester ID for this device. On we have it we can deduce the streamID and the deviceID. The way to do it will depend on whether we use device tree or ACPI: - For device tree, the streamID, and deviceID will be equal to the requester ID - For ACPI, we would have to look up in the ACPI IORT. For the latter, I think they are static tables and therefore can be parse in Xen. So we wouldn't need to PHYSDEVOP_pci_host_bridge_add to pass an offset. This will also avoid any assumption that deviceID for a given root complex are always contiguous and make extendable for any new hardware require a different *ID. So what we really care is the requester ID. Although, I'm not sure if you can find it in Xen. If not, we may need to customize (i.e adding a new PHYSDEVOP) PCI add device to take a requesterID in parameter. Now, in the case of the guest, as we are only supporting device tree, we could make the assumption that requesterID == deviceID as long as this is exposed in a DOMCTL to allow us flexibility. It would make sense to extend DOMCTL_assign_device to take the vBDF (or requesterID?) in parameter. Regards, -- Julien Grall