From: Brendan Jackman <jackmanb@google.com>
To: Brendan Jackman <jackmanb@google.com>,
syzbot ci <syzbot+ci693402a94575bcb2@syzkaller.appspotmail.com>,
<bp@alien8.de>, <dave.hansen@linux.intel.com>, <hpa@zytor.com>,
<kvm@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<mingo@redhat.com>, <pbonzini@redhat.com>, <seanjc@google.com>,
<tglx@linutronix.de>, <x86@kernel.org>
Cc: <syzbot@lists.linux.dev>, <syzkaller-bugs@googlegroups.com>
Subject: Re: [syzbot ci] Re: KVM: x86: Unify L1TF flushing under per-CPU variable
Date: Tue, 14 Oct 2025 11:46:27 +0000 [thread overview]
Message-ID: <DDI0QRWVTMQT.3BA2T46YJLIII@google.com> (raw)
In-Reply-To: <DDHX5G54GS7D.1YC8514SPRGQF@google.com>
On Tue Oct 14, 2025 at 8:57 AM UTC, Brendan Jackman wrote:
> On Tue Oct 14, 2025 at 6:13 AM UTC, syzbot ci wrote:
>> BUG: using __this_cpu_write() in preemptible code in x86_emulate_instruction
>
> Ah. And now I realise I never booted my debug config on an actual
> Skylake host, I'd better do that, presumably running the KVM selftests
> with DEBUG_PREEMPT etc would have been enough to catch this earlier.
>
> Anyway, I guest we just want to use vcpu->arch.last_vmentry_cpu instead
> of smp_processor_id()?
Just went to code it up and changed my mind about this. If the vCPU is
being migrated, it doesn't really matter which CPU stuff like
x86_emulate_instruction() sets the bit on since it's vcpu_load()'s job to
make sure it's set on the CPU that actually needs it. So I think instead
we just want raw_cpu_write() here, then there's no pointless remote
updates. The bit might get set on a CPU that doesn't end up needing it
for the current vCPU, but it was gonna get the bit set before it ran the
next vCPU anyway.
next prev parent reply other threads:[~2025-10-14 11:46 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-13 15:20 [PATCH] KVM: x86: Unify L1TF flushing under per-CPU variable Brendan Jackman
2025-10-13 16:31 ` Sean Christopherson
2025-10-13 16:52 ` Brendan Jackman
2025-10-14 6:13 ` [syzbot ci] " syzbot ci
2025-10-14 8:57 ` Brendan Jackman
2025-10-14 11:46 ` Brendan Jackman [this message]
2025-10-14 7:24 ` [PATCH] " kernel test robot
2025-10-14 9:02 ` Brendan Jackman
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=DDI0QRWVTMQT.3BA2T46YJLIII@google.com \
--to=jackmanb@google.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=syzbot+ci693402a94575bcb2@syzkaller.appspotmail.com \
--cc=syzbot@lists.linux.dev \
--cc=syzkaller-bugs@googlegroups.com \
--cc=tglx@linutronix.de \
--cc=x86@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