From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1L0l5w-0005jY-Vy
	for qemu-devel@nongnu.org; Thu, 13 Nov 2008 17:55:25 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1L0l5v-0005jI-7k
	for qemu-devel@nongnu.org; Thu, 13 Nov 2008 17:55:23 -0500
Received: from [199.232.76.173] (port=47736 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1L0l5v-0005iu-2P
	for qemu-devel@nongnu.org; Thu, 13 Nov 2008 17:55:23 -0500
Received: from fmmailgate01.web.de ([217.72.192.221]:56107)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <jan.kiszka@web.de>) id 1L0l5u-0008UT-IC
	for qemu-devel@nongnu.org; Thu, 13 Nov 2008 17:55:22 -0500
Message-ID: <491CB052.5040809@web.de>
Date: Thu, 13 Nov 2008 23:55:14 +0100
From: Jan Kiszka <jan.kiszka@web.de>
MIME-Version: 1.0
References: <20081103103558.213902776@mchn012c.ww002.siemens.net>
	<491CA4FD.8000202@bellard.org>
In-Reply-To: <491CA4FD.8000202@bellard.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: jan.kiszka@web.de
Subject: [Qemu-devel] Re: [PATCH 00/12] Enhance debugging support - 4th take
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
Cc: jan.kiszka@siemens.com

Fabrice Bellard wrote:
> I had a quick look at the patch serie (I don't have the time to look at
> it carefully). I find the patch globally acceptable, but I have two remarks:
> 
> - Patch 01/12 may introduce a performance regression due to the change
> in tb_find_fast(). If gcc does not optimizes the code correctly, your
> change will introduce many unneeded memory accesses and a call to
> memcmp() in the fast path, which is not acceptable.

OK, will remove the memcmp to play safe. Beyond that, there is only a
static inline cpu_get_tb_cpu_state involved in the fast path which
dereferences addresses. If that gets blown up to a real function, the
compiler is not configured for performance anyway. But I can check the
results again with older and current compilers, comparing object sizes.

> - Patch 12/12 needs improvements (load/save VM)

Good point, will check and add missing bits.

> and possibly more
> analysis to see if it complies with the x86 spec, so it could be applied
> later.

No problem (as long as "later" doesn't mean another 5 months ;) ),

Please keep in mind that this patch allows to run a lot of
debug-register-using guest code that broke so far. So, unless you or
someone else with deep x86 knowledge find issues during that code
inspection, hunting them via concrete test cases may be helpful as well.

Thanks for having a look!
Jan