From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zachary Amsden Subject: Re: [patch 00/21] Xen-paravirt: Xen guest implementation for paravirt_ops interface Date: Fri, 16 Feb 2007 13:04:52 -0800 Message-ID: <45D61C74.2000601@vmware.com> References: <20070216022449.739760547@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Christoph Lameter Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com, Andi Kleen , linux-kernel@vger.kernel.org, Chris Wright , virtualization@lists.osdl.org, Andrew Morton List-Id: virtualization@lists.linuxfoundation.org Christoph Lameter wrote: > On Thu, 15 Feb 2007, Jeremy Fitzhardinge wrote: > > >> This patch series implements the Linux Xen guest in terms of the >> paravirt-ops interface. The features in implemented this patch series >> > > I am thoroughly confused. Maybe that is because I have not been following > this issue closely but it seems that you are using the paravirt interface > as an API for Xen code in the guest? I thought the idea of paravirt was to > have an API that is generic? This patchset seems to be mostly realizing > Xen specific functionality? How does the code here interact with KVM, > VMWare and other hypervisors? > For the most part, it doesn't disturb VMware or KVM. Xen does need some additional functionality in paravirt-ops because they took a different design choice - direct page tables instead of shadow page tables. This is where all the requirements for the new Xen paravirt-ops hooks come from. Zach