Re: [edk2-devel] [PATCH RFC v2 04/28] MdePkg: Define the Page State Change VMGEXIT structures

["Laszlo Ersek" <lersek@redhat.com>]

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