Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp979762ybe; Thu, 19 Sep 2019 06:56:12 -0700 (PDT) X-Google-Smtp-Source: APXvYqwBPjWdHpwIJqYeQt6wIeZlltQjhiQA260XvbqmwC8yd7dk1vYi7i4ZzFU0Z0YuwjmpS3yx X-Received: by 2002:aa7:c614:: with SMTP id h20mr3847616edq.209.1568901372050; Thu, 19 Sep 2019 06:56:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568901372; cv=none; d=google.com; s=arc-20160816; b=U9SH5nRIoTmSlIDwRV06ra2Zc8s1gEwteOvO8lKhUDFMfDeb22yNxxT1p6876c8och VGA0Tchq6aDLgN8pZXsJy4YHUwHe40CC+xx5LP2POWkP8SWw9celUYNEfGhU/FNmaFTQ iAeFqG9RgszwJJjXJA7Iit48DjDy87jF8mi38sDtC2y6L0drPomMg/mBMOTzH/mKvc+a tXbz/htP1p4GPAHQOeTW+nOXLjPN6jaG4ga/C4I4ORh2VVFZaq0hRPo//wf87vQkW1WZ 54iAi7wljyItIeFMnTF+aBs8Xz/TFoJV4S/rAxKLZyXZChhMeAOv7FP7ovgi+zbMOxTh 8enw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=yYAMKLXRUWhJqqKacN5KDT7iw1YkJmEY8pu6fdVH/G8=; b=0UvQaWonNA8/7pIBkFr7XtXzS08Jv+HVhjQi8FRS8ID7ghBrUu5MGViPfcfOyBZaNU jqhbvHh+M/NiKCL6rTILf1YL00Y5bKRfHwpMpqlAz2N+Gc1bMJEpIfob+jo3Ce+BWfer Wddxiwbxurhnnoo9vS580to8O6iKwOXs5xMcBeXq3HmDt0v0O5IeiovazBTgJCLEkYrF YUjs3Sy4E4tWFEw+a1UnP4eXNC9fjoWkmuZNjr1FSFO8Gel9Eku01Mv7H5OQwLLgboQy MhDCGn5z1o7yTFJFJJbQ41JHmHjEGdlzVijh8YCxJncbJ40P1o7UPfFSybmlbPp/Oxwd Jrdg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=BCHVqSuL; 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 96si5343167edq.24.2019.09.19.06.55.49; Thu, 19 Sep 2019 06:56:12 -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=BCHVqSuL; 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 S1732252AbfISNHa (ORCPT + 99 others); Thu, 19 Sep 2019 09:07:30 -0400 Received: from mail.kernel.org ([198.145.29.99]:51932 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731332AbfISNHa (ORCPT ); Thu, 19 Sep 2019 09:07:30 -0400 Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 643CF21D79 for ; Thu, 19 Sep 2019 13:07:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1568898448; bh=xDlkbYtekNq2g+j/zLZRiaXJuHeVfYxFX/p6ICWFSTw=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=BCHVqSuL/6xTcR4UIQNbftn+i7ALTmzjbkxcwXg9kdHIXUeW5wKOJj0jG8SGA29kT rlFF6uog75GxK0bdFaRZNI0ABOEfr0Om7lb2CRZPfxIDL3GXQYc0LdqrbSwCsSMul1 OvFGEKKeZ74rerDPYJ6ZKN6QBZCubXMaIdO0VgrU= Received: by mail-wr1-f46.google.com with SMTP id r3so3028521wrj.6 for ; Thu, 19 Sep 2019 06:07:28 -0700 (PDT) X-Gm-Message-State: APjAAAXHPl0m8kNYX8Ex3qEL/RaAJ+oHgVzkJkbhtMVKZXo+EkEuZ1Cf RlBBXutW0jESZlAMhaD+1RYwRKnm0SxaQKgiRTw= X-Received: by 2002:a5d:66d2:: with SMTP id k18mr7066721wrw.7.1568898446854; Thu, 19 Sep 2019 06:07:26 -0700 (PDT) MIME-Version: 1.0 References: <20190321163623.20219-12-julien.grall@arm.com> <0dfe120b-066a-2ac8-13bc-3f5a29e2caa3@arm.com> <20190619091219.GB7767@fuggles.cambridge.arm.com> <20190619123939.GF7767@fuggles.cambridge.arm.com> <20190624104006.lvm32nahemaqklxc@willie-the-truck> <20190912140256.fwbutgmadpjbjnab@willie-the-truck> <057a0af3-93f7-271c-170e-4b31e6894c3c@linaro.org> In-Reply-To: <057a0af3-93f7-271c-170e-4b31e6894c3c@linaro.org> From: Guo Ren Date: Thu, 19 Sep 2019 21:07:15 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH RFC 11/14] arm64: Move the ASID allocator code in a separate file To: Jean-Philippe Brucker Cc: Will Deacon , Catalin Marinas , Palmer Dabbelt , christoffer.dall@arm.com, Atish Patra , Julien Grall , gary@garyguo.net, linux-riscv@lists.infradead.org, kvmarm@lists.cs.columbia.edu, Mike Rapoport , aou@eecs.berkeley.edu, Arnd Bergmann , suzuki.poulose@arm.com, Marc Zyngier , Paul Walmsley , linux-arm-kernel@lists.infradead.org, Anup Patel , Linux Kernel Mailing List , iommu@lists.linux-foundation.org, james.morse@arm.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Mon, Sep 16, 2019 at 8:57 PM Jean-Philippe Brucker wrote: > On 13/09/2019 09:13, Guo Ren wrote: > > Another idea is seperate remote TLB invalidate into two instructions: > > > > - sfence.vma.b.asyc > > - sfence.vma.b.barrier // wait all async TLB invalidate operations > > finished for all harts. > > It's not clear to me how this helps, but I probably don't have the whole > picture. If you have a place where it is safe to wait for the barrier to > complete, why not do the whole invalidate there? > > > (I remember who mentioned me separate them into two instructions after > > session. Anup? Is the idea right ?) Forget it, I still use irq signal in my formal proposal [1]. I also couldn't image the whole picture :P > > To solve the problem, we could define a async mode in sfence.vma.b to > > slove the problem and finished with per_cpu_irq/exception. > > The solution I had to this problem is pinning the ASID [1] used by the > IOMMU, to prevent the CPU from recycling the ASID on rollover. This way > the CPU doesn't have to wait for IOMMU invalidations to complete, when > scheduling a task that might not even have anything to do with the IOMMU. > > In the Arm SMMU, ASID and IOASID (PASID) are separate identifiers. IOASID > indexes an entry in the context descriptor table, which contains the ASID. > So with unpinned shared ASID you don't need to invalidate the ATC on > rollover, since the IOASID doesn't change, but you do need to modify the > context descriptor and invalidate cached versions of it. The terminology confused me a lot. I perfer use PASID for IOMMU and ASID is for CPU. Arm's entry of the context descriptor table contains a "IOASID" IOASID != ASID for CPU_TLB and IOMMU_TLB. When you say "since the IOASID doesn't change",Is it PASID or my IOASID ? -_*! PASID in PCI-sig was used to determine transfer address space. For intel, the entry which is indexed by PASID also contain S1/S2.PGD and DID(VMID). For arm, the entry which is indexed by PASID only contain S1.PGD and IOASID. Compare to Intel Vt-d Scalable mode, arm's design can't support PCI Virtual Function. > > Once you have pinned ASIDs, you could also declare that IOASID = ASID. I > don't remember finding an argument to strictly forbid it, even though ASID > and IOASID have different sizes on Arm (respectively 8/16 and 20 bits). ASID and IOASID are hard to keep the same between CPU system and IOMMU system. So I introduce S1/S2.PGD.PPN as a bridge between CPUs and IOMMUs. See my proposal [1] 1: https://lore.kernel.org/linux-csky/1568896556-28769-1-git-send-email-guoren@kernel.org/T/#u -- Best Regards Guo Ren ML: https://lore.kernel.org/linux-csky/