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
