From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: lersek@redhat.com) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by groups.io with SMTP; Mon, 22 Jul 2019 12:45:56 -0700 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 36B5DC036744; Mon, 22 Jul 2019 19:45:56 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-23.ams2.redhat.com [10.36.117.23]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3E5775C220; Mon, 22 Jul 2019 19:45:53 +0000 (UTC) Subject: Re: [PATCH v3 24/35] OvmfPkg/XenPlatformPei: Rework memory detection To: Anthony PERARD , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Cc: devel@edk2.groups.io, xen-devel@lists.xenproject.org, Ard Biesheuvel , Jordan Justen , Julien Grall , Andrew Cooper References: <20190704144233.27968-1-anthony.perard@citrix.com> <20190704144233.27968-25-anthony.perard@citrix.com> <20190715141521.aqmpchgzyleoergc@MacBook-Air-de-Roger.local> <20190722145319.GG1208@perard.uk.xensource.com> From: "Laszlo Ersek" Message-ID: <8b9cb231-e9e5-8f92-f8d4-a6f05efaa888@redhat.com> Date: Mon, 22 Jul 2019 21:45:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20190722145319.GG1208@perard.uk.xensource.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Mon, 22 Jul 2019 19:45:56 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 07/22/19 16:53, Anthony PERARD wrote: > On Mon, Jul 15, 2019 at 04:15:21PM +0200, Roger Pau Monn=C3=A9 wrote: >> On Thu, Jul 04, 2019 at 03:42:22PM +0100, Anthony PERARD wrote: >>> When running as a Xen PVH guest, there is no CMOS to read the memory >>> size from. Rework GetSystemMemorySize(Below|Above)4gb() so they can >>> works without CMOS by reading the e820 table. >>> >>> Rework XenPublishRamRegions for PVH, handle the Reserve type and expl= ain >>> about the ACPI type. MTRR settings aren't modified anymore, on HVM, i= t's >>> already done by hvmloader, on PVH it is supposed to have sane default= . >>> >>> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3D1689 >>> Signed-off-by: Anthony PERARD >>> Acked-by: Laszlo Ersek >>> --- >>> >>> Notes: >>> Comment for Xen people: >>> About MTRR, should we redo the setting in OVMF? Even if in both c= ase of >>> PVH and HVM, something would have setup the default type to write= back >>> and handle a few other ranges like PCI hole, hvmloader for HVM or= and >>> libxc I think for PVH. >> >> That's a tricky question. Ideally we would like the firmware (OVMF) to >> take care of that, because it already has code to do so. Problem here >> is that PVH can also be booted without firmware, in which case it >> needs the hypervisor to have setup some sane initial MTRR state. >> >> The statement in the PVH document about initial MTRR state is vague >> enough that allows Xen to boot into the guest with a minimal MTRR >> state, that can for example not contain UC regions for the MMIO >> regions of passed through devices, hence I think OVMF should be in >> charge of creating a more complete MTRR state if possible. >> >> Is this something OVMF already has logic for? >=20 > Well, there are some logic but it's for QEMU (and uses an interface tha= t > isn't available when running on Xen, fwcfg). >=20 > The logic that was there for Xen HVM was very simple, a single set > cache-write-back for the RAM, that's why I remove it (and because I'm > not sure yet I figured out how to run the mtrr functions correctly in > OVMF). >=20 > I probably going to have to write a new logic which would rewrite the > MTRR from scratch instead of relying on the existing setup. MTRR setup is complex in OVMF, in comparison to firmware that runs on physical machines, because: - the physical RAM size can change from boot to boot, with almost total freedom, and that can incur some unexpected changes in the physical RAM map too (i.e. affect not just the end, but holes) - the number of variable MTRRs is severely limited and can't cover an arbitrary physical RAM map. And, some platform-independent modules in edk2 consume variable MTRRs too, via gDS->SetMemorySpaceAttributes(), so we have to be very conservative with even those variable MTRRs that exist= . Even on QEMU i440fx & pc, we've *just* made OVMF cope with an arbitrary guest RAM size (that is, beyond 128MB), and that logic relies on some open-coded board-specific knowledge about low (<4G) RAM size. So much so that, on i440fx, we place the 32-bit PCI IOMMU aperture based on what we can configure with a minimal amount of variable MTRRs, and not vice versa (i.e. we don't first set the 32-bit MMIO aperture and then attempt to mark it as uncached). Please see: https://bugzilla.tianocore.org/show_bug.cgi?id=3D1814 This is one of the nastiest parts of OVMF. (PlatformPei is, in general.) Thanks Laszlo