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.129.124])
 by mx.groups.io with SMTP id smtpd.web10.32365.1634536874770849301
 for <devel@edk2.groups.io>;
 Sun, 17 Oct 2021 23:01:15 -0700
Authentication-Results: mx.groups.io;
 dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=irYogNVE;
 spf=pass (domain: redhat.com, ip: 170.10.129.124, mailfrom: kraxel@redhat.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1634536873;
	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=clWBR1lLYKPaiWIKH97OwK75ubpMlwS5dtMWb0xwRlE=;
	b=irYogNVEBic9+7eFWicssWlPyDlW9juZ0IYZdQPRO4CyK2Y5IGw/JKnsDzqKwqI+c97vkN
	fUIorflLFmd3oduWsbD+egQG1sbHKSAs6lBps8kCD5j4OXVBw5AmMDa+d4eCGdVEK08neg
	jzxqyB+j2fxQZP3Ry+k9e/hnyUqzFtk=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com
 [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-55-gZ9qC0cwOtCYqr7vOHk1Dw-1; Mon, 18 Oct 2021 02:01:09 -0400
X-MC-Unique: gZ9qC0cwOtCYqr7vOHk1Dw-1
Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14])
	(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B67CF1006AA3;
	Mon, 18 Oct 2021 06:01:07 +0000 (UTC)
Received: from sirius.home.kraxel.org (unknown [10.39.192.23])
	by smtp.corp.redhat.com (Postfix) with ESMTPS id 5914E5DA60;
	Mon, 18 Oct 2021 06:01:07 +0000 (UTC)
Received: by sirius.home.kraxel.org (Postfix, from userid 1000)
	id 7B906180063D; Mon, 18 Oct 2021 08:01:05 +0200 (CEST)
Date: Mon, 18 Oct 2021 08:01:05 +0200
From: "Gerd Hoffmann" <kraxel@redhat.com>
To: Brijesh Singh <brijesh.singh@amd.com>
Cc: devel@edk2.groups.io, James Bottomley <jejb@linux.ibm.com>,
	Min Xu <min.m.xu@intel.com>, Jiewen Yao <jiewen.yao@intel.com>,
	Tom Lendacky <thomas.lendacky@amd.com>,
	Jordan Justen <jordan.l.justen@intel.com>,
	Ard Biesheuvel <ardb+tianocore@kernel.org>,
	Erdem Aktas <erdemaktas@google.com>,
	Michael Roth <Michael.Roth@amd.com>
Subject: Re: [PATCH v9 30/32] OvmfPkg/PlatformPei: mark cpuid and secrets memory reserved in EFI map
Message-ID: <20211018060105.dbmomij5xcft6jpn@sirius.home.kraxel.org>
References: <20211013165713.727815-1-brijesh.singh@amd.com>
 <20211013165713.727815-31-brijesh.singh@amd.com>
 <20211014085851.e5xtspfcyz75lgog@sirius.home.kraxel.org>
 <6bb1abde-3795-1917-92b1-6659ac98846d@amd.com>
 <20211015052648.rcr55juuhoit4efh@sirius.home.kraxel.org>
 <8689d369-b5a3-07ee-5df5-981637224fcd@amd.com>
MIME-Version: 1.0
In-Reply-To: <8689d369-b5a3-07ee-5df5-981637224fcd@amd.com>
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14
Authentication-Results: relay.mimecast.com;
	auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=kraxel@redhat.com
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

  Hi,

> The MEMFD range is outside of the firmware image map,  MEMFD begins with
> 0x800000 [1] and in my boots I don't see it reserved in e820.

Ah, ok.

> Here is the snippet.
> 
> [ ... ]
> [    0.000000] BIOS-e820: [mem 0x0000000000800000-0x0000000000807fff] ACPI NVS
> [    0.000000] BIOS-e820: [mem 0x0000000000808000-0x000000000080afff] usable
> [    0.000000] BIOS-e820: [mem 0x000000000080b000-0x000000000080bfff] ACPI NVS
> [    0.000000] BIOS-e820: [mem 0x000000000080c000-0x000000000080ffff] usable
> [    0.000000] BIOS-e820: [mem 0x0000000000810000-0x00000000008fffff] ACPI NVS
> [ ... ]

Hmm.  Confused.  memfd size is 0xD00000, so should the block from 800000
to 8cffff be reserved?  Why does it end at 8fffff instead?

The first hole is this:

    0x008000|0x001000
    gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbPageTableBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbPageTableSize
    0x009000|0x002000
    gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbSize

The second hole is this (git master) ...

    0x00C000|0x001000
    gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBackupBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBackupSize

And IIRC the cpuid + secrets pages are added there.

So, yes, they must be reserved indeed.  What about the other pages?
Shouldn't they be reserved too?  Or will they not be used any more
at runtime?

thanks,
  Gerd