[no subject]

[Andi Kleen]

Sender: ak@xxxxxxxxxxxxx
To: Rik van Riel <riel@xxxxxxxxxx>
cc: linux-kernel@xxxxxxxxxxxxxxx, akpm@xxxxxxxx,
	Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>, Steven.Hand@xxxxxxxxxxxx,
	Christian.Limpach@xxxxxxxxxxxx, Keir.Fraser@xxxxxxxxxxxx
Subject: arch/xen considered harmful was Re: Xen VMM patch set - take 2
References: <E1CXLph-0000XC-00@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
	<Pine.LNX.4.61.0411281206100.12575@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
From: Andi Kleen <ak@xxxxxxx>
Date: 14 Dec 2004 17:49:07 +0100
In-Reply-To: <Pine.LNX.4.61.0411281206100.12575@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Message-ID: <p73mzwgddvg.fsf_-_@xxxxxxxxxxxxx>
Lines: 48
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Rik van Riel <riel@xxxxxxxxxx> writes:

[very late answer]

> Stunned silence I guess - merging an architecture is
> usually much more controversial ;)

In my opinion it's still an extremly bad idea to have arch/xen
an own architecture. It will cause a lot of work long term
to maintain it, especially when it gets x86-64 support too.
It would be much better to just merge it with i386/x86-64.

Currently it's already difficult enough to get people to
add fixes to both i386 and x86-64, adding fixes to three
or rather four (xen32 and xen64) architectures will be quite bad.
In practice we'll likely get much worse code drift and missing
fixes. Also I still suspect Ian is underestimating how much
work it is long term to keep an Linux architecture uptodate.

I cannot imagine the virtualization hooks are intrusive anyways. The
only things it needs to hook idle and the page table updates, right?
Doing that cleanly in the existing architectures shouldn't be that
hard.

I suspect xen64 will be rather different from xen32 anyways
because as far as I can see the tricks Xen32 uses to be
fast (segment limits) just plain don't work on 64bit
because the segments don't extend into 64bit space.
So having both in one architecture may also end up messy.

And i386 and x86-64 are in many pieces very different anyways,
I have my doubts that trying to mesh them together in arch/xen
will be very pretty.

Also the other thing I'm worried about is that there is no clear
specification on how the Xen<->Linux interface works. Assuming
there will be other para Hypervisors in the future too will we
end up with even more virtual architectures? It would be much
better to have at least a somewhat defined "linux virtual interface"
first that is actually understood by multiple people outside
the Xen group.

I think before merging stuff the hypervisor interfaces need to be
discussed on linux-kernel. Splitting the patches and posting them
as individual pieces for i386 with good description will be a good
first step for that.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/