From: Guo Ren <guoren@kernel.org> To: Catalin Marinas <catalin.marinas@arm.com> Cc: aou@eecs.berkeley.edu, Marc Zyngier <marc.zyngier@arm.com>, Anup Patel <anup.Patel@wdc.com>, Will Deacon <will.deacon@arm.com>, linux-kernel@vger.kernel.org, rppt@linux.ibm.com, hch@infradead.org, Atish Patra <Atish.Patra@wdc.com>, Julien Grall <julien.grall@arm.com>, Palmer Dabbelt <palmer@sifive.com>, gary@garyguo.net, paul.walmsley@sifive.com, linux-riscv@lists.infradead.org, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH RFC 11/14] arm64: Move the ASID allocator code in a separate file Date: Mon, 24 Jun 2019 00:35:35 +0800 Message-ID: <CAJF2gTTVUToRkRtxTmtWDotMGXy5YQCpL1h_2neTBuN3e6oz1w@mail.gmail.com> (raw) In-Reply-To: <20190621141606.GF18954@arrakis.emea.arm.com> Thx Catalin, On Fri, Jun 21, 2019 at 10:16 PM Catalin Marinas <catalin.marinas@arm.com> wrote: > > On Wed, Jun 19, 2019 at 07:51:03PM +0800, Guo Ren wrote: > > On Wed, Jun 19, 2019 at 4:54 PM Julien Grall <julien.grall@arm.com> wrote: > > > On 6/19/19 9:07 AM, Guo Ren wrote: > > > > Move arm asid allocator code in a generic one is a agood idea, I've > > > > made a patchset for C-SKY and test is on processing, See: > > > > https://lore.kernel.org/linux-csky/1560930553-26502-1-git-send-email-guoren@kernel.org/ > > > > > > > > If you plan to seperate it into generic one, I could co-work with you. > > > > > > Was the ASID allocator work out of box on C-Sky? > > > > Almost done, but one question: > > arm64 remove the code in switch_mm: > > cpumask_clear_cpu(cpu, mm_cpumask(prev)); > > cpumask_set_cpu(cpu, mm_cpumask(next)); > > > > Why? Although arm64 cache operations could affect all harts with CTC > > method of interconnect, I think we should keep these code for > > primitive integrity in linux. Because cpu_bitmap is in mm_struct > > instead of mm->context. > > We didn't have a use for this in the arm64 code, so no point in > maintaining the mm_cpumask. On some arm32 systems (ARMv6) with no > hardware broadcast of some TLB/cache operations, we use it to track > where the task has run to issue IPI for TLB invalidation or some > deferred I-cache invalidation. The operation of set/clear mm_cpumask was removed in arm64 compared to arm32. It seems no side effect on current arm64 system, but from software meaning it's wrong. I think we should keep mm_cpumask just like arm32. > > (there was also a potential optimisation on arm64 to avoid broadcast > TLBI if the task only ran on a single CPU but Will found that was rarely > the case on an SMP system because of rebalancing happening during > execve(), ending up with two bits set in the mm_cpumask) > > The way you use it on csky is different from how it is done on arm. It > seems to clear the mask for the scheduled out (prev) task but this > wouldn't work on arm(64) since the TLB still contains prev entries > tagged with the scheduled out ASID. Whether it matters, I guess it > depends on the specifics of your hardware. Sorry for the mistake quote, what I mean is what is done in arm32: clear all bits of mm->cpu_mask in new_context(), and set back one by one. Here is my patch: https://lore.kernel.org/linux-csky/CAJF2gTQ0xQtQY1t-g9FgWaxfDXppMkFooCQzTFy7+ouwUfyA6w@mail.gmail.com/T/#m2ed464d2dfb45ac6f5547fb3936adf2da456cb65 > > While the algorithm may seem fairly generic, the semantics have a few > corner cases specific to each architecture. See [1] for a description of > the semantics we need on arm64 (CnP is a feature where the hardware > threads of the same core can share the TLB; the original algorithm > violated the requirements when this feature was enabled). C-SKY SMP is only one hart per core, but here is a patch [1] with my thought on SMT duplicate tlb flush: [1] https://lore.kernel.org/linux-csky/1561305869-18872-1-git-send-email-guoren@kernel.org/T/#u For TLA+ model, I still need some learning before I could talk with you. > > BTW, if you find the algorithm fairly straightforward ;), see this > bug-fix which took a formal model to identify: a8ffaaa060b8 ("arm64: > asid: Do not replace active_asids if already 0"). I think it's one fo the cases that other archs also could get benefit from arm's asid allocator code. Btw, Is this detected by arm's aisd allocator TLA+ model ? Or a real bug report ? -- Best Regards Guo Ren ML: https://lore.kernel.org/linux-csky/ _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
next prev parent reply index Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-03-21 16:36 [PATCH RFC 00/14] kvm/arm: Align the VMID allocation with the arm64 ASID one Julien Grall 2019-03-21 16:36 ` [PATCH RFC 01/14] arm64/mm: Introduce asid_info structure and move asid_generation/asid_map to it Julien Grall 2019-03-21 17:03 ` Suzuki K Poulose 2019-03-21 17:27 ` Julien Grall 2019-03-21 16:36 ` [PATCH RFC 02/14] arm64/mm: Move active_asids and reserved_asids to asid_info Julien Grall 2019-03-21 16:36 ` [PATCH RFC 03/14] arm64/mm: Move bits " Julien Grall 2019-03-21 16:36 ` [PATCH RFC 04/14] arm64/mm: Move the variable lock and tlb_flush_pending " Julien Grall 2019-03-21 16:36 ` [PATCH RFC 05/14] arm64/mm: Remove dependency on MM in new_context Julien Grall 2019-03-21 16:36 ` [PATCH RFC 06/14] arm64/mm: Store the number of asid allocated per context Julien Grall 2019-03-21 16:36 ` [PATCH RFC 07/14] arm64/mm: Introduce NUM_ASIDS Julien Grall 2019-03-21 16:36 ` [PATCH RFC 08/14] arm64/mm: Split asid_inits in 2 parts Julien Grall 2019-03-21 16:36 ` [PATCH RFC 09/14] arm64/mm: Split the function check_and_switch_context in 3 parts Julien Grall 2019-03-21 16:36 ` [PATCH RFC 10/14] arm64/mm: Introduce a callback to flush the local context Julien Grall 2019-03-21 16:36 ` [PATCH RFC 11/14] arm64: Move the ASID allocator code in a separate file Julien Grall 2019-06-05 16:56 ` Julien Grall 2019-06-05 20:41 ` Palmer Dabbelt 2019-06-11 1:56 ` Gary Guo 2019-06-19 8:07 ` Guo Ren 2019-06-19 8:54 ` Julien Grall 2019-06-19 9:12 ` Will Deacon 2019-06-19 12:18 ` Guo Ren 2019-06-19 12:39 ` Will Deacon 2019-06-20 9:33 ` Guo Ren 2019-06-24 10:40 ` Will Deacon 2019-06-25 7:25 ` Palmer Dabbelt 2019-09-07 23:52 ` Guo Ren 2019-09-12 14:02 ` Will Deacon 2019-09-12 14:59 ` Guo Ren 2019-09-13 7:13 ` Guo Ren 2019-09-14 8:49 ` Guo Ren 2019-09-16 12:57 ` Jean-Philippe Brucker 2019-09-19 13:07 ` Guo Ren 2019-09-19 15:18 ` Jean-Philippe Brucker 2019-09-20 0:07 ` Guo Ren 2019-09-20 7:18 ` Jean-Philippe Brucker 2019-09-14 14:01 ` Palmer Dabbelt 2019-09-15 5:03 ` Anup Patel 2019-09-16 18:18 ` Will Deacon 2019-09-16 18:28 ` Palmer Dabbelt 2019-09-17 3:42 ` Anup Patel 2019-09-19 13:36 ` Guo Ren 2019-06-19 11:51 ` Guo Ren 2019-06-19 12:52 ` Julien Grall 2019-06-21 14:16 ` Catalin Marinas 2019-06-23 16:35 ` Guo Ren [this message] 2019-06-24 10:22 ` Will Deacon 2019-06-27 9:41 ` qi.fuli 2019-06-27 10:26 ` Will Deacon 2019-06-24 15:38 ` Catalin Marinas 2019-06-30 4:29 ` Guo Ren 2019-07-01 9:17 ` Catalin Marinas 2019-07-16 3:31 ` Guo Ren 2019-07-22 16:38 ` Catalin Marinas 2019-03-21 16:36 ` [PATCH RFC 12/14] arm64/lib: asid: Allow user to update the context under the lock Julien Grall 2019-03-21 16:36 ` [PATCH RFC 13/14] arm/kvm: Introduce a new VMID allocator Julien Grall 2019-03-21 16:36 ` [PATCH RFC 14/14] kvm/arm: Align the VMID allocation with the arm64 ASID one Julien Grall
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=CAJF2gTTVUToRkRtxTmtWDotMGXy5YQCpL1h_2neTBuN3e6oz1w@mail.gmail.com \ --to=guoren@kernel.org \ --cc=Atish.Patra@wdc.com \ --cc=anup.Patel@wdc.com \ --cc=aou@eecs.berkeley.edu \ --cc=catalin.marinas@arm.com \ --cc=gary@garyguo.net \ --cc=hch@infradead.org \ --cc=julien.grall@arm.com \ --cc=kvmarm@lists.cs.columbia.edu \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-riscv@lists.infradead.org \ --cc=marc.zyngier@arm.com \ --cc=palmer@sifive.com \ --cc=paul.walmsley@sifive.com \ --cc=rppt@linux.ibm.com \ --cc=will.deacon@arm.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
KVM ARM Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/kvmarm/0 kvmarm/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 kvmarm kvmarm/ https://lore.kernel.org/kvmarm \ kvmarm@lists.cs.columbia.edu public-inbox-index kvmarm Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/edu.columbia.cs.lists.kvmarm AGPL code for this site: git clone https://public-inbox.org/public-inbox.git