From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rusty Russell Subject: Re: [patch 00/21] Xen-paravirt: Xen guest implementation for paravirt_ops interface Date: Sat, 17 Feb 2007 16:05:42 +1100 Message-ID: <1171688742.18876.69.camel@localhost.localdomain> References: <20070216022449.739760547@goop.org> <45D61C74.2000601@vmware.com> <45D626BB.20007@vmware.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <45D626BB.20007@vmware.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.osdl.org Errors-To: virtualization-bounces@lists.osdl.org To: Zachary Amsden Cc: Chris Wright , virtualization@lists.osdl.org, xen-devel@lists.xensource.com, JAndi Kleen , Andrew Morton , linux-kernel@vger.kernel.org, Christoph Lameter List-Id: virtualization@lists.linuxfoundation.org On Fri, 2007-02-16 at 13:48 -0800, Zachary Amsden wrote: > Christoph Lameter wrote: > > It still seems to be implemented for Xen and not to support a variety o= f = > > page table methods in paravirt ops. > = > Yes, but that is just because the Xen hooks happens to be near the last = > part of the merge. VMI required some special hooks, as do both Xen and = > lhype (I think ... Rusty can correct me if lhype's puppy's have = > precluded the addition of new hooks). lguest was supposed to be a demonstration of paravirt_ops, so it shouldn't have added any. But note that I did change some other things, such as the esp0 initialization for the swapper. Puppies are still alive and well. Although Andi not pushing into 2.6.21 (yet?) made puppies sad 8( > Xen page table handling is very = > different, mostly it is trap and emulate so writable page tables can = > work, which means they don't always issue hypercalls for PTE updates, = > although they do have that option, should the hypervisor MMU model = > change, or performance concerns prompt a different model (or perhaps, = > migration?) Yes, Xen really like their direct pagetable stuff. I'm a traditionalist, myself, but it did require some expansion of paravirt_ops. KVM might well want more, although from here it's more likely we'll move some of the hooks up the stack a little IMHO. Cheers, Rusty. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932646AbXBQFGf (ORCPT ); Sat, 17 Feb 2007 00:06:35 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932647AbXBQFGf (ORCPT ); Sat, 17 Feb 2007 00:06:35 -0500 Received: from ozlabs.org ([203.10.76.45]:44630 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932646AbXBQFGf (ORCPT ); Sat, 17 Feb 2007 00:06:35 -0500 Subject: Re: [patch 00/21] Xen-paravirt: Xen guest implementation for paravirt_ops interface From: Rusty Russell To: Zachary Amsden Cc: Christoph Lameter , JAndi Kleen , Andrew Morton , linux-kernel@vger.kernel.org, virtualization@lists.osdl.org, xen-devel@lists.xensource.com, Chris Wright In-Reply-To: <45D626BB.20007@vmware.com> References: <20070216022449.739760547@goop.org> <45D61C74.2000601@vmware.com> <45D626BB.20007@vmware.com> Content-Type: text/plain Date: Sat, 17 Feb 2007 16:05:42 +1100 Message-Id: <1171688742.18876.69.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2007-02-16 at 13:48 -0800, Zachary Amsden wrote: > Christoph Lameter wrote: > > It still seems to be implemented for Xen and not to support a variety of > > page table methods in paravirt ops. > > Yes, but that is just because the Xen hooks happens to be near the last > part of the merge. VMI required some special hooks, as do both Xen and > lhype (I think ... Rusty can correct me if lhype's puppy's have > precluded the addition of new hooks). lguest was supposed to be a demonstration of paravirt_ops, so it shouldn't have added any. But note that I did change some other things, such as the esp0 initialization for the swapper. Puppies are still alive and well. Although Andi not pushing into 2.6.21 (yet?) made puppies sad 8( > Xen page table handling is very > different, mostly it is trap and emulate so writable page tables can > work, which means they don't always issue hypercalls for PTE updates, > although they do have that option, should the hypervisor MMU model > change, or performance concerns prompt a different model (or perhaps, > migration?) Yes, Xen really like their direct pagetable stuff. I'm a traditionalist, myself, but it did require some expansion of paravirt_ops. KVM might well want more, although from here it's more likely we'll move some of the hooks up the stack a little IMHO. Cheers, Rusty.