[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <458f6b85-cdb2-5e6b-6730-4875f0e4cdba@redhat.com>
Date: Mon, 5 Aug 2019 09:14:44 +0200
From: Paolo Bonzini <pbonzini@...hat.com>
To: Anup Patel <anup@...infault.org>
Cc: Anup Patel <Anup.Patel@....com>,
Palmer Dabbelt <palmer@...ive.com>,
Paul Walmsley <paul.walmsley@...ive.com>,
Radim K <rkrcmar@...hat.com>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Thomas Gleixner <tglx@...utronix.de>,
Atish Patra <Atish.Patra@....com>,
Alistair Francis <Alistair.Francis@....com>,
Damien Le Moal <Damien.LeMoal@....com>,
Christoph Hellwig <hch@...radead.org>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH v2 10/19] RISC-V: KVM: Handle WFI exits for VCPU
On 05/08/19 09:12, Anup Patel wrote:
> On Fri, Aug 2, 2019 at 2:33 PM Paolo Bonzini <pbonzini@...hat.com> wrote:
>>
>> On 02/08/19 09:47, Anup Patel wrote:
>>> + if (!kvm_riscv_vcpu_has_interrupt(vcpu)) {
>>
>> This can be kvm_arch_vcpu_runnable instead, since kvm_vcpu_block will
>> check it anyway before sleeping.
>
> I think we can skip this check here because kvm_vcpu_block() is
> checking it anyway. Agree ??
Yes, but it's quite a bit faster to do this outside the call. There's a
bunch of setup before kvm_vcpu_block reaches that point, and it includes
mfences too once you add srcu_read_unlock/lock here.
Paolo
Powered by blists - more mailing lists