On 1 February 2011 18:16, Mike Frysinger <vap...@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() ? 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
