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

[Diana Madalina Craciun]

On 07/06/2017 02:44 AM, Michael S. Tsirkin wrote:
> On Wed, May 31, 2017 at 12:02:56PM +0000, Diana Madalina Craciun wrote:
>> 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?
> I guess we'd use the PCI Segment number for that?
>
>

Yes, we can use the PCI segment for this scenario. But this would mean
different solutions for the same problem. The main problem is that we
can have multiple entities in the system that are using MSIs (for now
PCI and NXP non-PCI bus infrastructure
(https://lwn.net/Articles/635905/). I guess that we may have other
platform devices that are using MSIs in the future.

Thanks,
Diana