From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH v2 1/4] x86: move syscall trampolines off the stack Date: Thu, 21 May 2015 12:50:13 +0100 Message-ID: <555DC675.2080708@citrix.com> References: <555DCA7C020000780007CA7E@mail.emea.novell.com> <555DCC74020000780007CA9B@mail.emea.novell.com> <555DBCC1.5050002@citrix.com> <555DE21D020000780007CB8B@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YvP5n-0005J0-Aq for xen-devel@lists.xenproject.org; Thu, 21 May 2015 11:56:51 +0000 In-Reply-To: <555DE21D020000780007CB8B@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 21/05/15 12:48, Jan Beulich wrote: >>>> On 21.05.15 at 13:08, 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 >> Reviewed-by: Andrew Cooper >> >> 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