[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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





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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.