public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "sunceping" <cepingx.sun@intel.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: "devel@edk2.groups.io" <devel@edk2.groups.io>,
	"Aktas, Erdem" <erdemaktas@google.com>,
	"Yao, Jiewen" <jiewen.yao@intel.com>,
	"Xu, Min M" <min.m.xu@intel.com>,
	"Reshetova, Elena" <elena.reshetova@intel.com>,
	"Sun, CepingX" <cepingx.sun@intel.com>
Subject: Re: [edk2-devel] [PATCH V1 1/1] OvmfPkg/QemuBootOrderLib: Measure the etc/boot-menu-wait
Date: Wed, 20 Mar 2024 08:41:41 +0000	[thread overview]
Message-ID: <IA0PR11MB83551B67288FC77FC5D05710E7332@IA0PR11MB8355.namprd11.prod.outlook.com> (raw)
In-Reply-To: <pcavopv4ypqzu2fzvo36zqghty7jp7wyerclvdi24c7ayl3yzk@t4dfgrbskv3i>


On Thursday, March 14, 2024 5:31 PM Gerd Hoffmann wrote:
> Load, measure and cache all fw_cfg entries we care about early in the PEI phase
> (or SEC phase for pei-less builds), so we can
>  (a) easily have a fixed order, and
>  (b) store them all in HOBs?
> 
> Which implies SEC/PEI must read all relevant fw_cfg entries, even in case they
> are used only later in the DXE phase.
> 
> Advantage is we have a single cache which can be used in all firmware phases.
> When using global variables in DXE we still can end up reading entries multiple
> times, either because entries are needed by both PEI and DXE, or because
> multiple DXE modules need them (global variables are per module).
> 
We have some concerns that in above solution the size of a single cache is large
( because all fw_cfg data need to be read from qemu). 
Further more this is not a lazy mode which means some fw_cfg data 
may be read but it is not to be consumed later. 

We propose below solution :

Add a new API in QemuFwCfgLib,
RETURN_STATUS QemuFwCfgGetData(fw_cfg_name, *size, *value, FW_CFG_GET_DATA_FLAG flag).	

Input:
@fw_cfg_name: The fw_cfg file name .
@size: Number of bytes in the file.
@value: Value of fw_cfg item read. 
@flag: Bitmap providing additional information(cache?  measurement ?)
             #define  FW_CFG_GET_DATA_CACHE 0x00000001
             #define  FW_CFG_GET_DATA_MEASUREMENT 0x00000002

Output:
@return: RETURN_NOT_FOUND: The fw_cfg file is not found
	   RETURN_UNSUPPORTED: The fw_cfg is unavailable.
                 RETURN_BUFFER_TOO_SMALL: The required buffer size is in @size.
                 RETURN_SUCCESS:  The fw_cfg file is found and load the data successfully.

Description:
 This function finds fw_cfg item and reads its data into value.  And it also provides callers with
 options to cache and/or measurement. 

Pros:
Caller can decide how to get the fw_cfg data from QEMU (cache? Measurement?)
 And it can reduce the code complexity because it pack 3 fw_cfg call 
(QemuFwCfgFindFile/QemuFwCfgSelectItem/QemuFwCfgReadBytes) into one call. 

What's your thought?


Thanks
Ceping


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116915): https://edk2.groups.io/g/devel/message/116915
Mute This Topic: https://groups.io/mt/104880546/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



  reply	other threads:[~2024-03-20  8:41 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-12 23:51 [edk2-devel] [PATCH V1 1/1] OvmfPkg/QemuBootOrderLib: Measure the etc/boot-menu-wait sunceping
2024-03-12  7:57 ` Yao, Jiewen
2024-03-13  8:39   ` sunceping
2024-03-12 11:04 ` Gerd Hoffmann
2024-03-13  8:50   ` sunceping
2024-03-14  9:30     ` Gerd Hoffmann
2024-03-20  8:41       ` sunceping [this message]
2024-03-20 10:04         ` Gerd Hoffmann
2024-03-21  8:39           ` sunceping
2024-03-21 12:25             ` Gerd Hoffmann
2024-03-22  8:29               ` sunceping
2024-03-22  9:05                 ` Gerd Hoffmann
2024-03-26  9:08                   ` sunceping
2024-03-26 15:44                     ` Gerd Hoffmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=IA0PR11MB83551B67288FC77FC5D05710E7332@IA0PR11MB8355.namprd11.prod.outlook.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox