From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1JlLkE-0000KP-85
	for qemu-devel@nongnu.org; Mon, 14 Apr 2008 06:17:02 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1JlLkD-0000Il-7U
	for qemu-devel@nongnu.org; Mon, 14 Apr 2008 06:17:01 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1JlLkD-0000IT-1x
	for qemu-devel@nongnu.org; Mon, 14 Apr 2008 06:17:01 -0400
Received: from www.seclab.tuwien.ac.at ([128.130.60.29]
	helo=mail.seclab.tuwien.ac.at) by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <ck@iseclab.org>) id 1JlLkC-0004wI-NA
	for qemu-devel@nongnu.org; Mon, 14 Apr 2008 06:17:00 -0400
Received: from ckol.seclab.tuwien.ac.at (ckol.seclab.tuwien.ac.at
	[128.130.60.51])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.seclab.tuwien.ac.at (Postfix) with ESMTP id 10DA931247
	for <qemu-devel@nongnu.org>; Mon, 14 Apr 2008 12:14:57 +0200 (CEST)
From: Clemens Kolbitsch <ck@iseclab.org>
Date: Mon, 14 Apr 2008 12:16:08 +0200
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200804141216.08755.ck@iseclab.org>
Subject: [Qemu-devel] dyngen_code in 16 bit
Reply-To: 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

Hi!
For a research project I extended Qemu to include some extra code inside the 
op_XXX instructions that increased the generated TB-code's size to quite some 
extend... 

Now I have a problem when having block chaining enabled (that I don't want to 
disable for performance reasons :-/): The code_gen_buffer sometimes contains 
code areas that span more than 0xffff bytes, however, dyngen and all 
functions related to it use 16 bit pointers, etc. Therefore, e.g. the 
dyngen_code function uses the 16 bit pointers to overwrite certain params and 
of course destroys the TB-code.

When working with x86 hosts and guests (both 32 bit), is there a specific 
reason for all these pointers to be 16 bits or has it just been a safe 
assumption up to now?? I have tried rewriting the code to use 32 bit, but 
keep getting segfaults... however, of course, I might have missed some code 
still.

Any help is - as always - greatly appreciated!!

Cheers,
Clemens