Re:Another related question Re: [Qemu-devel] Question about softmmu

Re:Another related question Re: [Qemu-devel] Question about softmmu

[olivier cozette]

  Hello Ye,


>So EIP is just the offset of current instruction.

Yes

>When address mapping changes,
>the CS segment register also changes.

No.
The virtual adress is CS+EIP (CS.Base+EIP), this virtual address is translated
to the physical address with the page mapping. In pseudo code, the real address
is PAGE_MAPPING(CS+EIP). So, if the page mapping change the CS stay the same.

>That's why QEMU does not need to flush
>the code. Am I right?


>The reason I'm thinking about this is because I'm implementing QEMU's
>translation method in my ARM simulator which needs to simulate the whole system
>running Linux. In ARM, since PC is just r15, you can access it as a normal
>register and it is the absolute virtual address. So I wonder if I have to flush
>code cache every time page table changes.

I don't know well ARM processor, but i know Alpha, and it's different from the
x86.

With x86, the data stored in the data/code cache are stored with the physical
address (page mapping is done between processor and cache), and so the cache
don't need to be flushed when page mapping change (CR3 change).

With alpha (and probably arm), the address stored in cache are the virtual
address (page mapping is done between cache and memory).

But, i presume this difference have no impact with Qemu cache, and it will be
better to don't flush qemu cache.



   Olivier


Thanks,
Ye

Re:Another related question Re: [Qemu-devel] Question about softmmu

[olivier cozette]

  Hello Ye,


>So EIP is just the offset of current instruction.

Yes

>When address mapping changes,
>the CS segment register also changes.

No.
The virtual adress is CS+EIP (CS.Base+EIP), this virtual address is translated
to the physical address with the page mapping. In pseudo code, the real address
is PAGE_MAPPING(CS+EIP). So, if the page mapping change the CS stay the same.

>That's why QEMU does not need to flush
>the code. Am I right?


>The reason I'm thinking about this is because I'm implementing QEMU's
>translation method in my ARM simulator which needs to simulate the whole system
>running Linux. In ARM, since PC is just r15, you can access it as a normal
>register and it is the absolute virtual address. So I wonder if I have to flush
>code cache every time page table changes.

I don't know well ARM processor, but i know Alpha, and it's different from the
x86.

With x86, the data stored in the data/code cache are stored with the physical
address (page mapping is done between processor and cache), and so the cache
don't need to be flushed when page mapping change (CR3 change).

With alpha (and probably arm), the address stored in cache are the virtual
address (page mapping is done between cache and memory).

But, i presume this difference have no impact with Qemu cache, and it will be
better to don't flush qemu cache.



   Olivier


Thanks,
Ye

Re:Another related question Re: [Qemu-devel] Question about softmmu

[Ye Wen]

Hi, Olivier:

Actually I'm thinking of a special case:
1. A basic block is translated and the PC value patched in is
   the virtual address when it is translated. At this time,
   the address mapping is virtual page 0 -> physical page 0
2. Now the mapping changes. virtual page 1 -> physical page 0,
   which means the physical location of the block doesn't change
   but its virtual address changes.
3. Since page table changes, the virtual pc hash flushed. But we
   still can find the block using physical hash.
4. Now the block is executed again. But since the embedded pc value
   is still the old value, will this cause problem?

Sorry to bother you again. But I'm really confused.

Thanks,
Ye
Quoting olivier cozette <olivier.cozette@u-picardie.fr>:

>   Hello Ye,
>
>
> >So EIP is just the offset of current instruction.
>
> Yes
>
> >When address mapping changes,
> >the CS segment register also changes.
>
> No.
> The virtual adress is CS+EIP (CS.Base+EIP), this virtual address is
> translated
> to the physical address with the page mapping. In pseudo code, the real
> address
> is PAGE_MAPPING(CS+EIP). So, if the page mapping change the CS stay the same.
>
> >That's why QEMU does not need to flush
> >the code. Am I right?
>
>
> >The reason I'm thinking about this is because I'm implementing QEMU's
> >translation method in my ARM simulator which needs to simulate the whole
> system
> >running Linux. In ARM, since PC is just r15, you can access it as a normal
> >register and it is the absolute virtual address. So I wonder if I have to
> flush
> >code cache every time page table changes.
>
> I don't know well ARM processor, but i know Alpha, and it's different from
> the
> x86.
>
> With x86, the data stored in the data/code cache are stored with the physical
> address (page mapping is done between processor and cache), and so the cache
> don't need to be flushed when page mapping change (CR3 change).
>
> With alpha (and probably arm), the address stored in cache are the virtual
> address (page mapping is done between cache and memory).
>
> But, i presume this difference have no impact with Qemu cache, and it will be
> better to don't flush qemu cache.
>
>
>
>    Olivier
>
>
> Thanks,
> Ye
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>


