All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dov Murik <dovmurik@linux.ibm.com>
To: "Tom Lendacky" <thomas.lendacky@amd.com>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>,
	qemu-devel@nongnu.org
Cc: Eduardo Habkost <ehabkost@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	James Bottomley <jejb@linux.ibm.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	Dov Murik <dovmurik@linux.ibm.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH] hw/i386/pc: Document pc_system_ovmf_table_find
Date: Tue, 29 Jun 2021 10:29:32 +0300	[thread overview]
Message-ID: <3f573ada-9244-9df0-c342-23dab3ba9396@linux.ibm.com> (raw)
In-Reply-To: <fd154b04-847a-efbd-7ae6-abc54630ac8f@linux.ibm.com>



On 29/06/2021 8:56, Dov Murik wrote:
> 
> 
> On 29/06/2021 1:03, Tom Lendacky wrote:
>> On 6/22/21 7:58 AM, Dov Murik wrote:
>>> +cc: Tom Lendacky
>>>
>>> On 22/06/2021 15:47, Philippe Mathieu-Daudé wrote:
>>>> On 6/22/21 2:44 PM, Dov Murik wrote:
>>>>> Suggested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>>>>> Signed-off-by: Dov Murik <dovmurik@linux.ibm.com>
>>>>> ---
>>>>>  hw/i386/pc_sysfw.c | 14 ++++++++++++++
>>>>>  1 file changed, 14 insertions(+)
>>>>>
>>>>> diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c
>>>>> index 6ce37a2b05..e8d20cb83f 100644
>>>>> --- a/hw/i386/pc_sysfw.c
>>>>> +++ b/hw/i386/pc_sysfw.c
>>>>> @@ -176,6 +176,20 @@ static void pc_system_parse_ovmf_flash(uint8_t *flash_ptr, size_t flash_size)
>>>>>      ovmf_table += tot_len;
>>>>>  }
>>>>>  
>>>>> +/**
>>>>> + * pc_system_ovmf_table_find - Find the data associated with an entry in OVMF's
>>>>> + * reset vector GUIDed table.
>>>>> + *
>>>>> + * @entry: GUID string of the entry to lookup
>>>>> + * @data: Filled with a pointer to the entry's value (if not NULL)
>>>>> + * @data_len: Filled with the length of the entry's value (if not NULL). Pass
>>>>> + *            NULL here if the length of data is known.
>>>>> + *
>>>>> + * Note that this function must be called after the OVMF table was found and
>>>>> + * copied by pc_system_parse_ovmf_flash().
>>>>
>>>> What about replacing this comment by:
>>>>
>>>>   assert(ovmf_table && ovmf_table_len);
>>>>
>>>
>>> I think this will break things: in target/i386/sev.c we have SEV-ES code
>>> that calls pc_system_ovmf_table_find() and can deal with the case when
>>> there's no OVMF table.  An assert will break it.
>>
>> Right, what would be best is to differentiate between an OVMF table that
>> isn't present in the flash vs the fact that pc_system_parse_ovmf_flash()
>> wasn't called, asserting only on the latter.
>>
> 
> [+cc James who wrote this code]
> 
> 
> Thanks Tom; I agree.  To achieve that, we need one of these:
> 
> (a) add a 'static bool ovmf_table_parsed' which will be set to true at
> the beginning of pc_system_parse_ovmf_flash(). Then, at the beginning of
> pc_system_ovmf_table_find add: assert(ovmf_table_parsed).
> 
> (b) (ab)use our existing ovmf_table_len static variable: initialize it
> to -1 (meaning that we haven't parsed the OVMF flash yet). When looking
> for the table set it to 0 (meaning that OVMF table doesn't exist or is
> invalid). When a proper table is found and copied to ovmf_table, then
> set it to the real length (>= 0).

typo: That should be    (> 0).


> At the beginning of
> pc_system_ovmf_table_find add: assert(ovmf_table_len != -1). (this -1
> can be #define OVMF_FLASH_NOT_PARSED -1).
> 
> 
> Phil, Tom, James: which do you prefer? other options? Rust enum? ;-)
> 
> 
> Thanks,
> Dov
> 
> 
>> Thanks,
>> Tom
>>
>>>
>>>
>>>> Otherwise,
>>>>
>>>> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>>>>
>>>
>>> Thanks!
>>>
>>> -Dov
>>>
>>>
>>>
>>>> Thanks!
>>>>
>>>>> + *
>>>>> + * Return: true if the entry was found in the OVMF table; false otherwise.
>>>>> + */
>>>>>  bool pc_system_ovmf_table_find(const char *entry, uint8_t **data,
>>>>>                                 int *data_len)
>>>>>  {
>>>>>
>>>>


      parent reply	other threads:[~2021-06-29  7:31 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-22 12:44 [PATCH] hw/i386/pc: Document pc_system_ovmf_table_find Dov Murik
2021-06-22 12:47 ` Philippe Mathieu-Daudé
2021-06-22 12:58   ` Dov Murik
2021-06-28 22:03     ` Tom Lendacky
2021-06-29  5:56       ` Dov Murik
2021-06-29  7:11         ` Philippe Mathieu-Daudé
2021-06-29 13:28           ` Tom Lendacky
2021-06-29  7:29         ` Dov Murik [this message]

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-all 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=3f573ada-9244-9df0-c342-23dab3ba9396@linux.ibm.com \
    --to=dovmurik@linux.ibm.com \
    --cc=ehabkost@redhat.com \
    --cc=jejb@linux.ibm.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=philmd@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=thomas.lendacky@amd.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.