Re: [RFC v2-fix-v2 1/1] x86/traps: Add #VE support for TDX guest

[Dave Hansen]

On 5/27/21 9:24 AM, Sean Christopherson wrote:
> On Thu, May 27, 2021, Luck, Tony wrote:
>> +struct ve_info {
>> +	u64 exit_reason;
>> +	u64 exit_qual;
>> +	u64 gla;
>> +	u64 gpa;
>> +	u32 instr_len;
>> +	u32 instr_info;
>> +};
>>
>> I guess that "gla" = Guest Linear Address ... which is a very "Intel" way of
>> describing what everyone else would call a Guest Virtual Address.
>>
>> I don't feel strongly about this though. If this has already been hashed
>> out already then stick with this name.
> The "real" #VE information area that TDX is usurping is an architectural struct
> that defines exit_reason, exit_qual, gla, and gpa, and those fields in turn come
> directly from their corresponding VMCS fields with longer versions of the same
> names, e.g. ve_info->gla is a reflection of vmcs.GUEST_LINEAR_ADDRESS.
> 
> So normally I would agree that the "linear" terminology is obnoxious, but in
> this specific case I think it's warranted.

The architectural name needs to be *somewhere*.  But, we do diverge from
the naming in plenty of places.  The architectural name "XSTATE_BV" is
called xstate.xfeatures in the FPU code, for instance.

In this case, the _least_ we can do is:

	u64 gla; /* Guest Linear (virtual) Address */

although I also wouldn't mind if we did something like:

	u64 guest_vaddr; /* Guest Linear Address (gla) in the spec */

either.