Hi Manish,
On 13/08/2015 10:42, Manish Jaggi wrote:
3.2. Mapping between streamID - deviceID - pci sbdf - requesterID
-----------------------------------------------------------------------------
For a simpler case all should be equal to BDF. But there are some devices
that use the wrong requester ID for DMA transactions. Linux kernel has
PCI
quirks for these. How the same be implemented in Xen or a diffrent
approach
has to be taken is TODO here.
Till that time, for basic implementation it is assumed that all are equal
to BDF.
Back to this streamID = DeviceID = requestID = SBDF again...
I've just found a patch for Linux send by one of your colleague about
tweaking the requesterID for thunder-X board (See [1]). The most
interesting bits are:
static u32 pci_requester_id_ecam(struct pci_dev *dev)
{
return (((pci_domain_nr(dev->bus) >> 2) << 19) |
((pci_domain_nr(dev->bus) % 4) << 16) |
(dev->bus->number << 8) | dev->devfn);
}
static u32 thunder_pci_requester_id(struct pci_dev *dev, u16 alias)
{
int ret;
ret = thunder_pem_requester_id(dev);
if (ret >= 0)
return (u32)ret;
return pci_requester_id_ecam(dev);
}
Which is then used to override the default function used by ITS to find
the deviceID.
AFAICT, this means that you can't safely assume that DeviceID == sBDF
even for your platform. Is that right?
If so, I'm afraid that you have to handle DeviceID != sBDF (and so on)
in your design doc. I.e how do you plan to get the base requester ID.
I can see 2 different solutions:
1) Let DOM0 pass the first requester ID when registering the bus
Pros:
* Less per-platform code in Xen
Cons:
* Assume that the requester ID are contiguous. (Is it really a
cons?)
* Still require quirk for buggy device (i.e requester ID not
correct)
2) Do it in Xen
Pros:
* We are not relying on DOM0 giving the requester ID
=> Not assuming contiguous requester ID
Cons:
* Per PCI bridge code to handle the mapping
Regards,
[1] https://lkml.org/lkml/2015/7/15/703
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel