On Tuesday, October 31, 2023 8:45 AM, Erdem Aktas wrote:

> On Sun, Oct 29, 2023 at 11:42 PM Sun, CepingX <cepingx.sun@intel.com>

> wrote:

> >

> > On Saturday, October 28, 2023 12:45 AM, Erdem Aktas wrote:

> > This should be the [PATCH V1 2/2] I assume?

> > Yes, the name is same with [PATCH v1 0/2] , may be confusion, I would

> update in next version to avoid the same title name.

> >

> >

> > On Thu, Oct 26, 2023 at 5:58 PM sunceping <cepingx.sun@intel.com> wrote:

> >  [Sources]

> >    VirtualMemory.h

> >    MemoryEncryption.c

> > +  X64/TdVmCallMapGPA.nasm

> > I do not think we need another TdVmCallMapGPA definition, do we?

> > Currently,  the TdVmCall always clears the R11 if the return code is not

> successful,  which means we need to change TdVmCall if we don't add

> TdVmCallMapGPA.

> > Refer the GHCI Spec , if the returns code is not successful, the R11

> > value is not valid for the sub-functions except MapGPA,  which means

> TdVmCall should clear the value on unsuccessful returns and only save the

> value if MapGPA returns unsuccessfully.  If an update is required, the logic in

> TdVmCall could be complex.

>

> It seems like TdVmCallMapGPA function is actually duplicating most of the

> code that the TdVmCall function is already doing.

> According to the spec, R11 has meaningful data when mapgpa has RETRY,

> GPA_IN_USE or ALIGN_ERROR.

> I do not think the TdVmCall change logic would be complex (or not more

> than what TdVmCallMapGPA is already doing).

> I would like to see what others are saying on this.

>

Yes, we can wait for other's comments.  @Gerd Hoffmann ,  Could you help add a comment?

 

> > -  TdStatus = TdVmCall (TDVMCALL_MAPGPA, PhysicalAddress, Length, 0,

> > 0, NULL);

> > +  while (RetryCount < MAX_RETRIES_PER_PAGE) {

> > +    TdStatus = TdVmCallMapGPA (PhysicalAddress, Length,

> > + &MapGpaRetryaddr);

> > Why not this?

> >  TdStatus = TdVmCall (TDVMCALL_MAPGPA, PhysicalAddress, Length, 0, 0,

> > &MapGpaRetryaddr); The TdVmCall always clears the R11 value when

> unsuccessful returns as above comments, therefor add the

> TdVmCallMapGPA to handle it.

> right, the tdvmcall does not handle the R11 correctly for mapGPA. I think it

> should be an easy fix in that function instead of creating a whole copy of that

> function.

> Is there a reason why we think it is complicated?

 

If an update is required,  the TdVmCall has to add a flag or value to indicate the

 MapGPA and always compares the return code before clearing. This indicates

that additional code must be developed specifically to handle the results and solely

 for MapGPA at this time,  it would make the code seems complex and not easy extend

 in the future.

Based on the above considerations, we extract the code for MapGPA as an individual function,

 that' s easy to understand and extend for other results in the future.

 

Thanks

Ceping