On 20/12/2022 16:27, David Woodhouse wrote:
On 20 December 2022 13:56:39 GMT, Paul Durrant <xadimg...@gmail.com> wrote:
The callback via is essentially just another line interrupt but its assertion
is closely coupled with the vcpu upcall_pending bit. Because that is being
dealt with in-kernel then the via should be dealt with in-kernel, right?
Not right now, because there's not a lot of point in kernel acceleration in the
case that it's delivered as GSI. There's no per-vCPU delivery, so it doesn't
get used for IPI, for timers. None of the stuff we want to accelerate
in-kernel. Only the actual PV drivers.
If we do FIFO event channels in the future then the kernel will probably need
to own those; they need spinlocks and you can have *both* userspace and kernel
delivering with test-and-set-bit sequences like you can with 2level.
Even so, I was tempted to add a VFIO-like eventfd pair for the vCPU0
evtchn_upcall_pending and let the kernel drive it... but qemu doesn't even do
the EOI side of that as $DEITY intended, so I didn't.
My point was that clearing upcall_pending is essentially the equivalent
of EOI-at-device i.e. it's the thing that drops the line. So, without
some form of interception, we need some way to check it at an
appropriate time... and as you say, there may be no exit to VMM for EOI
of the APIC. So when?
Paul
