From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:55347)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <B07421@freescale.com>) id 1Tjd2D-0001Dr-9w
	for qemu-devel@nongnu.org; Fri, 14 Dec 2012 16:43:12 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <B07421@freescale.com>) id 1Tjd2A-0000wJ-2M
	for qemu-devel@nongnu.org; Fri, 14 Dec 2012 16:43:09 -0500
Date: Fri, 14 Dec 2012 15:42:55 -0600
From: Scott Wood <scottwood@freescale.com>
References: <1355451124-2559-1-git-send-email-scottwood@freescale.com>
	<1355451124-2559-5-git-send-email-scottwood@freescale.com>
	<B20683A9-43C9-4D0A-8C8B-ACD759B6AD90@suse.de>
In-Reply-To: <B20683A9-43C9-4D0A-8C8B-ACD759B6AD90@suse.de> (from
	agraf@suse.de on Fri Dec 14 06:35:12 2012)
Message-ID: <1355521375.4740.6@snotra>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; delsp=Yes; format=Flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] [PATCH 4/6] openpic: don't crash on a register
 access without a CPU context
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Alexander Graf <agraf@suse.de>
Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org

On 12/14/2012 06:35:12 AM, Alexander Graf wrote:
>=20
> On 14.12.2012, at 03:12, Scott Wood wrote:
>=20
> > If we access a register via the QEMU memory inspection commands =20
> (e.g.
> > "xp") rather than from guest code, we won't have a CPU context.
> > Gracefully fail to access the register in that case, rather than
> > crashing.
>=20
> Can't we set cpu_single_env in the debug memory access case? I'm not =20
> sure this is the only device with that problem, and by always having =20
> cpu_single_env available we would completely get rid of the whole bug =20
> category.

So, how would we go about doing this?  cpu_single_env is declared as =20
thread-local storage.  Even if there's some way to deliberately inspect =20
a different thread's local storage, I don't see how you'd get it to =20
work automatically without changing all those drivers (and are there =20
really that many that care about the CPU?) -- and we might break other =20
places that already check whether cpu_single_env is NULL.

FWIW, hw/pc.c does pretty much the same thing as this patch in =20
cpu_get_current_apic().

-Scott=