Re: [RFC PATCH] xen/dm: arm: Introudce arm_inject_msi DM op

[Jan Beulich <jbeulich@xxxxxxxx>]

On 19.12.2023 15:12, Julien Grall wrote:
> On 19/12/2023 13:57, Jan Beulich wrote:
>> On 19.12.2023 14:48, Mykyta Poturai wrote:
>>> This patch adds the ability for the device emulator to inject MSI
>>> interrupts into guests. This is done by adding a new DM op to the device
>>> model library.
>>>
>>> It is not possible to reuse already existing inject_msi DM op, because
>>> it does not have a devid parameter, which is required for translation of
>>> MSIs to interrupt numbers on ARM.
>>
>> Yet then ...
>>
>>> @@ -112,6 +113,20 @@ int dm_op(const struct dmop_args *op_args)
>>>           break;
>>>       }
>>>   
>>> +    case XEN_DMOP_arm_inject_msi:
>>> +    {
>>> +        const struct xen_dm_op_arm_inject_msi *data =
>>> +            &op.u.arm_inject_msi;
>>> +
>>> +        if ( d->arch.vgic.its == NULL )
>>> +        {
>>> +            rc = -EINVAL;
>>> +            break;
>>> +        }
>>> +        vgic_its_trigger_msi(d, d->arch.vgic.its, data->devid, data->data);
>>> +        break;
>>> +
>>> +    }
>>
>> ... you're not using the addr field at all, which therefore could likely
>> hold the devid data (encoded to really represent some form of address,
>> or stored directly - much depends on what purpose the address serves on
>> Arm for MSI).
> 
> For real HW, the address would point to an ITS doorbell. All access will 
> be tagged by the HW with the DeviceID. This is then used with the data 
> (an event ID) to look up the associated interrupt.

So no properties of the destination are encoded in the address (besides
it being an ITS specific address of course)?

> I think for Xen on Arm, we want 'addr' to be the SBDF. This could then 
> be used to find the associated vITS and device ID.

FTAOD, the vSBDF you mean then?

Jan