[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0702161356380.29218@schroedinger.engr.sgi.com>
Date: Fri, 16 Feb 2007 13:59:44 -0800 (PST)
From: Christoph Lameter <clameter@....com>
To: Zachary Amsden <zach@...are.com>
cc: Jeremy Fitzhardinge <jeremy@...p.org>, Andi Kleen <ak@....de>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, virtualization@...ts.osdl.org,
xen-devel@...ts.xensource.com, Chris Wright <chrisw@...s-sol.org>,
Rusty Russell <rusty@...tcorp.com.au>
Subject: Re: [patch 00/21] Xen-paravirt: Xen guest implementation for
paravirt_ops interface
On Fri, 16 Feb 2007, Zachary Amsden wrote:
> 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). 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?)
Well looks like there are still some major design issues to be ironed out.
What is proposed here is to make paravirt_ops a fake generic
API and then tunnel through it to vendor specific kernel mods.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists