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@lists.xen.org
http://lists.xen.org/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
