From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.61])
 by mx.groups.io with SMTP id smtpd.web10.8569.1580393931716715202
 for <devel@edk2.groups.io>;
 Thu, 30 Jan 2020 06:18:51 -0800
Authentication-Results: mx.groups.io;
 dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Ta4hr3so;
 spf=pass (domain: redhat.com, ip: 205.139.110.61, mailfrom: lersek@redhat.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1580393930;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=snITmVpMu9/HR5733Jryc+uxAoipOxFNLTv8frDC3JA=;
	b=Ta4hr3soDSZJD0HEbpUSbjYFXHIgjA3ZRAaIdAaQcE5QKdAvdIpwxBi05pBxKe3L9Qcl3j
	sxND/NPxqkFl3RWCqHrV4cnJ4sww/yPg8eIJpbGv5FVk0d8aZpWNGFiT1ED5ZTTCc+YA35
	6xHQ9xfxlgFY8NiTwebG53fTl09idk4=
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-122-Ig4oCnFqPFiYxm4P_harpA-1; Thu, 30 Jan 2020 09:18:47 -0500
Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 00536800D48;
	Thu, 30 Jan 2020 14:18:46 +0000 (UTC)
Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-35.ams2.redhat.com [10.36.117.35])
	by smtp.corp.redhat.com (Postfix) with ESMTP id 32C2D60BE1;
	Thu, 30 Jan 2020 14:18:44 +0000 (UTC)
Subject: Re: [edk2-devel] Saving data structure at Pre EFI Initialization phase in memory to use it at DXE phase by some UEFI application?
To: sergestus@yandex.ru, devel@edk2.groups.io
References: <af1f1e7f-4088-d3b7-b6d3-b626c2e93602@redhat.com>
 <14732.1580389052139587541@groups.io>
From: "Laszlo Ersek" <lersek@redhat.com>
Message-ID: <55fabeb6-f7b6-0c65-2216-a212f6dc1171@redhat.com>
Date: Thu, 30 Jan 2020 15:18:44 +0100
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: <14732.1580389052139587541@groups.io>
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12
X-MC-Unique: Ig4oCnFqPFiYxm4P_harpA-1
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Language: en-US
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

On 01/30/20 13:57, sergestus@yandex.ru wrote:
> Thank you, may I just create a new GUID (sysHostGuid),

Right, just get your own GUID with "uuidgen".

> then call BuildGuidDataHob passing in it the sysHostGuid

Yes.

> and SYSHOST structure?

Well, not exactly. It depends.

If your SYSHOST structure is a few KB tops (up to 64-ish KB), then sure,
you can embed the SYSHOST structure right into the HOB.

Otherwise, you should
- make your PEI code dependent on gEfiPeiMemoryDiscoveredPpiGuid,
- call the AllocatePages() PEI service,
- populate the allocated area with the SYSHOST structure,
- take the 64-bit EFI_PHYSICAL_ADDRESS, output by AllocatePages(), as a
UINT64,
- call BuildGuidDataHob() on the *UINT64*. In other words, embed the
address of the structure, not the structure.

> Will I be able to find the structure in the DXE phase looking up by the sysHostGuid?

Yes, with GetFirstGuidHob().

If you embedded the structure in the HOB, then you can consume it right
from the HOB (at the address returned by GetFirstGuidHob()).

Otherwise, you should read the address (the UINT64 object) out of the
HOB. Then dereference it as a pointer, and that's where your struct will be.

The point is that memory allocated in the PEI phase with the
AllocatePages() PEI service, *after* permanent RAM has been installed
(i.e. after gEfiPeiMemoryDiscoveredPpiGuid is placed in the PPI
database), is stable. You can pass the address from PEI to DXE using a
GUID HOB.

Thanks
Laszlo