[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <45F1EA32.8080108@redhat.com>
Date: Fri, 09 Mar 2007 18:13:54 -0500
From: Rik van Riel <riel@...hat.com>
To: Ingo Molnar <mingo@...e.hu>
CC: Chris Wright <chrisw@...s-sol.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Jeremy Fitzhardinge <jeremy@...p.org>,
Zachary Amsden <zach@...are.com>,
Thomas Gleixner <tglx@...utronix.de>,
john stultz <johnstul@...ibm.com>, akpm@...ux-foundation.org,
LKML <linux-kernel@...r.kernel.org>,
Rusty Russell <rusty@...tcorp.com.au>, Andi Kleen <ak@...e.de>,
Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: ABI coupling to hypervisors via CONFIG_PARAVIRT
Ingo Molnar wrote:
> ok, sure, how about the one i mentioned: long-term i'd like to have a
> paravirt model where the guest does not store /any/ page tables - all
> paging is managed by the hypervisor. The guest has a vma tree, but
> otherwise it does not process pagefaults, has no concept of a pte (if in
> paravirt mode), has no concept of kernel page tables either: there are
> hypercalls to allocate/free guest-kernel memory, etc. This needs some
> (serious) MM surgery but it's doable and it's interesting as well. How
> would you map this to the VMI backend?
Ugh!
In a situation like that, how does the guest handle pageouts?
What about the dirty and accessed bits?
I'm guessing VMI would deal with this kind of abstraction in
exactly the same way we do the "native hardware" layer behind
paravirt_ops. Ie. this example is a red herring.
--
Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is. Each group
calls the other unpatriotic.
-
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