Re: [Qemu-devel] [PATCH v2 0/2] Add global device ID in virt machine

[Diana Madalina Craciun]

On 05/25/2017 01:12 AM, Michael S. Tsirkin wrote:
> 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://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Ftree%2Fdrivers%2Fstaging%2Ffsl-mc%2FREADME.txt%3Fh%3Dv4.10&data=01%7C01%7Cdiana.craciun%40nxp.com%7Cce2cc4d066944ce2759308d4a2f1f3f8%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0&sdata=CJAiTF6Qnq4gklSqon7xcRby0O1HQvytTUSdPwaHuSE%3D&reserved=0
>>
>> 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 ...

It is not that other devices need something else in the requester ID,
but more about finding a way to provide an unique ID across the system
(more precisely it should be unique for all devices connected to the
same IOMMU/ITS). The DT already offers support to describe the
translation between stream IDs/device IDs to requester ID for PCI
devices (iommu-map for IOMMU ([1]) and msi-map for MSIs ([2]). It will
not change the way the requester ID is used in PCI in general, but only
the places that need a unique ID (which are the MSIs and IOMMU).

If we are to use a value of 0 for the constant in case of PCI devices,
what happens if we have multiple PCI controllers?

[1]
https://www.kernel.org/doc/Documentation/devicetree/bindings/pci/pci-iommu.txt
[2]
https://www.kernel.org/doc/Documentation/devicetree/bindings/pci/pci-msi.txt

Thanks,

Diana