> > The only reason this doesn't have any visible effect is:
> > (1) x86 doesn't have split icache/dcache so no incoherency issues
> >
>
> I think intel new architecture does split instruction cache/data cache.
> http://upload.wikimedia.org/wikipedia/commons/6/64/Intel_Nehalem_arch.svg
>
> But I
On 27 January 2012 02:55, Xin Tong wrote:
> I think intel new architecture does split instruction cache/data cache.
> http://upload.wikimedia.org/wikipedia/commons/6/64/Intel_Nehalem_arch.svg
It may have a separate I/D cache in the implementation, but from
the programmer's point of view they are
On Thu, Jan 26, 2012 at 3:55 PM, Peter Maydell wrote:
> On 26 January 2012 19:52, Xin Tong wrote:
> > It seems to me that when QEMU emits a TB to TB transition, it does not
> look
> > for whether the code has already been generated or not ( at least x86 on
> x86
> > emulation) . it just lay down
On 26 January 2012 19:52, Xin Tong wrote:
> It seems to me that when QEMU emits a TB to TB transition, it does not look
> for whether the code has already been generated or not ( at least x86 on x86
> emulation) . it just lay down a 4 byte address, waiting to be patched later.
> Am I right ?
Yes,
On Thu, Nov 24, 2011 at 08:54:36PM -0500, Xin Tong wrote:
> I came back to the block chaining code. This code is still not very
> clear to me. Here we are linking tb_next -> tb. jmp_next of the tb
> contains the next tbs it will jump to. why are we checking the
> !tb->jmp_next[n], but not !tb_next-
I came back to the block chaining code. This code is still not very
clear to me. Here we are linking tb_next -> tb. jmp_next of the tb
contains the next tbs it will jump to. why are we checking the
!tb->jmp_next[n], but not !tb_next->jmp_next[n] ?
static inline void tb_add_jump(TranslationBlock *t
> Say your are trying to emulate an indirect jump ( i.e. jmp eax). Because eax
> is unknown at compile time, you will have to return to the mainloop to look
> it up. However, if you know some likely values, you can do a few cached
> compare and hope it hits one of them.
>
> compare eax = 0x33e3e23
Say the
On Fri, Sep 23, 2011 at 10:50 PM, 陳韋任 wrote:
> > I see, so they (jmp_next, jmp_first) are just for finding the tbs when
> > unchaining is needed. do they have any other uses? also, does QEMU do
> inline
> > caching ( when it is a conditional branch)?
>
> Yes, they are used for unchaini
> I see, so they (jmp_next, jmp_first) are just for finding the tbs when
> unchaining is needed. do they have any other uses? also, does QEMU do inline
> caching ( when it is a conditional branch)?
Yes, they are used for unchaining. Please see cpu_unlink_tb ->
tb_reset_jump_recursive.
What "i
> if direct chaining is used, am I right to think that jmp_next and jmp_first
> will not be used ?
You have to know that when we say "TB", it might means different
things according to the context.
QEMU use struct TranslationBlock to record some information about
TB in the code cache. Take dir
if direct chaining is used, am I right to think that jmp_next and jmp_first
will not be used ?
Thanks
Xin
On Wed, Sep 21, 2011 at 10:36 PM, 陳韋任 wrote:
> > Well, the comment is from source code. I don't catch why you think "list
> > of TBS jumping to this one" is wrong.
> > My understand is th
> Well, the comment is from source code. I don't catch why you think "list
> of TBS jumping to this one" is wrong.
> My understand is that TB chain be used forreduce switch from the
> translation
> cache to the guest code. It will be a circular list if there is no interrupt
> or exceptional.
On 09/22/2011 09:58 AM, 陳韋任 wrote:
/* list of TBs jumping to this one. This is a circular list using
the two least significant bits of the pointers to tell what is
the next pointer: 0 = jmp_next[0], 1 = jmp_next[1], 2 =
jmp_first */
struct TranslationBlock
> I am new to QEMU, can anyone please tell me where the TB chaining code is in
> QEMU ?
struct TranslationBlock has fields used to to block chaining. You also
need to look into it.
cpu_exec (cpu-exec.c)
It's the main execution loop where the interrupt/exception is handled
, and translared TB
> /* list of TBs jumping to this one. This is a circular list using
> the two least significant bits of the pointers to tell what is
> the next pointer: 0 = jmp_next[0], 1 = jmp_next[1], 2 =
> jmp_first */
> struct TranslationBlock *jmp_next[2];
> struct Trans
On 09/22/2011 07:05 AM, Xin Tong wrote:
I am new to QEMU, can anyone please tell me where the TB chaining code is in
QEMU ?
Actually, TB chaining was implemented via TB list. You might want to look at
Exec.c
In struct TranslationBlock, the following data are used to directly call
another TB
On Sat, Jun 16, 2007 at 02:27:05PM +0100, Paul Brook wrote:
> > I read from the Qemu internal documentation this:
> > ``When MMU mappings change, only the chaining of the basic
> > blocks is reset (i.e. a basic block can no longer jump directly
> > to another one).''
> >
> > But when I
> I read from the Qemu internal documentation this:
> ``When MMU mappings change, only the chaining of the basic
> blocks is reset (i.e. a basic block can no longer jump directly
> to another one).''
>
> But when I read the code, I find that tlb_flush() doesn't reset the
> chaining betw
18 matches
Mail list logo
