qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [Qemu-devel] ARM PC-relative Loads, and TBs in soft MMU
@ 2016-04-22 15:06 Tom Spink
  2016-04-23 12:21 ` Peter Maydell
  0 siblings, 1 reply; 3+ messages in thread
From: Tom Spink @ 2016-04-22 15:06 UTC (permalink / raw)
  To: qemu-devel

Hello,

I have a question about ARM PC-relative load instructions in softmmu 
execution, and how the PC is constant-folded at JIT compilation time 
into a TB.

I have observed in translate.c the following code:

/* Set a variable to the value of a CPU register.  */
static void load_reg_var(DisasContext *s, TCGv_i32 var, int reg)
{
     if (reg == 15) {
         uint32_t addr;
         if (s->thumb)
             addr = (long)s->pc + 2;
         else
             addr = (long)s->pc + 4;
         tcg_gen_movi_i32(var, addr);
     } else {
         tcg_gen_mov_i32(var, cpu_R[reg]);
     }
}

This constant folds the value of the PC into the TCG mov for (potential) 
use by a memory operation, but it is my understanding that this will be 
the *virtual* PC.

It is also my understanding that since TBs are physically indexed in the 
TB cache, they aren't invalidated when the guest page tables change.

So, my question is, how can a TB for a particular block containing a 
constant folded *virtual* PC work, if the MMU mappings change and a 
different virtual address is used to access the same physical address?

E.g. assume we have an instruction such as: ldr r0, [pc, #8]

If this is compiled in a block that begins at virtual address 0x10000, 
then the load will be emitted as a constant load from address 0x10008 
(and will be subject to the usual TLB lookup code).  But, if the MMU 
mappings change, and the block is entered from virtual address 0x20000 
(because 0x20000 now points to the same physical page), then the load 
will be incorrect, as it would still be accessing address 0x10000, but 
should actually be accessing address 0x20008.

Have I made any incorrect assumptions, or is there something else going 
on that I'm not aware of?

Thanks in advance for any information you can give me,
Tom

-- 
Kindest Regards,
Tom Spink

University of Edinburgh

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Qemu-devel] ARM PC-relative Loads, and TBs in soft MMU
  2016-04-22 15:06 [Qemu-devel] ARM PC-relative Loads, and TBs in soft MMU Tom Spink
@ 2016-04-23 12:21 ` Peter Maydell
  2016-04-25 11:41   ` Tom Spink
  0 siblings, 1 reply; 3+ messages in thread
From: Peter Maydell @ 2016-04-23 12:21 UTC (permalink / raw)
  To: Tom Spink; +Cc: QEMU Developers

On 22 April 2016 at 16:06, Tom Spink <t.spink@sms.ed.ac.uk> wrote:
> So, my question is, how can a TB for a particular block containing a
> constant folded *virtual* PC work, if the MMU mappings change and a
> different virtual address is used to access the same physical address?
>
> E.g. assume we have an instruction such as: ldr r0, [pc, #8]
>
> If this is compiled in a block that begins at virtual address 0x10000, then
> the load will be emitted as a constant load from address 0x10008 (and will
> be subject to the usual TLB lookup code).  But, if the MMU mappings change,
> and the block is entered from virtual address 0x20000 (because 0x20000 now
> points to the same physical page), then the load will be incorrect, as it
> would still be accessing address 0x10000, but should actually be accessing
> address 0x20008.

TBs are looked up by (virtual) PC + flags + physical address, so if
the same lump of code is mapped at two different virtual addresses
we'll translate it twice. (More precisely, tb_find_fast() checks
only the virtual address, but it does so in a cache which is
invalidated when the guest does a TLB invalidate operation; if
the cache misses we fall back to tb_find_slow() which also checks
physical address.)

thanks
-- PMM

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Qemu-devel] ARM PC-relative Loads, and TBs in soft MMU
  2016-04-23 12:21 ` Peter Maydell
@ 2016-04-25 11:41   ` Tom Spink
  0 siblings, 0 replies; 3+ messages in thread
From: Tom Spink @ 2016-04-25 11:41 UTC (permalink / raw)
  To: Peter Maydell; +Cc: QEMU Developers

On 23/04/16 13:21, Peter Maydell wrote:
> TBs are looked up by (virtual) PC + flags + physical address, so if
> the same lump of code is mapped at two different virtual addresses
> we'll translate it twice. (More precisely, tb_find_fast() checks
> only the virtual address, but it does so in a cache which is
> invalidated when the guest does a TLB invalidate operation; if
> the cache misses we fall back to tb_find_slow() which also checks
> physical address.)
>
> thanks

Thank-you very much for your explanation, and taking the time to respond.

> -- PMM

Much appreciated!

-- 
Kindest Regards,
Tom Spink

University of Edinburgh


The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2016-04-25 11:41 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-04-22 15:06 [Qemu-devel] ARM PC-relative Loads, and TBs in soft MMU Tom Spink
2016-04-23 12:21 ` Peter Maydell
2016-04-25 11:41   ` Tom Spink

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).