From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52943) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VeAj3-0002Q5-TL for qemu-devel@nongnu.org; Wed, 06 Nov 2013 16:33:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VeAix-0004X9-Tp for qemu-devel@nongnu.org; Wed, 06 Nov 2013 16:33:21 -0500 Received: from mx1.redhat.com ([209.132.183.28]:57661) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VeAix-0004X5-MF for qemu-devel@nongnu.org; Wed, 06 Nov 2013 16:33:15 -0500 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rA6LXFDd004709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 6 Nov 2013 16:33:15 -0500 Date: Wed, 6 Nov 2013 23:36:14 +0200 From: "Michael S. Tsirkin" Message-ID: <20131106213614.GA22469@redhat.com> References: <20131106112214.14a448b6@redhat.com> <527A7EDE.3060409@redhat.com> <20131106174834.GA11767@redhat.com> <527A814D.5020804@redhat.com> <20131106183912.GA16747@redhat.com> <527AB0EC.8080200@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <527AB0EC.8080200@redhat.com> Subject: Re: [Qemu-devel] BUG: QEMU aborts when setting breakpoint in gdb (bisected) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Luiz Capitulino , qemu-devel , marcel.a@redhat.com On Wed, Nov 06, 2013 at 10:13:16PM +0100, Paolo Bonzini wrote: > Il 06/11/2013 19:39, Michael S. Tsirkin ha scritto: > > Because this will affect performance in unpredicatable way. > > It's not really unpredictable. It can be easily unit-tested, Go ahead, post, test, I'm not stopping you. > and anyway > the targets with 64-bit address spaces don't have any particular > performance problem. That's only s390x and they happen not to use IO for anything, instead they do hypercalls. So hard to tell. > > We can't make such changes in 1.7 IMHO: > > it would need much more than just a quick "works for me". > > I can say the same about phys_page_find. Why? It's *obvious* this code is not designed to work with addresses > target address space. You doubt that? What is the worry here? > It's been obviously broken for > years and nobody ever cared, it cannot be super-urgent now to fix it. > > Paolo Well we added a bunch of code and now it is failing. > >> > I don't feel confident > >> > changing phys_page_find, even if it's just 2 lines. > >> > > >> > Paolo > > Well it's *obviously* broken if address is outside target address > > space. > > Take a look at the patch first, then argue.