|
|
|
|
|
|
|
|
|
|
xen-devel
[Xen-devel] Re: [GIT PULL] xen /proc/mtrr implementation
To: |
Ingo Molnar <mingo@xxxxxxx> |
Subject: |
[Xen-devel] Re: [GIT PULL] xen /proc/mtrr implementation |
From: |
Chris Wright <chrisw@xxxxxxxxxxxx> |
Date: |
Mon, 18 May 2009 10:51:18 -0700 |
Cc: |
Jeremy Fitzhardinge <jeremy@xxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, the arch/x86 maintainers <x86@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx>, "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>, "H. Peter Anvin" <hpa@xxxxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx>, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> |
Delivery-date: |
Tue, 19 May 2009 14:27:28 -0700 |
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
In-reply-to: |
<20090518085902.GE10687@xxxxxxx> |
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
List-post: |
<mailto:xen-devel@lists.xensource.com> |
List-subscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
List-unsubscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
References: |
<20090513133021.GA7277@xxxxxxx> <4A0ADBA2.2020300@xxxxxxxx> <20090515182757.GA19256@xxxxxxx> <4A0DCC11.10307@xxxxxxxx> <m1my9ex818.fsf@xxxxxxxxxxxxxxxxx> <4A0DFF78.6000501@xxxxxxxx> <20090515202250.0f1218ef@jbarnes-g45> <m1iqk1k708.fsf@xxxxxxxxxxxxxxxxx> <4A10EAC4.9070701@xxxxxxxx> <20090518085902.GE10687@xxxxxxx> |
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
* Ingo Molnar (mingo@xxxxxxx) wrote:
> Here Xen invades an already fragile piece of upstream code
> (/proc/mtrr) that is obsolete and on the way out. If you want a
> solution you should add PAT support to Xen and you should use recent
> upstream kernels. Or you should emulate /proc/mtrr in _Xen the
> hypervisor_, if you really care that much - without increasing the
> amount of crap in Linux.
Could you be specific re: technical issues? I see in the general mtrr
impact has one oddity:
+int __init common_num_var_ranges
+static int __init xen_num_var_ranges(void);
+.num_var_ranges =
A bit unusual to have an __init function in an ops table. Albeit safe in
this case. Could slightly minimize impact by keeping setup_num_var_ranges
and have it do:
if (mtrr_if->num_var_ranges)
num_var_ranges = mtrr_if->num_var_ranges();
else
num_var_ranges = common_num_var_ranges;
Similarly, could do a simple inline stub to remove the extra ifdef.
+#ifdef CONFIG_XEN_DOM0
+ xen_init_mtrr();
+#endif
But those are pretty minor. I think the changes proposed are pretty
small and reasonable to make existing /proc/mtrr usable in Xen dom0
(different discussion of when to formally deprecate /proc/mtrr).
thanks,
-chris
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|