On Sat, July 16, 2011 6:53 am, Gabe Black wrote: > 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. >
I determined that m5Reg is being set correctly. The problem is with the CS Flags register. In the function updateHandyM5reg(), the longMode bit of the CS Flags register is used to determine the mode in which the processor operates. This bit is off, and hence the processor runs in compatibility mode instead of running in 64-bit mode. But this sounds really surprising to me since the address that program generated is a 64-bit address, in which case I would expect the CS Flags register to have it long mode bit on. I will dig more in to why the CS Flags register is set the way it is set. Thanks Nilay _______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
