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

Re: [Xen-devel] [PATCH v2 1/4] x86: move syscall trampolines off the stack



On 21/05/15 12:48, Jan Beulich wrote:
>>>> On 21.05.15 at 13:08, <andrew.cooper3@xxxxxxxxxx> wrote:
>> On 21/05/15 11:15, Jan Beulich wrote:
>>> This is needed as stacks are going to become non-executable. Use
>>> separate stub pages (shared among suitable CPUs on the same node)
>>> instead.
>>>
>>> Stub areas (currently 128 bytes each) are being split into two parts -
>>> a fixed usage one (the syscall ones) and dynamically usable space,
>>> which will be used by subsequent changes to hold dynamically generated
>>> code during instruction eumlation.
>>>
>>> While sharing physical pages among certain CPUs on the same node, for
>>> now the virtual mappings get established in distinct pages for each
>>> CPU. This isn't a strict requirement, but simplifies VA space
>>> management for this initial implementation: Sharing VA space would
>>> require additional tracking of which areas are currently in use. If
>>> the VA and/or TLB overhead turned out to be a problem, such extra code
>>> could easily be added.
>>>
>>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>>
>> It might be wise to have a BUILD_BUG_ON() which confirms that
>> STUBS_PER_PAGE is a power of two, which is a requirement given the way
>> it is used.
> Good idea. Along with that one I'm also adding
>
>     BUILD_BUG_ON(STUB_BUF_SIZE / 2 < MAX_INST_LEN + 1);
>
> to patch 2 and
>
>     BUILD_BUG_ON(STUB_BUF_SIZE / 2 < 16);
>
> to patch 3, in the hope that this won't invalidate your R-b.

Both fine by me

~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®.