lkml.org 
[lkml]   [2009]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [GIT PULL] xen /proc/mtrr implementation
Ingo Molnar 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.
>

That's a gross mis-characterisation of what we're talking about here.

arch/x86 already defines an mtrr_ops, which defines how to manipulate
the MTRR registers. There are currently several implementations of that
interface. In Xen the MTRR registers belong to the hypervisor, but it
allows a privileged kernel to modify them via hypercalls. I simply
added a new, straightforward mtrr_ops implementation to do that. It
adds about 120 lines of new code, in a single mtrr/xen.c file.

That's it. I could add any number of bizarre convolutions to achieve
the same effect, but given that there's an existing interface that is
exactly designed for what we want to achieve, I have to admit it didn't
occur to me to do anything else.

MTRR may well be on its way out, and PAT is the proper way to achieve
the same effect from now on. But MTRR is still a widely used
kernel-internal API as well as usermode ABI, and it seems just
gratuitous to not support it when doing so is such a low-impact change.
And if/when it comes to be time to completely deprecate/remove mtrr
support, we can delete it along with everything else.

I'm honestly at a loss to explain the vehemence of your objection to
these changes given their nature.

We're also working on making PAT support work where possible. But that
doesn't mean we want to do without anything in the meantime.

But more generally, we need to work out how to move things forward.

That said, we can live without. If these MTRR patches are your biggest
concern, drop them, pull the rest so we can get them seen, tested, in
linux-next, etc, ready for the next merge window. You know, like you
said you wanted to do the last time you blocked the Xen patches.

I would prefer to move them through tip.git: I appreciate your
(constructive) comments and reviews, the testing infrastructure has
proved very valuable in the past, and they'll generally get wider
exposure than my pool of testers. And its just the right way to do it.

But if you're so concerned that they'll simply give Linus more
ammunition to beat you up with, to the extent that you're
second-guessing yourself, then I'm perfectly happy to submit them
myself. I don't think it would be an overall better outcome, but it
keeps the heat off you, and we'd be making some progress.

J


\
 
 \ /
  Last update: 2009-05-18 20:11    [W:0.114 / U:0.228 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site