Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp4571595ybe; Mon, 16 Sep 2019 14:41:16 -0700 (PDT) X-Google-Smtp-Source: APXvYqx5hmCdWjrrJLAdTA7eTz86bZuk73vp9Ea03lgvYwJJYexYksocKzV+tn3vE3Jz/zdsF07c X-Received: by 2002:a50:ec81:: with SMTP id e1mr1464988edr.107.1568670075981; Mon, 16 Sep 2019 14:41:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568670075; cv=none; d=google.com; s=arc-20160816; b=hnizXcHodUE6s/SxHUrc7mWEQjobP2pL15sooAUW4YkGzoTbu3CDWXyM2/1eI9QjIn XNUCdNr0vCdpL3R+/bdPcxQCt8F4O5nbyviBv6MXofey2CCSgtLKj5pUvniIAVTJaAQw ouUZUcXG1s8N3W9Zzsx6jqXOgj0JT6yYdZBq7YZ5PtBCmT4vXO8cctXs9LwUs77lDU9p XFcimB1m9S8lBMFzmHO81AB/Ood/fsDwgi6cAaX8w05rvxHoBTETGJfqIlkzgLxAv0AR rgDW/4ZNRLBkyCJ8/RcRXD0L9jP0qpHHg0eNyAJvHsZXdL9yRbPe3MzSBZNN4dxTgEq2 XVWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=kiFYiO6iGr0McyUoh7kPbPhtwBSc+p8v/ScHIRzV/dQ=; b=Fsx2+8vF130jmbiC8QmFkIejehONVdY+rsWZJDwiuS4moCuFnT31CzauJXSrD55RJt v/W6Wi2EGjJQrrur7T2jZ0vswQj5cOHZ5+GI7BDRM9DWq6ckTBxhEyEOxaHRoG6hUXtW xCgeJk0Xtz9BxuESs+bJz/xSKL76co0onG4yZMKicTlAP8KdvL2/6pBRgG8C9xBegfLF gf24WQ/QOHoIpi4Rl8PSaC0OGl+WQuzChDVHO8j7ouY/3nXSIWUcOTAAGjm0wKyK/cCR /EXoAc0cixsQcPlhNnWaau5dQBdvxJl0NUeZqNIaYrneUnWPvu+wF9vA583NgFHiLyZN Q4ew== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=hCmKcOBd; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d4si74498ejk.327.2019.09.16.14.40.52; Mon, 16 Sep 2019 14:41:15 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=hCmKcOBd; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390234AbfIPSSJ (ORCPT + 99 others); Mon, 16 Sep 2019 14:18:09 -0400 Received: from mail.kernel.org ([198.145.29.99]:40224 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732383AbfIPSSI (ORCPT ); Mon, 16 Sep 2019 14:18:08 -0400 Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A49CE206A4; Mon, 16 Sep 2019 18:18:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1568657887; bh=cvqXyAoP8LXl4eQWtl4xAFxdBZY+YNwOUsM8E8y5L+I=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=hCmKcOBdZQjDrk/s24oKublKlHuvENgTEev4fbOttzaSiyY1s8W7HQFd0rotrvv87 S4zvcdSpSDg9o+9giWpiCF24fHzYKjBU7vVaY0TzRg42R6e8zdKauzviGVD913jFxO FrwmDsU3hjX6DSKArgN63xEx+rHvAH21xb3FOAng= Date: Mon, 16 Sep 2019 19:18:00 +0100 From: Will Deacon To: Anup Patel Cc: Palmer Dabbelt , "guoren@kernel.org" , Will Deacon , "julien.thierry@arm.com" , "aou@eecs.berkeley.edu" , "james.morse@arm.com" , Arnd Bergmann , "suzuki.poulose@arm.com" , "marc.zyngier@arm.com" , "catalin.marinas@arm.com" , "linux-kernel@vger.kernel.org" , "rppt@linux.ibm.com" , Christoph Hellwig , Atish Patra , "julien.grall@arm.com" , "gary@garyguo.net" , Paul Walmsley , "christoffer.dall@arm.com" , "linux-riscv@lists.infradead.org" , "kvmarm@lists.cs.columbia.edu" , "linux-arm-kernel@lists.infradead.org" , "iommu@lists.linux-foundation.org" Subject: Re: [PATCH RFC 11/14] arm64: Move the ASID allocator code in a separate file Message-ID: <20190916181800.7lfpt3t627byoomt@willie-the-truck> References: <20190912140256.fwbutgmadpjbjnab@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Sep 15, 2019 at 05:03:38AM +0000, Anup Patel wrote: > > > > -----Original Message----- > > From: linux-kernel-owner@vger.kernel.org > owner@vger.kernel.org> On Behalf Of Palmer Dabbelt > > Sent: Saturday, September 14, 2019 7:31 PM > > To: will@kernel.org > > Cc: guoren@kernel.org; Will Deacon ; > > julien.thierry@arm.com; aou@eecs.berkeley.edu; james.morse@arm.com; > > Arnd Bergmann ; suzuki.poulose@arm.com; > > marc.zyngier@arm.com; catalin.marinas@arm.com; Anup Patel > > ; linux-kernel@vger.kernel.org; > > rppt@linux.ibm.com; Christoph Hellwig ; Atish Patra > > ; julien.grall@arm.com; gary@garyguo.net; Paul > > Walmsley ; christoffer.dall@arm.com; linux- > > riscv@lists.infradead.org; kvmarm@lists.cs.columbia.edu; linux-arm- > > kernel@lists.infradead.org; iommu@lists.linux-foundation.org > > Subject: Re: [PATCH RFC 11/14] arm64: Move the ASID allocator code in a > > separate file > > > > On Thu, 12 Sep 2019 07:02:56 PDT (-0700), will@kernel.org wrote: > > > On Sun, Sep 08, 2019 at 07:52:55AM +0800, Guo Ren wrote: > > >> On Mon, Jun 24, 2019 at 6:40 PM Will Deacon wrote: > > >> > > I'll keep my system use the same ASID for SMP + IOMMU :P > > >> > > > >> > You will want a separate allocator for that: > > >> > > > >> > https://lkml.kernel.org/r/20190610184714.6786-2-jean-philippe.bruck > > >> > er@arm.com > > >> > > >> Yes, it is hard to maintain ASID between IOMMU and CPUMMU or > > >> different system, because it's difficult to synchronize the IO_ASID > > >> when the CPU ASID is rollover. > > >> But we could still use hardware broadcast TLB invalidation > > >> instruction to uniformly manage the ASID and IO_ASID, or OTHER_ASID in > > our IOMMU. > > > > > > That's probably a bad idea, because you'll likely stall execution on > > > the CPU until the IOTLB has completed invalidation. In the case of > > > ATS, I think an endpoint ATC is permitted to take over a minute to > > > respond. In reality, I suspect the worst you'll ever see would be in > > > the msec range, but that's still an unacceptable period of time to hold a > > CPU. > > > > > >> Welcome to join our disscusion: > > >> "Introduce an implementation of IOMMU in linux-riscv" > > >> 9 Sep 2019, 10:45 Jade-room-I&II (Corinthia Hotel Lisbon) RISC-V MC > > > > > > I attended this session, but it unfortunately raised many more > > > questions than it answered. > > > > Ya, we're a long way from figuring this out. > > For everyone's reference, here is our first attempt at RISC-V ASID allocator: > http://archive.lwn.net:8080/linux-kernel/20190329045111.14040-1-anup.patel@wdc.com/T/#u With a reply stating that the patch "absolutely does not work" ;) What exactly do you want people to do with that? It's an awful lot of effort to review this sort of stuff and given that Guo Ren is talking about sharing page tables between the CPU and an accelerator, maybe you're better off stabilising Linux for the platforms that you can actually test rather than getting so far ahead of yourselves that you end up with a bunch of wasted work on patches that probably won't get merged any time soon. Seriously, they say "walk before you can run", but this is more "crawl before you can fly". What's the rush? Will