From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1O1L3B-0007ml-4s
	for qemu-devel@nongnu.org; Mon, 12 Apr 2010 10:55:45 -0400
Received: from [140.186.70.92] (port=55027 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1O1L38-0007mR-Rz
	for qemu-devel@nongnu.org; Mon, 12 Apr 2010 10:55:43 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <rth7680@gmail.com>) id 1O1L37-0001rD-SI
	for qemu-devel@nongnu.org; Mon, 12 Apr 2010 10:55:42 -0400
Received: from mail-ew0-f227.google.com ([209.85.219.227]:34174)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <rth7680@gmail.com>) id 1O1L37-0001r8-L1
	for qemu-devel@nongnu.org; Mon, 12 Apr 2010 10:55:41 -0400
Received: by ewy27 with SMTP id 27so1962725ewy.10
	for <qemu-devel@nongnu.org>; Mon, 12 Apr 2010 07:55:40 -0700 (PDT)
Sender: Richard Henderson <rth7680@gmail.com>
Message-ID: <4BC3345A.6090401@twiddle.net>
Date: Mon, 12 Apr 2010 07:55:22 -0700
From: Richard Henderson <rth@twiddle.net>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [RFC] Host vs Guest memory allocation
References: <4BBA6803.3000008@twiddle.net>
	<20100405231821.GA27894@volta.aurel32.net>
	<4BC3088E.5080603@redhat.com>
In-Reply-To: <4BC3088E.5080603@redhat.com>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
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: Avi Kivity <avi@redhat.com>
Cc: qemu-devel Developers <qemu-devel@nongnu.org>, Aurelien Jarno <aurelien@aurel32.net>

On 04/12/2010 04:48 AM, Avi Kivity wrote:
>>> (1) Enable softmmu for userland. This is of course the highest overhead,
>>> but will work for all combinations.
>>>
...
> You could reduce the overhead somewhat by using kvm for memory
> translation on hosts that support it. Of course tcg translation and
> syscall costs will grow by the exit overhead.

I've thought about this a bit, and what seemed to be the stickler is
what is the environment that runs in the guest?  TCG generated code
is of course fine, but what about the helper functions?  How can we
tell whether a given helper function can run in the restricted 
environment of the guest or whether it needs to transition back to the 
environment of the host to do its work?

I suppose the obvious solution is some sort of flag on the function that 
well-maintained ports will set.  But the whole marshalling thing is 
still pretty tricky.


r~