[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 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.

Jan


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