* Ingo Molnar (mingo@elte.hu) wrote:
quoted text
> 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
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/