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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 19.12.2023 15:19, Andrew Cooper wrote:
> On 19/12/2023 1:48 pm, 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.
> 
> Ok, so the original hypercall is broken.
> 
> But the new hypercall isn't ARM specific. It's just better form of
> inject_msi, and needed for all architectures.
> 
> So, name it DMOP_inject_msi2 and get rid of the ARM infix.
> 
>> This approach was successfully tested on a virtio-pci setup with QEMU
>> backend emulating block devices with following changes from the mainline
>> Xen:
>>
>> This branch was taken as a base for virtio-pci:
>> https://github.com/xen-troops/xen/tree/xen-4.18-xt0.2
>>
>> With added new VGICv3 from here:
>> https://github.com/Deedone/xen/tree/new_vgic_v2
>> (although it should also work with the current VGIC)
>>
>> And patches from this branch to allow for proper ITS emulation in guests:
>> https://github.com/stewdk/xen/commits/pcie-passthrough-arm-vpci-v11
>>
>> The main purpose of this RFC is to get some feedback on the addition of
>> the new DM op. Is it the right approach or should we somehow modify the
>> existing inject_msi DM op to be compatible with ARM?
> 
> The DM_OP ABI does allow you to extend the structure behind
> DMOP_inject_msi, as long as 0 is meaningful.
> 
> However, the semantics of zero-extending are wrong in this case, because
> it would mean that users of DMOP_inject_msi on an updated Xen would be
> sending interrupts with an implicit source id of host bridge.
> 
> So you need a new DMOP_inject_msi2 that has better semantics.

As said in another reply, the existing structure has a 32-bit padding
field, which could be used here. In the handler it's properly being
checked to be zero right now; whether that would want to remain this
way, or whether we'd expect source ID to also be passed on x86 I don't
know (yet).

Jan