Adding MSI support for virtio-pci to QEMU as Xen backend on ARM

Adding MSI support for virtio-pci to QEMU as Xen backend on ARM

[Mykyta Poturai]

Hello everyone,

I am currently working on adding MSI support to virtio-pci on ARM with Xen.
As far as I understand QEMU Xen ARM machine that is used for virtio-pci device emulation does not initialize any interrupt controllers. And that makes it somewhat unclear what is the best approach to adding the MSI support. So, I would appreciate some thoughts on this.
To trigger the MSI interrupt in Xen guests we basically need to call a single DMOP, which I am also implementing.

So far, I have come up with 3 possible approaches:
1. Hooking up the existing GIC code to the Xen Arm machine and extending it with the DMOP call.
2. Writing some new barebones GIC implementation with only the required methods (something similar to xen_apic.c).
3. Just hooking up the DMOP call to the existing PCI code based on xen_enabled() check.

Maybe there is something else that is better that I have missed.

Best regards
Mykyta

Re: Adding MSI support for virtio-pci to QEMU as Xen backend on ARM

[Stefano Stabellini]

+Stewart

On Fri, 8 Dec 2023, Mykyta Poturai wrote:
> Hello everyone,
> 
> I am currently working on adding MSI support to virtio-pci on ARM with Xen.

Excellent!


> As far as I understand QEMU Xen ARM machine that is used for virtio-pci device emulation does not initialize any interrupt controllers. And that makes it somewhat unclear what is the best approach to adding the MSI support. So, I would appreciate some thoughts on this.
> To trigger the MSI interrupt in Xen guests we basically need to call a single DMOP, which I am also implementing.

You should be able to call xen_inject_msi


> So far, I have come up with 3 possible approaches:
> 1. Hooking up the existing GIC code to the Xen Arm machine and extending it with the DMOP call.

No, I would rather avoid this for a couple of reasons. In reality, the
GIC is emulated by Xen, not QEMU. So letting QEMU think that QEMU is
emulating a GIC is more error prone than the alternatives and also it
would allocate resources needlessly.


> 2. Writing some new barebones GIC implementation with only the required methods (something similar to xen_apic.c).
> 3. Just hooking up the DMOP call to the existing PCI code based on xen_enabled() check.

I would rather not introduce any more if (xen_enabled()) checks beyond
the ones we already have unless it is the only option. So I would go
with option 2). Even better if we could reuse xen_apic.c. xen_apic.c is
just a stub, which is basically the same thing that we need here.

Re: Adding MSI support for virtio-pci to QEMU as Xen backend on ARM

[Alex Bennée]

Stefano Stabellini <sstabellini@kernel.org> writes:

> +Stewart
>
> On Fri, 8 Dec 2023, Mykyta Poturai wrote:
>> Hello everyone,
>> 
>> I am currently working on adding MSI support to virtio-pci on ARM with Xen.
>
> Excellent!
>
>
>> As far as I understand QEMU Xen ARM machine that is used for
>> virtio-pci device emulation does not initialize any interrupt
>> controllers. And that makes it somewhat unclear what is the best
>> approach to adding the MSI support. So, I would appreciate some
>> thoughts on this.
>> To trigger the MSI interrupt in Xen guests we basically need to call a single DMOP, which I am also implementing.
>
> You should be able to call xen_inject_msi
>
>
>> So far, I have come up with 3 possible approaches:
>> 1. Hooking up the existing GIC code to the Xen Arm machine and extending it with the DMOP call.
>
> No, I would rather avoid this for a couple of reasons. In reality, the
> GIC is emulated by Xen, not QEMU. So letting QEMU think that QEMU is
> emulating a GIC is more error prone than the alternatives and also it
> would allocate resources needlessly.
>
>
>> 2. Writing some new barebones GIC implementation with only the required methods (something similar to xen_apic.c).
>> 3. Just hooking up the DMOP call to the existing PCI code based on xen_enabled() check.
>
> I would rather not introduce any more if (xen_enabled()) checks beyond
> the ones we already have unless it is the only option. So I would go
> with option 2). Even better if we could reuse xen_apic.c. xen_apic.c is
> just a stub, which is basically the same thing that we need here.

I guess the APIC part of the name is part of the historical baggage of
x86 - really it's just a xenpv-irq controller?

Anyway yeah I think just move it from hw/i386/xen to hw/xen and maybe
give it a new name with an alias to the old one we can deprecate over
time?

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro