qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Diana Madalina Craciun
Subject: Re: [Qemu-arm] [PATCH v2 0/2] Add global device ID in virt machine
Date: Fri, 11 Aug 2017 14:31:52 +0000

On 08/01/2017 05:05 AM, Michael S. Tsirkin wrote:
> On Mon, Jul 31, 2017 at 03:13:09PM +0000, Diana Madalina Craciun wrote:
>> On 07/31/2017 05:06 PM, Michael S. Tsirkin wrote:
>>> On Mon, Jul 31, 2017 at 01:22:45PM +0000, Diana Madalina Craciun wrote:
>>>>>> 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://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flwn.net%2FArticles%2F635905%2F&data=01%7C01%7Cdiana.craciun%40nxp.com%7C6b0c6c879af64718a21908d4d81d534e%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0&sdata=bpYMMqajWzgzdbdQgy%2FUYR7y%2BswyvwE%2BqFzs7wdIkkA%3D&reserved=0).
>>>>  I guess that we may have other
>>>> platform devices that are using MSIs in the future.
>>>>
>>>> Thanks,
>>>> Diana
>>>>
>>>>
>>> Don't have the time to explore NXP in depth, sorry - there's
>>> a lot of complexity there.
>>> Could you maybe stick some bits to specify bus type in there?
>>> It just looks very wrong to push low level things like this
>>> that users have no interest in up the stack.
>>>
>> Let's generalize the problem a little bit, the NXP details just does not
>> matter much. The problem we have is the following:
>>
>> The GIC-ITS, the ARM MSI controller is using deviceIDs in order to remap
>> the interrupts. Each device which is expected to send MSIs has a
>> deviceID associated with it. These deviceIDs are configured into devices
>> by software/firmware. There is support in the device tree to specify the
>> correlation between requesterID and deviceID:
>>
>> "msi-map: Maps a Requester ID to an MSI controller and associated
>>   msi-specifier data. The property is an arbitrary number of tuples of
>>   (rid-base,msi-controller,msi-base,length)"
>> (https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Ftree%2FDocumentation%2Fdevicetree%2Fbindings%2Fpci%2Fpci-msi.txt&data=01%7C01%7Cdiana.craciun%40nxp.com%7C259982f3a83b4160083708d4d881d48a%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0&sdata=QSRwrYcsTk9%2FgekD0YBYKvpWv05%2BXKiH2abPp%2FtHpes%3D&reserved=0)
>>
>> Our problem is that we have to allocate these deviceIDs in QEMU as well
>> and we have to ensure that they are unique. Currently, for PCI, the
>> assumption requesterID=deviceID is made which will no longer be true in
>> case other devices are added. So we need a way (preferable a general
>> one) to allocate these IDs to different devices in the system in a
>> consistent way which will ensure that two devices do not share the same ID.
> My question would be, do other types of devices that are there
> right now have some kind of ID like the requester ID?
> If so I would say just use that, and set high bits in the device ID
> to specify the type (e.g. 00 for pci, etc).

Would this mean extending the PCI requesterID usage as well? Or assume
that it's 00 for PCI and no changes are needed? I understand that with
this approach the allocation is  static: 00 for PCI, 01 for device type
X, etc., so the situation when we have multiple controllers (PCI or
whatever other devices) has to be solved differently. Wouldn't be this
more complex?

>
>
> IMHO if possible that is preferable to pushing this up to users.
>
>
>> The reason I put this ID into the controller itself is because on real
>> hardware is actually programmed into the controller. It is needed (for
>> example) when the MSIs are sent.
>>
>> Thanks,
>>
>> Diana
>>
> IIUC what happens on real hardware is controller maps each requester ID
> (or presumably other source ID in the request) to the device ID,
> and the mapping is internal to controller.
> If you wanted a lot of flexibility then looks like you could pass this
> mapping to controllers, but is it really necessary?
> Why don't we build a mapping that's convenient for us?
>
>
Thanks,

Diana




reply via email to

[Prev in Thread] Current Thread [Next in Thread]