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

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





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.
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,



_______________________________________________
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®.