From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936701Ab3DJBFT (ORCPT ); Tue, 9 Apr 2013 21:05:19 -0400 Received: from terminus.zytor.com ([198.137.202.10]:53928 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934865Ab3DJBFR (ORCPT ); Tue, 9 Apr 2013 21:05:17 -0400 Message-ID: <5164B93A.1050706@zytor.com> Date: Tue, 09 Apr 2013 17:58:34 -0700 From: "H. Peter Anvin" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: Steven Rostedt CC: Eric Northup , Kees Cook , "kernel-hardening@lists.openwall.com" , Ingo Molnar , LKML , "x86@kernel.org" , Konrad Rzeszutek Wilk , Jeremy Fitzhardinge , Marcelo Tosatti , Alex Shi , Borislav Petkov , Alexander Duyck , Frederic Weisbecker , "Paul E. McKenney" , "xen-devel@lists.xensource.com" , "virtualization@lists.linux-foundation.org" , Dan Rosenberg , Julien Tinnes , Will Drewry Subject: Re: Readonly GDT References: <20130408224328.GA17641@www.outflux.net> <51634935.9010905@zytor.com> <51645D6F.7070705@zytor.com> <51646054.3090509@zytor.com> <5164B5BD.5050702@zytor.com> <1365555234.25498.91.camel@gandalf.local.home> In-Reply-To: <1365555234.25498.91.camel@gandalf.local.home> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/09/2013 05:53 PM, Steven Rostedt wrote: > On Tue, 2013-04-09 at 17:43 -0700, H. Peter Anvin wrote: >> OK, thinking about the GDT here. >> >> The GDT is quite small -- 256 bytes on i386, 128 bytes on x86-64. As >> such, we probably don't want to allocate a full page to it for only >> that. This means that in order to create a readonly mapping we have to >> pack GDTs from different CPUs together in the same pages, *or* we >> tolerate that other things on the same page gets reflected in the same >> mapping. > > What about grouping via nodes? > Would be nicer for locality, although probably adds [even] more complexity. We don't really care about 32-bit NUMA anymore -- it keeps getting suggested for deletion, even. For 64-bit it might make sense to just reflect out of the percpu area even though it munches address space. >> >> However, the packing solution has the advantage of reducing address >> space consumption which matters on 32 bits: even on i386 we can easily >> burn a megabyte of address space for 4096 processors, but burning 16 >> megabytes starts to hurt. > > Having 4096 32 bit processors, you deserve what you get. ;-) > Well, the main problem is that it might get difficult to make this a runtime thing; it more likely ends up being a compile-time bit. -hpa