From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH 1/4] x86: move syscall trampolines off the stack Date: Tue, 19 May 2015 10:24:36 +0100 Message-ID: <555B0154.8080008@citrix.com> References: <5559DAFF020000780007AFE2@mail.emea.novell.com> <5559FB2E020000780007B196@mail.emea.novell.com> <555A31FD.3030706@citrix.com> <555AF73F020000780007B6BC@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YudlS-0006mx-1v for xen-devel@lists.xenproject.org; Tue, 19 May 2015 09:24:42 +0000 In-Reply-To: <555AF73F020000780007B6BC@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel , Keir Fraser List-Id: xen-devel@lists.xenproject.org On 19/05/15 07:41, Jan Beulich wrote: >>>> On 18.05.15 at 20:39, wrote: >> On 18/05/15 13:46, 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. >>> >>> Signed-off-by: Jan Beulich >> Can you please include a description of how you intend the stubs to >> function, and how they are layed out? Parts of the code look like a >> single page per stub, while other bits look like several stubs per page. > I'm adding this to the already present description: > > 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. Thanks - this clarifies things a lot. > >> (Personally, I would split the stub allocation/mapping/freeing into a >> patch separately to moving the syscall trampolines, as each are >> moderately complicated changes.) > I'm afraid this wouldn't work: The freeing of the stub page depends > on finding the first byte of each stub area being other than 0xCC in > order for the page to not get freed. Yet only the setting up of the > syscall stubs guarantees this (and I'm not really looking forward to > add - however little - code to store a placeholder instead). Ah ok. ~Andrew