From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: + stupid-hack-to-make-mainline-build.patch added to -mm tree Date: Thu, 08 Mar 2007 11:52:41 -0800 Message-ID: <45F06989.8030207@goop.org> References: <45EF0CF5.5090305@goop.org> <45EF175D.6030609@vmware.com> <1173302503.24738.795.camel@localhost.localdomain> <45EF372E.7030600@goop.org> <1173308717.24738.898.camel@localhost.localdomain> <45EF49E9.7040509@vmware.com> <1173313373.24738.937.camel@localhost.localdomain> <45EF6077.9090302@vmware.com> <20070308182456.GH19575@sequoia.sous-sol.org> <45F06720.8080901@goop.org> <20070308194740.GJ10574@sequoia.sous-sol.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20070308194740.GJ10574@sequoia.sous-sol.org> Sender: linux-kernel-owner@vger.kernel.org To: Chris Wright Cc: Daniel Arai , Virtualization Mailing List , akpm@linux-foundation.org, john stultz , tglx@linutronix.de, Ingo Molnar , LKML List-Id: virtualization@lists.linuxfoundation.org Chris Wright wrote: > I agree with that, but I think that's esp. for things like create and launch > new vcpu. The IPI bit I'm not as clear on, nor running this all on native > as well. > Well, native would fall back to using the existing arch/i386 versions of those functions, so that's reasonably straightforward. There'll need to be a bit of internal rearrangement so that the Xen code can call in to do things like set up the pda/gdt and other bits of CPU state. I don't think IPI is especially interesting in itself, is it? It's a necessary mechanism to implement smp_call_function(), but Xen can do IPI without having to invoke any of the existing apic-based IPI code. The other main user of IPI is cross-cpu tlb shootdown, but Xen has much more efficient mechanisms than IPI for that (so we'll need to make the tlb pv_ops interface a little wider to pass down a cpuset). J