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

[Manish Jaggi <mjaggi@xxxxxxxxxxxxxxxxxx>]

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

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