[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] CPUTLBEntry Question

From: amateur
Subject: Re: [Qemu-devel] CPUTLBEntry Question
Date: Thu, 14 Jun 2007 21:41:36 +0800
User-agent: Mutt/1.5.13 (2006-08-11)

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]