From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=42967 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1PkLEo-0004mw-67
	for qemu-devel@nongnu.org; Tue, 01 Feb 2011 13:46:03 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <peter.maydell@linaro.org>) id 1PkLEl-0004LH-OG
	for qemu-devel@nongnu.org; Tue, 01 Feb 2011 13:46:01 -0500
Received: from mail-ey0-f173.google.com ([209.85.215.173]:36207)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <peter.maydell@linaro.org>) id 1PkLEl-0004Kj-E1
	for qemu-devel@nongnu.org; Tue, 01 Feb 2011 13:45:59 -0500
Received: by eyg7 with SMTP id 7so3554977eyg.4
	for <qemu-devel@nongnu.org>; Tue, 01 Feb 2011 10:45:57 -0800 (PST)
MIME-Version: 1.0
In-Reply-To: <AANLkTi=AG-u0Kkvp__k1VPxqZgBfe7KKLp2SBwUzo88A@mail.gmail.com>
References: <1295864581-13494-1-git-send-email-vapier@gentoo.org>
	<20110131140054.GA24608@edde.se.axis.com>
	<AANLkTi=QMN9CfWn9PnDhuA4e-pJF5-xJdmC-kQc67No_@mail.gmail.com>
	<929A8BC2-BC8C-459D-96C0-FF8E9C1BF5FD@suse.de>
	<AANLkTi=E+14FZ9-kJyhST3WN=afJ6Du-2w_0pD2kMqXj@mail.gmail.com>
	<AANLkTinTu8ZGkMUpD6JHbXiBj5eF+bOnt8J--9Pz5xLG@mail.gmail.com>
	<AANLkTi=EH5zCd_znOVZFcEmLvOF=vOK2vR5v9YDhtcvb@mail.gmail.com>
	<AANLkTi=AG-u0Kkvp__k1VPxqZgBfe7KKLp2SBwUzo88A@mail.gmail.com>
Date: Tue, 1 Feb 2011 18:45:57 +0000
Message-ID: <AANLkTiny4xTPNNvbmqw_szedw53ecvsrMGV_rSf3i+Xk@mail.gmail.com>
Subject: Re: [Qemu-devel] [PATCH 0/4] new Blackfin QEMU port
From: Peter Maydell <peter.maydell@linaro.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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.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: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Mike Frysinger <vapier@gentoo.org>
Cc: "Edgar E. Iglesias" <edgar.iglesias@gmail.com>, toolchain-devel@blackfin.uclinux.org, Alexander Graf <agraf@suse.de>, qemu-devel@nongnu.org

On 1 February 2011 18:16, Mike Frysinger <vapier@gentoo.org> wrote:
> On Tue, Feb 1, 2011 at 12:30, Peter Maydell wrote:
>> That's OK too, that would fall into my category (3).
>
> so the TB invalidation checking can be taken care of implicitly if i
> handled things in cpu_get_tb_cpu_state() ? =C2=A0that would be nice.

It doesn't invalidate the TB, it just means that qemu can have
two different TBs for the same address and distinguish between
them. So in cpu_get_tb_cpu_state() you encode the relevant bits
of env into the flags, and then in translate.c, instead of looking
at env members, you unpack tb->flags (usually into a disas context
struct) and look at the results of your unpacking.

> but i guess i'm not seeing how i would handle this scenario ... i want
> to attach to each TB the state of the two 32bit lbregs when that TB
> was created. =C2=A0then in this state func, make sure the current lbregs
> have the same values. =C2=A0but if i need to encode this information into
> "flags", i dont think i have enough space.

That's right -- you only have a total of 64 bits (you can use flags
and also cs_base since you're not a PC with a weird addressing
setup), so you have to be stingy about what you put in there.
Also if you're likely to repeatedly execute the same bit of code
with different values of lbregs you probably don't want to put them
in tb_flags anyway, because you'd end up repeatedly translating
the code and holding lots of nearly-identical TBs for it.

-- PMM