Re: [Xen-devel] [PATCH for-4.7 v2 2/2] xen/x86: Introduce a new VMASSIST for architectural behaviour of iopl

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 07/04/2016 23:53, Jan Beulich wrote:
>>>> On 08.04.16 at 00:30, <andrew.cooper3@xxxxxxxxxx> wrote:
>> On 07/04/2016 22:55, Jan Beulich wrote:
>>>>>> On 07.04.16 at 23:39, <andrew.cooper3@xxxxxxxxxx> wrote:
>>>> @@ -1763,7 +1765,8 @@ static void load_segments(struct vcpu *n)
>>>>                  vcpu_info(n, evtchn_upcall_mask) = 1;
>>>>  
>>>>              regs->entry_vector |= TRAP_syscall;
>>>> -            regs->_eflags      &= 0xFFFCBEFFUL;
>>>> +            regs->_eflags      &= 
>>>> ~(X86_EFLAGS_AC|X86_EFLAGS_VM|X86_EFLAGS_RF|
>>>> +                                    
>>>> X86_EFLAGS_NT|X86_EFLAGS_IOPL|X86_EFLAGS_TF);
>>> Why AC, which didn't get cleared before? Did you just copy
>>> the 64-bit variant from below?
>> Yes,
>>
>>> Assuming so, with it removed Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
>> Why keep the disparity?
> Because there's no reason to clear AC for 32-bit guests.

Nor 64bit guests.  A 64bit PV kernel should be acutely aware it is
running in ring3, and suitably audit flags at each of its entry points,
as all entry points have to do.

But as with all these hidden gems in the PV ABI, that ship has long
since sailed.

I will return it to how it was, although keeping the named constants.

~Andrew

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