I printed out the instruction trace by enabling TRACE_RIP. I've found that when xen is running inside of marss, all instructions in Dom0 Linux kernel space is printed as "kernel: 0", and all xen instructions are printed as "kernel: 1". But in a non-virtualized environment, kernel instructions should be printed as "kernel: 1". This may due to the modified privilege level (cs register) in xen environments. I am wondering if this will affect the instructions decoding procedure in ptlsim.
I tried to look up the instruction where assertion is triggered (the last instruction rip in the ptl_rip_trace file). I found that the rip is pointing to an incorrect address, which is in between of two valid instruction addresses. I think this may be the reason of the assertion failure. Does anyone have any suggestions how should I proceed to further diagnosis this problem? Any suggestions would be appreciated. Thanks. Xin On Wed, Apr 17, 2013 at 4:02 PM, Xin Xu <[email protected]> wrote: > I tried to use -snapshot on a clean image file. But I still see assertion > failures. I found that it seems the assertion failures usually occur when > xen DomU is running some tasks. If the DomU is idle, the simulation seems > be to fine. So I guess that it is not the simulation corrupting the image > file. > > I am relatively new on marss. I am wondering how should I find out where > is the problem. Is that possible that there are some instructions that are > not correctly handled in the simulation mode? > > Thank you > > > On Tue, Apr 16, 2013 at 11:50 AM, Xin Xu <[email protected]> wrote: > >> I see. Sorry for misunderstanding. I will try that and update results >> here. Thanks for you suggestion. >> >> >> On Tue, Apr 16, 2013 at 11:46 AM, Paul Rosenfeld <[email protected]>wrote: >> >>> What I meant was that if the first time you run the simulation it works >>> fine but on subsequent runs it errors out, then this might be an indication >>> that the simulation is corrupting your image. However, if the simulation >>> errors out on a fresh disk image (no simulations previously run on it), >>> then it might be an indication that something else is wrong. >>> >>> But either way, I think the -snapshot argument is a good precaution. >>> >>> >>> On Tue, Apr 16, 2013 at 11:41 AM, Xin Xu <[email protected]> wrote: >>> >>>> Hi Paul, >>>> >>>> The error occurs when after simulation mode is started, it seems that >>>> the Assertion `ctx.page_fault_addr != 0' failure occur very soon after >>>> the simulation starts. The output shows that >>>> >>>> Completed 0 cycles, 0 commits: 0 Hz, >>>> 0 insns/sec >>>> >>>> But for the Assertion `physreg->data' failure, there are some >>>> instructions are committed: >>>> >>>> Completed 351000 cycles, 225581 commits: 420941 Hz, >>>> 266862 insns/sec >>>> >>>> I will try snapshot parameter when run simulations. >>>> >>>> By the way, apparently the rootsize=60GB is too large for >>>> ubuntu-vm-builder, it always produce an image with 5GB space. I now changed >>>> it to 20GB. The produced image is in correct size now. I will do further >>>> test to see if this can change the situation. >>>> >>>> Thanks >>>> >>>> >>>> >>>> On Tue, Apr 16, 2013 at 11:27 AM, Paul Rosenfeld >>>> <[email protected]>wrote: >>>> >>>>> Sorry, forgot to reply all. >>>>> >>>>> Does the error happen on the very first time you try to run a disk >>>>> image or is it intermittent? >>>>> >>>>> I'd recommend you add the -snapshot option when you are planning on >>>>> running simulation. This will throw away any changes to the disk that >>>>> happen during your session when the simulation ends and hopefully make the >>>>> corruption go away. >>>>> >>>>> >>>>> On Tue, Apr 16, 2013 at 11:24 AM, Xin Xu <[email protected]>wrote: >>>>> >>>>>> Hi Paul, >>>>>> >>>>>> Thanks for your reply. Here is the command, >>>>>> >>>>>> qemu/qemu-system-x86_64 -m 4096 -hda tmpDSQFvf.qcow2 -net >>>>>> nic,model=ne2k_pci -net user >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Apr 16, 2013 at 11:21 AM, Paul Rosenfeld < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> What is the command are you using to start marss (specifically, are >>>>>>> you using the -snapshot option)? >>>>>>> >>>>>>> >>>>>>> On Mon, Apr 15, 2013 at 2:58 PM, Xin Xu <[email protected]>wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I am trying to set up a customized image with xen hypervisor using >>>>>>>> the ubuntu-vm-builder tool. I follow the instructions in this page >>>>>>>> http://marss86.org/~marss86/index.php/Custom_Disk_Images >>>>>>>> and create a precise 12.04 ubuntu image with default disk size 4GB. >>>>>>>> This image can be correctly loaded and executed within the marssx86 in >>>>>>>> emulation mode. However, once I start the simulation mode using these >>>>>>>> commands >>>>>>>> >>>>>>>> simconfig -machine xeon_single_core >>>>>>>> simconfig -run -stopinsns 10m -stats output.log >>>>>>>> >>>>>>>> after certain numbers of instructions, the simulation breaks with >>>>>>>> assertion failures. I observed two types of assertions: >>>>>>>> >>>>>>>> Assertion `ctx.page_fault_addr != 0' failed >>>>>>>> Assertion `physreg->data' failed >>>>>>>> >>>>>>>> >>>>>>>> I searched in the mailing list, it seems that the problem is caused >>>>>>>> by the corrupted images. I create several images with 12.04 and 11.10. >>>>>>>> They >>>>>>>> all have the same problem. I am not sure where is the problem. >>>>>>>> >>>>>>>> One thing I would like to mention is even if I specify the rootsize >>>>>>>> in the config file of ubuntu-vm-builder to other sizes such as >>>>>>>> 60gb/40gb, >>>>>>>> but the created image is always 4gb. I am not sure if this is related >>>>>>>> or >>>>>>>> not. >>>>>>>> >>>>>>>> I also tried the raw format image that created by virtualbox, the >>>>>>>> problem is same. The emulation part is OK even if an application is >>>>>>>> running >>>>>>>> in domu, but the simulation always breaks. >>>>>>>> >>>>>>>> Any suggestions would be appreciated. Thanks >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> http://www.marss86.org >>>>>>>> Marss86-Devel mailing list >>>>>>>> [email protected] >>>>>>>> https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
_______________________________________________ http://www.marss86.org Marss86-Devel mailing list [email protected] https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
