Re: [Xen-devel] [PATCH] x86: compact supposedly unused entry point code

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 20/06/16 15:04, Jan Beulich wrote:
>>>> On 20.06.16 at 15:58, <andrew.cooper3@xxxxxxxxxx> wrote:
>> On 20/06/16 14:49, Jan Beulich wrote:
>>>>>> On 20.06.16 at 14:54, <andrew.cooper3@xxxxxxxxxx> wrote:
>>>> On 20/06/16 13:48, Jan Beulich wrote:
>>>>>>>> On 20.06.16 at 14:15, <andrew.cooper3@xxxxxxxxxx> wrote:
>>>>>> On 20/06/16 12:04, Jan Beulich wrote:
>>>>>>> No point in aligning entry points which aren't supposed to be used
>>>>>>> anyway.
>>>>>>>
>>>>>>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>>>>>> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>>>>> Thanks, but - any thoughts on this part:
>>>>>
>>>>> TBD: Might consider simply using "andq $-15,%rsp", delivering an
>>>>> uninitialized error code (which shouldn't matter).
>>>> I was still considering that part.
>>>>
>>>> These are entries we never expect to actually take.  At that point, the
>>>> small overhead of setting up the error code to 0 is probably better than
>>>> leaving it uninitialised.
>>> I understand - it's really a matter of balancing the overhead on
>>> these paths (which will never have an effect if these entries indeed
>>> are unused, and which is of no interest if they are used by due some
>>> other flaw) with the (likely negligible, but non-zero) overhead they
>>> introduce on _other_ paths (due to cache and TLB consumption). I.e.
>>> my goal was to make these unused entries as small as possible. And
>>>
>>>     andq    $-15,%rsp
>>>     movl    $vector,4(%rsp)
>>>
>>> (obviously we can't use movb here) is smaller than the current
>>>
>>>     testb   $8,%spl
>>>     jz      1f
>>>     pushq   $0
>>>     movb    $vector,4(%rsp)
>>>
>>> afaict.
>> All of them head to do_reserved_trap() and panic().
> Not sure I'm guessing right what you mean to say with that, so I
> can only reiterate that I don't care at all how long it takes for
> execution to get through this path. All I care about is that this
> code be as small as possible, to limit its impact on surrounding
> code. But for the few bytes to save here I guess there was
> already way to much talk.
>
>> An alternative would be to drop all this entry code, mark the vectors as
>> not present in the IDT, and handle #NP[IDT vector] with a slightly
>> different error message in do_trap().
> Would likely increase overall code size (i.e. the opposite of what
> I'd like to achieve here).

I find that hard to believe.

I have a number of other improvements pending in this area.  I will add
this to the list.

~Andrew

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