[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2 1/2] x86emul: make _PRE_EFLAGS() tolerate first argument being 32-bit



>>> On 04.01.17 at 12:51, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 04/01/17 11:46, Andrew Cooper wrote:
>> On 04/01/17 11:42, Andrew Cooper wrote:
>>> On 04/01/17 11:38, Jan Beulich wrote:
>>>>>>> On 04.01.17 at 11:56, <andrew.cooper3@xxxxxxxxxx> wrote:
>>>>> On 04/01/17 10:22, Jan Beulich wrote:
>>>>>> As this adds an instruction, the question is whether it would be worth
>>>>>> forking _PRE_EFLAGS() into two flavors: One dealing with _sav in a
>>>>>> register (allowing several instructions to be dropped) and another
>>>>>> dealing with it being on the stack (in which case the logic needs to
>>>>>> remain as is, since between the first PUSH and the last POP we mustn't
>>>>>> access variables possibly living on the stack).
>>>>> Looking at the code, why does so much of this need to be written in
>>>>> ASM?  Most looks like it could be moved into C.
>>>>>
>>>>> All that is needed in ASM is something like:
>>>>>
>>>>> push %[flags_before]
>>>>> popf
>>>>> ... op ...
>>>>> pushf
>>>>> pop %[flags_after]
>>>>>
>>>>> And the actual masking calculations can be done in C.
>>>> I did think about this yesterday, but came to the conclusion that it
>>>> can't be easily converted. Yet now that I look at the sketched out
>>>> code above, I can't see why I came to that conclusion.
>> It is always possible that my 30s thinking about this is subtly wrong...
> 
> Or even, better yet with LAHF/SAHF which avoids all the stack
> operations.  (Needing alternatives to cover the slim case of running on
> the few 64bit processors without these instructions.)

No - that wouldn't cover EFLAGS.OF.

Jan


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.