From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754683AbZESM1o (ORCPT ); Tue, 19 May 2009 08:27:44 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752890AbZESM1i (ORCPT ); Tue, 19 May 2009 08:27:38 -0400 Received: from mx2.mail.elte.hu ([157.181.151.9]:34011 "EHLO mx2.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752879AbZESM1h (ORCPT ); Tue, 19 May 2009 08:27:37 -0400 Date: Tue, 19 May 2009 14:26:23 +0200 From: Ingo Molnar To: Gerd Hoffmann Cc: Jan Beulich , Jeremy Fitzhardinge , Xen-devel , the arch/x86 maintainers , Linux Kernel Mailing List , Jesse Barnes , "Eric W. Biederman" , "H. Peter Anvin" , Thomas Gleixner , Linus Torvalds Subject: Re: [Xen-devel] Re: [GIT PULL] xen /proc/mtrr implementation Message-ID: <20090519122623.GD14305@elte.hu> References: <4A0DFF78.6000501@goop.org> <20090515202250.0f1218ef@jbarnes-g45> <4A10EAC4.9070701@goop.org> <20090518085902.GE10687@elte.hu> <4A11A3F8.1010202@goop.org> <20090519095918.GA11790@elte.hu> <4A12A46A02000078000017E1@vpn.id2.novell.com> <20090519110837.GA10548@elte.hu> <4A12A05C.6050004@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A12A05C.6050004@redhat.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-ELTE-SpamScore: -1.5 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-1.5 required=5.9 tests=BAYES_00 autolearn=no SpamAssassin version=3.2.3 -1.5 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Gerd Hoffmann wrote: > On 05/19/09 13:08, Ingo Molnar wrote: >> Or, alternatively, the hypervisor can expose its own administrative >> interface to manage MTRRs. > > Guess what? Xen does exactly that. And the xen mtrr_ops > implementation uses that interface ... No, that is not an 'administrative interface' - that is a guest kernel level hack that complicates Linux, extends its effective ABI dependencies and which has to be maintained there from that point on. There's really just three proper technical solutions here: - either catch the lowlevel CPU hw ops (the MSR modifications, which isnt really all that different from the mtrr_ops approach so it shouldnt pose undue difficulties to the Xen hypervisor). That will be maximally transparent and compatible, with zero changes needed to the Linux kernel. - or introduce its own hypercall API based administration API, without bothering the guest kernel with crap. Trivially patch Xorg to make use of it and that's it. There is absolutely no reason to introduce some intermediate crap into Linux. Ingo From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Subject: Re: Re: [GIT PULL] xen /proc/mtrr implementation Date: Tue, 19 May 2009 14:26:23 +0200 Message-ID: <20090519122623.GD14305@elte.hu> References: <4A0DFF78.6000501@goop.org> <20090515202250.0f1218ef@jbarnes-g45> <4A10EAC4.9070701@goop.org> <20090518085902.GE10687@elte.hu> <4A11A3F8.1010202@goop.org> <20090519095918.GA11790@elte.hu> <4A12A46A02000078000017E1@vpn.id2.novell.com> <20090519110837.GA10548@elte.hu> <4A12A05C.6050004@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <4A12A05C.6050004@redhat.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Gerd Hoffmann Cc: Jeremy Fitzhardinge , Xen-devel , the arch/x86 maintainers , Linux Kernel Mailing List , Jesse Barnes , Jan Beulich , "H. Peter Anvin" , Thomas Gleixner , Linus Torvalds , "Eric W. Biederman" List-Id: xen-devel@lists.xenproject.org * Gerd Hoffmann wrote: > On 05/19/09 13:08, Ingo Molnar wrote: >> Or, alternatively, the hypervisor can expose its own administrative >> interface to manage MTRRs. > > Guess what? Xen does exactly that. And the xen mtrr_ops > implementation uses that interface ... No, that is not an 'administrative interface' - that is a guest kernel level hack that complicates Linux, extends its effective ABI dependencies and which has to be maintained there from that point on. There's really just three proper technical solutions here: - either catch the lowlevel CPU hw ops (the MSR modifications, which isnt really all that different from the mtrr_ops approach so it shouldnt pose undue difficulties to the Xen hypervisor). That will be maximally transparent and compatible, with zero changes needed to the Linux kernel. - or introduce its own hypercall API based administration API, without bothering the guest kernel with crap. Trivially patch Xorg to make use of it and that's it. There is absolutely no reason to introduce some intermediate crap into Linux. Ingo