From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4001:c06::241; helo=mail-io0-x241.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 9C4D822402E16 for ; Wed, 28 Feb 2018 08:40:12 -0800 (PST) Received: by mail-io0-x241.google.com with SMTP id b34so3897265ioj.6 for ; Wed, 28 Feb 2018 08:46:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=973DR3HrXrDjZgFoQeyPDVzsqA+6UEAtREj456QRe08=; b=C5Xdq/1b2xfi06VmWqubsfnB4hG8NJdbT4PEUgC0+mEQ5aut0l2fz4Xhr1R/mJLlk/ KKmMFMLSUvGK5bdzCJbUcD/OsQup+A76e2at7e98qtc016pgo9J5FrD8wKcb5OccHWgW 6mjNi/WYnnrfEr9MnUCScCxj/rVpAGsgCqLkA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=973DR3HrXrDjZgFoQeyPDVzsqA+6UEAtREj456QRe08=; b=WuskIFXJQQkNhSsBdWri3gYN+9NXhKtrjIkUPcFAaFdhFeZlFBs3ff1QUXA5ub/0sF DfftDbuByY9YYpUW+6OcTLPU7RSWkQ3qbI2NgWcv1NY0PKzchCdCj/c+WhuLM0rNQQDm ovaB+wVSapy8Hg4iLD21ldQzqU+AHXmE1Fo8XNO4dkAoBB1BAKEr0fCr1ZQ0PtWkhQKo EsHzNJzJcpYjOKLotbO6LUQkCnSKQNgsQkza4SYvhhTpY5QCWRyrhZapIepq9qZKpDN/ 8mt20llpcml4FJterJYvkOnqP3R6GfpVaKlhRtQAPY0tDI75LcPZ6DYqd1fUdcsh4FYb cIxw== X-Gm-Message-State: APf1xPCiSwusSWziUY2h6iwlWZhAt9fev6rvQcS5h7Dxmwj+BxnntZTJ SIv45uLl19EUHeBLSBXTUpXeRyxtOKnvjgq1Q7HY9Q== X-Google-Smtp-Source: AG47ELumrhrQRNZ8033Yhf9Ux0pPg/hY+ZqKqFylrPu2S42G1O5VWjUEYzVtSiTUfhftbe6sbTjlBKUOzpPBQ4giIE0= X-Received: by 10.107.56.69 with SMTP id f66mr20608092ioa.170.1519836379164; Wed, 28 Feb 2018 08:46:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.138.209 with HTTP; Wed, 28 Feb 2018 08:46:18 -0800 (PST) In-Reply-To: <20180228164334.df5tbd6v4lymfp6l@bivouac.eciton.net> References: <20180227092017.23617-1-ard.biesheuvel@linaro.org> <20180227092017.23617-3-ard.biesheuvel@linaro.org> <20180228162611.v6h4ll666u4gmf7e@bivouac.eciton.net> <20180228164334.df5tbd6v4lymfp6l@bivouac.eciton.net> From: Ard Biesheuvel Date: Wed, 28 Feb 2018 16:46:18 +0000 Message-ID: To: Leif Lindholm Cc: "edk2-devel@lists.01.org" , Graeme Gregory , Masahisa Kojima Subject: Re: [PATCH edk2-platforms 2/5] Silicon/SynQuacer: tweak PCI I/O windows for ACPI/Linux support X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 16:40:13 -0000 Content-Type: text/plain; charset="UTF-8" On 28 February 2018 at 16:43, Leif Lindholm wrote: > On Wed, Feb 28, 2018 at 04:30:50PM +0000, Ard Biesheuvel wrote: >> On 28 February 2018 at 16:26, Leif Lindholm wrote: >> > On Tue, Feb 27, 2018 at 09:20:14AM +0000, Ard Biesheuvel wrote: >> >> ACPI is not able to describe PCI resource windows that involve both type >> >> and address translation (i.e., for I/O windows on architectures that do >> >> not support port I/O natively), and so the ACPI/Linux code has a hard >> >> time performing the resource allocation in such cases. For instance, the >> >> secondary I/O window we implement on SynQuacer: >> >> >> >> I/O 0x10000 ... 0x1ffff -> 0x77f00000 >> >> >> >> is misinterpreted by Linux, and results in the MMIO range starting at >> >> 0x77f10000 to be mapped for I/O port access to this range. >> >> >> >> This can be mitigated by using the same PCI range for I/O port access >> >> on both RCs., i.e., 0x0 ... 0xffff. This configuration can be represented >> >> using both DT and ACPI, and will work as expected in Linux, since it only >> >> involves type translation and not address translation. >> >> >> >> However, there is a downside: EDK2 does not cope with I/O address >> >> translation in the generic PCI host bridge driver, and so it does >> >> not allow two regions 0x0 ... 0xffff to be configured. >> >> >> >> So in addition, let's reduce the windows declared to the UEFI PCI layer >> >> to 0x0 ... 0x7fff and 0x8000 ... 0xffff. >> > >> > ", able to cover windows witha single 64KB page."? >> >> ?? > > Or why was that size picked? > > Seems consistent with our "no conflicting mappings within a 64KB > region" rule. > Not really. I think 16 bits of I/O space is rather common, but we could also increase both I/O windows to 0x0 .. 0x1ffff, and split them into 0x0..0xffff and 0x10000..0x1ffff on the UEFI side. Also, they don't even have to be adjacent, as long as we use a 1:1 mapped slice for each. >> >> This leaves ample room for I/O >> >> BARs (which nobody uses anymore anyway), and allows UEFI and the OS to >> >> share the same static configuration of the PCIe BAR windows. >> >> >> >> Contributed-under: TianoCore Contribution Agreement 1.1 >> >> Signed-off-by: Ard Biesheuvel >> >> --- >> >> Heyi Gui is currently implementing support for address translation in >> >> the generic PCI host bridge driver, so hopefully, limiting the I/O >> >> ranges in UEFI is something we can revert shortly. >> >> >> >> Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi | 2 +- >> >> Silicon/Socionext/SynQuacer/Include/Platform/Pcie.h | 18 +++++++++++------- >> >> Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLibConstructor.c | 4 ++-- >> >> 3 files changed, 14 insertions(+), 10 deletions(-) >> >> >> >> diff --git a/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi b/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi >> >> index 05d1673a5c2b..6eb5fd9430cb 100644 >> >> --- a/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi >> >> +++ b/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi >> >> @@ -483,7 +483,7 @@ >> >> bus-range = <0x0 0x7e>; >> >> #address-cells = <3>; >> >> #size-cells = <2>; >> >> - ranges = <0x1000000 0x00 0x00010000 0x00 0x77f00000 0x0 0x00010000>, >> >> + ranges = <0x1000000 0x00 0x00000000 0x00 0x77f00000 0x0 0x00010000>, >> >> <0x2000000 0x00 0x78000000 0x00 0x78000000 0x0 0x08000000>, >> >> <0x3000000 0x3f 0x00000000 0x3f 0x00000000 0x1 0x00000000>; >> >> >> >> diff --git a/Silicon/Socionext/SynQuacer/Include/Platform/Pcie.h b/Silicon/Socionext/SynQuacer/Include/Platform/Pcie.h >> >> index 2d3d5cd91be0..ee57377ac3be 100644 >> >> --- a/Silicon/Socionext/SynQuacer/Include/Platform/Pcie.h >> >> +++ b/Silicon/Socionext/SynQuacer/Include/Platform/Pcie.h >> >> @@ -23,12 +23,12 @@ >> >> >> >> #define SYNQUACER_PCI_SEG0_BUSNUM_MIN 0x0 >> >> #define SYNQUACER_PCI_SEG0_BUSNUM_MAX 0x7e >> >> +#define SYNQUACER_PCI_SEG0_BUSNUM_RANGE 0x7f >> >> >> >> #define SYNQUACER_PCI_SEG0_PORTIO_MIN 0x0 >> >> -#define SYNQUACER_PCI_SEG0_PORTIO_MAX 0xffff >> >> -#define SYNQUACER_PCI_SEG0_PORTIO_SIZE 0x10000 >> >> +#define SYNQUACER_PCI_SEG0_PORTIO_MAX 0x7fff >> >> #define SYNQUACER_PCI_SEG0_PORTIO_MEMBASE 0x67f00000 >> >> -#define SYNQUACER_PCI_SEG0_PORTIO_MEMSIZE SYNQUACER_PCI_SEG0_PORTIO_SIZE >> >> +#define SYNQUACER_PCI_SEG0_PORTIO_MEMSIZE 0x10000 >> >> >> >> #define SYNQUACER_PCI_SEG0_MMIO32_MIN 0x68000000 >> >> #define SYNQUACER_PCI_SEG0_MMIO32_MAX 0x6fffffff >> >> @@ -45,12 +45,12 @@ >> >> >> >> #define SYNQUACER_PCI_SEG1_BUSNUM_MIN 0x0 >> >> #define SYNQUACER_PCI_SEG1_BUSNUM_MAX 0x7e >> >> +#define SYNQUACER_PCI_SEG1_BUSNUM_RANGE 0x7f >> >> >> >> -#define SYNQUACER_PCI_SEG1_PORTIO_MIN 0x10000 >> >> -#define SYNQUACER_PCI_SEG1_PORTIO_MAX 0x1ffff >> >> -#define SYNQUACER_PCI_SEG1_PORTIO_SIZE 0x10000 >> >> +#define SYNQUACER_PCI_SEG1_PORTIO_MIN 0x8000 >> >> +#define SYNQUACER_PCI_SEG1_PORTIO_MAX 0xffff >> >> #define SYNQUACER_PCI_SEG1_PORTIO_MEMBASE 0x77f00000 >> >> -#define SYNQUACER_PCI_SEG1_PORTIO_MEMSIZE SYNQUACER_PCI_SEG1_PORTIO_SIZE >> >> +#define SYNQUACER_PCI_SEG1_PORTIO_MEMSIZE 0x10000 >> >> >> >> #define SYNQUACER_PCI_SEG1_MMIO32_MIN 0x78000000 >> >> #define SYNQUACER_PCI_SEG1_MMIO32_MAX 0x7fffffff >> >> @@ -65,4 +65,8 @@ >> >> #define SYNQUACER_PCI_SLOT1_LOCATION SYNQUACER_PCI_LOCATION(0, 1, 3) >> >> #define SYNQUACER_PCI_SLOT2_LOCATION SYNQUACER_PCI_LOCATION(0, 1, 7) >> >> >> >> +#define SYNQUACER_PCI_OS_IO_BASE 0x0 >> >> +#define SYNQUACER_PCI_OS_IO_LIMIT 0xffff >> >> +#define SYNQUACER_PCI_OS_IO_RANGE 0x10000 >> > >> > Would you be greatly opposed to describing these as >> > >> > #define SYNQUACER_PCI_OS_IO_BASE SYNQUACER_PCI_SEG0_PORTIO_MIN >> > #define SYNQUACER_PCI_OS_IO_LIMIT SYNQUACER_PCI_SEG1_PORTIO_MAX >> > #define SYNQUACER_PCI_OS_IO_RANGE SYNQUACER_PCI_SEG1_PORTIO_MEMSIZE >> > or >> > #define SYNQUACER_PCI_OS_IO_RANGE SYNQUACER_PCI_SEG0_PORTIO_MEMSIZE >> > >> > which aren't conceptually the same, but explicitly describe the >> > desired configuration in this case? >> >> Sure. And as a bonus, these will still be correct after Heyi's >> PciHostbridgeDxe patches get merged and we can move to 0x0..0xffff for >> both regions. > > \o/ > > / > Leif