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

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



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().

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().

~Andrew

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

 


Rackspace

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