qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/4] new Blackfin QEMU port


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH 0/4] new Blackfin QEMU port
Date: Tue, 1 Feb 2011 18:45:57 +0000

On 1 February 2011 18:16, Mike Frysinger <address@hidden> 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() ?  that 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.  then in this state func, make sure the current lbregs
> have the same values.  but 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]