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:c0b::243; helo=mail-it0-x243.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it0-x243.google.com (mail-it0-x243.google.com [IPv6:2607:f8b0:4001:c0b::243]) (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 CDECE22402E0F for ; Wed, 28 Feb 2018 08:24:44 -0800 (PST) Received: by mail-it0-x243.google.com with SMTP id k79so4224344ita.2 for ; Wed, 28 Feb 2018 08:30:52 -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=CrCcyLcnnmW8usEo6y3ZP0YYxb1Oq0VNRKMfeEDODXg=; b=gLtkC6vWP9dBwwnhDCH+udQbvEGSdhndmTLIltMWLHHrC+yZHOym0ROyza6YGi6rEM mF6UyJjl5fX4kI0gRVHFyXeOZv7wuHkddI+Tcx8ahgSM5oXZdZenvzEGACeNpTTyCiGG FnDxIeMOGIG7XfRwV0v+RkV/lmdVecEyIeliU= 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=CrCcyLcnnmW8usEo6y3ZP0YYxb1Oq0VNRKMfeEDODXg=; b=PyI8dSm8bNvWHkkfSMBrQWfwUj3Deihyz76v16OK0cmMQF0u87clahWK3dwZP2PxyC TsGJN3KCykx3VbzMpE50lpLluD6tqA16IPAAP+KA9dfNCXVC8D7bUFtUufNoioRK+ONF N6EEI8ya7tAKvFJzKgjzQS92gBOoUrknxlKdHnjtGYczFl0aFLP1dTK1PXYYxvTUB6OP R/cu5XGqSwnBNelGJO/Dl5Ov6pfRK8fk9HGCgrMAu10l9FiyPSyTPUurXoLP2Ns5WRe9 0NShhQbzfMT8gdBF8QDoBmEz54FaeRp/SYQ/nbYRfnZWWL/yAmbjoFqnabkcRhuK/Jo2 lIlQ== X-Gm-Message-State: APf1xPDbrYVD0HqZsiV5Ur38KHh01i7NmN3aN1kxtk26PlFB2ZhKnyhN oYFOehij/IsoLLGHfSDsjjytiacHjYlR21a+3T2GXA== X-Google-Smtp-Source: AH8x227uwNAmv+agRrWPNWEe/rBssQ6mZTV+jyJdx67/6fI4soUmxUvqsKP8wMv6rNVysPKhJfYMyUX0hMUNL87Fq7c= X-Received: by 10.36.217.22 with SMTP id p22mr21532909itg.106.1519835451505; Wed, 28 Feb 2018 08:30:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.138.209 with HTTP; Wed, 28 Feb 2018 08:30:50 -0800 (PST) In-Reply-To: <20180228162611.v6h4ll666u4gmf7e@bivouac.eciton.net> References: <20180227092017.23617-1-ard.biesheuvel@linaro.org> <20180227092017.23617-3-ard.biesheuvel@linaro.org> <20180228162611.v6h4ll666u4gmf7e@bivouac.eciton.net> From: Ard Biesheuvel Date: Wed, 28 Feb 2018 16:30:50 +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:24:45 -0000 Content-Type: text/plain; charset="UTF-8" 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."? > ?? >> 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.