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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 31.01.17 at 11:39, <andrew.cooper3@xxxxxxxxxx> wrote:
> 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).

For this bit I understand the reasoning. I don't think the same applies
to bits 9..12 though.

>>> @@ -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?

Transparent unions are rather old a feature of gcc; I can't speak
of clang, though, but we certainly have uses of them already in
our tree.

Jan


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