On 05/04/21 20:53, Brijesh Singh wrote:
>
> On 5/4/21 7:33 AM, Laszlo Ersek wrote:
>> On 04/30/21 13:51, Brijesh Singh wrote:
>>> +typedef PACKED struct {
>>> + UINT16 CurrentEntry;
>>> + UINT16 EndEntry;
>>> + UINT32 Rsvd;
>>> +} SNP_PAGE_STATE_HEADER;
>> (9) If my understanding of the spec is correct, "EndEntry" has
>> *inclusive* meaning. That's unusual. Any particular reason for not
>> making "EndEntry" exclusive (in the spec)?
>
> Sometimes guest may need to fill only few entries. The "EndEntry" will
> give hint to hypervisor that it should stop processing after it reached
> to the EndEntry.
I understood the purpose of EndEntry.
My question is why the entry identified by EndEntry *itself* needs to be
processed.
Put differently, I'm asking why your loop controlling expression is
Info->Header.CurrentEntry <= Info->Header.EndEntry [1]
and why not
Info->Header.CurrentEntry < Info->Header.EndEntry [2]
in patch #21 ("OvmfPkg/MemEncryptSevLib: Add support to validate system
RAM").
In case [1], EndEntry is an inclusive limit.
In case [2], EndEntry would be an exclusive limit.
My question is why the spec defines EndEntry with inclusive rather than
exclusive meaning.
Using inclusive low bounds with exclusive high bounds has mental advantages:
https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html
Is there a specific reason for which the spec chose the inclusive high
bound?
Thanks
Laszlo
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#74766): https://edk2.groups.io/g/devel/message/74766
Mute This Topic: https://groups.io/mt/82479051/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
