Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp5124649rwd; Sun, 4 Jun 2023 21:27:52 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ49iYM8CGZrALf1pHI6wSd3fyX9gadKwMthhylxgcyT59p/dEbBnttQPCVjdDgGqghVLfhc X-Received: by 2002:ac8:5e52:0:b0:3f3:8c37:f1ee with SMTP id i18-20020ac85e52000000b003f38c37f1eemr6999753qtx.53.1685939272184; Sun, 04 Jun 2023 21:27:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1685939272; cv=none; d=google.com; s=arc-20160816; b=ubc3RCIi8c3tJ2NjRonO/9VKE1RgSfvpeCoHdJpYZQBaLiL5G1dMbghHlcon2y9CFQ bB2un+UF69E5R4JyyqFmfkNTAa9pM+MqTKVnwmCjjsFJ87kddmwTvvQNQmVYEKuqUB4v jHjn3SRLRnWCBSaO0+3ldf2YpqzA1Sgox8rEfQqBFfKiwjsN/B4Pld3E8fVOabsZhBaH a6nw+pItorX6NsLiUymqBcxNFs5wXpWEXn1ZthufzYiUh031hPyDFoA7VzXhoRs/tg6V TyFcnCFYmuW1si1SY58Du3ooShu6VwJKjv8iO9hVq+AusXogV90axtI6/ZdQtlf7shBv zubw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=XInRlcWSAmQuAWuzkZFXz1ffBJK2M7amA/wVsEgJPwI=; b=aUU69HTc2jg0D06edC4UDeKHZ6guOPP+2f45lQ9dcgGYdSDzJXFbBsVgCZIOGzbN3o tE8MELrnkLYa1D1WfY+iju5P+Rfu1KNy5osqYkG/WW/o7wmkLDSXROwtF64CEmxBBFmw A+R+FJER4PCcvrW/djtnS38VUpw5Z5aJO15KtsKvLnwiDdH93PYKW07o1+RGRftOwas0 EA9g2cL/XlUzwec/s9JQlVYZsTN8SHhirqzN3HiyJTy0fMUsYy0DmPP7Y4xDSaoDRUVg lXdlX3rs/wDWWxYyc9b7J7GMtKJ4YFTWpfZ+6cQJl4oxOId+k6eyqsj3TelGWs9a0+Mx 0VmQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=mgErmNct; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id o11-20020a63730b000000b0054294720d56si5086855pgc.387.2023.06.04.21.27.38; Sun, 04 Jun 2023 21:27:52 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=mgErmNct; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 S232891AbjFED6e (ORCPT + 99 others); Sun, 4 Jun 2023 23:58:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41256 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232559AbjFED61 (ORCPT ); Sun, 4 Jun 2023 23:58:27 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 699F8DF; Sun, 4 Jun 2023 20:58:25 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id E621E61DE8; Mon, 5 Jun 2023 03:58:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5394FC4339E; Mon, 5 Jun 2023 03:58:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1685937504; bh=Lozl+B9c9ZtOgU9jlGHLMSW0ijTaUHs8B+vJDZaxmP0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=mgErmNctkUMj3Cg5fufF5WtfEHwtkGjsoSQf/8rbdjspHdQIHDDPJQHQgGOItjHpg elJD8LbmhcJDo/sQ0FTE267hTCcyb6uM2z3tEFrhOIWFfJyTC099VWljAOwmxI8zx4 8SElgRpma4jSIuXrX3LwXFTtqnUzTBzaXxoKIzC1/rNkvvl6ehN+sL6hU1JwxeqaO6 NJYAUFQz5Z95djQor7BeNs+CikjXG92aMc8fE1WUrM66l5t+gPiGSn+oKs3F25rAUj l4wDa3jUXSHgtTLyijLRrR5awkrjlyx9/66jpmBFYvDoynwxIX+QQnZj6rVVDlRd+J RnkhWX1ANKVIw== Received: by mail-ed1-f48.google.com with SMTP id 4fb4d7f45d1cf-5147e441c33so9141696a12.0; Sun, 04 Jun 2023 20:58:24 -0700 (PDT) X-Gm-Message-State: AC+VfDyQ8Vqr73e6Z8kwnvW5u3n0LNgRLWU2Zg1Nd1Aqpg3gk1qfFLgD nuRhDj7EJ6dXzbihNTOWd9+aq/zi5nx2bsYfJa4= X-Received: by 2002:aa7:c252:0:b0:514:a302:c334 with SMTP id y18-20020aa7c252000000b00514a302c334mr9117220edo.14.1685937502492; Sun, 04 Jun 2023 20:58:22 -0700 (PDT) MIME-Version: 1.0 References: <20230605034423.1528206-1-maobibo@loongson.cn> In-Reply-To: <20230605034423.1528206-1-maobibo@loongson.cn> From: Huacai Chen Date: Mon, 5 Jun 2023 11:58:10 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2] PCI: Align pci memory space base address with page size To: Bibo Mao Cc: Catalin Marinas , Will Deacon , helgaas@kernel.org, linux-pci@vger.kernel.org, Jianmin Lv , WANG Xuerui , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, loongarch@lists.linux.dev, loongson-kernel@lists.loongnix.cn Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Bibo, Three suggestions: 1, split to two patches. 2, the "(align < PAGE_SIZE)" condition can be removed. 3, you can unify the comments between ARM64 and LoongArch. Huacai On Mon, Jun 5, 2023 at 11:44=E2=80=AFAM Bibo Mao wrot= e: > > Some PCI devices has only 4K memory space size, it is normal in general > machines and aligned with page size. However some architectures which > support different page size, default page size on LoongArch is 16K, and > ARM64 supports page size varying from 4K to 64K. On machines where larger > page size is use, memory space region of two different pci devices may be > in one page. It is not safe with mmu protection, also VFIO pci device > driver requires base address of pci memory space page aligned, so that it > can be memory mapped to qemu user space when it is pass-through to vm. > > It consumes more pci memory resource with page size alignment requirement= , > on 64 bit system it should not be a problem. And UEFI bios set pci memory > base address with 4K fixed-size aligned, the safer solution is to align > with larger size on UEFI BIOS stage on these architectures, linux kernel > can reuse resource from UEFI bios. For new devices such hotplug pci > devices and sriov devices, pci resource is assigned in Linux kernel side. > > Signed-off-by: Bibo Mao > --- > arch/arm64/kernel/pci.c | 13 +++++++++++++ > arch/loongarch/pci/pci.c | 18 ++++++++++++++++++ > 2 files changed, 31 insertions(+) > > diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c > index 2276689b5411..e2f7b176b156 100644 > --- a/arch/arm64/kernel/pci.c > +++ b/arch/arm64/kernel/pci.c > @@ -232,4 +232,17 @@ void pcibios_remove_bus(struct pci_bus *bus) > acpi_pci_remove_bus(bus); > } > > +resource_size_t pcibios_align_resource(void *data, const struct resource= *res, > + resource_size_t size, resource_size_t ali= gn) > +{ > + resource_size_t start =3D res->start; > + > + /* > + * align base address of pci memory resource with page size > + */ > + if ((res->flags & IORESOURCE_MEM) && (align < PAGE_SIZE)) > + start =3D ALIGN(start, PAGE_SIZE); > + > + return start; > +} > #endif > diff --git a/arch/loongarch/pci/pci.c b/arch/loongarch/pci/pci.c > index 2726639150bc..943a48e60fb1 100644 > --- a/arch/loongarch/pci/pci.c > +++ b/arch/loongarch/pci/pci.c > @@ -83,6 +83,24 @@ int pcibios_alloc_irq(struct pci_dev *dev) > return acpi_pci_irq_enable(dev); > } > > +/* > + * memory space size of some pci cards is 4K, it is separated with > + * different pages for generic architectures, so that mmu protection can > + * work with different pci cards. However page size for LoongArch system > + * is 16K, memory space of different pci cards may share the same page > + * on LoongArch, it is not safe here. > + */ > +resource_size_t pcibios_align_resource(void *data, const struct resource= *res, > + resource_size_t size, resource_size_t ali= gn) > +{ > + resource_size_t start =3D res->start; > + > + if ((res->flags & IORESOURCE_MEM) && (align < PAGE_SIZE)) > + start =3D ALIGN(start, PAGE_SIZE); > + > + return start; > +} > + > static void pci_fixup_vgadev(struct pci_dev *pdev) > { > struct pci_dev *devp =3D NULL; > -- > 2.27.0 >