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

[Paul Durrant]

On 20/12/2022 16:27, David Woodhouse wrote:
> 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.

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