From: Ingo Molnar <mingo@elte.hu>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
Jesse Barnes <jbarnes@virtuousgeek.org>,
the arch/x86 maintainers <x86@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Xen-devel <xen-devel@lists.xensource.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [GIT PULL] xen /proc/mtrr implementation
Date: Mon, 18 May 2009 10:59:02 +0200 [thread overview]
Message-ID: <20090518085902.GE10687@elte.hu> (raw)
In-Reply-To: <4A10EAC4.9070701@goop.org>
* Jeremy Fitzhardinge <jeremy@goop.org> wrote:
> It's not really virtualized. We're talking about dom0, which is
> the guest domain which has access to the real machine's real
> hardware; the MTRR is part of that.
That is a really broken model and design of virtualization:
splitting the hypervisor into Xen and then a separate Linux dom0
entity because reality called home a few years ago and you needed
actual working drivers and hardware support and a developer
community to pull that off ...
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.
Without a better reason than what you've given so far the answer is
really: "no thanks" ...
My suspicion is that Linus would (rightfully) refuse to pull such a
broken approach from me, so why should i pull it? If i'm wrong and
if you can get an Acked-by from Linus _before_ sending a pull
request we can override my NAK. I've Cc:-ed him, in case he wants to
express an opinion.
Ingo
WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@elte.hu>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Xen-devel <xen-devel@lists.xensource.com>,
the arch/x86 maintainers <x86@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Jesse Barnes <jbarnes@virtuousgeek.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [GIT PULL] xen /proc/mtrr implementation
Date: Mon, 18 May 2009 10:59:02 +0200 [thread overview]
Message-ID: <20090518085902.GE10687@elte.hu> (raw)
In-Reply-To: <4A10EAC4.9070701@goop.org>
* Jeremy Fitzhardinge <jeremy@goop.org> wrote:
> It's not really virtualized. We're talking about dom0, which is
> the guest domain which has access to the real machine's real
> hardware; the MTRR is part of that.
That is a really broken model and design of virtualization:
splitting the hypervisor into Xen and then a separate Linux dom0
entity because reality called home a few years ago and you needed
actual working drivers and hardware support and a developer
community to pull that off ...
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.
Without a better reason than what you've given so far the answer is
really: "no thanks" ...
My suspicion is that Linus would (rightfully) refuse to pull such a
broken approach from me, so why should i pull it? If i'm wrong and
if you can get an Acked-by from Linus _before_ sending a pull
request we can override my NAK. I've Cc:-ed him, in case he wants to
express an opinion.
Ingo
next prev parent reply other threads:[~2009-05-18 8:59 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-12 23:27 [GIT PULL] xen /proc/mtrr implementation Jeremy Fitzhardinge
2009-05-12 23:27 ` [PATCH 1/6] xen: set cpu_callout_mask to make mtrr work Jeremy Fitzhardinge
2009-05-12 23:27 ` [PATCH 2/6] xen mtrr: Use specific cpu_has_foo macros instead of generic cpu_has() Jeremy Fitzhardinge
2009-05-12 23:27 ` [PATCH 3/6] xen mtrr: Use generic_validate_add_page() Jeremy Fitzhardinge
2009-05-12 23:27 ` [PATCH 4/6] xen mtrr: Implement xen_get_free_region() Jeremy Fitzhardinge
2009-05-12 23:27 ` [PATCH 5/6] xen mtrr: Add xen_{get,set}_mtrr() implementations Jeremy Fitzhardinge
2009-05-12 23:27 ` [PATCH 6/6] xen mtrr: Kill some unnecessary includes Jeremy Fitzhardinge
2009-05-13 13:30 ` [GIT PULL] xen /proc/mtrr implementation Ingo Molnar
2009-05-13 13:30 ` Ingo Molnar
2009-05-13 14:39 ` Jeremy Fitzhardinge
2009-05-13 14:39 ` Jeremy Fitzhardinge
2009-05-15 18:27 ` Ingo Molnar
2009-05-15 18:27 ` Ingo Molnar
2009-05-15 20:09 ` Jeremy Fitzhardinge
2009-05-15 20:09 ` Jeremy Fitzhardinge
2009-05-15 23:26 ` Eric W. Biederman
2009-05-15 23:49 ` Jeremy Fitzhardinge
2009-05-15 23:49 ` Jeremy Fitzhardinge
2009-05-16 3:22 ` Jesse Barnes
2009-05-16 3:22 ` Jesse Barnes
2009-05-16 4:26 ` Eric W. Biederman
2009-05-16 18:22 ` Jesse Barnes
2009-05-16 18:22 ` Jesse Barnes
2009-05-18 5:02 ` Jeremy Fitzhardinge
2009-05-18 5:02 ` Jeremy Fitzhardinge
2009-05-18 4:57 ` Jeremy Fitzhardinge
2009-05-18 4:57 ` Jeremy Fitzhardinge
2009-05-18 8:59 ` Ingo Molnar [this message]
2009-05-18 8:59 ` Ingo Molnar
2009-05-18 13:17 ` [Xen-devel] " Jan Beulich
2009-05-18 17:51 ` Chris Wright
2009-05-18 18:07 ` Jeremy Fitzhardinge
2009-05-18 18:07 ` Jeremy Fitzhardinge
2009-05-19 9:59 ` Ingo Molnar
2009-05-19 9:59 ` Ingo Molnar
2009-05-19 10:22 ` [Xen-devel] " Jan Beulich
2009-05-19 10:22 ` Jan Beulich
2009-05-19 11:08 ` [Xen-devel] " Ingo Molnar
2009-05-19 11:08 ` Ingo Molnar
2009-05-19 12:04 ` [Xen-devel] " Gerd Hoffmann
2009-05-19 12:04 ` Gerd Hoffmann
2009-05-19 12:26 ` [Xen-devel] " Ingo Molnar
2009-05-19 12:26 ` Ingo Molnar
2009-05-19 12:32 ` [Xen-devel] " Alan Cox
2009-05-19 12:32 ` Alan Cox
2009-05-19 12:37 ` [Xen-devel] " Ingo Molnar
2009-05-19 12:37 ` Ingo Molnar
2009-05-19 13:21 ` [Xen-devel] " Gerd Hoffmann
2009-05-19 13:21 ` Gerd Hoffmann
2009-05-19 13:31 ` [Xen-devel] " Ingo Molnar
2009-05-19 13:31 ` Ingo Molnar
2009-05-19 13:51 ` [Xen-devel] " Gerd Hoffmann
2009-05-19 13:51 ` Gerd Hoffmann
2009-05-19 14:17 ` [Xen-devel] " Ingo Molnar
2009-05-19 14:17 ` Ingo Molnar
2009-05-19 14:55 ` [Xen-devel] " Gerd Hoffmann
2009-05-19 14:55 ` Gerd Hoffmann
2009-05-19 15:24 ` [Xen-devel] " Ingo Molnar
2009-05-19 15:24 ` Ingo Molnar
2009-05-20 8:01 ` [Xen-devel] " Gerd Hoffmann
2009-05-20 8:01 ` Gerd Hoffmann
2009-05-20 16:35 ` [Xen-devel] " Jeremy Fitzhardinge
2009-05-20 16:35 ` Jeremy Fitzhardinge
2009-05-20 16:12 ` Jeremy Fitzhardinge
2009-05-20 16:12 ` Jeremy Fitzhardinge
2009-05-20 8:16 ` Andi Kleen
2009-05-20 16:39 ` Jeremy Fitzhardinge
2009-05-20 16:39 ` Jeremy Fitzhardinge
2009-05-20 22:52 ` Andi Kleen
2009-05-20 22:49 ` Jeremy Fitzhardinge
2009-05-20 22:49 ` Jeremy Fitzhardinge
2009-05-20 23:03 ` H. Peter Anvin
2009-05-20 23:03 ` H. Peter Anvin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090518085902.GE10687@elte.hu \
--to=mingo@elte.hu \
--cc=ebiederm@xmission.com \
--cc=hpa@zytor.com \
--cc=jbarnes@virtuousgeek.org \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.