On Tue, May 23, 2017 at 02:12:43PM +0300, Diana Craciun wrote: > The NXP DPAA2 is a hardware architecture designed for high-speeed network > packet processing. The DPAA2 hardware components are managed by a hardware > component called the Management Complex (or MC) which provides an > object-base abstraction for software drivers to use the DPAA2 hardware. > For more details you can see: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/fsl-mc/README.txt?h=v4.10 > > The interrupts generated by the DPAA2 hardware components are MSIs. We will > add > support for direct assigning these DPAA2 components/objects to a virtual > machine. However, this will add the need to expand the MSI usage in QEMU. > > Currently the MSIs in QEMU are pretty much tied to PCI. For ARM the > GIC ITS is using a device ID for interrupt translation. Currently, for > PCI, the requester ID is used as device ID. This will not work when > we add another entity that needs also a device ID which is supposed to > be unique across the system. > > My proposal is to add a static allocation in the virt machine. I considered > that this allocation is specific to each machine/platform. Currently only > virt machine has it, but other implementations may use the same mechanism > as well. > So, I used a static allocation with this formula: > > DeviceID = zero_extend( RequesterID[15:0] ) + 0x10000 * Constant > > This formula was taken from SBSA spec (Appendix I: DeviceID generation and > ITS groups). In case of QEMU the constant will be different for each entity. > In this way a unique DeviceID will be generated and the device ID will be > derived from a requesterID (in case of PCI) or other means in case of other > entities. > > The implementation is generic as there might be in the future other non-pci > devices > that are using MSIs or IOMMU. Any architecture can use it, though currently > only the ARM architecture is using the function that retrieves the stream ID. > I > did not change all the replacements of the pci_requester_id (with > pci_stream_id) > in the code (although if the constant is 0, the stream_id is equal with > requester_id). > The other architectures (e.g. intel iommu code) assume that the ID is the > requester ID. > > Tested on NXP LS2080 platform. > > History:
I am confused. I get it that non-PCI things want something else in their requester ID, but why require it for PCI devices? How about using Constant == 0 for PCI? This way you do not need to touch PCI at all as DeviceID == RequesterID ... > v1->v2 > ------ > - the stream ID was added as a field in the pci device structure in order > not to traverse the PCI hierarchy each time a MSI is sent. > > > Diana Craciun (2): > Increased the size of requester_id field from MemTxAttrs > Add a unique ID in the virt machine to be used as device ID > > hw/arm/virt.c | 26 ++++++++++++++++++++++++++ > hw/i386/amd_iommu.c | 2 +- > hw/i386/intel_iommu.c | 2 +- > hw/intc/arm_gicv3_its_common.c | 2 +- > hw/intc/arm_gicv3_its_kvm.c | 2 +- > hw/pci-host/gpex.c | 6 ++++++ > hw/pci/msi.c | 2 +- > hw/pci/pci.c | 25 +++++++++++++++++++++++++ > include/exec/memattrs.h | 4 ++-- > include/hw/arm/virt.h | 1 + > include/hw/intc/arm_gicv3_its_common.h | 2 +- > include/hw/pci-host/gpex.h | 2 ++ > include/hw/pci/pci.h | 8 ++++++++ > kvm-all.c | 4 ++-- > 14 files changed, 78 insertions(+), 10 deletions(-) > > -- > 2.5.5
