Re: [kvm-ppc-devel] [PATCH] Fix signal handing line KVM PowerPC

[Hollis Blanchard <hollisb@us.ibm.com>]

On Fri, 2008-02-08 at 10:42 +0100, Christian Ehrhardt wrote:
> Hollis Blanchard wrote:
> > On Mon, 2008-02-04 at 20:00 -0600, Hollis Blanchard wrote:
> >> On Fri, 2008-02-01 at 15:48 -0600, Jerone Young wrote:
> >>> Code was missing for our kernel code to properly handle signals, by
> >>> setting the signal mask and saving off our current one, then restoring
> >>> it at the end. This code does what x86 does and now keyboard input
> >>> works.
> >>>
> >>> Signed-off-by: Jerone Young <jyoung5@us.ibm.com>
> >>>
> >>>
> >>> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> >>> --- a/arch/powerpc/kvm/powerpc.c
> >>> +++ b/arch/powerpc/kvm/powerpc.c
> >>> @@ -685,6 +688,10 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_v
> >>>  int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
> >>>  {
> >>>         int r;
> >>> +       sigset_t sigsaved;
> >>> +
> >>> +       if (vcpu->sigset_active)
> >>> +               sigprocmask(SIG_SETMASK, &vcpu->sigset, &sigsaved);
> >>>
> >>>         if (vcpu->mmio_needed) {
> >>>                 if (!vcpu->mmio_is_write)
> >>> @@ -702,6 +709,10 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_v
> >>>
> >>>         r = __kvmppc_vcpu_run(run, vcpu);
> >>>         local_irq_enable(); /* XXX */
> >>> +
> >>> +         
> >>> +       if (vcpu->sigset_active)
> >>> +               sigprocmask(SIG_SETMASK, &sigsaved, NULL);
> >>>
> >>>         return r;
> >>>  }
> >> Applied, thanks. Please watch your whitespace in the future though
> >> (including in your mailer :).
> > 
> > I had to revert this because it caused guest output to "pause" until a
> > qemu keypress.
> > 
> 
> FYI - While I'm at looking into this I found that when I apply this patch my guest get an oops because it gets an unexpected signal in the (guest)kernel.
> The same guest/host combination just without that patch works, maybe this helps us debugging this.
> 
> Guest Output
> [...]
> PCI: Probing PCI hardware
> NET: Registered protocol family 2
> IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
> TCP estalished hash table entries: 8192 (order: 4, 65536 bytes)
> TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
> TCP: Hash tables configured (established 8192 bind 8192)
> TCP reno registered
> trap!
> Oops: Exception in kernel mode, sig: 4 [#1]
> Bamboo
> Modules linked in:
> NIP: c0035d8c LR: c0027cbc CTR: 00000000
> REGS: c06a5b40 TRAP: 0700   Not tainted  (2.6.23-rc1)
> MSR: 00029002 <EE,ME>  CR: 84000022  XER: 20000000
> TASK = c06b9530[2] 'kthreadd' THREAD: c06a4000
> GPR00: 00000001 c06a5bf0 c06b9530 c06a5bf8 000005b5 00000000 00000000 00000000
> GPR08: 000005b5 000005af 00000005 00000020 f26abea8 00000000 c0276130 00000000
> GPR16: c0270000 c0270000 c0276138 c06a5d10 c06a5ef0 c06a5fa0 c06bf2d0 c0270000
> GPR24: fffffff4 00000611 c0270000 00800711 c06a5bf8 000000d0 00000000 c06b9530
> NIP [c0035d8c] run_posix_cpu_timers+0x2c/0x7dc
> LR [c0027cbc] update_process_times+0xa0/0xb4
> Call Trace:
> [c06a5bf0] [003dacde] 0x3dacde (unreliable)
> [c06a5c40] [c0027cbc] update_process_times+0xa0/0xb4
> [c06a5c60] [c000968c] timer_interrupt+0xc4/0x558
> [c06a5d00] [c000c570] ret_from_except+0x0/0x18
> [c06a5dc0] [c0036be8] ktime_get_ts+0x2c/0x74
> [c06a5de0] [c001bbe4] copy_process+0x94/0xec8
> [c06a5e60] [c001cabc] do_fork+0x6c/0x1d8
> [c06a5eb0] [c0005938] sys_clone+0x68/0x84
> [c06a5ee0] [c000bf34] ret_from_syscall+0x0/0x3c
> [c06a5fa0] [c06a3e84] 0xc06a3e84
> [c06a5fb0] [c0033dc0] kthreadd+0xd8/0xdc
> [c06a5ff0] [c000cff0] kernel_thread+0x48/0x64
> Instruction dump:
> 4bffffe0 7c0802a6 9421ffb0 be810020 3b810008 7c7f1b78 93810008 90010054
> 7f83e378 9381000c 7c0000a6 54008ffe <0f000000> 817f01b0 2f8b0000 419e05f0
> Kernel panic - not syncing: Fatal exception in interrupt

The lack of this patch is causing some serious issues, so we need to
figure this out.

What's concerning me about this backtrace is that it seems we have
somehow incorrectly enabled (guest) MSR[EE]. You can see where we
delivered the decrementer, but timer_interrupt is supposed to be called
with EE=0. The BUG_ON() we've hit explicitly tests that, and you can
also see MSR[EE]=1 in the register dump.

Could we have a race in modifying vcpu->guest_msr somewhere? Something
related to the queueing of signals for qemu that this patch allows?

-- 
Hollis Blanchard
IBM Linux Technology Center


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
kvm-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel