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

[David Woodhouse]

On 20 December 2022 17:25:31 GMT, Paul Durrant <xadimgnik@gmail.com> wrote:
>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?

If we have an in-kernel APIC then it has a notifier callback on EOI and we can 
poll evtchn_upcall_pending then. That's another point in favour of handling it 
in kernel.

And for userspace APIC we *do* get an exit of course... but QEMU lacks that 
notifier mechanism for EOI of pseudo-level interrupts for that "should it still 
be pending?" check.