[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] CPUTLBEntry Question
From: |
Ryan Riley |
Subject: |
[Qemu-devel] CPUTLBEntry Question |
Date: |
Wed, 13 Jun 2007 16:25:07 -0400 |
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
- [Qemu-devel] CPUTLBEntry Question,
Ryan Riley <=