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: Fri, 22 May 2015 09:35:43 +0100 Message-ID: <555EEA5F.9090306@citrix.com> References: <555DCA7C020000780007CA7E@mail.emea.novell.com> <555DCC74020000780007CA9B@mail.emea.novell.com> <555DBCC1.5050002@citrix.com> <555DE21D020000780007CB8B@mail.emea.novell.com> <555F040E020000780007D185@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YviQf-00041Z-RN for xen-devel@lists.xenproject.org; Fri, 22 May 2015 08:35:41 +0000 In-Reply-To: <555F040E020000780007D185@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 22/05/2015 09:25, Jan Beulich wrote: >>>> On 21.05.15 at 13:48, 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. > Sadly this can't be a BUILD_BUG_ON(), as STUBS_PER_PAGE isn't a > compile time constant (due to the use of max()). I made it an > ASSERT() for the time being. In some copious free time, I shall see about borrowing some of the Linux constants infrastructure. We have quite a few examples of calculations which should be able to be evaluated by the compiler, but cant given our current setup. ~Andrew