Konrad Rzeszutek Wilk
2013-Feb-13 18:11 UTC
9d02b43dee0d7fb18dfb13a00915550b1a3daa9f (xen PVonHVM: use E820_Reserved area for shared_info) causes regression with 32-bit PVHVM guests (v3.8-rcX) on Xen 4.1
Hey Olaf, The commit 9d02b43dee0d7fb18dfb13a00915550b1a3daa9f (xen PVonHVM: use E820_Reserved area for shared_info) causes a regression when doing ''xm restore'' (or migrate) of a 32-bit PVHVM guest with Xen 4.1. This is xen-4.1-testing with v3.8-rc7 and me just doing ''xm save <name> <file>'' followed by ''xm restore <file> && xm console <name>'' and I don''t see anything on the serial console. The ''xentop'' shows the guest consuming 100% cycles spinning around in pvlock_read. By just reverting this patch (well, also a7be94ac8d69c037d08f0fd94b45a593f1d45176) the problem disappears. Any thoughts of what might be wrong?
Olaf Hering
2013-Feb-13 18:58 UTC
Re: 9d02b43dee0d7fb18dfb13a00915550b1a3daa9f (xen PVonHVM: use E820_Reserved area for shared_info) causes regression with 32-bit PVHVM guests (v3.8-rcX) on Xen 4.1
On Wed, Feb 13, Konrad Rzeszutek Wilk wrote:> Any thoughts of what might be wrong?Do you have a xenctx output when it hangs? Olaf
Konrad Rzeszutek Wilk
2013-Feb-13 19:43 UTC
Re: 9d02b43dee0d7fb18dfb13a00915550b1a3daa9f (xen PVonHVM: use E820_Reserved area for shared_info) causes regression with 32-bit PVHVM guests (v3.8-rcX) on Xen 4.1
On Wed, Feb 13, 2013 at 07:58:26PM +0100, Olaf Hering wrote:> On Wed, Feb 13, Konrad Rzeszutek Wilk wrote: > > > Any thoughts of what might be wrong? > > Do you have a xenctx output when it hangs?> /usr/lib64/xen/bin/xenctx -s System.map -a 5 0cs:eip: 0060:c10730f5 native_safe_halt+0x5 flags: 00000246 i z p ss:esp: 0068:c171df8c eax: 00000000 ebx: c176df70 ecx: 00000000 edx: 00000000 esi: 00000000 edi: 00000000 ebp: c171df8c ds: 007b es: 007b fs: 00d8 gs: 0000 cr0: 8005003b cr2: 00000000 cr3: 00000000 cr4: b747f000 dr0: 00000000 dr1: 00000000 dr2: 00000000 dr3: 00000000 dr6: 00000000 dr7: 00000000 Code (instr addr c10730f5) 55 89 e5 fb 5d c3 8d 76 00 8d bc 27 00 00 00 00 55 89 e5 fb f4 <5d> c3 89 f6 8d bc 27 00 00 00 00 Stack: c171dfa4 c1050101 00000096 c176df70 00000000 c1720800 c171dfb0 c104fab8 c17bb3c0 c171dfb8 c157e3df c171dfd8 c1775b1d 000000f7 ffffffff ffffffff c1775663 c17bb3c0 7a54b000 c171dff8 c17752e6 05a94000 00000000 7ffdf000 00000000 00200800 00033000 01d0d003 00000000 Call Trace: [<c10730f5>] native_safe_halt+0x5 <-- [<c1050101>] default_idle+0x41 [<c104fab8>] cpu_idle+0x68 [<c157e3df>] rest_init+0x6f [<c1775b1d>] start_kernel+0x32b [<c1775663>] unknown_bootoption [<c17752e6>] i386_start_kernel+0xa9> /usr/lib64/xen/bin/xenctx -s System.map -a 5 1cs:eip: 0060:c1073dc8 pvclock_clocksource_read+0x18 flags: 00000086 s nz p ss:esp: 0068:f0c8de44 eax: 63dcc977 ebx: 00000001 ecx: 2f908000 edx: 00000077 esi: f0c6f030 edi: 00000742 ebp: f0c8de60 ds: 007b es: 007b fs: 00d8 gs: 0000 cr0: 8005003b cr2: 00000000 cr3: 00000000 cr4: b766ae24 dr0: 00000000 dr1: 00000000 dr2: 00000000 dr3: 00000000 dr6: 00000000 dr7: 00000000 Code (instr addr c1073dc8) 57 56 53 83 ec 10 8b 38 89 04 24 66 90 8d 76 00 0f ae e8 0f 31 <8b> 0c 24 89 44 24 08 8b 04 24 89 Stack: f10fc120 2af6a2d6 000002a5 00000001 00000001 f0c6f030 00000002 f0c8de6c c103f2c5 00000001 f0c8de74 c104e218 f0c8deb8 c10b4f22 00000015 76f0981d 0000000d fffffff2 ffffffff f11035d0 f11035d0 f11035c0 00000015 2d1b4a9b 00000015 00000001 00000001 f0c6f030 00000002 f0c8df00 c10b5131 f10fe9a0 Call Trace: [<c1073dc8>] pvclock_clocksource_read+0x18 <-- [<c103f2c5>] xen_clocksource_read+0x25 [<c104e218>] sched_clock+0x8 [<c10b4f22>] sched_clock_local+0xb2 [<c10b5131>] sched_clock_cpu+0x131 [<c103f2c5>] xen_clocksource_read+0x25 [<c103f488>] xen_clocksource_get_cycles+0x8 [<c10cb433>] ktime_get+0x43 [<c10b5901>] irqtime_account_irq+0x41 [<c108a77e>] irq_exit+0xe [<c13316e0>] xen_evtchn_do_upcall+0x20 [<c1595ff9>] xen_hvm_callback_vector+0x2d [<c10730f5>] native_safe_halt+0x5 [<c1050101>] default_idle+0x41 [<c104fab8>] cpu_idle+0x68 [<c1588bd7>] start_secondary+0x19f And then if I time it just right I can see on the VCPU1 sometimes:> /usr/lib64/xen/bin/xenctx -s System.map -a 5 1cs:eip: 0060:c10b4ef5 sched_clock_local+0x85 flags: 00000002 nz ss:esp: 0068:f0c8de7c eax: 2d1b4a9b ebx: 2d1b4a9b ecx: 00000015 edx: 00000015 esi: 2d1b4a9b edi: 00000015 ebp: f0c8deb8 ds: 007b es: 007b fs: 00d8 gs: 0000 cr0: 8005003b cr2: 00000000 cr3: 00000000 cr4: b766ae24 dr0: 00000000 dr1: 00000000 dr2: 00000000 dr3: 00000000 dr6: 00000000 dr7: 00000000 Code (instr addr c10b4ef5) 0c 24 89 5c 24 04 8b 74 24 20 8b 7c 24 24 8b 1c 24 8b 4c 24 04 <89> 74 24 28 89 f0 8b 74 24 18 89 Stack: 2d1b4a9b 00000015 feb559f0 00000026 ffffffd9 ffffffff f11035d0 f11035c0 2d1b4a9b 00000015 ffffffff ffffffff 00000001 f0c6f030 00000002 f0c8df00 c10b5131 f10fe9a0 f0c8ded0 c103f2c5 c176ce80 f0c8ded8 c103f488 f0c8df00 c10cb433 f11035c0 f11035c0 00000046 f10fc100 f10fc104 00000001 f0c6f030 Call Trace: [<c10b4ef5>] sched_clock_local+0x85 <-- [<c10b5131>] sched_clock_cpu+0x131 [<c103f2c5>] xen_clocksource_read+0x25 [<c103f488>] xen_clocksource_get_cycles+0x8 [<c10cb433>] ktime_get+0x43 [<c10b5901>] irqtime_account_irq+0x41 [<c108a77e>] irq_exit+0xe [<c13316e0>] xen_evtchn_do_upcall+0x20 [<c1595ff9>] xen_hvm_callback_vector+0x2d [<c10730f5>] native_safe_halt+0x5 [<c1050101>] default_idle+0x41 [<c104fab8>] cpu_idle+0x68 [<c1588bd7>] start_secondary+0x19f So the VCPU1 is looping around trying to read the pvclock. Presumarily the info is full of zeros.
Olaf Hering
2013-Feb-13 21:19 UTC
Re: 9d02b43dee0d7fb18dfb13a00915550b1a3daa9f (xen PVonHVM: use E820_Reserved area for shared_info) causes regression with 32-bit PVHVM guests (v3.8-rcX) on Xen 4.1
On Wed, Feb 13, Konrad Rzeszutek Wilk wrote:> So the VCPU1 is looping around trying to read the pvclock. Presumarily > the info is full of zeros.I will have a look tomorrow. Is the page perhaps not mapped and qemu is spinning in dom0? Olaf
Konrad Rzeszutek Wilk
2013-Feb-13 21:44 UTC
Re: 9d02b43dee0d7fb18dfb13a00915550b1a3daa9f (xen PVonHVM: use E820_Reserved area for shared_info) causes regression with 32-bit PVHVM guests (v3.8-rcX) on Xen 4.1
On Wed, Feb 13, 2013 at 10:19:54PM +0100, Olaf Hering wrote:> On Wed, Feb 13, Konrad Rzeszutek Wilk wrote: > > > So the VCPU1 is looping around trying to read the pvclock. Presumarily > > the info is full of zeros. > > I will have a look tomorrow. Is the page perhaps not mapped and qemu is > spinning in dom0?QEMU looks to be idle.> > Olaf
Olaf Hering
2013-Feb-14 15:15 UTC
Re: 9d02b43dee0d7fb18dfb13a00915550b1a3daa9f (xen PVonHVM: use E820_Reserved area for shared_info) causes regression with 32-bit PVHVM guests (v3.8-rcX) on Xen 4.1
On Wed, Feb 13, Konrad Rzeszutek Wilk wrote:> Any thoughts of what might be wrong?After a quick browsing of the involved code I dont see anything obvious. Since kexec for PVonHVM does not work anyway even with this patch, please revert 9d02b43dee0d7fb18dfb13a00915550b1a3daa9f and a7be94ac8d69c037d08f0fd94b45a593f1d45176 to avoid the regression. Please also send the .config for the guest, and say if dom0 is 32bit as well. Olaf
Konrad Rzeszutek Wilk
2013-Feb-15 02:30 UTC
Re: 9d02b43dee0d7fb18dfb13a00915550b1a3daa9f (xen PVonHVM: use E820_Reserved area for shared_info) causes regression with 32-bit PVHVM guests (v3.8-rcX) on Xen 4.1
On Thu, Feb 14, 2013 at 04:15:09PM +0100, Olaf Hering wrote:> On Wed, Feb 13, Konrad Rzeszutek Wilk wrote: > > > Any thoughts of what might be wrong? > > After a quick browsing of the involved code I dont see anything obvious. > Since kexec for PVonHVM does not work anyway even with this patch, > please revert 9d02b43dee0d7fb18dfb13a00915550b1a3daa9f and > a7be94ac8d69c037d08f0fd94b45a593f1d45176 to avoid the regression.OK.> > Please also send the .config for the guest, and say if dom0 is 32bit as > well.Dom0 is 64-bit. And attached is the config.> > Olaf > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel