From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: citrix.com, ip: 216.71.155.175, mailfrom: anthony.perard@citrix.com) Received: from esa6.hc3370-68.iphmx.com (esa6.hc3370-68.iphmx.com [216.71.155.175]) by groups.io with SMTP; Thu, 08 Aug 2019 04:13:33 -0700 Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none; spf=None smtp.pra=anthony.perard@citrix.com; spf=Pass smtp.mailfrom=anthony.perard@citrix.com; spf=None smtp.helo=postmaster@mail.citrix.com Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender authenticity information available from domain of anthony.perard@citrix.com) identity=pra; client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com; envelope-from="anthony.perard@citrix.com"; x-sender="anthony.perard@citrix.com"; x-conformance=sidf_compatible Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of anthony.perard@citrix.com designates 162.221.158.21 as permitted sender) identity=mailfrom; client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com; envelope-from="anthony.perard@citrix.com"; x-sender="anthony.perard@citrix.com"; x-conformance=sidf_compatible; x-record-type="v=spf1"; x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83 ~all" Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender authenticity information available from domain of postmaster@mail.citrix.com) identity=helo; client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com; envelope-from="anthony.perard@citrix.com"; x-sender="postmaster@mail.citrix.com"; x-conformance=sidf_compatible IronPort-SDR: tDNMY0Y2rlfRYYjQxIXnbDDw2JLAkMdTB2NTVHJT8XRTMhHpNGlY91qwzx8kCpTj0R5FOHshHj zkJm8DhWCbjgXAXdn0Ov8fcHCqxJXS4r4PymiGxgL3ecXeGp2LzqSY98i37BPAQa85XvQSUUls HtPKunelrkaKWLa+kvvYmDkWRshw9ISY7xS0hPhP9VBaVUDQ/4uCOqlplGbP8Hm2nNVplqPZ8m Twi5oZ00O/WB4fenhPJM1kq+7SSNRPrAzve6O6ItMJ43SSeEImSM5sbefCAq7pIQCHXXQ5CpFo C9g= X-SBRS: 2.7 X-MesageID: 4184311 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.64,360,1559534400"; d="scan'208";a="4184311" Date: Thu, 8 Aug 2019 12:13:30 +0100 From: "Anthony PERARD" To: Roger Pau =?iso-8859-1?Q?Monn=E9?= CC: , Julien Grall , , Jordan Justen , Ard Biesheuvel , Laszlo Ersek , Andrew Cooper Subject: Re: [PATCH v4 23/35] OvmfPkg/XenPlatformPei: Rework memory detection Message-ID: <20190808111330.GT1242@perard.uk.xensource.com> References: <20190729153944.24239-1-anthony.perard@citrix.com> <20190729153944.24239-24-anthony.perard@citrix.com> <20190807152852.e47kogsxubbjkue5@Air-de-Roger> MIME-Version: 1.0 In-Reply-To: <20190807152852.e47kogsxubbjkue5@Air-de-Roger> User-Agent: Mutt/1.12.1 (2019-06-15) Return-Path: anthony.perard@citrix.com Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit On Wed, Aug 07, 2019 at 05:34:32PM +0200, Roger Pau Monné wrote: > On Mon, Jul 29, 2019 at 04:39:32PM +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 > > work without CMOS by reading the e820 table. > > > > Rework XenPublishRamRegions to also care for the reserved and ACPI > > entry in the e820 table. The region that was added by InitializeXen() > > isn't needed as that same entry is in the e820 table provided by > > hvmloader. > > > > MTRR settings aren't modified anymore, on HVM it's already done by > > hvmloader, on PVH it is supposed to have sane default. MTRR will need > > to be done properly but keeping what's already been done by programmes > ^ firmware I've used programmes instead of firmware because in case of PVH, OVMF is the first firmware to run, libxl (and what ever it called) is what causes an MTRR to be setup, no firmware are involved in that. > > + // > > + // Round up the start address, and round down the end address. > > + // > > + Base = ALIGN_VALUE (Entry->BaseAddr, (UINT64)EFI_PAGE_SIZE); > > + End = (Entry->BaseAddr + Entry->Length) & ~(UINT64)EFI_PAGE_MASK; > > + > > + switch (Entry->Type) { > > + case EfiAcpiAddressRangeMemory: > > + AddMemoryRangeHob (Base, End); > > + break; > > + case EfiAcpiAddressRangeACPI: > > + AddReservedMemoryRangeHob (Base, End, FALSE); > > + break; > > + case EfiAcpiAddressRangeReserved: > > + if (Base < LocalApic && LocalApic < End) { > > Don't you also need to check for equality? In case such region starts > at Base == LocalApic? > > I guess it doesn't matter that much since this is to workaround a > specific issue with hvmloader, but I would like to see this sorted out > in hvmloader so that there's no clash anymore. Indeed, it doesn't matter to much, so I've been lazy. But Laszlo have pointed that out as well, so there were going to be a patch to make the workaround better. But I feel like I'm going to need to repost the series, so I'm probably going to fix that as well. Thanks, -- Anthony PERARD