WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [PATCH] xen: core dom0 support

To: Andi Kleen <andi@xxxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH] xen: core dom0 support
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Sun, 01 Mar 2009 15:34:13 -0800
Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, "H. Peter Anvin" <hpa@xxxxxxxxx>, the arch/x86 maintainers <x86@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>
Delivery-date: Sun, 01 Mar 2009 15:34:44 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <87eixi35ew.fsf@xxxxxxxxxxxxxxxxx>
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: <1235786365-17744-1-git-send-email-jeremy@xxxxxxxx> <20090227212812.26d02f34.akpm@xxxxxxxxxxxxxxxxxxxx> <49A8DF28.4050301@xxxxxxxx> <87eixi35ew.fsf@xxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.19 (X11/20090105)
Andi Kleen wrote:
I would say the more interesting question is less how much additional
code it is or even how much it changes the main kernel, but more how
different the code execution paths in interaction with Xen are
compared to what a native kernel would do. Because such differences
always would need to be considered in future changes.

Yes. A big part of what I'm doing is trying to keep the Xen changes self-contained to try and minimize their system-wide impact. Basically it comes down to that if you use (mostly existing) kernel APIs in the way they're intended to be used, then things just work out for both Xen and native cases. The whole point of keeping the kernel modular is so that if people implement and use the the interfaces correctly, the internal details shouldn't matter very much. Often the process of adding Xen support has resulted in putting clear, well defined interfaces into parts of the kernel where previously things were, well, in need of cleaning up.

For example things like: doesn't use PAT with Xen or apparently very
different routing are somewhat worrying because it means it's a
completely different operation modus with Xen that needs to be taken
care of later, adding to complexity.

Unless we're planning on dropping support for processes with no or broken PAT support, we're always going to have to deal with the non-PAT case. Xen just falls into the "processor with no PAT" case. And if/when we work out how to paravirtualize PAT, it will no longer be in that case.

Unfortunately it also looks like that Xen the HV does things
more and more different from what mainline kernel does so these differences will likely continue to grow over time.

I hope that won't be the case. As part of considering any change to Xen is considering what changes would be needed to the guest operating systems to make use of that feature.

   J

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>