Re: [Xen-devel] [PATCH 3/4] x86/pv: Drop {compat_, }create_bounce_frame() and use the C version instead

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 09.05.17 at 19:24, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 09/05/17 17:16, Jan Beulich wrote:
>>>>> On 08.05.17 at 17:48, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> @@ -181,8 +181,7 @@ ENTRY(compat_post_handle_exception)
>>>          testb $TBF_EXCEPTION,TRAPBOUNCE_flags(%rdx)
>>>          jz    compat_test_all_events
>>>  .Lcompat_bounce_exception:
>>> -        call  compat_create_bounce_frame
>>> -        movb  $0,TRAPBOUNCE_flags(%rdx)
>>> +        call  pv_create_exception_frame
>>>          jmp   compat_test_all_events
>> Considering this recurring pattern of call/jmp I wonder whether we
>> could reduce the branch tracking structure utilization in the CPU a
>> little by folding these paths.
> 
> I think we can lift all of this softirq/event/nmi/mce handling logic up
> into C, which will remove almost all of the guest-handling asm code in
> entry.S
> 
> However, it would still retain this "goto again" structure, and will
> eventually have to drop back into asm to actually return to the guest.
> 
> The problem (which I haven't got a good solution for yet) is that, if I
> make the C functions noreturn, I will need to duplicate them so they can
> jmp to the proper return point.  The alternative would be a moderately
> hard to predict conditional jump.

Quite likely it would be possible to avoid source level duplication,
having the compiler produce two (or more) variants distinguished
mainly by that final jump. Question is whether the extra cache
(and to a lesser degree TLB) pressure wouldn't be worse than a
frequently mis-predicted branch. Another option might be to use
an indirect branch instead, making sure this uses a register
operand, with the involved register loaded well ahead of its use.

Jan


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