Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp3675455pxv; Mon, 26 Jul 2021 09:11:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyCbnV3wtXbBtiglowiLnXkwZPpHFsaiXRKBBgA2s16B4+EFAy2T6FkEqJbF72N3AwB0z0t X-Received: by 2002:a05:6402:1768:: with SMTP id da8mr22253564edb.43.1627315859877; Mon, 26 Jul 2021 09:10:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627315859; cv=none; d=google.com; s=arc-20160816; b=PNohmOHNQM2xAI5KH0RDIgnN41uz6P6N0vd7zsW7TQk2goHByCzHsfsfQVSXiVx52+ hG/MSHBDr6T0yeWGQrsR2S0iZ3pRlz6aed4LeOtJjkmXSvrheMY1/WXnb91mLlUQ3OUu DexSk9c7wowsJIpa9K3zqOSNV/6v+SVfPkA7Uv4bOMJ7buIgQtyW/G7n/II9GVJVAEja hARwc5uZBBmC7Uih2+PU79y2swKi5mkqCYyUMqoyMHGtMvt6VtBAce/ILlicMxMA4b8d 0Zn8oGxsMtmZaINOPJhpc7SfwXn46CsqjMpEAKrC7bNbgMG1LPFrI4005VRXK25G8r75 Fu1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=JYRlEZ+cWy4VNCnkyoqgB2brluU2b5Z8pmug4Av5GNQ=; b=WqIywYUavJfi2WCD/nGbe6sjZh++8aeSYtqtdXAJ/6nFprZCDe/fKCrvw9C5vujYwa kRvX3bjAWPWRrD164LRMASzSkb29kt/1fQi+7eOl0YFpd4hhuEVvSCNt9/Mpj3lsfhg6 qkzkbzKQqgRx26Vo2GxqJyQIxO/0zf3L3VGWXq49aHlF/F5AAI1mQS2TpOikQq5aCbgz iLPTiCT0jdbWDj1pwdHScsVAqecybPc5kA88I88mcUBsrSje/rCfWIoZ6oNeEtvwSaPm FtwD9RzBtBcikL7/eyXUplJXcm5ojgRau+SiFqaNrYDOpku8zc0SCGywdfrPTWsH8wpf /ZQg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=BPTCKa8I; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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. [23.128.96.18]) by mx.google.com with ESMTP id u15si346035edt.211.2021.07.26.09.10.36; Mon, 26 Jul 2021 09:10:59 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=BPTCKa8I; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S231689AbhGZP2M (ORCPT + 99 others); Mon, 26 Jul 2021 11:28:12 -0400 Received: from mail.kernel.org ([198.145.29.99]:54616 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237459AbhGZPPr (ORCPT ); Mon, 26 Jul 2021 11:15:47 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id C890A6108B; Mon, 26 Jul 2021 15:55:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1627314945; bh=llO7j+UYXFsFMGBP2Lr/phtn9B//6nPGyDgjSbRlY04=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=BPTCKa8I0cjzgvmONZeN6PppfX+OowPyjg4RadHLiH+yFgnEge5sjLCoWkJlwEHPC Fe/Hj93b68vv0V5PRbPCsdQ1Cs5Xsws5EWoBald+Qx69bNw9YRlfq05K/LFzwxWR2C +D8XY/7YCmczRW7+avKsrggGDPLZ3lJToHGcglC3b0aSjh67M12nqSPqNfco8/a5Vz 2jdOLeMN9JyVt3b5P42RvHrqVBdLaFgRr0CUkmjl8q5k8NObN/vAhYkzYfJAytF6TX QZ6Akd8pGTgYGjiWnqysaifPhEF9learIDKmz7m+1MmOta9wdgPQQqtPvQk1+EmadC 7RWsJh8uQV+Nw== Received: by mail-oi1-f180.google.com with SMTP id t128so11440230oig.1; Mon, 26 Jul 2021 08:55:45 -0700 (PDT) X-Gm-Message-State: AOAM530cUuxkoiW96k5t3F4eSztXM4UCWCvgMXgZKIxXLQDY0HKNhbDB ap1HJR0nrIcnYhZWV0awOv632TLCvrckAWvbkqQ= X-Received: by 2002:aca:4c49:: with SMTP id z70mr11433310oia.174.1627314945217; Mon, 26 Jul 2021 08:55:45 -0700 (PDT) MIME-Version: 1.0 References: <20210726100026.12538-1-lorenzo.pieralisi@arm.com> In-Reply-To: <20210726100026.12538-1-lorenzo.pieralisi@arm.com> From: Ard Biesheuvel Date: Mon, 26 Jul 2021 17:55:33 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] ACPI: Add memory semantics to acpi_os_map_memory() To: Lorenzo Pieralisi Cc: Linux Kernel Mailing List , Will Deacon , Hanjun Guo , Sudeep Holla , Catalin Marinas , "Rafael J. Wysocki" , ACPI Devel Maling List , Linux ARM , Veronika kabatova , Robin Murphy Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 26 Jul 2021 at 12:00, Lorenzo Pieralisi wrote: > > The memory attributes attached to memory regions depend on architecture > specific mappings. > > For some memory regions, the attributes specified by firmware (eg > uncached) are not sufficient to determine how a memory region should be > mapped by an OS (for instance a region that is define as uncached in > firmware can be mapped as Normal or Device memory on arm64) and > therefore the OS must be given control on how to map the region to match > the expected mapping behaviour (eg if a mapping is requested with memory > semantics, it must allow unaligned accesses). > > Rework acpi_os_map_memory() and acpi_os_ioremap() back-end to split > them into two separate code paths: > > acpi_os_memmap() -> memory semantics > acpi_os_ioremap() -> MMIO semantics > > The split allows the architectural implementation back-ends to detect > the default memory attributes required by the mapping in question > (ie the mapping API defines the semantics memory vs MMIO) and map the > memory accordingly. > > Link: https://lore.kernel.org/linux-arm-kernel/31ffe8fc-f5ee-2858-26c5-0fd8bdd68702@arm.com > Signed-off-by: Lorenzo Pieralisi > Cc: Ard Biesheuvel > Cc: Will Deacon > Cc: Hanjun Guo > Cc: Sudeep Holla > Cc: Catalin Marinas > Cc: "Rafael J. Wysocki" For the patch in general Acked-by: Ard Biesheuvel Couple of nits/questions below > --- > arch/arm64/include/asm/acpi.h | 3 +++ > arch/arm64/kernel/acpi.c | 19 ++++++++++++++++--- > drivers/acpi/osl.c | 23 ++++++++++++++++------- > include/acpi/acpi_io.h | 8 ++++++++ > 4 files changed, 43 insertions(+), 10 deletions(-) > > diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h > index bd68e1b7f29f..7535dc7cc5aa 100644 > --- a/arch/arm64/include/asm/acpi.h > +++ b/arch/arm64/include/asm/acpi.h > @@ -50,6 +50,9 @@ pgprot_t __acpi_get_mem_attribute(phys_addr_t addr); > void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size); > #define acpi_os_ioremap acpi_os_ioremap > > +void __iomem *acpi_os_memmap(acpi_physical_address phys, acpi_size size); > +#define acpi_os_memmap acpi_os_memmap > + > typedef u64 phys_cpuid_t; > #define PHYS_CPUID_INVALID INVALID_HWID > > diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c > index f3851724fe35..1c9c2f7a1c04 100644 > --- a/arch/arm64/kernel/acpi.c > +++ b/arch/arm64/kernel/acpi.c > @@ -273,7 +273,8 @@ pgprot_t __acpi_get_mem_attribute(phys_addr_t addr) > return __pgprot(PROT_DEVICE_nGnRnE); > } > > -void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size) > +static void __iomem *__acpi_os_ioremap(acpi_physical_address phys, > + acpi_size size, bool memory) > { > efi_memory_desc_t *md, *region = NULL; > pgprot_t prot; > @@ -299,9 +300,11 @@ void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size) > * It is fine for AML to remap regions that are not represented in the > * EFI memory map at all, as it only describes normal memory, and MMIO > * regions that require a virtual mapping to make them accessible to > - * the EFI runtime services. > + * the EFI runtime services. Determine the region default > + * attributes by checking the requested memory semantics. > */ > - prot = __pgprot(PROT_DEVICE_nGnRnE); > + prot = memory ? __pgprot(PROT_NORMAL_NC) : > + __pgprot(PROT_DEVICE_nGnRnE); > if (region) { > switch (region->type) { > case EFI_LOADER_CODE: > @@ -361,6 +364,16 @@ void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size) > return __ioremap(phys, size, prot); > } > > +void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size) > +{ > + return __acpi_os_ioremap(phys, size, false); > +} > + > +void __iomem *acpi_os_memmap(acpi_physical_address phys, acpi_size size) > +{ > + return __acpi_os_ioremap(phys, size, true); > +} > + > /* > * Claim Synchronous External Aborts as a firmware first notification. > * > diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c > index 45c5c0e45e33..6db62f3a390e 100644 > --- a/drivers/acpi/osl.c > +++ b/drivers/acpi/osl.c > @@ -284,7 +284,8 @@ acpi_map_lookup_virt(void __iomem *virt, acpi_size size) > #define should_use_kmap(pfn) page_is_ram(pfn) > #endif > > -static void __iomem *acpi_map(acpi_physical_address pg_off, unsigned long pg_sz) > +static void __iomem *acpi_map(acpi_physical_address pg_off, unsigned long pg_sz, > + bool memory) > { > unsigned long pfn; > > @@ -294,7 +295,8 @@ static void __iomem *acpi_map(acpi_physical_address pg_off, unsigned long pg_sz) > return NULL; > return (void __iomem __force *)kmap(pfn_to_page(pfn)); > } else > - return acpi_os_ioremap(pg_off, pg_sz); > + return memory ? acpi_os_memmap(pg_off, pg_sz) : > + acpi_os_ioremap(pg_off, pg_sz); > } > > static void acpi_unmap(acpi_physical_address pg_off, void __iomem *vaddr) > @@ -309,9 +311,10 @@ static void acpi_unmap(acpi_physical_address pg_off, void __iomem *vaddr) > } > > /** > - * acpi_os_map_iomem - Get a virtual address for a given physical address range. > + * __acpi_os_map_iomem - Get a virtual address for a given physical address range. > * @phys: Start of the physical address range to map. > * @size: Size of the physical address range to map. > + * @memory: true if remapping memory, false if IO > * > * Look up the given physical address range in the list of existing ACPI memory > * mappings. If found, get a reference to it and return a pointer to it (its > @@ -321,8 +324,8 @@ static void acpi_unmap(acpi_physical_address pg_off, void __iomem *vaddr) > * During early init (when acpi_permanent_mmap has not been set yet) this > * routine simply calls __acpi_map_table() to get the job done. > */ > -void __iomem __ref > -*acpi_os_map_iomem(acpi_physical_address phys, acpi_size size) > +static void __iomem __ref > +*__acpi_os_map_iomem(acpi_physical_address phys, acpi_size size, bool memory) > { > struct acpi_ioremap *map; > void __iomem *virt; > @@ -353,7 +356,7 @@ void __iomem __ref > > pg_off = round_down(phys, PAGE_SIZE); > pg_sz = round_up(phys + size, PAGE_SIZE) - pg_off; > - virt = acpi_map(phys, size); > + virt = acpi_map(phys, size, memory); > if (!virt) { > mutex_unlock(&acpi_ioremap_lock); > kfree(map); > @@ -372,11 +375,17 @@ void __iomem __ref > mutex_unlock(&acpi_ioremap_lock); > return map->virt + (phys - map->phys); > } > + > +void __iomem __ref > +*acpi_os_map_iomem(acpi_physical_address phys, acpi_size size) I am aware that this just duplicated the prototype above, but I think this should be void __iomem *__ref given that the __ref comes after the * in the prototype below. > +{ > + return __acpi_os_map_iomem(phys, size, false); > +} > EXPORT_SYMBOL_GPL(acpi_os_map_iomem); > > void *__ref acpi_os_map_memory(acpi_physical_address phys, acpi_size size) > { > - return (void *)acpi_os_map_iomem(phys, size); > + return (void *)__acpi_os_map_iomem(phys, size, true); I think this should be (__force void *) to shut up sparse address space warnings. > } > EXPORT_SYMBOL_GPL(acpi_os_map_memory); > > diff --git a/include/acpi/acpi_io.h b/include/acpi/acpi_io.h > index 027faa8883aa..a0212e67d6f4 100644 > --- a/include/acpi/acpi_io.h > +++ b/include/acpi/acpi_io.h > @@ -14,6 +14,14 @@ static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys, > } > #endif > > +#ifndef acpi_os_memmap > +static inline void __iomem *acpi_os_memmap(acpi_physical_address phys, > + acpi_size size) > +{ > + return ioremap_cache(phys, size); > +} > +#endif > + > extern bool acpi_permanent_mmap; > > void __iomem __ref > -- > 2.31.0 >