From mboxrd@z Thu Jan 1 00:00:00 1970 From: Manish Jaggi Subject: Re: PCI Pass-through in Xen ARM - Draft 2. Date: Tue, 7 Jul 2015 14:16:19 +0530 Message-ID: <559B91DB.8030408@caviumnetworks.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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <559B8B64.9030800@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 , "xen-devel@lists.xen.org" , Ian Campbell , Konrad Rzeszutek Wilk , Stefano Stabellini , "Kulkarni, Ganapatrao" , Prasun Kapoor , "Kumar, Vijaya" List-Id: xen-devel@lists.xenproject.org On Tuesday 07 July 2015 01:48 PM, Julien Grall wrote: > Hi Manish, > > On 07/07/2015 08:10, Manish Jaggi wrote: >> On Monday 06 July 2015 05:15 PM, Julien Grall wrote: >>> On 06/07/15 12:09, Manish Jaggi wrote: >>>> >>>> On Monday 06 July 2015 04:13 PM, Julien Grall wrote: >>>>> On 05/07/15 06:55, Manish Jaggi wrote: >>>>>>>> 4.3 Hypercall for bdf mapping notification to xen >>>>>>>> ----------------------------------------------- >>>>>>>> #define PHYSDEVOP_map_sbdf 43 >>>>>>>> typedef struct { >>>>>>>> u32 s; >>>>>>>> u8 b; >>>>>>>> u8 df; >>>>>>>> u16 res; >>>>>>>> } sbdf_t; >>>>>>>> struct physdev_map_sbdf { >>>>>>>> int domain_id; >>>>>>>> sbdf_t sbdf; >>>>>>>> sbdf_t gsbdf; >>>>>>>> }; >>>>>>>> >>>>>>>> Each domain has a pdev list, which contains the list of all pci >>>>>>>> devices. >>>>>>>> The >>>>>>>> pdev structure already has a sbdf information. The arch_pci_dev is >>>>>>>> updated to >>>>>>>> contain the gsbdf information. (gs- guest segment id) >>>>>>>> >>>>>>>> Whenever there is trap from guest or an interrupt has to be >>>>>>>> injected, >>>>>>>> the pdev >>>>>>>> list is iterated to find the gsbdf. >>>>>>> Can you give more background for this section? i.e: >>>>>>> - Why do you need this? >>>>>>> - How xen will translate the gbdf to a vDeviceID? >>>>>> In the context of the hypercall processing. >>>>> That wasn't my question. I asked, how Xen will find the mapping >>>>> between >>>>> the gdbf and vDeviceID? He doesn't have access to the firmware table >>>>> and >>>>> therefore not able to find the right one. >>>> I believe gsbdf and vDeviceID would be same. >>> Xen and the guest need to translate the gsbdf the same way. If this is >>> clearly defined by a spec, then you should give a link to it. >> They are same, will change sbdf ->DeviceID and gsbdf->vDeviceID. > > As asked you in the previous mail, can you please prove it? The > function used to get the requester ID (pci_for_each_dma_alias) is more > complex than a simple return sbdf. I am not sure what you would like me to prove. As of ThunderX Xen code we have assumed sbdf == deviceID. We are not using ACPI as of now. This is our implementation. It cannot be wrong outrightly. Can you please suggest what could be the other approach. > > Furthermore, AFAICT, the IORT Table (from ACPI) [1] is used to specify > the relationships between the requester ID and the DeviceID. So it's > not obvious that sbdf == DeviceID. > >>> If not, you have to explain in this design doc how you plan to have xen >>> and the guest using the same vdevID for a given gsbdf. >>> >>> Regards, >>> >> > > [1] > http://infocenter.arm.com/help/topic/com.arm.doc.den0049a/DEN0049A_IO_Remapping_Table.pdf > >