Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp6512321rwd; Mon, 5 Jun 2023 20:23:04 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7Y6Sz8BM5bnS6939ncSIYb6tKFH2dN/N2lHm7DPWkP5dqcwiomKO68DLzw2XJTcenV5Nlj X-Received: by 2002:a05:6808:9a7:b0:39c:274a:50f6 with SMTP id e7-20020a05680809a700b0039c274a50f6mr793632oig.23.1686021784361; Mon, 05 Jun 2023 20:23:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686021784; cv=none; d=google.com; s=arc-20160816; b=XFvyDhzQXlsIU0srqyVAfAQOH9noAuwaJTHezRvBmfFch11iNt+0cPfWbLeVsOqL0A pgKFXYI/ldjqTNluv9sNXdkJyHDThnnzzviDP584AbCygK3Ll/SpRvD4c3DilISsptDf hkTfAex7CcR2p1loOB4ryNdTv9QpxuelmOt3qTycNJsfFgAAi+DZQVd5m0SvjT9lU8OI fmbA8lOPcMDCLyPf55R5+xyjmJXtZJwE8xvE4vTvrluIkDas7WKBYc8L+5FzaoDjvnwf p/kSswCZIC60TRdhP6lBzDmwm7PP9nQLfAzo6AdGfi5yAGPBfzOJcI62A/WGcNKzJMbI B4Eg== 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=DnAo8mQ7PBHzF7VUFXq6WayXO9vev/GPjHqAPObnVy0=; b=H2889iqWfHNyIZZ/fG9glOMVQOzoITlcF2RKvbqDMUzjKpZYxt9gEE6T0t12PajPbG zzT9wDsR4OAblR6BRaEg/lxJV6nZLwgV+0dcifmk6VvbJRmP8iHCrV2vN8iNqDUbzueH +ii9PZnTwXR+kp6f7mp+cRet/VBQroduggNP5UsljmIbC8WnZTzDsnOycxITV30yV0UF hMtxWiV+Vk0mptLRDMQiXO2h+Dvkl6HHBQ8HxWv9NiDlXFQZ1BdlH8bG4kw1IcdjWnGG wnxpalUy3OOQVJ80vrbZTTvM5XwnLZrq2yjn3KnFyqK6LdEMG4KLWyu8MDezSH04/Qsw S7BA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=Fe9mMIpY; 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 j17-20020a170902da9100b001a6e98a5f21si6701881plx.586.2023.06.05.20.22.52; Mon, 05 Jun 2023 20:23:04 -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=Fe9mMIpY; 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 S233832AbjFFCRy (ORCPT + 99 others); Mon, 5 Jun 2023 22:17:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49060 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233706AbjFFCRw (ORCPT ); Mon, 5 Jun 2023 22:17:52 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AB2901A7; Mon, 5 Jun 2023 19:17:50 -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 F0F84614D8; Tue, 6 Jun 2023 02:17:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 59467C433EF; Tue, 6 Jun 2023 02:17:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1686017869; bh=PwAxfEO6U+WKSxEaEYXu3C2Un1n6Ggfy5FOFAmLtwcI=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Fe9mMIpYFB6cIcBpLMM5q2WcJyh/joZeOme7/DfuQtFJ2VYT6KAI0Gkh74//69+23 9Cs42dhFPfEBOTZUrN4YJ2xaha3+sGOfYVhtV8VEQO1hnw9qAcN42VK+pugeyFY510 YFevXn+8Nmh7H62gGlN/b2BCrGPVCD7d/XNgcUi+2jdDzVo80HDrJsqMK1I4NTCZHI U8BHJwwcBwfkO7bK4nlSdiRN/UWnmknXtvnc7v+zueM2jxaathkYf492vf0JrAiP6C hmy/WaombE0amn1d23d6x/9DeWQKuW9du52TnGnidzVER8xJMNOFfMi0OylVu/GfcX 1CQRse8FootMg== Received: by mail-ej1-f42.google.com with SMTP id a640c23a62f3a-976a0a1a92bso585066166b.1; Mon, 05 Jun 2023 19:17:49 -0700 (PDT) X-Gm-Message-State: AC+VfDw4PtbXeguzzSixR/GXTtLJ3qdFWDwZhMKVQAWpb8kNPe25YZrT 5rZvPeoQ631VhbggMYDE97jM6Z4laX2IaAaJw+c= X-Received: by 2002:a17:907:16a5:b0:978:6be4:7efb with SMTP id hc37-20020a17090716a500b009786be47efbmr679173ejc.7.1686017867509; Mon, 05 Jun 2023 19:17:47 -0700 (PDT) MIME-Version: 1.0 References: <20230605034423.1528206-1-maobibo@loongson.cn> <749898e2-01c2-9f74-f939-fac36227431a@loongson.cn> In-Reply-To: <749898e2-01c2-9f74-f939-fac36227431a@loongson.cn> From: Huacai Chen Date: Tue, 6 Jun 2023 10:17:35 +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 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 On Mon, Jun 5, 2023 at 2:31=E2=80=AFPM bibo, mao wrot= e: > > > > =E5=9C=A8 2023/6/5 11:58, Huacai Chen =E5=86=99=E9=81=93: > > Hi, Bibo, > > > > Three suggestions: > > 1, split to two patches. > will do. > > 2, the "(align < PAGE_SIZE)" condition can be removed. > With "(align < PAGE_SIZE)" condition, there is little modification compa= red > to the weak function. > resource_size_t __weak pcibios_align_resource(void *data, > const struct resource *res, > resource_size_t size, > resource_size_t align) > { > return res->start; > } Why? I think "align > PAGE_SIZE" doesn't ensure res->start is aligned here. > > or do you mean something this? > if (res->flags & IORESOURCE_MEM) { > align =3D max_t(resource_size_t, PAGE_SIZE, align); > start =3D ALIGN(start, align); > } > No, I mean use "start =3D ALIGN(start, PAGE_SIZE)" unconditionally. Huacai > > > 3, you can unify the comments between ARM64 and LoongArch. > will do. > > Regards > Bibo, Mao > > > > > Huacai > > > > On Mon, Jun 5, 2023 at 11:44=E2=80=AFAM Bibo Mao = wrote: > >> > >> Some PCI devices has only 4K memory space size, it is normal in genera= l > >> machines and aligned with page size. However some architectures which > >> support different page size, default page size on LoongArch is 16K, an= d > >> ARM64 supports page size varying from 4K to 64K. On machines where lar= ger > >> 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 requirem= ent, > >> on 64 bit system it should not be a problem. And UEFI bios set pci mem= ory > >> base address with 4K fixed-size aligned, the safer solution is to alig= n > >> with larger size on UEFI BIOS stage on these architectures, linux kern= el > >> can reuse resource from UEFI bios. For new devices such hotplug pci > >> devices and sriov devices, pci resource is assigned in Linux kernel si= de. > >> > >> 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 resou= rce *res, > >> + resource_size_t size, resource_size_t = align) > >> +{ > >> + 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 sys= tem > >> + * is 16K, memory space of different pci cards may share the same pag= e > >> + * on LoongArch, it is not safe here. > >> + */ > >> +resource_size_t pcibios_align_resource(void *data, const struct resou= rce *res, > >> + resource_size_t size, resource_size_t = align) > >> +{ > >> + 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 > >> > > _______________________________________________ > > Loongson-kernel mailing list -- loongson-kernel@lists.loongnix.cn > > To unsubscribe send an email to loongson-kernel-leave@lists.loongnix.cn >