From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O1LHH-0005oK-KT for qemu-devel@nongnu.org; Mon, 12 Apr 2010 11:10:19 -0400 Received: from [140.186.70.92] (port=47447 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O1LHA-0005m0-5U for qemu-devel@nongnu.org; Mon, 12 Apr 2010 11:10:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O1LH3-0004Nt-IA for qemu-devel@nongnu.org; Mon, 12 Apr 2010 11:10:11 -0400 Received: from mx1.redhat.com ([209.132.183.28]:65001) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O1LH3-0004Nm-6w for qemu-devel@nongnu.org; Mon, 12 Apr 2010 11:10:05 -0400 Message-ID: <4BC337C2.2090500@redhat.com> Date: Mon, 12 Apr 2010 18:09:54 +0300 From: Avi Kivity 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> <4BC3345A.6090401@twiddle.net> In-Reply-To: <4BC3345A.6090401@twiddle.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson Cc: qemu-devel Developers , Aurelien Jarno On 04/12/2010 05:55 PM, Richard Henderson wrote: > >> 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'd guess all helpers can run in guest context except those that cause a transition to target kernel mode. > 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. Pass everything through memory; will there be many transitions apart from trapping instructions and missing translations? For extra points run the translator in guest context. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.