All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Oliver Upton <oliver.upton@linux.dev>
Cc: Marc Zyngier <maz@kernel.org>,
	kvmarm@lists.linux.dev,  linux-arm-kernel@lists.infradead.org,
	kvm@vger.kernel.org,  James Morse <james.morse@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	 Zenghui Yu <yuzenghui@huawei.com>,
	isaku.yamahata@intel.com, pbonzini@redhat.com,
	 Kristina Martsenko <kristina.martsenko@arm.com>,
	stable@vger.kernek.org
Subject: Re: [PATCH] KVM: arm64: Disable preemption in kvm_arch_hardware_enable()
Date: Mon, 10 Jul 2023 15:13:30 -0700	[thread overview]
Message-ID: <ZKyCimgRJThIR0pw@google.com> (raw)
In-Reply-To: <ZKxL09AW1s2uL28x@linux.dev>

On Mon, Jul 10, 2023, Oliver Upton wrote:
> On Mon, Jul 10, 2023 at 11:04:08AM -0700, Sean Christopherson wrote:
> > On Mon, Jul 03, 2023, Marc Zyngier wrote:
> > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > > index aaeae1145359..a28c4ffe4932 100644
> > > --- a/arch/arm64/kvm/arm.c
> > > +++ b/arch/arm64/kvm/arm.c
> > > @@ -1894,8 +1894,17 @@ static void _kvm_arch_hardware_enable(void *discard)
> > >  
> > >  int kvm_arch_hardware_enable(void)
> > >  {
> > > -	int was_enabled = __this_cpu_read(kvm_arm_hardware_enabled);
> > > +	int was_enabled;
> > >  
> > > +	/*
> > > +	 * Most calls to this function are made with migration
> > > +	 * disabled, but not with preemption disabled. The former is
> > > +	 * enough to ensure correctness, but most of the helpers
> > > +	 * expect the later and will throw a tantrum otherwise.
> > > +	 */
> > > +	preempt_disable();
> > > +
> > > +	was_enabled = __this_cpu_read(kvm_arm_hardware_enabled);
> > 
> > IMO, this_cpu_has_cap() is at fault.
> 
> Who ever said otherwise?

Sorry, should have phrased that as "should be fixed".
 
> > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> > index 7d7128c65161..b862477de2ce 100644
> > --- a/arch/arm64/kernel/cpufeature.c
> > +++ b/arch/arm64/kernel/cpufeature.c
> > @@ -3193,7 +3193,9 @@ static void __init setup_boot_cpu_capabilities(void)
> >  
> >  bool this_cpu_has_cap(unsigned int n)
> >  {
> > -       if (!WARN_ON(preemptible()) && n < ARM64_NCAPS) {
> > +       __this_cpu_preempt_check("has_cap");
> > +
> > +       if (n < ARM64_NCAPS) {
> 
> This is likely sufficient, but to Marc's point we have !preemptible()
> checks littered about, it just so happens that this_cpu_has_cap() is the
> first to get called. We need to make sure there aren't any other checks
> that'd break under hotplug.

Ah, "we" is all of arm64.  E.g. this pattern in arch/arm64/kernel/cpu_errata.c
is splattered all over the place.

  WARN_ON(scope != SCOPE_LOCAL_CPU || preemptible());

AFAICT, the only issue in KVM proper is the BUG_ON() in kvm_vgic_init_cpu_hardware().

Sadly, a hack-a-fix for stable probably does make sense :-(

WARNING: multiple messages have this Message-ID (diff)
From: Sean Christopherson <seanjc@google.com>
To: Oliver Upton <oliver.upton@linux.dev>
Cc: Marc Zyngier <maz@kernel.org>,
	kvmarm@lists.linux.dev,  linux-arm-kernel@lists.infradead.org,
	kvm@vger.kernel.org,  James Morse <james.morse@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	 Zenghui Yu <yuzenghui@huawei.com>,
	isaku.yamahata@intel.com, pbonzini@redhat.com,
	 Kristina Martsenko <kristina.martsenko@arm.com>,
	stable@vger.kernek.org
Subject: Re: [PATCH] KVM: arm64: Disable preemption in kvm_arch_hardware_enable()
Date: Mon, 10 Jul 2023 15:13:30 -0700	[thread overview]
Message-ID: <ZKyCimgRJThIR0pw@google.com> (raw)
In-Reply-To: <ZKxL09AW1s2uL28x@linux.dev>

On Mon, Jul 10, 2023, Oliver Upton wrote:
> On Mon, Jul 10, 2023 at 11:04:08AM -0700, Sean Christopherson wrote:
> > On Mon, Jul 03, 2023, Marc Zyngier wrote:
> > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > > index aaeae1145359..a28c4ffe4932 100644
> > > --- a/arch/arm64/kvm/arm.c
> > > +++ b/arch/arm64/kvm/arm.c
> > > @@ -1894,8 +1894,17 @@ static void _kvm_arch_hardware_enable(void *discard)
> > >  
> > >  int kvm_arch_hardware_enable(void)
> > >  {
> > > -	int was_enabled = __this_cpu_read(kvm_arm_hardware_enabled);
> > > +	int was_enabled;
> > >  
> > > +	/*
> > > +	 * Most calls to this function are made with migration
> > > +	 * disabled, but not with preemption disabled. The former is
> > > +	 * enough to ensure correctness, but most of the helpers
> > > +	 * expect the later and will throw a tantrum otherwise.
> > > +	 */
> > > +	preempt_disable();
> > > +
> > > +	was_enabled = __this_cpu_read(kvm_arm_hardware_enabled);
> > 
> > IMO, this_cpu_has_cap() is at fault.
> 
> Who ever said otherwise?

Sorry, should have phrased that as "should be fixed".
 
> > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> > index 7d7128c65161..b862477de2ce 100644
> > --- a/arch/arm64/kernel/cpufeature.c
> > +++ b/arch/arm64/kernel/cpufeature.c
> > @@ -3193,7 +3193,9 @@ static void __init setup_boot_cpu_capabilities(void)
> >  
> >  bool this_cpu_has_cap(unsigned int n)
> >  {
> > -       if (!WARN_ON(preemptible()) && n < ARM64_NCAPS) {
> > +       __this_cpu_preempt_check("has_cap");
> > +
> > +       if (n < ARM64_NCAPS) {
> 
> This is likely sufficient, but to Marc's point we have !preemptible()
> checks littered about, it just so happens that this_cpu_has_cap() is the
> first to get called. We need to make sure there aren't any other checks
> that'd break under hotplug.

Ah, "we" is all of arm64.  E.g. this pattern in arch/arm64/kernel/cpu_errata.c
is splattered all over the place.

  WARN_ON(scope != SCOPE_LOCAL_CPU || preemptible());

AFAICT, the only issue in KVM proper is the BUG_ON() in kvm_vgic_init_cpu_hardware().

Sadly, a hack-a-fix for stable probably does make sense :-(

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-07-10 22:13 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-03 16:35 [PATCH] KVM: arm64: Disable preemption in kvm_arch_hardware_enable() Marc Zyngier
2023-07-03 16:35 ` Marc Zyngier
2023-07-04 18:32 ` Kristina Martsenko
2023-07-04 18:32   ` Kristina Martsenko
2023-07-04 18:54   ` Oliver Upton
2023-07-04 18:54     ` Oliver Upton
2023-07-05  9:36   ` Marc Zyngier
2023-07-05  9:36     ` Marc Zyngier
2023-07-10 18:04 ` Sean Christopherson
2023-07-10 18:04   ` Sean Christopherson
2023-07-10 18:16   ` Marc Zyngier
2023-07-10 18:16     ` Marc Zyngier
2023-07-10 18:20   ` Oliver Upton
2023-07-10 18:20     ` Oliver Upton
2023-07-10 22:13     ` Sean Christopherson [this message]
2023-07-10 22:13       ` Sean Christopherson
2023-07-11 20:00 ` Oliver Upton
2023-07-11 20:00   ` Oliver Upton

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=ZKyCimgRJThIR0pw@google.com \
    --to=seanjc@google.com \
    --cc=isaku.yamahata@intel.com \
    --cc=james.morse@arm.com \
    --cc=kristina.martsenko@arm.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=maz@kernel.org \
    --cc=oliver.upton@linux.dev \
    --cc=pbonzini@redhat.com \
    --cc=stable@vger.kernek.org \
    --cc=suzuki.poulose@arm.com \
    --cc=yuzenghui@huawei.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.