From: Sean Christopherson <seanjc@google.com>
To: "František Šumšal" <frantisek@sumsal.cz>
Cc: kvm@vger.kernel.org
Subject: Re: BUG: soft lockup - CPU#0 stuck for 26s! with nested KVM on 5.19.x
Date: Wed, 7 Sep 2022 15:23:30 +0000 [thread overview]
Message-ID: <Yxi3cj6xKBlJ3IJV@google.com> (raw)
In-Reply-To: <a8fc728c-073c-2ff5-2436-40c84c3c62e1@sumsal.cz>
On Wed, Sep 07, 2022, František Šumšal wrote:
> On 9/7/22 17:08, Sean Christopherson wrote:
> > On Wed, Sep 07, 2022, František Šumšal wrote:
> > > Hello!
> > >
> > > In our Arch Linux part of the upstream systemd CI I recently noticed an
> > > uptrend in CPU soft lockups when running one of our tests. This test runs
> > > several systemd-nspawn containers in succession and sometimes the underlying
> > > VM locks up due to a CPU soft lockup
> >
> > By "underlying VM", do you mean L1 or L2? Where
> >
> > L0 == Bare Metal
> > L1 == Arch Linux (KVM, 5.19.5-arch1-1/5.19.7-arch1-1)
> > L2 == Arch Linux (nested KVM or QEMU TCG, 5.19.5-arch1-1/5.19.7-arch1-1)
>
> I mean L2.
Is there anything interesting in the L1 or L0 logs? A failure in a lower level
can manifest as a soft lockup and/or stall in the VM, e.g. because a vCPU isn't
run by the host for whatever reason.
Does the bug repro with an older version of QEMU? If it's difficult to roll back
the QEMU version, then we can punt on this question for now.
Is it possible to run the nspawn tests in L1? If the bug repros there, that would
greatly shrink the size of the haystack.
next prev parent reply other threads:[~2022-09-07 15:23 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-07 9:39 BUG: soft lockup - CPU#0 stuck for 26s! with nested KVM on 5.19.x František Šumšal
2022-09-07 15:08 ` Sean Christopherson
2022-09-07 15:11 ` František Šumšal
2022-09-07 15:23 ` Sean Christopherson [this message]
2022-09-08 8:30 ` František Šumšal
2022-09-08 15:08 ` Sean Christopherson
2022-09-08 15:24 ` František Šumšal
2022-09-09 8:33 ` František Šumšal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Yxi3cj6xKBlJ3IJV@google.com \
--to=seanjc@google.com \
--cc=frantisek@sumsal.cz \
--cc=kvm@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox