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

Re: [Xen-devel] Re: Xen is a feature

To: "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>
Subject: Re: [Xen-devel] Re: Xen is a feature
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Fri, 29 May 2009 16:26:39 -0700
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxxxxx>, "x86@xxxxxxxxxx" <x86@xxxxxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, Andi Kleen <andi@xxxxxxxxxxxxxx>, Keir Fraser <Keir.Fraser@xxxxxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxx>
Delivery-date: Fri, 29 May 2009 16:27:12 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <0B53E02A2965CE4F9ADB38B34501A3A188156C9C@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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: <162f4c90-6431-4a2a-b337-6d7451d7b11e@default> <20090528001350.GD26820@xxxxxxx> <4A1F302E.8030501@xxxxxxxx> <20090528.210559.137121893.davem@xxxxxxxxxxxxx> <4A1FCE8E.2060604@xxxxxxxxxxxxx> <87tz33ep1b.fsf@xxxxxxxxxxxxxxxxx> <0B53E02A2965CE4F9ADB38B34501A3A188156C9C@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.21 (X11/20090320)
Nakajima, Jun wrote:
I think we still need some (or all?) of additional dom0 PV ops even for HVM 
(Hardware-based VM) dom0. Hardware-based virtualization can significantly clean 
up the CPU-related PV ops (including some for local APIC), but they have 
nothing to do with dom0.

Some hooks in the host could be removed by reusing the HVM-specific code with 
modifications to the virtualization logic, but I think people need to tell 
which specific ones are intrusive, to be fair.

I think two things will significantly clean up the dom0 apic patches:

   One is to adjust the LAPIC and IOAPIC probing code so that it
   behaves correctly if the APIC cpuid flag is clear.  That would
   remove a lot of the init-time ad-hoc Xen changes I made.

   The other is to implement Ingo's suggestion of a proper ioapic
   driver layer.  I think that would not only resolve the low-level
   IO-APIC register access issue, but probably clean up a lot of the
vector allocation/handling, and make a clear path for MSI support. With luck it will also clean up things like x2apic support

I'm planning on putting some time into investigating these next week.

Once we've nailed down the details of how to make PAT work for PV guests on the Xen side, we should be able to implement that fairly easily in Linux with no core x86 changes.

I really don't think emulating MTRR register writes is the right way to implement Xen MTRR support, given that a much more semantically appropriate interface already exists, but we can do that if nothing else gets merged.

IanC is restructuring the swiotlb changes in a way that I hope will be acceptable to all.

At that point, I think we really will have resolved all the high-level concerns expressed about the overall architecture of the patches, and maybe we can finally see some progress.

   J

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