[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] PCI Pass-through in Xen ARM: Draft 4
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@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |