From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web11.18012.1684748360653468542 for ; Mon, 22 May 2023 02:39:20 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=brslYbNc; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1684748359; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7d9ucmRUnTOLUODWy6YpvGTRdGuKjSaWyhyM+zileoI=; b=brslYbNc+Q6jxZEUSMGLFytiuedoLztDPdnT8jAXkJK5MyRRAofVYN3Uwa+s4kTuzx607h fo8aef/zT0lH60d2ZHaCqcumTN0AK/8lBTV4S0n4quAbOvZ+Wv6Oq0Bk1ByGXo/LxvWru5 OsRi3RMQX5ycKsym1BLTjv2Sh+Vbs5s= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [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-614-dVE5QptzMYC5c11kq6TmdQ-1; Mon, 22 May 2023 05:39:17 -0400 X-MC-Unique: dVE5QptzMYC5c11kq6TmdQ-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 537708007D9; Mon, 22 May 2023 09:39:17 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.139]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 251287C2A; Mon, 22 May 2023 09:39:17 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id BA5C51800606; Mon, 22 May 2023 11:39:15 +0200 (CEST) Date: Mon, 22 May 2023 11:39:15 +0200 From: "Gerd Hoffmann" To: Pedro Falcato Cc: devel@edk2.groups.io, Jordan Justen , Oliver Steffen , Pawel Polawski , Ard Biesheuvel , Jiewen Yao Subject: Re: [edk2-devel] [PATCH 0/3] OvmfPkg: gigabyte page tweaks Message-ID: References: <20230517102449.1334621-1-kraxel@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.5 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit On Thu, May 18, 2023 at 12:16:21AM +0100, Pedro Falcato wrote: > On Wed, May 17, 2023 at 11:24 AM Gerd Hoffmann wrote: > The Intel SDM and AMD manuals both mention possible bad side effects > for having large pages (2MB/4MB/1GB) spanning multiple MTRRs. qemu takes care to use gigabyte-alignment for guest RAM for performance reasons. Unless you are explicitly creating something unusual the memory layout below 4G is 2G RAM + 2G MMIO (q35 machine type) or 3G RAM + 1G MMIO (pc machine type). edk2 creates mtrr uncachable entries for the mmio regions (both 32bit and 64bit window). On q35 it looks like this: reg00: base=0x080000000 ( 2048MB), size= 2048MB, count=1: uncachable reg01: base=0x7000000000 (458752MB), size=65536MB, count=1: uncachable Both are gigabyte-aligned and are a multiple of gigabytes in size, so you simply can't create gigabyte page table entries crossing mtrr entry borders. That's relatively recent change though, q35 used to be different, see commit e4b3fd905a17 ("OvmfPkg/PlatformInitLib: simplify mtrr setup") > While I don't expect my comment to be a blocker (particularly as other > OVMF platforms are already using them), I think it's probably a good > idea to let you know. Yes, thanks, sure good to know. But I don't expect that being a problem. take care, Gerd