--
Ye Wen
wen@umail.ucsb.edu

RE : Another related question Re: [Qemu-devel] Question about softmmu

[Olivier Cozette]

	I Ye,


I understand your problem, but in this case, you must change the mapping and
so you must send this change to the processor (access special memory,
explicitly invalidate one page), so the page is flushed
(tlb_flush_page/exec.c) and all tb in this page are invalidate
(tb_invalidate/exec.c). So tb_invalidate delete all tb that call this tb.
This function deletes all jmp to this tb. 

So, in my opinion, you problem won't occur.


	Olivier


>Actually I'm thinking of a special case:
>1. A basic block is translated and the PC value patched in is
>   the virtual address when it is translated. At this time,
>   the address mapping is virtual page 0 -> physical page 0
>2. Now the mapping changes. virtual page 1 -> physical page 0,
>   which means the physical location of the block doesn't change
>   but its virtual address changes.
>3. Since page table changes, the virtual pc hash flushed. But we
>   still can find the block using physical hash.
>4. Now the block is executed again. But since the embedded pc value
>   is still the old value, will this cause problem?

Re:Another related question Re: [Qemu-devel] Question about softmmu

[Olivier Cozette]

  Hello Ye,

First, I will describe the memory access. All access to memory from the CPU,
data access or load instruction access cross the TLB (Translation Look aside
Buffer), the TLB convert the virtual address to the real address (it's a
cache of the page mapping), so only the real address go to the memory
subsystem or the cache. Note that the TLB are only flushed when you change
CR3 value or if you use INVLPG instruction.

               
-------       
| Proc|
------->=====>-------------
              |  TLB      |
              ------------->=======\/
						--------------
                                   | Cache/Memory|
                                   ---------------

With i386, the only to get the pc (eip register) is to use the CALL
instruction, this instruction store the virtual next PC (eip) and so if the
mapping change, the next PC change.

With Qemu in target-i386/translate.c you have this code :

    case 2: /* call Ev */
            /* XXX: optimize if memory (no 'and' is necessary) */
            if (s->dflag == 0)
                gen_op_andl_T0_ffff();
            next_eip = s->pc - s->cs_base;
            gen_op_movl_T1_im(next_eip);
            gen_push_T1(s);
            gen_op_jmp_T0();
            gen_eob(s);
            break;

              


Olivier

Re:Another related question Re: [Qemu-devel] Question about softmmu

[Ye Wen]

Thanks for your reply, Olivier.

So EIP is just the offset of current instruction. When address mapping changes,
the CS segment register also changes. That's why QEMU does not need to flush
the code. Am I right?

The reason I'm thinking about this is because I'm implementing QEMU's
translation method in my ARM simulator which needs to simulate the whole system
running Linux. In ARM, since PC is just r15, you can access it as a normal
register and it is the absolute virtual address. So I wonder if I have to flush
code cache every time page table changes.

Thanks,
Ye
Quoting Olivier Cozette <olivier.cozette@u-picardie.fr>:

>
>   Hello Ye,
>
> First, I will describe the memory access. All access to memory from the CPU,
> data access or load instruction access cross the TLB (Translation Look aside
> Buffer), the TLB convert the virtual address to the real address (it's a
> cache of the page mapping), so only the real address go to the memory
> subsystem or the cache. Note that the TLB are only flushed when you change
> CR3 value or if you use INVLPG instruction.
>
>
> -------
> | Proc|
> ------->=====>-------------
>               |  TLB      |
>               ------------->=======\/
> 						--------------
>                                    | Cache/Memory|
>                                    ---------------
>
> With i386, the only to get the pc (eip register) is to use the CALL
> instruction, this instruction store the virtual next PC (eip) and so if the
> mapping change, the next PC change.
>
> With Qemu in target-i386/translate.c you have this code :
>
>     case 2: /* call Ev */
>             /* XXX: optimize if memory (no 'and' is necessary) */
>             if (s->dflag == 0)
>                 gen_op_andl_T0_ffff();
>             next_eip = s->pc - s->cs_base;
>             gen_op_movl_T1_im(next_eip);
>             gen_push_T1(s);
>             gen_op_jmp_T0();
>             gen_eob(s);
>             break;
>
>
>
>
> Olivier
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>


--
Ye Wen
wen@umail.ucsb.edu