Re: Lockdep show 6.6-rc regression in Xen HVM CPU hotplug

[David Woodhouse <dwmw2@xxxxxxxxxxxxx>]

On Wed, 2023-10-25 at 17:10 +0100, David Woodhouse wrote:
> On Wed, 2023-10-25 at 09:19 +0200, Juergen Gross wrote:
> > On 24.10.23 15:45, David Woodhouse wrote:
> > > On Tue, 2023-10-24 at 14:08 +0200, Juergen Gross wrote:
> > > > 
> > > > > I can probably change xen_send_IPI_one() to not need 
> > > > > irq_get_chip_data().
> > > > 
> > > > David, could you test the attached patch, please? Build tested only.
> > > 
> > > No longer whines when offlining CPU1.
> > > 
> > > Still triple-faults when bringing it back online. Or if I remove the
> > > lockdep_assert_irqs_disabled() from load_current_idt(), gives the same
> > > warnings as before, all on the same theme about IRQs being enabled when
> > > they shouldn't be.
> > 
> > I think this is a false positive. No idea (again) why it would trigger only
> > with my patch applied.
> > 
> > The problem seems to be that lockdep_assert_irqs_disabled() doesn't know
> > about the "cli" at the very beginning of trampoline_start().
> 
> Right. I have no idea why your patch would make any difference to that.
> Or why it would appear only on Xen, for that matter? It doesn't even
> happen in Xen emulation under Qemu/KVM, strangely.
> 
> (I *do* have a different failure mode under KVM, where CPU1 doesn't
> seem to be receiving interrupts at all after bringing it back online,
> but only in the per-vCPU local APIC upcall mode. Still poking at that,
> which is the reason I was testing any of this in the first place)

FWIW I've finally worked out the failure mode under KVM which had me
looking at hotplug in the first place (which is because Xen checks
vcpu_info->evtchn_upcall_pending when enabling the local APIC and
injects the vector if so, while KVM wasn't doing that, so during
onlining when the vCPU sets up TIMER_VIRQ *before* setting up the local
APIC, the callback was getting lost).

I still have *no* idea why lockdep is giving us those false positives
after your patch, and no idea why it happens only on real Xen and not
in QEMU.

Attachment: smime.p7s
Description: S/MIME cryptographic signature