From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id 7D15C7803DF for ; Wed, 20 Dec 2023 15:18:07 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=FCd/l/mVR3ndeiQR3sGaM3upH4qIjvGBatU6IUoLQw0=; c=relaxed/simple; d=groups.io; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:To:Cc:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type; s=20140610; t=1703085486; v=1; b=u9lTKMXOpQDxIgxkGgBYBFLEUJigwRvn4G2COgwsxxir2c446Zf3oBWbheFXE3RkC5YsY1nt 5BKo7qZKnvCL2nxUjRk+vA0BVmcDRHQT8UxEV9wB8EPuc4u65ot52yzqGqbmnDdDVWxiqTdxG7x IV7/zbayvxEFXsF5ZV+SfkYo= X-Received: by 127.0.0.2 with SMTP id lW9rYY7687511xupYyq0mbb7; Wed, 20 Dec 2023 07:18:06 -0800 X-Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by mx.groups.io with SMTP id smtpd.web10.24017.1703085485136652976 for ; Wed, 20 Dec 2023 07:18:05 -0800 X-Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id F3903CE1D6D for ; Wed, 20 Dec 2023 15:18:01 +0000 (UTC) X-Received: by smtp.kernel.org (Postfix) with ESMTPSA id 387BAC433C8 for ; Wed, 20 Dec 2023 15:18:01 +0000 (UTC) X-Received: by mail-lj1-f180.google.com with SMTP id 38308e7fff4ca-2cc6acf5e3dso47103431fa.1 for ; Wed, 20 Dec 2023 07:18:01 -0800 (PST) X-Gm-Message-State: fkzmp6QO2fiD9EBnpvORn7Jnx7686176AA= X-Google-Smtp-Source: AGHT+IHWcD5eZH5C/r3HYSBPU7XlwwADEI1lMzCgJd14THcgFcihlJ4NNfYq4g9ezYLsH3wSFh/VcmVyXiGYwkLyPdE= X-Received: by 2002:a2e:5301:0:b0:2cc:3d90:17b1 with SMTP id h1-20020a2e5301000000b002cc3d9017b1mr2241923ljb.49.1703085479387; Wed, 20 Dec 2023 07:17:59 -0800 (PST) MIME-Version: 1.0 References: <20231212130932.2467028-1-lichao@loongson.cn> <17A017C201FEB90D.32321@groups.io> <9014a7b3-095c-42b1-a9ef-5a388818385d@loongson.cn> In-Reply-To: From: "Ard Biesheuvel" Date: Wed, 20 Dec 2023 16:17:47 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH v4 19/37] UefiCpuPkg: Add MMIO method in CpuIo2Dxe To: "Ni, Ray" Cc: "devel@edk2.groups.io" , "lichao@loongson.cn" , "Kumar, Rahul R" , Gerd Hoffmann , Leif Lindholm , Ard Biesheuvel , Sami Mujawar Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,ardb@kernel.org List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: Content-Type: text/plain; charset="UTF-8" X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=u9lTKMXO; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io On Wed, 20 Dec 2023 at 13:28, Ni, Ray wrote: > > Thanks for pointing it out. > I found it in ACPI spec that tells how to use "Resource Type Specific Flags" to describe a MEM resource while maps to IO, > and an IO resource while maps to MEM. > > I assume that the IO port accesses are all from PCI device drivers. They are all from/to PCI endpoints, and typically by a dedicated driver. But there are other ways to access I/O ports as well: for instance, the 'mm' tool in the UEFI shell can be used to access port I/O directly, and this is implemented using the CpuIo2 protocol. CpuIo2 is used in most generic code that needs to perform port I/O afaict. > Then, we can change the PciHostBridgeLib lib interface to add a new field Io2Mmio aperture > to PCI_ROOT_BRIDGE indicating the mapping from IO to MMIO? > > If Io2Mmio aperture is valid, any IO access is translated by PciHostBridgeDxe driver to MMIO access. > The CPU is typically the agent that performs the access (disregarding peer-to-peer, which does not work at all with translation), so I'd say that the MMIO access performed by the CPU is translated to port I/O, not the other way around. Currently, PciHostBridgeDxe is generic code which performs all port I/O via CpuIo2, and I am not convinced this really needs to change. Note that this has been working on ARM for almost 10 years now. I used to travel to UEFI plugfests with a bag of PCIe plugin cards, including ones with serial ports that can only work if port I/O is implemented correctly. I am open to exploring different ways to solve this problem, but please be aware that in my opinion, this problem already has a working solution. > Such design has some limitations or opens: > 1. how to be backward compatible to existing x86 firmware. We'd still need an abstraction that performs port I/O, which would be implemented using io access instructions on x86. Basically, what CpuIo2 does today. > 2. Is the IO window the same as MMIO window? Can IO window and MMIO window use different strides? E.g.: IO[0-0x10] maps to MMIO[0x100 - 0x120]. That is an excellent question. I don't know the answer, but all implementations I have been involved in use a 1:1 stride between MMIO and port IO > 3. No multiple IO windows for each PciRootBridge > Support for port IO is not mandatory in PCIe, and very few endpoints actually require it (only legacy PCIe endpoints are permitted to rely on them iirc). Having a single port I/O resource window per host bridge does not seem like a big issue to me. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#112762): https://edk2.groups.io/g/devel/message/112762 Mute This Topic: https://groups.io/mt/103261693/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=-