Re: [RFC PATCH v2 20/22] i386/xen: HVMOP_set_param / HVM_PARAM_CALLBACK_IRQ

[David Woodhouse]

On 20 December 2022 13:56:39 GMT, Paul Durrant <xadimgnik@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.