Re: [Xen-devel] PCI Pass-through in Xen ARM - Draft 2.

[Manish Jaggi <mjaggi@xxxxxxxxxxxxxxxxxx>]

On Tuesday 07 July 2015 02:16 PM, Manish Jaggi wrote:
> 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
If ACPI is not used IORT (sbdf - StreamID - deviceID mapping) has to be 
done in device tree.
Can we add this as a TODO. So that first series of patches can be 
accepted with StreamID == DeviceID = sbdf
> >
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel