[Qemu-devel] CPUTLBEntry Question

[Qemu-devel] CPUTLBEntry Question

[Ryan Riley]

I'm making some small changes to the TLB stuff in QEMU 0.9.0
(specifically, I'm only working with i386-softmmu) and have run into
an odd question I'm hoping someone can answer for me.  The CPUTLBEntry
structure definition in cpu-defs.h looks like this...

typedef struct CPUTLBEntry {
    /* bit 31 to TARGET_PAGE_BITS : virtual address
       bit TARGET_PAGE_BITS-1..IO_MEM_SHIFT : if non zero, memory io
                                              zone number
       bit 3                      : indicates that the entry is invalid
       bit 2..0                   : zero
    */
    target_ulong addr_read;
    target_ulong addr_write;
    target_ulong addr_code;
    /* addend to virtual address to get physical address */
    target_phys_addr_t addend;
} CPUTLBEntry;

If I change it to add another member, like so..

typedef struct CPUTLBEntry {
    /* bit 31 to TARGET_PAGE_BITS : virtual address
       bit TARGET_PAGE_BITS-1..IO_MEM_SHIFT : if non zero, memory io
                                              zone number
       bit 3                      : indicates that the entry is invalid
       bit 2..0                   : zero
    */
    target_ulong addr_read;
    target_ulong addr_write;
    target_ulong addr_code;
    /* addend to virtual address to get physical address */
    target_phys_addr_t addend;
    /* New member */
    target_phys_addr_t blah;
} CPUTLBEntry;

then QEMU crashes on startup.  (It also crashes if I put that blah
entry on the beginning instead of the end.)  I'm sure there's code
somewhere that must be making assumptions about the size of TLB entry,
but I'm at a loss for finding it.  (I have noticed that the assembly
code in softmmu_header.h indexes to the addend based on addr_read or
addr_write, but adding a new member to the end of the structure
shouldn't impact that, right?)

If anyone has any insight, I would be very appreciative.

Thanks
Ryan

Re: [Qemu-devel] CPUTLBEntry Question

[Paul Brook]

> then QEMU crashes on startup.  (It also crashes if I put that blah
> entry on the beginning instead of the end.)  I'm sure there's code
> somewhere that must be making assumptions about the size of TLB entry,
> but I'm at a loss for finding it.  (I have noticed that the assembly
> code in softmmu_header.h indexes to the addend based on addr_read or
> addr_write, but adding a new member to the end of the structure
> shouldn't impact that, right?)

Wrong. The assembly implementation assumes CPUTLBEntry is 16 bytes (or to be 
exact 1 << CPU_TLB_ENTRY_BITS).

The C implementation in softmmu_header.h will work with any layout.

Paul

Re: [Qemu-devel] CPUTLBEntry Question

[Ryan Riley]

On 6/14/07, Paul Brook <paul@codesourcery.com> wrote:
> > then QEMU crashes on startup.  (It also crashes if I put that blah
> > entry on the beginning instead of the end.)  I'm sure there's code
> > somewhere that must be making assumptions about the size of TLB entry,
> > but I'm at a loss for finding it.  (I have noticed that the assembly
> > code in softmmu_header.h indexes to the addend based on addr_read or
> > addr_write, but adding a new member to the end of the structure
> > shouldn't impact that, right?)
>
> Wrong. The assembly implementation assumes CPUTLBEntry is 16 bytes (or to be
> exact 1 << CPU_TLB_ENTRY_BITS).
>
> The C implementation in softmmu_header.h will work with any layout.
>
> Paul
>

That fixed/answered everything for me.  Thanks for your help, everyone.

Thanks
Ryan

Re: [Qemu-devel] CPUTLBEntry Question

[amateur]

On Wed, Jun 13, 2007 at 04:25:07PM -0400, Ryan Riley wrote:
> typedef struct CPUTLBEntry {
>    /* bit 31 to TARGET_PAGE_BITS : virtual address
>       bit TARGET_PAGE_BITS-1..IO_MEM_SHIFT : if non zero, memory io
>                                              zone number
>       bit 3                      : indicates that the entry is invalid
>       bit 2..0                   : zero
>    */
>    target_ulong addr_read;
>    target_ulong addr_write;
>    target_ulong addr_code;
>    /* addend to virtual address to get physical address */
>    target_phys_addr_t addend;
> } CPUTLBEntry;
> 
> If I change it to add another member, like so..
> 
> typedef struct CPUTLBEntry {
>    /* New member */
>    target_phys_addr_t blah;
> } CPUTLBEntry;
> 
> then QEMU crashes on startup.  (It also crashes if I put that blah
> entry on the beginning instead of the end.)  I'm sure there's code
> somewhere that must be making assumptions about the size of TLB entry,
> but I'm at a loss for finding it.  (I have noticed that the assembly
> code in softmmu_header.h indexes to the addend based on addr_read or
> addr_write, but adding a new member to the end of the structure
> shouldn't impact that, right?)
-------------------------
The softmmu_header.h code does assume each TLB entry has a fixed size
of (2^CPU_TLB_ENTRY_BITS) bytes. Not only the assembly code, but also
the C code assume this. So if you want to add new members into
CPUTLBEntry, add the new member at the end of the data structure, and
adjust CPU_TLB_ENTRY_BITS accordingly.

Best Regards
Tianlei Zhao

-- 
Don't look back, the lemmings are gaining on you.

Re: [Qemu-devel] CPUTLBEntry Question

[Blue Swirl]

On 6/14/07, amateur <tianlei.zhao@gmail.com> wrote:
> The softmmu_header.h code does assume each TLB entry has a fixed size
> of (2^CPU_TLB_ENTRY_BITS) bytes. Not only the assembly code, but also
> the C code assume this. So if you want to add new members into
> CPUTLBEntry, add the new member at the end of the data structure, and
> adjust CPU_TLB_ENTRY_BITS accordingly.

No, on Sparc32 target_ulong is 32 bits (on 32-bit host) but
target_phys_addr_t is 64 bits. That makes the structure size 20 bytes.
Everything still works.

Re: [Qemu-devel] CPUTLBEntry Question

[amateur]

On Thu, Jun 14, 2007 at 05:00:32PM +0300, Blue Swirl wrote:
> On 6/14/07, amateur <tianlei.zhao@gmail.com> wrote:
> >The softmmu_header.h code does assume each TLB entry has a fixed size
> >of (2^CPU_TLB_ENTRY_BITS) bytes. Not only the assembly code, but also
> >the C code assume this. So if you want to add new members into
> >CPUTLBEntry, add the new member at the end of the data structure, and
> >adjust CPU_TLB_ENTRY_BITS accordingly.
> 
> No, on Sparc32 target_ulong is 32 bits (on 32-bit host) but
> target_phys_addr_t is 64 bits. That makes the structure size 20 bytes.
> Everything still works.
-------------------------
Oh, yes. It's my fault. I confused CPU_TLB_SIZE and
CPU_TLB_ENTRY_BITS. Paul Brook is right. The C code works with any
CPUTLBEntry layout.

-- 
^[[32m题目:《村行》^[[m
^[[33m作者:王禹称（繁体“称”，换“亻”旁）（９５４－１００１）^[[m
马穿山径菊初黄，信马悠悠野兴长。
万壑有声含晚籁，数峰无语立斜阳。
棠梨叶落胭脂色，荞麦花开白雪香。
何事吟余忽惆怅，村桥原树似吾乡。