[Lguest] Loading Lguest guest - Unhandled trap 256 at x100000

[Eviatar Khen]

Well after examining the code I see that Lguest sets a default trap number
to 256 before switching to the guest.
Hence it seems that your first switch fails. I'm not sure how to debug this.
Perhaps if you'll find a way to output the registers status during the
switch.
Or, you can wait for Rusty to save the day again...


On Sat, Apr 27, 2013 at 4:59 AM, Naman Muley <naman.g.muley at gmail.com>wrote:

> Hello again,
>
> Thanks Eviatar. I have attached the the System.map and the config file
> with this email. The disassembly.txt is pretty huge, 818 Mb, hence not on
> this email. I'll upload it on dropbox and share the link for  future use of
> anyone.
>
> I tried to have the config exactly as Rusty mentions in the lguest.txt.
> But the default values of CONFIG_PHYSICAL_ALIGN and CONFIG_PHYSICAL_START
> were 0x1000000 and not 0x100000 i think. I changed them to 0x100000 as
> Rusty mentions. Could you explain what both these values do? I know that
> the new guest starts from here, but could you elaborate on that ?
>
> Thanks for all your help. I appreciate all the help
>
> Naman
>
>
> On Fri, Apr 26, 2013 at 5:18 PM, Eviatar Khen <eviatarkhen at gmail.com>wrote:
>
>> You are wrong, the interrupt was not delivered to the guest because it in
>> invalid. An unhanded interrupt makes the host crash the guest.
>> It is hard to understand something from the screenshot. dSend to the
>> mailing list the config file and the system.map.
>>
>>
>> On Sat, Apr 27, 2013 at 1:04 AM, Naman Muley <naman.g.muley at gmail.com>wrote:
>>
>>> Hey Eviatar,
>>>
>>> Thank you so much. I understand what i was doing.
>>> I've attached a screenshot of the disassembly. But i did not understand
>>> "it is very interesting to understand who generated it". how can you figure
>>> that out from the binary disassembly?
>>>
>>> Also, i did try read up on the unhandled trap, i found this:
>>> http://wiki.debian.org/Lguest
>>> and I understand why 256 is kind of odd because that interrupt number is
>>> not covered by the host and so we send it as a valid number to the guest.
>>> But the guest doesnt know how to handle this one.
>>> But i have no idea what is causing this and how to remove this.
>>>
>>> Any idea?
>>>
>>> Naman
>>>
>>>
>>> On Fri, Apr 26, 2013 at 4:33 PM, Eviatar Khen <eviatarkhen at gmail.com>wrote:
>>>
>>>>  Hi Naman,
>>>>
>>>> I think what Ron meant was to disassembly of the kernel's image
>>>> (vmlinux), not the Lguest binary (which is user space and does not generate
>>>> directly interrupts).
>>>> The guest crashes because the host got an invalid interrupt number, and
>>>> it is very interesting to understand who generated it.
>>>>
>>>> Good luck,
>>>>
>>>> Eviatar
>>>>
>>>>
>>>> On 04/26/2013 08:34 PM, Naman Muley wrote:
>>>>
>>>> Hey Ron,
>>>>
>>>>  Thanks for reaching out. I did the following( i am not sure if that's
>>>> what you wanted me to do) :
>>>>
>>>>  objdump -D -b binary -m i386 Documentation/virtual/lguest/lguest  >
>>>> /home/ngm7/disassembly.txt
>>>> Following is the screenshot: Does that make sense ?
>>>>
>>>>  I had to take a screenshot because the disassembly.txt is inside the
>>>> virtual machine. I'm working on ways to get that file out of the virtual
>>>> machine.
>>>>
>>>> NOTE: the last line in the file was 6a1d. In the meanwhile, if you want
>>>> to look at any specific line, let me know.
>>>> I apologize for the raw kind of feedback.
>>>>
>>>>  Naman
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Apr 26, 2013 at 11:45 AM, ron minnich <rminnich at gmail.com>wrote:
>>>>
>>>>> you might want to do a quick disassembly of the binary to see what's
>>>>> at 0x100000. The 256 is (to me) kind of odd. So what's the start of
>>>>> that image look like? Sorry, I'm rusty on lguest (i.e. I'm not Rusty)
>>>>> so I'm not going to be as useful. But I would be curious to see the
>>>>> disassembly.
>>>>>
>>>>> ron
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Lguest mailing listLguest at lists.ozlabs.orghttps://lists.ozlabs.org/listinfo/lguest
>>>>
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/lguest/attachments/20130427/5299eeaa/attachment.html>