On Mon, 2022-12-12 at 16:39 +0000, Paul Durrant wrote:
On 12/12/2022 16:26, David Woodhouse wrote:
On Mon, 2022-12-12 at 16:16 +0000, Paul Durrant wrote:
On 09/12/2022 09:56, David Woodhouse wrote:
From: Ankur Arora <ankur.a.arora@oracle.com>
The HVM_PARAM_CALLBACK_IRQ parameter controls the system-wide event
channel upcall method. The vector support is handled by KVM internally,
when the evtchn_upcall_pending field in the vcpu_info is set.
The GSI and PCI_INTX delivery methods are not supported. yet; those
need to simulate a level-triggered event on the I/OAPIC.
That's gonna be somewhat limiting if anyone runs a Windows guest with
upcall vector support turned off... which is an option at:
https://xenbits.xen.org/gitweb/?p=pvdrivers/win/xenbus.git;a=blob;f=src/xenbus/evtchn.c;;hb=HEAD#l1928
Sure. And as you know, I also added the 'xen_no_vector_callback' option
to the Linux command line to allow for that mode to be tested with
Linux too:
https://git.kernel.org/torvalds/c/b36b0fe96a
The GSI and PCI_INTX modes will be added in time, but not yet.
Ok, but maybe worth calling out the limitation in the commit comment for
those wishing to kick the tyres.
Hm... this isn't as simple in QEMU as I hoped.
The way I want to handle it is like the way that VFIO eventfd pairs
work for level-triggered interrupts: the first eventfd is triggered on
a rising edge, and the other one is a 'resampler' which is triggered on
EOI, and causes the first one to be retriggered if the level is still
actually high.
However... unlike the kernel and another VMM that you and I are
familiar with, QEMU doesn't actually hook that up to the EOI in the
APIC/IOAPIC at all.
Instead, when VFIO devices assert a level-triggered interrupt, QEMU
*unmaps* that device's BARs from the guest so it can trap-and-emulate
them, and each MMIO read or write will also trigger the resampler
(whether that line is currently masked in the APIC or not).
I suppose we could try making the page with the vcpu_info as read-only,
and trapping access to that so we spot when the guest clears its own
->evtchn_upcall_pending flag? That seems overly complex though.
So I've resorted to doing what Xen itself does: just poll the flag on
every vmexit. Patch is at the tip of my tree at
https://git.infradead.org/users/dwmw2/qemu.git/shortlog/refs/heads/xenfv
and below.
However, in the case of the in-kernel irqchip we might not even *get* a
vmexit all the way to userspace; can't a guest just get stuck in an
interrupt storm with it being handled entirely in-kernel? I might
decree that this works *only* with the split irqchip.
Then again, it'll work *nicely* in the kernel where the EOI
notification exists, so I might teach the kernel's evtchn code to
create those eventfd pairs like VFIO's, which can be hooked in as IRQFD
routing to the in-kernel {IOA,}PIC.