Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp3122644yba; Mon, 22 Apr 2019 20:36:18 -0700 (PDT) X-Google-Smtp-Source: APXvYqxY+I7FpNf4JiRIhYI7qxR9fuSqFn7RFJhRku9jwUD1k1KysdbEC8cdK62DVCUlY3a2fK8F X-Received: by 2002:a17:902:4681:: with SMTP id p1mr23082119pld.42.1555990578136; Mon, 22 Apr 2019 20:36:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555990578; cv=none; d=google.com; s=arc-20160816; b=c8G21sUoKMms8MsB6KqLtUggRzj7NfvHx7VjqCXJAtKEofZ+kvAcVC01rmWAFOV46f XN737paTwd9lgWQrsD+H31V2i1kD5c1vdLPbv3Qc8odvEMuQjPdQ50znimOXGJZSrlI6 mklbjl/uveWh4NmhGI9MXIwGTXjDLjJG53TwJewzL1jksN2ZjJI3dHp9FYYlXwN0eDeU a6uMbJ8x+tOlKmoKEcUES3xkJTCIAHRlasFewCphrlzV03z5rpgmcdcshmQ2Yk76hGK8 lsbJXFv/4/6OiFghxxAVrb2+IbmG30Bcs5kN70CIngRZ9xBGtYdM2yvXcgvZR12nO3jg 4UZg== 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=qZi/R0BADNVze+RLT0aJCaRWUjjdYJK7cmupg7p/ihM=; b=y9F4z05l0UAaSBhsJ163WJU5zT5QbJ8jooWvKcFvL6ruKLEvj5wBrJQYFz0xNpVtVl 7B3aTGJrQe/MTKqWjwiLl+4aeYDTICK+p+nftu5JSXsFBhbOtdNhOfezOVQ0vEQ/rXDR OFyHel8CKPMs6Pg7VKFad4gdlMBJ84GKZPSvU7gpZBUBYFnl1r3oYMhmquoZaueZLChZ GPFlMSpYbiW0OF8fd2FE3tYQaKlZjI87KuDSfBcmL8rUB3X3yTpHw/SXyspy6cTTxZC4 R2Owijt8wPBFcJeopCwjBTOsrapz2N1h7jj9QvVD6ypA3J9VEqYR/6UdKOuGByjVw0Va fiBw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="tpWNj/qZ"; 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 p16si796181plq.315.2019.04.22.20.36.03; Mon, 22 Apr 2019 20:36:18 -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="tpWNj/qZ"; 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 S1730890AbfDWAN6 (ORCPT + 99 others); Mon, 22 Apr 2019 20:13:58 -0400 Received: from mail.kernel.org ([198.145.29.99]:39488 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729885AbfDWAN5 (ORCPT ); Mon, 22 Apr 2019 20:13:57 -0400 Received: from guoren-Inspiron-7460 (23.83.240.247.16clouds.com [23.83.240.247]) (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 4D98320685; Tue, 23 Apr 2019 00:13:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1555978436; bh=jUT3W1rtS7YmOCZ3sQoFiOEjp5WEQRPO6ykT66B45h4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=tpWNj/qZiwyRp2k9/QCMjtYT3QaIA5cCeNOt3XnKN9Fa8+MR70P/2FYCfT9BadWWk +iJnspEvEIHRL5E7JxnuBJkCOOjJu1E831ncQhZt93njCMkc2pIzQ0Ei5hDJkWU4dy YJ29LMBu5n7TLDJASKdz9kg3QTSYbXOJO/Hh0JXE= Date: Tue, 23 Apr 2019 08:13:48 +0800 From: Guo Ren To: Christoph Hellwig Cc: ren_guo@c-sky.com, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, tech-privileged@lists.riscv.org, Andrew Waterman , Anup Patel , Arnd Bergmann , Greentime Hu , Marek Szyprowski , Mike Rapoport , Palmer Dabbelt , Robin Murphy , Scott Wood , Vincent Chen , Xiang Xiaoyan Subject: Re: [PATCH] riscv: Support non-coherency memory model Message-ID: <20190423001348.GA31639@guoren-Inspiron-7460> References: <1555947870-23014-1-git-send-email-guoren@kernel.org> <20190422161814.GA30694@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190422161814.GA30694@lst.de> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thx Christoph, On Mon, Apr 22, 2019 at 06:18:14PM +0200, Christoph Hellwig wrote: > On Mon, Apr 22, 2019 at 11:44:30PM +0800, guoren@kernel.org wrote: > > - Add _PAGE_COHERENCY bit in current page table entry attributes. The bit > > designates a coherence for this page mapping. Software set the bit to > > tell the hardware that the region of the page's memory area must be > > coherent with IOs devices in SOC system by PMA settings. > > If IOs and CPU are already coherent in SOC system, CPU just ignore > > this bit. > > > > PTE format: > > | XLEN-1 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 > > PFN C RSW D A G U X W R V > > ^ > > BIT(9): Coherence attribute bit > > 0: hardware needn't keep the page coherenct and software will > > maintain the coherence with cache clear/invalid operations. > > 1: hardware must keep the page coherenct and software needn't > > maintain the coherence. > > BIT(8): Reserved for software and now it's _PAGE_SPECIAL in linux > > > > Add a new hardware bit in PTE also need to modify Privileged > > Architecture Supervisor-Level ISA: > > https://github.com/riscv/riscv-isa-manual/pull/374 > > > > - Add SBI_FENCE_DMA 9 in riscv-sbi. > > sbi_fence_dma(start, size, dir) could synchronize CPU cache data with > > DMA device in non-coherency memory model. The third param's definition > > is the same with linux's in include/linux/dma-direction.h: > > Please don't make this an SBI call. We need a proper instruction > for cache flushing and invalidation. We'll also need that for pmem > support for example. I heard at least one other vendor already > had an instruction, and we really need to get this into the privileged > spec ASAP (yesterday in fact). > > If you have your own instructions already we can probably binary > patch those in using the Linux alternatives mechanism once we have > a standardized way in the privileged spec. > > We should probably start a working group for this ASAP unless we can > get another working group to help taking care of it. Good news, I prefer to use instructions directly instead of SBI_CALL. Our instruction is "dcache.c/iva %0" (one cache line) and the parameter is virtual address in S-state. When get into M-state by SBI_CALL, we could let dcache.c/iva use physical addres directly and it needn't kmap page for RV32 with highmem (Of cause highmem is not ready in RV32 now). > > > +#define pgprot_noncached pgprot_noncached > > +static inline pgprot_t pgprot_noncached(pgprot_t _prot) > > +{ > > + unsigned long prot = pgprot_val(_prot); > > + > > + prot |= _PAGE_COHERENCY; > > + > > + return __pgprot(prot); > > Nitpick: this can be shortened to > > return __pgprot(pgprot_val(prot) | _PAGE_COHERENCY)); Good. > > Also is this really a coherent flag, or an 'uncached' flag like in > many other architectures? There are a lot of features about coherency attributes, eg: cacheable, bufferable, strong order ..., and coherency is a more abstract name to contain all of these. In our hardware, coherence = uncached + unbufferable + (stong order). But I'm not very care about the name is, uncached is also ok. My key point is the bits of page attributes is very precious and this patch will use the last unused attribute bit in PTE. Another point is we could get more attribute bits by modify the riscv spec: - Remove Global bit, I think it's duplicate with the User bit in linux. - Change _PAGE_PFN_SHIFT from 10 to 12, because the huge pfn in RV32 is very useless and current RV32 linux doesn't even implement highmem. And then we could get another three page attribute bits in PTE. > > > +++ b/arch/riscv/mm/dma-mapping.c > > This should probably be called dma-noncoherent.c > > It should also have a user visible config option so that we don't > have to build it for fully coherent systems. Ok, dma-noncoherent.c is more clear. > > > +void arch_dma_prep_coherent(struct page *page, size_t size) > > +{ > > + memset(page_address(page), 0, size); > > No need for this memset, the caller takes care of it. Ok > > > diff --git a/arch/riscv/mm/ioremap.c b/arch/riscv/mm/ioremap.c > > index bd2f2db..f6aaf1e 100644 > > --- a/arch/riscv/mm/ioremap.c > > +++ b/arch/riscv/mm/ioremap.c > > @@ -73,7 +73,7 @@ static void __iomem *__ioremap_caller(phys_addr_t addr, size_t size, > > */ > > void __iomem *ioremap(phys_addr_t offset, unsigned long size) > > { > > - return __ioremap_caller(offset, size, PAGE_KERNEL, > > + return __ioremap_caller(offset, size, PAGE_KERNEL_COHERENCY, > > __builtin_return_address(0)); > > } > > EXPORT_SYMBOL(ioremap); > > I think ioremap is a different story, and should be a separate patch. Ok Best Regards Guo Ren