[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.