On 12/2/22 01:29, Ashish Gupta (SJC) wrote:
Hi Paolo,
While we were accessing code change done by commit :
5f33887a36824f1e906863460535be5d841a4364
Bijan, noticed following:
From the changed code in commit #
5f33887a36824f1e906863460535be5d841a4364 , we see that the following check
!kvm_vcpu_apicv_active(vcpu)*/)/*
has been removed, so in fact the new code is basically assuming that
apicv is always active.
Right, instead it checks irqchip_in_kernel(kvm) && enable_apicv. This
is documented in the commit message:
However, these checks do not attempt to synchronize with changes to
the IRTE. In particular, there is no path that updates the IRTE
when APICv is re-activated on vCPU 0; and there is no path to wakeup
a CPU that has APICv disabled, if the wakeup occurs because of an
IRTE that points to a posted interrupt.
The full series is at
https://lore.kernel.org/lkml/20211123004311.2954158-2-pbonzini@xxxxxxxxxx/T/
and has more details:
Now that APICv can be disabled per-CPU (depending on whether it has
some setup that is incompatible) we need to deal with guests having
a mix of vCPUs with enabled/disabled posted interrupts. For
assigned devices, their posted interrupt configuration must be the
same across the whole VM, so handle posted interrupts by hand on
vCPUs with disabled posted interrupts.
All four patches were marked as stable, but it looks like the first
three did not apply and therefore are not part of 5.10.
78311a514099932cd8434d5d2194aa94e56ab67c
KVM: x86: ignore APICv if LAPIC is not enabled
7e1901f6c86c896acff6609e0176f93f756d8b2a
KVM: VMX: prepare sync_pir_to_irr for running with APICv disabled
37c4dbf337c5c2cdb24365ffae6ed70ac1e74d7a
KVM: x86: check PIR even for vCPUs with disabled APICv
The three commits do not have any subsequent commit that Fixes them.
The latest upstream code however seems to disable apicv conditionally
depending on if it is actually being used:
Right.
We found that, once we disable hyperv benightment for Linux vm,
everything is working fine (on v5.10.84)
Further Eiichi noticed, that your change were introduced in 5.16 and
backported to 5.10.84.
On the other hand, Vitaly's patch (commit
#0f250a646382e017725001a552624be0c86527bf) was introduced in 5.15 and
NOT backported to 5.10.X.
Should we backport Vitaly's patch to stable 5.10.X? Do you think that
will solve issue what we are facing?
As you found out there are a lot of dependent changes to introduce
__kvm_request_apicv_update so it's not really feasible.
Paolo
