On Tue, 2023-10-24 at 13:29 +0100, Paul Durrant wrote:
>
> > + /* If the guest has set a per-vCPU callback vector, prefer that. */
> > + if (gsi && kvm_xen_has_vcpu_callback_vector()) {
> > + in_kernel = kvm_xen_has_cap(EVTCHN_SEND);
> > + gsi = 0;
> > + }
> > +
>
> So this deals with setting the callback via after setting the upcall
> vector. What happens if the guest then disables the upcall vector (by
> setting it to zero)? Xen checks 'v->arch.hvm.evtchn_upcall_vector != 0'
> for every event delivery.
Qemu and KVM check before each delivery too. For a vCPU other than
vCPU0, if it isn't the per-vCPU lapic upcall vector, and it isn't the
system-wide vector, the interrupt isn't supposed to be delivered (the
GSI is tied to vCPU0).
However, we don't support dynamically disabling the kernel acceleration
(telling it to forget about the VIRQs, IPIs so that we can handle them
in userspace from now on). Not except for soft reset, when they're all
torn down anyway.
I don't really *want* to support that either. Better to make the kernel
mode unconditional, having it signal userspace via an eventfd when
vCPU0 has an upcall pending and it's GSI or INTx. But that's a *pair*
of eventfds, one for the resampler... and first I have to fix Qemu's
interrupt controller models to do the resampling properly on ack (qv).
Right now this works for all guests in practice and I have other yaks
to shave :)
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
