[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 08 Aug 2023 17:43:02 +0100
From: Marc Zyngier <maz@...nel.org>
To: Raghavendra Rao Ananta <rananta@...gle.com>
Cc: Sean Christopherson <seanjc@...gle.com>,
Oliver Upton <oliver.upton@...ux.dev>,
James Morse <james.morse@....com>,
Suzuki K Poulose <suzuki.poulose@....com>,
Paolo Bonzini <pbonzini@...hat.com>,
Huacai Chen <chenhuacai@...nel.org>,
Zenghui Yu <yuzenghui@...wei.com>,
Anup Patel <anup@...infault.org>,
Atish Patra <atishp@...shpatra.org>,
Jing Zhang <jingzhangos@...gle.com>,
Reiji Watanabe <reijiw@...gle.com>,
Colton Lewis <coltonlewis@...gle.com>,
David Matlack <dmatlack@...gle.com>,
linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.linux.dev,
linux-mips@...r.kernel.org, kvm-riscv@...ts.infradead.org,
linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org,
kvm@...r.kernel.org
Subject: Re: [PATCH v7 02/12] KVM: arm64: Use kvm_arch_flush_remote_tlbs()
On 2023-08-08 17:19, Raghavendra Rao Ananta wrote:
> On Tue, Aug 8, 2023 at 8:07 AM Sean Christopherson <seanjc@...gle.com>
> wrote:
>>
>> On Fri, Aug 04, 2023, Raghavendra Rao Ananta wrote:
>> > On Wed, Aug 2, 2023 at 4:28 PM Raghavendra Rao Ananta
>> > <rananta@...gle.com> wrote:
>> > >
>> > > Sure, I'll change it to kvm_arch_flush_vm_tlbs() in v8.
>> > >
>> > While working on the renaming, I realized that since this function is
>> > called from kvm_main.c's kvm_flush_remote_tlbs(). Do we want to rename
>> > this and the other kvm_flush_*() functions that the series introduces
>> > to match their kvm_arch_flush_*() counterparts?
>>
>> Hmm, if we're going to rename one arch hook, then yes, I think it
>> makes sense to
>> rename all the common APIs and arch hooks to match.
>>
>> However, x86 is rife with the "remote_tlbs" nomenclature, and renaming
>> the common
>> APIs will just push the inconsistencies into x86. While I 100% agree
>> that the
>> current naming is flawed, I am not willing to end up with x86 being
>> partially
>> converted.
>>
>> I think I'm ok renaming all of x86's many hooks? But I'd definitely
>> want input
>> from more x86 folks, and the size and scope of this series would
>> explode. Unless
>> Marc objects and/or has a better idea, the least awful option is
>> probably to ignore
>> the poor "remote_tlbs" naming and tackle it in a separate series.
>>
> Sure, I think it's better to do it in a separate series as well. I'm
> happy to carry out the task after this one gets merged. But, let's
> wait for Marc and others' opinion on the matter.
Yeah, let's punt that to a separate series. I'm more interested in
getting this code merged than in the inevitable bike-shedding that
will result from such a proposal.
Raghavendra, any chance you could respin the series this week?
I'd really like it to spend some quality time in -next...
Thanks,
M.
--
Jazz is not dead. It just smells funny...
Powered by blists - more mailing lists