Re: [Xen-devel] [PATCH 1/2] x86/vmx: Introduce a bitfield structure for EPT_VIOLATION EXIT_QUALIFICATIONs

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 31/01/17 10:19, Jan Beulich wrote:
>>>> On 30.01.17 at 17:54, <andrew.cooper3@xxxxxxxxxx> wrote:
>> This results in rather more readable code.  No functional change.
>>
>> All fields currently specified are included, but commented out as no support
>> for their use is present.
> I'd rather not see them be commented out: Why should the first user
> of them have to touch the structure declaration another time?

I purposefully don't want someone to think they can use .eff_user_exec
before doing the work to enable the feature (which amongst other things
will involve shuffling the position of bits in an ept_entry_t as the
hardware user exec bit is currently where Xen's .recalc bit currently
lives).

>
>> @@ -3792,11 +3789,11 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>>  
>>      case EXIT_REASON_EPT_VIOLATION:
>>      {
>> -        paddr_t gpa;
>> +        paddr_t gpa; ept_qual_t q;
>>  
>>          __vmread(GUEST_PHYSICAL_ADDRESS, &gpa);
>> -        __vmread(EXIT_QUALIFICATION, &exit_qualification);
>> -        ept_handle_violation(exit_qualification, gpa);
>> +        __vmread(EXIT_QUALIFICATION, &q.raw);
>> +        ept_handle_violation(q, gpa);
>>          break;
>>      }
> If you made the union a transparent one, I think you wouldn't have
> to touch this code at all.

Is that liable to work on all supported compilers?

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel