From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33)
	id 1Bp5xr-0000Lf-5b
	for qemu-devel@nongnu.org; Mon, 26 Jul 2004 09:56:27 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33)
	id 1Bp5xq-0000LK-9u
	for qemu-devel@nongnu.org; Mon, 26 Jul 2004 09:56:26 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.33) id 1Bp5xq-0000L2-2x
	for qemu-devel@nongnu.org; Mon, 26 Jul 2004 09:56:26 -0400
Received: from [66.54.152.27] (helo=jive.SoftHome.net)
	by monty-python.gnu.org with smtp (Exim 4.34) id 1Bp5uW-0002Sx-CJ
	for qemu-devel@nongnu.org; Mon, 26 Jul 2004 09:53:00 -0400
From: Mulyadi Santosa <a_mulyadi@softhome.net>
Subject: Re: [Qemu-devel] qemu-fast kernel patch question
Date: Mon, 26 Jul 2004 20:51:30 +0700
References: <410280F2.4020809@optusnet.com.au>
	<Pine.LNX.4.56.0407251213260.1397@halef.NotaMusica.com>
	<20040725200311.GA23104@jbrown.mylinuxbox.org>
In-Reply-To: <20040725200311.GA23104@jbrown.mylinuxbox.org>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200407262051.30041.a_mulyadi@softhome.net>
Reply-To: a_mulyadi@softhome.net, qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

Hello Jim :-)

First thank you to help correcting my logics :-)

> You could patch the host not to use that area, but then it would have to
> use another area ... thus you'd have to patch the guest anyways, regardless
> of the host.
Agree....why I don't think in such a logic before...hrrrrrr :-)

> Fabrice has said that the eventual idea is to have qemu-fast detect which
> areas are not accessable via mmap() and use the softmmu to emulate for only
> those areas. The rest would be accessed via the faster mmap(). So, if you
> patch qemu-fast in the right way, you might not have to patch the guest or
> the host. :)

So, that would be running mmap() scanning on early boot of Qemu, am  I right? 
from there, Qemu can take decision which area is free and which is already 
taken by host....Hm....looks like Qemu needs additional kernel module 
inserted to host's kernel to help Qemu on "memory layout" negotiation....:-)

regards

Mulyadi