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
