|
|
|
|
|
|
|
|
|
|
xen-devel
RE: [Xen-devel] Re: [PATCH] FP instruction in realmode emulation
Hi Keir and Nitin,
We have tried the HVM booting with base kernel on #16971. There
isn't problem.
Best Regards,
Yongkang You
I eyeballed the problem. Please try c/s
16971.
Thanks, Keir
On 1/2/08 19:14, "Kamble, Nitin
A" <nitin.a.kamble@xxxxxxxxx> wrote:
Hi
Keir, Here is the call trace. (XEN) HVM2: Press F10
to select boot device. (XEN) HVM2: Booting from Hard Disk... (XEN) HVM2:
int13_harddisk: function 41, unmapped device for ELDL=81 (XEN) HVM2:
int13_harddisk: function 08, unmapped device for ELDL=81 (XEN) HVM2: ***
int 15h function AX=00C0, BX=0000 not yet supported! (XEN) Xen BUG at
traps.c:2624 (XEN) ----[ Xen-3.3-unstable x86_32p debug=n Not
tainted ]---- (XEN) CPU: 1 (XEN) EIP:
e008:[<ff138be2>]
do_device_not_available+0x22/0xc0 (XEN) EFLAGS: 00010202
CONTEXT: hypervisor (XEN) eax: ff1e3fb4 ebx:
ff238080 ecx: 0000e010 edx: ff1e3b44 (XEN) esi: ff1e3b44
edi: 0000e010 ebp: 00000002 esp:
ff1e3b20 (XEN) cr0: 8005003b cr4: 000026f0 cr3: 2bed3000
cr2: 00000000 (XEN) ds: e010 es: e010
fs: 0000 gs: 0000 ss: e010 cs:
e008 (XEN) Xen stack trace from esp=ff1e3b20: (XEN)
00000000 00000002 00000002 ff1674f1 00000002 ff238080
0000e010 ff1874b3 (XEN) ff1e3b44 000000db 00000002
ff1678e0 00000000 ff1e3ed0 00000002 ff238000 (XEN)
00070000 ff14090c 0000e008 00010246 ff1e3ed0 ff1e3d34
00000000 00000001 (XEN) ff1e3ed0 ff1e3ed0 00000000
00011e32 ff1cd080 ffbf8080 ffe38000 ff1505a2 (XEN)
ff1e3fb4 ff1e3fb4 05117067 ff1e3fb4 ff1e3fb4 ff1e3fb4
ff1e3fb4 ff1e3fb4 (XEN) 05117067 80000000 00000004
ff1e3de0 ff1e3edc 00000000 00000004 00000002 (XEN)
00000000 00000000 00000044 00000001 ff1e3e04 00000000
ff1e3edc 00000086 (XEN) 00000020 ff1c4080 00000000
00000000 00000020 00000002 9000f000 00053493 (XEN)
00000001 00004477 d0567b2d ff1e3fb4 ff12b711 00000001
00000001 4200442e (XEN) 00000000 ff1cd080 00000002
00000286 00000000 00000000 00000400 e3000000 (XEN)
00000003 00000000 00000286 00000000 00000004 00000000
00000004 ff1cd080 (XEN) ffbf8003 00000002 ff238d40
00000000 ff1cd080 00000000 ff238080 00000002 (XEN)
00000000 00000000 ffffffff ff12cff2 ff238080 0002baf6
00000000 00000001 (XEN) 00000000 fed40f00 00000000
fffffffe 00000001 00000000 000000db 00000001 (XEN)
0000ac01 00000000 00009038 00000000 00008f98 00000000
00001fd6 ff1676a0 (XEN) ff1676a0 ff1676a0 ff1676a0
ff1676a0 00000001 00000002 ffffffff 00009fc0 (XEN)
f6c18710 fe0004f8 ff23e080 00000002 f6c18710 00009000
00000000 00000246 (XEN) 0041fbf8 00002948 00008fd8
00000010 00b80002 0000075d 00000000 00000246 (XEN)
00008f98 00000000 00000000 00000000 00000000 00000000
00939000 0000ffff (XEN) 00090000 00000000 ff1e3d34
ff1e3d3c ff1e3d38 ff1e3d4c 00000001 00000002 (XEN) Xen call trace: (XEN)
[<ff138be2>]
do_device_not_available+0x22/0xc0 (XEN)
[<ff1674f1>] realmode_emulate_write+0x41/0xd0 (XEN)
[<ff1874b3>] handle_exception+0x73/0xa7 (XEN)
[<ff1678e0>] realmode_load_fpu_ctxt+0x0/0x30 (XEN)
[<ff14090c>] x86_emulate+0x421c/0x9280 (XEN)
[<ff1505a2>] hvm_mmio_intercept+0xe2/0x420 (XEN)
[<ff12b711>] get_page+0x41/0x100 (XEN)
[<ff12cff2>] get_page_type+0x6e2/0x890 (XEN)
[<ff1676a0>] realmode_emulate_read+0x0/0x30 (XEN)
[<ff1676a0>] realmode_emulate_read+0x0/0x30 (XEN)
[<ff1676a0>] realmode_emulate_read+0x0/0x30 (XEN)
[<ff1676a0>] realmode_emulate_read+0x0/0x30 (XEN)
[<ff1676a0>] realmode_emulate_read+0x0/0x30 (XEN)
[<ff120a2e>] __find_next_zero_bit+0x7e/0x90 (XEN)
[<ff186c97>] map_domain_page+0x97/0x200 (XEN)
[<ff1ae000>] bogus_saved_magic+0x246/0x1016 (XEN)
[<ff14c6a8>] __hvm_copy+0x88/0x290 (XEN)
[<ff151416>]
hvm_io_assist+0xb6/0x12b0
Thanks & Regards, Nitin Linux Open
Source Technology Center, Intel
Corporation -------------------------------------------------------------------------------- The
Mind is like a parachute; it works much better when it's
open. >-----Original Message----- >From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx] >Sent:
Friday, February 01, 2008 12:48 AM >To: Kamble, Nitin A >Cc:
xen-devel@xxxxxxxxxxxxxxxxxxx >Subject: Re: [PATCH] FP instruction in
realmode emulation > >I am surprised we get there: when emulating
FPU instructions we first call >the ->load_fpu_ctxt hook, which calls
vmx_do_no_device_fault() -> >setup_fpu() -> clts(). Obviously
there is something going wrong though... >can you provide a
backtrace? > >Whatever the problem is, bear in mind that we
should never take a FPU fault >from within Xen and if we do that is a
bug in itself. > > -- Keir > >On 1/2/08 00:12,
"Nitin A Kamble" <nitin.a.kamble@xxxxxxxxx> wrote: > >>
Hi Keir, >> Our QA team also found that the latest base
kernel was failing on the >> new real mode emulation code. I looked
into it, and found out the >> culprit to be guest_mode() call in the
do_device_not_available handler. >> This guest_mode()
check over there is no more correct as the guest may >> run in
hypervisor context in the form of emulation. The attached patch >>
fixes this issue by removing the check. Another fix would be
modifying >> the guest_mode() macro. What do you think, Is this check
is needed there >> now ? >> >> Signed-off-By:
Nitin A Kamble <nitin.a.kamble@xxxxxxxxx> >> >
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|