From nobody Sat May 11 02:41:19 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of seabios.org designates 78.46.105.101 as permitted sender) client-ip=78.46.105.101; envelope-from=seabios-bounces@seabios.org; helo=coreboot.org; Authentication-Results: mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of seabios.org designates 78.46.105.101 as permitted sender) smtp.mailfrom=seabios-bounces@seabios.org; dmarc=fail(p=none dis=none) header.from=redhat.com Return-Path: Received: from coreboot.org (coreboot.org [78.46.105.101]) by mx.zohomail.com with SMTPS id 16644457224741005.326292468583; Thu, 29 Sep 2022 03:02:02 -0700 (PDT) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by coreboot.org (Postfix) with ESMTPA id C0F1B2C7DA; Thu, 29 Sep 2022 10:01:57 +0000 (UTC) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by coreboot.org (Postfix) with ESMTP id A54BB22B80 for ; Thu, 29 Sep 2022 10:01:42 +0000 (UTC) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-642-SM5LVUK8OMyJ5A36HOX8lw-1; Thu, 29 Sep 2022 06:01:39 -0400 Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 76FE0185A7AE; Thu, 29 Sep 2022 10:01:35 +0000 (UTC) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3FC79492B04; Thu, 29 Sep 2022 10:01:35 +0000 (UTC) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) id C0613180062C; Thu, 29 Sep 2022 12:01:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1664445701; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=nBuUl8Wyn0T0qkupyKpkSXCp6N/2KgsouMzJklmgn4U=; b=NPHj2cWdpdf86LeQVj3t6+Zc7Jn/GbbM8/BeagLQ0lHVTZbavSDVuCatq5OJ3SFbinEB69 UVzr+cGq1vIjJXDD5LLCUs2JDkJjmPL5PTX1fQNrd0Vsc43Z2r1Y+g9IesJqFOaCcqVqMp pnnZnNC26n/e6CRbyflquS7aO4UTgkw= X-MC-Unique: SM5LVUK8OMyJ5A36HOX8lw-1 Date: Thu, 29 Sep 2022 12:01:33 +0200 From: Gerd Hoffmann To: Alex Olson Message-ID: <20220929100133.va3d62evfcxouf24@sirius.home.kraxel.org> References: <0528ef6c135807121198189fb5c1e067f4a9ee14.camel@gmail.com> MIME-Version: 1.0 In-Reply-To: <0528ef6c135807121198189fb5c1e067f4a9ee14.camel@gmail.com> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.10 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline Message-ID-Hash: SX633I6RGU47WM3D5QSLDUGFQPQBTCVL X-Message-ID-Hash: SX633I6RGU47WM3D5QSLDUGFQPQBTCVL X-MailFrom: kraxel@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-seabios.seabios.org-0; header-match-seabios.seabios.org-1; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: seabios@seabios.org X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [SeaBIOS] Re: [RFC] PCIe-related MTRR inconsistency on Q35 List-Id: SeaBIOS mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable Authentication-Results: coreboot.org; auth=pass smtp.auth=mailman@coreboot.org smtp.mailfrom=seabios-bounces@seabios.org X-Spamd-Bar: ---- X-ZohoMail-DKIM: fail (Header signature does not verify) X-ZM-MESSAGEID: 1664445724734100001 Content-Type: text/plain; charset="utf-8" On Wed, Sep 28, 2022 at 10:56:34AM -0500, Alex Olson wrote: > Under SeaBIOS, I'm noticing that not all of the PCIe-related area is mark= ed > uncachable in the MTRR settings, at least in the Q35 platform (QEMU). >=20 > I feel like this is a bug, but I'm not familar with the lore behind Q35 a= nd > MTRRs, feedback would be appreciated. >=20 > The MCFG table contains an entry starting at Q35_HOST_BRIDGE_PCIEXBAR_ADD= R =20 > (0xb0000000) corresponding to a 256MB area. Later, the mch_mem_addr_setu= p() > routine defines the PCIe window (pcimem_start) starting at 0xc0000000=20 > (Q35_HOST_BRIDGE_PCIEXBAR_ADDR + Q35_HOST_BRIDGE_PCIEXBAR_SIZE). >=20 > I see in mtrr_setup(), that only a single variable MTRR is configured bas= ed > solely on pcimem_start and extends to the end of the 4GB boundary. It lo= oks to > me that this is probably fine for 440fx, but seems insufficient for Q35. >=20 > Q35 - original SeaBIOS 1.15.0: > # cat /proc/mtrr=20 > reg00: base=3D0x0c0000000 ( 3072MB), size=3D 1024MB, count=3D1: uncachable >=20 >=20 > Q35 - original EFI (ovmf 2202.02) > # cat /proc/mtrr=20 > reg00: base=3D0x0c0000000 ( 3072MB), size=3D 1024MB, count=3D1: uncachable > reg01: base=3D0x0b0000000 ( 2816MB), size=3D 256MB, count=3D1: uncachable > reg02: base=3D0x800000000 (32768MB), size=3D32768MB, count=3D1: uncachable See also https://github.com/tianocore/edk2/commit/2a0bd3bffc80d1982cf85cdad066f79a2f= 60c769 > Thus, for Q35, there is no explict attempt to configure the > Q35_HOST_BRIDGE_PCIEXBAR_ADDR area nor any potential the >4GB area used f= or PCIe > I/O. The inherent size restrictions on MTRR mask definitions make a comp= letely > generic solution a bit tricky. =20 qemu using gigabyte pages these days should simplify things. If there is 2G (or less) of low memory mark 2G -> 4G uncachable. If there is 3G (or less) of low memory mark 3G -> 4G uncachable. Doable with a single mtrr register, should cover 99% of the use cases and is a improvement over the current situation. > I believe solves the issue, but I'm not sure how to test it with a > 64-bit PCIe window. Patch the code to force it. seabios places everything below 4G if it fits, for backward compatibility reasons. Could be we are booting a 32bit guest OS which might not be able to deal with PCI bars mapped above 4G ... Maybe it makes sense to relax that a bit. In case we find memory above 4G it should be safe to assume that PCI bars above 4G are fine too. take care, Gerd commit c7074250e6faaeffc5e8966a8a0ecdfe8a5c2af3 Author: Gerd Hoffmann Date: Fri Sep 9 10:17:15 2022 +0200 [testing] force 64bit pci window diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c index ad6def93633b..08339da2905c 100644 --- a/src/fw/pciinit.c +++ b/src/fw/pciinit.c @@ -1108,7 +1108,7 @@ static void pci_bios_map_devices(struct pci_bus *buss= es) panic("PCI: out of I/O address space\n"); =20 dprintf(1, "PCI: 32: %016llx - %016llx\n", pcimem_start, pcimem_end); - if (pci_bios_init_root_regions_mem(busses)) { + if (1 || pci_bios_init_root_regions_mem(busses)) { struct pci_region r64_mem, r64_pref; r64_mem.list.first =3D NULL; r64_pref.list.first =3D NULL; _______________________________________________ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-leave@seabios.org