[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f07f6f55-9339-04b0-3877-d3240abd6d9c@redhat.com>
Date: Thu, 23 Apr 2020 10:57:57 +0200
From: Paolo Bonzini <pbonzini@...hat.com>
To: Marc Zyngier <maz@...nel.org>, Davidlohr Bueso <dave@...olabs.net>
Cc: tglx@...utronix.de, kvm@...r.kernel.org,
Davidlohr Bueso <dbueso@...e.de>, peterz@...radead.org,
torvalds@...ux-foundation.org, bigeasy@...utronix.de,
linux-kernel@...r.kernel.org, rostedt@...dmis.org,
linux-mips@...r.kernel.org, Paul Mackerras <paulus@...abs.org>,
joel@...lfernandes.org, will@...nel.org,
kvmarm@...ts.cs.columbia.edu
Subject: Re: [PATCH 4/5] kvm: Replace vcpu->swait with rcuwait
On 23/04/20 10:41, Marc Zyngier wrote:
>>
>> - if (swait_active(kvm_arch_vcpu_wq(vcpu)))
>> + if (rcu_dereference(kvm_arch_vpu_get_wait(vcpu)) != NULL)
> This doesn't compile (wrong function name, and rcu_dereference takes a
> variable). But whatever it would do if we fixed it looks dodgy. it isn't
> the rcuwait structure that you want to dereference, but rcuwait->task
> (we are checking whether we are called because we are blocking or being
> preempted).
>
Yes, I agree. Replacing swait with rcuwait is all good, but please make
the API look the same first. Just like you added prepare_to_rcuwait and
finish_rcuwait, let's add rcuwait_active as well.
Actually let's do it like this:
1) Davidlohr, please post only patches 1-3 to "equalize" the swait and
rcuwait APIs.
2) Peter, please prepare a topic branch for those, or provide Acked-by
3) let's get everything else through the KVM tree.
Thanks,
Paolo
Powered by blists - more mailing lists