Re: [PATCH] fix dirty_bit in xenivt.S (was Re: [Xen-ia64-devel] Fail tocreate VTI domain in lates Cset 10143)

[Isaku Yamahata <yamahata@xxxxxxxxxxxxx>]

On Wed, May 24, 2006 at 03:04:27PM +0800, Tian, Kevin wrote:
> >From: Isaku Yamahata
> >Sent: 2006年5月24日 11:56
> >
> >On Wed, May 24, 2006 at 06:10:53AM +0800, You, Yongkang wrote:
> >
> >> Well, I found a lot of bad address reported from serial port, no matter
> >creating VTI or XenU domain.
> >> (XEN) vcpu_translate: bad physical address: 0xa00000010000a0a0
> >
> >Does the attached patch fix it?
> >I saw the same message, so I tracked it down.
> >However I couldn't reproduce reliably, I don't know this patch solves it.
> >If you know the way to reproduce, could you tell us?
> >
> >--
> 
> Hi, Isaku,
>       I'm interesting why your patch can fix potential issue here. Ideally 
> XEN_HYPER_ITC_D is only the fast path which should have the same 
> effect as GP fault caused by itc.d. If your patch really helps, that means 
> the two paths (slow/fast) are incompatible which need to be solved, right?

Hi Kevin.
In fact the patch only hides the root cause.
Evantually I was able to reproduce it and get its stack trace
by inserting dump_stack() right after the debug message.
The following stack trace explains, I hope.
I'll make a patch to __get_domain_bundle().

Anyway I don't see any reason why only itc.d of dirty_bit handler isn't
para-virtualized so that the patch should be applied.

Note:
0xa00000010000a0a0 = itc.d of dirty_bit.
At 0xa00000010000a070 dirty_bit handler faults to nested data tlb miss,
and nested_dtlb_miss handler set psr.dt = 0 and jumps back
to dirty_bit handler.
Then itc.d was issued with psr.dt = 0 at 0xa00000010000a0a0.

(XEN) vcpu_translate: bad physical address: 0xa00000010000a0a0
(XEN) 
(XEN) Call Trace:
(XEN)  [<f000000004093320>] show_stack+0x80/0xa0
(XEN)                                 sp=f000000007f7f9d0 bsp=f000000007f790b0
(XEN)  [<f00000000406f0d0>] vcpu_translate+0x130/0x8f0
(XEN)                                 sp=f000000007f7fba0 bsp=f000000007f79050
(XEN)  [<f000000004067ef0>] ia64_do_page_fault+0xc0/0x520
(XEN)                                 sp=f000000007f7fbc0 bsp=f000000007f78ff0
(XEN)  [<f000000004091fc0>] ia64_leave_kernel+0x0/0x310
(XEN)                                 sp=f000000007f7fbe0 bsp=f000000007f78ff0
(XEN)  [<f000000004071c00>] __get_domain_bundle+0x0/0x40
(XEN)                                 sp=f000000007f7fde0 bsp=f000000007f78fc0
(XEN)  [<f0000000040641f0>] priv_handle_op+0x50/0xa60
(XEN)                                 sp=f000000007f7fde0 bsp=f000000007f78f68
(XEN)  [<f000000004064cb0>] priv_emulate+0xb0/0x130
(XEN)                                 sp=f000000007f7fe00 bsp=f000000007f78f38
(XEN)  [<f000000004069440>] ia64_handle_privop+0x30/0x90
(XEN)                                 sp=f000000007f7fe00 bsp=f000000007f78f08
(XEN)  [<f000000004091fc0>] ia64_leave_kernel+0x0/0x310
(XEN)                                 sp=f000000007f7fe00 bsp=f000000007f78f08
(XEN)  [<a00000010000a0a0>] ???
(XEN)                                 sp=f000000007f80000 bsp=f000000007f78dc0
(XEN)  [<a00000010000a070>] ???
(XEN)                                 sp=f000000007f80000 bsp=f000000007f78d80
(XEN)  [<a00000010000a070>] ???
(XEN)                                 sp=f000000007f80000 bsp=f000000007f78d40
(XEN)  [<a00000010000a070>] ???
(XEN)                                 sp=f000000007f80000 bsp=f000000007f78d00
(XEN)  [<a00000010000a070>] ???
(XEN)                                 sp=f000000007f80000 bsp=f000000007f78cc0



-- 
yamahata

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