thr3ads.net - Xen devel - [Xen-devel] [PATCH] guest MSR access in the realmode emulation [Jan 2008]

If this information is useful, please help other people find it:
Share via:

Nitin A Kamble

2008-Jan-31 01:58 UTC

[Xen-devel] [PATCH] guest MSR access in the realmode emulation

Hi Keir,
  Our QA guys found out that SMP windows guest was not booting with the
new realmode code. I looked into it and found out the realmode msr
access is missing from the new realmode code.	
   Attached is the patch to implement the MSR access in the new realmode
emulation code.

Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>

-- 
Thanks & Regards,
Nitin
Open Source Technology Center, Intel Corporation
-----------------------------------------------------------------
The mind is like a parachute; it works much better when it''s open



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser

2008-Jan-31 09:34 UTC

head link

[Xen-devel] Re: [PATCH] guest MSR access in the realmode emulation

You can''t directly access the physical EFER. I''ve modified the
patch to go
via the intercept routines in vmx.c and checked it in.

 Thanks,
 Keir

On 31/1/08 01:58, "Nitin A Kamble" <nitin.a.kamble@intel.com>
wrote:
> Hi Keir,
>   Our QA guys found out that SMP windows guest was not booting with the
> new realmode code. I looked into it and found out the realmode msr
> access is missing from the new realmode code. 
>    Attached is the patch to implement the MSR access in the new realmode
> emulation code.
> 
> Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Kamble, Nitin A

2008-Jan-31 20:56 UTC

head link

[Xen-devel] RE: [PATCH] guest MSR access in the realmode emulation

That''s right, I realized it later on. I was planning to change it the
same way.

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@cl.cam.ac.uk]
>Sent: Thursday, January 31, 2008 1:34 AM
>To: Kamble, Nitin A
>Cc: xen-devel@lists.xensource.com
>Subject: Re: [PATCH] guest MSR access in the realmode emulation
>
>You can''t directly access the physical EFER. I''ve modified
the patch to
go>via the intercept routines in vmx.c and checked it in.
>
> Thanks,
> Keir
>
>On 31/1/08 01:58, "Nitin A Kamble"
<nitin.a.kamble@intel.com> wrote:
>
>> Hi Keir,
>>   Our QA guys found out that SMP windows guest was not booting with
the>> new realmode code. I looked into it and found out the realmode msr
>> access is missing from the new realmode code.
>>    Attached is the patch to implement the MSR access in the new
realmode>> emulation code.
>>
>> Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Nitin A Kamble

2008-Feb-01 00:12 UTC

head link

[Xen-devel] [PATCH] FP instruction in realmode emulation

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@intel.com>
   
-- 
Thanks & Regards,
Nitin
Open Source Technology Center, Intel Corporation
-----------------------------------------------------------------
The mind is like a parachute; it works much better when it''s open



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser

2008-Feb-01 08:47 UTC

head link

[Xen-devel] 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@intel.com>
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@intel.com>
>    

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Kamble, Nitin A

2008-Feb-01 19:14 UTC

head link

[Xen-devel] RE: [PATCH] FP instruction in realmode emulation

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@cl.cam.ac.uk]
>Sent: Friday, February 01, 2008 12:48 AM
>To: Kamble, Nitin A
>Cc: xen-devel@lists.xensource.com
>Subject: Re: [PATCH] FP instruction in realmode emulation
> 
>I am surprised we get there: when emulating FPU instructions we firstcall
>the ->load_fpu_ctxt hook, which calls vmx_do_no_device_fault() ->
>setup_fpu() -> clts(). Obviously there is something going wrongthough...
>can you provide a backtrace?
> 
>Whatever the problem is, bear in mind that we should never take a FPUfault
>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@intel.com>
wrote:
> 
>> Hi Keir,
>>   Our QA team also found that the latest base kernel was failing onthe
>> new real mode emulation code. I looked into it, and found out the
>> culprit to be guest_mode() call in the do_device_not_availablehandler.
>>   This guest_mode() check over there is no more correct as the guestmay
>> run in hypervisor context in the form of emulation. The attachedpatch
>> fixes this issue by removing the check. Another fix would bemodifying
>> the guest_mode() macro. What do you think, Is this check is neededthere
>> now ?
>> 
>> Signed-off-By: Nitin A Kamble <nitin.a.kamble@intel.com>
>> 
> 
 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser

2008-Feb-02 10:29 UTC

head link

[Xen-devel] Re: [PATCH] FP instruction in realmode emulation

Can you get a backtrace from a debug build? It looks like
realmode_load_fpu_ctxt() is taking a fault, but it¹s hard to be certain
because there¹s a lot of chaff in the backtrace.

 -- Keir

On 1/2/08 19:14, "Kamble, Nitin A" <nitin.a.kamble@intel.com>
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@cl.cam.ac.uk]
>> >Sent: Friday, February 01, 2008 12:48 AM
>> >To: Kamble, Nitin A
>> >Cc: xen-devel@lists.xensource.com
>> >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@intel.com> 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@intel.com>
>>> >> 
>> > 
>  
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser

2008-Feb-03 10:32 UTC

head link

[Xen-devel] Re: [PATCH] FP instruction in realmode emulation

I eyeballed the problem. Please try c/s 16971.

 Thanks,
 Keir

On 1/2/08 19:14, "Kamble, Nitin A" <nitin.a.kamble@intel.com>
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@cl.cam.ac.uk]
>> >Sent: Friday, February 01, 2008 12:48 AM
>> >To: Kamble, Nitin A
>> >Cc: xen-devel@lists.xensource.com
>> >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@intel.com> 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@intel.com>
>>> >> 
>> > 
>  
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

You, Yongkang

2008-Feb-04 09:00 UTC

head link

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
 

________________________________

From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Keir Fraser
Sent: Sunday, February 03, 2008 6:32 PM
To: Kamble, Nitin A
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] Re: [PATCH] FP instruction in realmode emulation


I eyeballed the problem. Please try c/s 16971.

 Thanks,
 Keir

On 1/2/08 19:14, "Kamble, Nitin A" <nitin.a.kamble@intel.com>
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@cl.cam.ac.uk]
	>Sent: Friday, February 01, 2008 12:48 AM
	>To: Kamble, Nitin A
	>Cc: xen-devel@lists.xensource.com
	>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@intel.com> 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@intel.com>
	>> 
	> 
	 
	
	





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Xen devel - Jan 2008 - [PATCH] guest MSR access in the realmode emulation

[Xen-devel] [PATCH] guest MSR access in the realmode emulation

[Xen-devel] Re: [PATCH] guest MSR access in the realmode emulation

[Xen-devel] RE: [PATCH] guest MSR access in the realmode emulation

[Xen-devel] [PATCH] FP instruction in realmode emulation

[Xen-devel] Re: [PATCH] FP instruction in realmode emulation

[Xen-devel] RE: [PATCH] FP instruction in realmode emulation

[Xen-devel] Re: [PATCH] FP instruction in realmode emulation

[Xen-devel] Re: [PATCH] FP instruction in realmode emulation

RE: [Xen-devel] Re: [PATCH] FP instruction in realmode emulation