On 07/15/11 23:20, Nilay wrote: > On Fri, July 15, 2011 3:30 pm, Gabriel Michael Black wrote: >> Quoting Nilay Vaish <[email protected]>: >> >>> 1. If restoring from a checkpoint, does m5Reg takes the value stored >>> in the checkpoint or is it computed again from the values taken by >>> other registers? >> I don't know, but these should be equivalent. m5Reg is just a single >> place to get at some handy values so you only have to call into the >> ThreadContext once. If it's not setting them with side effects then I >> don't think the m5Reg will be updated. >> >>> 2. In 64-bit mode, should addressSize used in calculation of >>> effective address be 8? I see addressSize being set to 2. It seems >>> to me that the EFER register should be wrong in this case. But it is >>> being set to 0xD01, which means both LME and LMA are set. So, is the >>> addressSize being set correctly and I am thinking some thing wrong? >>> Or there is some thing else which is wrong, which makes addressSize >>> = 2? >> You haven't given many details, but yes, I think the address size in >> 64 bit mode is supposed to be 64 bits. Where is that not true? >> > I have created a gem5 checkpoint using checkpoint of a QEMU virtual > machine. This conversion process from a QEMU checkpoint to gem5 checkpoint > is likely to have bugs in it. The first instruction that gets executed is > the m5 checkpoint instruction (the QEMU checkpoint is created using the > same instruction as gem5). That works fine. > > The second instruction is a return from the checkpoint function (if you > recall, a ret occurs in the definition in m5op_x86.s). This instruction > needs the return address from the stack. I think EIP and the page table > point (CR3) are correctly read from QEMU cpt, since the instructions are > correctly decoded. But, when the second instruction tries to read the > stack, the translation for the address leads to a page fault. The > effective address is calculated using only the least 16 bits of the > supplied address (addressSize = 2), which is not the right thing to do. > Moreover, when I explicitly set addressSize to 8 in predecoder, the > instruction is able to find a mapping for the address it is trying to load > the return address from. > > Since the EFER register decides the mode, it seems to me that EFER is set > incorrectly. But EFER is being set to 3329, which means that LME AND LMA > are set. > > -- > Nilay > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
It sounds like you suspect the m5Reg isn't being updated correctly, and I think there's a good chance that's true. There's an updateHandyM5Reg function in isa.cc which will set m5Reg based on some other state. Ideally you'll use that, although you may need to separate it out of the ISA object so there's a function that just returns a value for other given state, and then you can have a function on the ISA object which calls that and then sets the actual register. Then you'll be able to reuse that code to set m5Reg in a checkpoint (assuming you do the conversion within gem5), through a ThreadContext, etc. Gabe _______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
