* [Qemu-devel] [question] mask SIGBUS in qemu main thread @ 2017-11-20 12:32 gengdongjiu 2017-11-20 12:50 ` Alex Bennée 0 siblings, 1 reply; 6+ messages in thread From: gengdongjiu @ 2017-11-20 12:32 UTC (permalink / raw) To: QEMU Developers, mst, peter.maydell@linaro.org, Ingo Molnar Cc: Huangshaoyu, Wuquanming Hi all, sorry to disturb you, I have a question to consult with you why the SIGBUS mask bit is set in the Qemu main thread? do we not want to Qemu main thread to handle the SIGBUS signal? thanks. As shown in [1], the Qemu main thread PID is 30976. "cat /proc/30976/status" in [2], we can see the "SigBlk: 0000000010002240", SIGBUS block bit is 7, so the SIGBUS block bit is set. then the Qemu main thread will not be woken up if there is SIGBUS set to it. thanks! [1]: # ps -eL | grep "qemu" 30976 30976 pts/7 00:00:00 qemu-system-x86 30976 30977 pts/7 00:00:00 qemu-system-x86 [2] # cat /proc/30976/status Name: qemu-system-x86 State: S (sleeping) Tgid: 30976 Ngid: 0 Pid: 30976 PPid: 34807 TracerPid: 0 Uid: 1000 1000 1000 1000 Gid: 1000 1000 1000 1000 FDSize: 256 Groups: 4 24 27 30 46 108 114 115 1000 NStgid: 30976 NSpid: 30976 NSpgid: 30976 NSsid: 34772 VmPeak: 604260 kB VmSize: 538724 kB VmLck: 0 kB VmPin: 0 kB VmHWM: 34176 kB VmRSS: 34176 kB VmData: 294308 kB VmStk: 136 kB VmExe: 4808 kB VmLib: 36144 kB VmPTE: 528 kB VmPMD: 16 kB VmSwap: 0 kB HugetlbPages: 0 kB Threads: 2 SigQ: 6/514067 SigPnd: 0000000000000000 ShdPnd: 0000000000000000 SigBlk: 0000000010002240 SigIgn: 0000000000001000 SigCgt: 0000000180004243 CapInh: 0000000000000000 CapPrm: 0000000000000000 CapEff: 0000000000000000 CapBnd: 0000003fffffffff CapAmb: 0000000000000000 Seccomp: 0 Cpus_allowed: ffff,ffffffff Cpus_allowed_list: 0-47 Mems_allowed: 00000000,00000003 Mems_allowed_list: 0-1 voluntary_ctxt_switches: 7638 nonvoluntary_ctxt_switches: 3 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [question] mask SIGBUS in qemu main thread 2017-11-20 12:32 [Qemu-devel] [question] mask SIGBUS in qemu main thread gengdongjiu @ 2017-11-20 12:50 ` Alex Bennée 2017-11-20 13:00 ` Peter Maydell 0 siblings, 1 reply; 6+ messages in thread From: Alex Bennée @ 2017-11-20 12:50 UTC (permalink / raw) To: gengdongjiu Cc: QEMU Developers, mst, peter.maydell@linaro.org, Ingo Molnar, Wuquanming, Huangshaoyu gengdongjiu <gengdongjiu@huawei.com> writes: > Hi all, > sorry to disturb you, I have a question to consult with you why the SIGBUS mask bit is set in the Qemu main thread? > do we not want to Qemu main thread to handle the SIGBUS signal? > thanks. What exactly do you expect the main thread to do with a SIGBUS signal? If QEMU doesn't catch the SIGBUS it will be up to the kernel to deal with it, probably by terminating QEMU. This is fine because this is a bug in QEMU that shouldn't have occurred. This is different from dealing with SIGBUS due to the guests action which might occur in the various vCPU threads. > As shown in [1], the Qemu main thread PID is 30976. > "cat /proc/30976/status" in [2], we can see the "SigBlk: 0000000010002240", SIGBUS block bit is 7, so the SIGBUS block bit is set. > then the Qemu main thread will not be woken up if there is SIGBUS set to it. > thanks! > > > [1]: > # ps -eL | grep "qemu" > 30976 30976 pts/7 00:00:00 qemu-system-x86 > 30976 30977 pts/7 00:00:00 qemu-system-x86 > > [2] > # cat /proc/30976/status > Name: qemu-system-x86 > State: S (sleeping) > Tgid: 30976 > Ngid: 0 > Pid: 30976 > PPid: 34807 > TracerPid: 0 > Uid: 1000 1000 1000 1000 > Gid: 1000 1000 1000 1000 > FDSize: 256 > Groups: 4 24 27 30 46 108 114 115 1000 > NStgid: 30976 > NSpid: 30976 > NSpgid: 30976 > NSsid: 34772 > VmPeak: 604260 kB > VmSize: 538724 kB > VmLck: 0 kB > VmPin: 0 kB > VmHWM: 34176 kB > VmRSS: 34176 kB > VmData: 294308 kB > VmStk: 136 kB > VmExe: 4808 kB > VmLib: 36144 kB > VmPTE: 528 kB > VmPMD: 16 kB > VmSwap: 0 kB > HugetlbPages: 0 kB > Threads: 2 > SigQ: 6/514067 > SigPnd: 0000000000000000 > ShdPnd: 0000000000000000 > SigBlk: 0000000010002240 > SigIgn: 0000000000001000 > SigCgt: 0000000180004243 > CapInh: 0000000000000000 > CapPrm: 0000000000000000 > CapEff: 0000000000000000 > CapBnd: 0000003fffffffff > CapAmb: 0000000000000000 > Seccomp: 0 > Cpus_allowed: ffff,ffffffff > Cpus_allowed_list: 0-47 > Mems_allowed: 00000000,00000003 > Mems_allowed_list: 0-1 > voluntary_ctxt_switches: 7638 > nonvoluntary_ctxt_switches: 3 -- Alex Bennée ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [question] mask SIGBUS in qemu main thread 2017-11-20 12:50 ` Alex Bennée @ 2017-11-20 13:00 ` Peter Maydell 2017-11-20 13:32 ` gengdongjiu 2017-11-20 14:23 ` Alex Bennée 0 siblings, 2 replies; 6+ messages in thread From: Peter Maydell @ 2017-11-20 13:00 UTC (permalink / raw) To: Alex Bennée Cc: gengdongjiu, QEMU Developers, Michael S. Tsirkin, Ingo Molnar, Wuquanming, Huangshaoyu On 20 November 2017 at 12:50, Alex Bennée <alex.bennee@linaro.org> wrote: > What exactly do you expect the main thread to do with a SIGBUS signal? For KVM, we (can) use SIGBUS for handling machine check exceptions: see qemu_init_sigbus() in cpus.c, where we use prctl(PR_MCE_KILL) to ask the host kernel to send us a SIGBUS if the memory used by the VM has memory corruption detected by the hardwar. This then lets us inform the guest (see kvm_mce_inject() in target/i386). (This will probably be coming to Arm KVM at some point, as part of the RAS extension support. See various threads in kvmarm list.) Because asynchronous signals are a pain to deal with, for the main thread we handle all our signals via signalfd(), which is why the main thread shows SIGBUS as blocked. The main thread will pick the signal up via the fd at some point. For KVM vcpu threads, the signal arrives asynchronously. See sigbus_handler() in cpus.c. thanks -- PMM ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [question] mask SIGBUS in qemu main thread 2017-11-20 13:00 ` Peter Maydell @ 2017-11-20 13:32 ` gengdongjiu 2017-11-20 14:23 ` Alex Bennée 1 sibling, 0 replies; 6+ messages in thread From: gengdongjiu @ 2017-11-20 13:32 UTC (permalink / raw) To: Peter Maydell, Alex Bennée Cc: QEMU Developers, Michael S. Tsirkin, Ingo Molnar, Wuquanming, Huangshaoyu On 2017/11/20 21:00, Peter Maydell wrote: > On 20 November 2017 at 12:50, Alex Bennée <alex.bennee@linaro.org> wrote: >> What exactly do you expect the main thread to do with a SIGBUS signal? > > For KVM, we (can) use SIGBUS for handling machine check exceptions: > see qemu_init_sigbus() in cpus.c, where we use prctl(PR_MCE_KILL) > to ask the host kernel to send us a SIGBUS if the memory used > by the VM has memory corruption detected by the hardwar. This > then lets us inform the guest (see kvm_mce_inject() in target/i386). > (This will probably be coming to Arm KVM at some point, as part > of the RAS extension support. See various threads in kvmarm list.) thanks, yes, indeed. when the RAS is enabled, if a guest memory address is corruption, host will unmap the stage2 mapping and try to find a Qemu thread to deliver the SIGBUS signal[1]. when Qemu receive the signal, it will try to do some recovery for guest. such as kvm_mce_inject() in target/i386. In host kernel[1], if the flag set MF_ACTION_REQUIRED, host will find current vcpu thread to deliver SIGBUS with si_code BUS_MCEERR_AR Otherwise it will find Qemu main thread to deliver the SIGBUS with si_code BUS_MCEERR_AO For this case, Qemu will block this SIGBUS and this signal will be always pending. For the KVM[2], it does not matter, because KVM will choose the current vcpu thread to deliver SIGBUS, not the main Qemu thread. [1] static int kill_proc(struct task_struct *t, unsigned long addr, int trapno, unsigned long pfn, struct page *page, int flags) .................. if ((flags & MF_ACTION_REQUIRED) && t->mm == current->mm) { si.si_code = BUS_MCEERR_AR; ret = force_sig_info(SIGBUS, &si, current); } else { /* * Don't use force here, it's convenient if the signal * can be temporarily blocked. * This could cause a loop when the user sets SIGBUS * to SIG_IGN, but hopefully no one will do that? */ si.si_code = BUS_MCEERR_AO; ret = send_sig_info(SIGBUS, &si, t); /* synchronous? */ } } [2] static void kvm_send_hwpoison_signal(unsigned long address, struct vm_area_struct *vma) { siginfo_t info; info.si_signo = SIGBUS; info.si_errno = 0; info.si_code = BUS_MCEERR_AR; info.si_addr = (void __user *)address; if (is_vm_hugetlb_page(vma)) info.si_addr_lsb = huge_page_shift(hstate_vma(vma)); else info.si_addr_lsb = PAGE_SHIFT; send_sig_info(SIGBUS, &info, current); } > > Because asynchronous signals are a pain to deal with, for the > main thread we handle all our signals via signalfd(), which is > why the main thread shows SIGBUS as blocked. The main thread > will pick the signal up via the fd at some point. For KVM vcpu > threads, the signal arrives asynchronously. See sigbus_handler() > in cpus.c. thanks Pether's explanation. yes, you are right. > > thanks > -- PMM > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [question] mask SIGBUS in qemu main thread 2017-11-20 13:00 ` Peter Maydell 2017-11-20 13:32 ` gengdongjiu @ 2017-11-20 14:23 ` Alex Bennée 2017-11-20 14:33 ` Peter Maydell 1 sibling, 1 reply; 6+ messages in thread From: Alex Bennée @ 2017-11-20 14:23 UTC (permalink / raw) To: Peter Maydell Cc: gengdongjiu, QEMU Developers, Michael S. Tsirkin, Ingo Molnar, Wuquanming, Huangshaoyu Peter Maydell <peter.maydell@linaro.org> writes: > On 20 November 2017 at 12:50, Alex Bennée <alex.bennee@linaro.org> wrote: >> What exactly do you expect the main thread to do with a SIGBUS signal? > > For KVM, we (can) use SIGBUS for handling machine check exceptions: > see qemu_init_sigbus() in cpus.c, where we use prctl(PR_MCE_KILL) > to ask the host kernel to send us a SIGBUS if the memory used > by the VM has memory corruption detected by the hardwar. This > then lets us inform the guest (see kvm_mce_inject() in target/i386). > (This will probably be coming to Arm KVM at some point, as part > of the RAS extension support. See various threads in kvmarm list.) > > Because asynchronous signals are a pain to deal with, for the > main thread we handle all our signals via signalfd(), which is > why the main thread shows SIGBUS as blocked. The main thread > will pick the signal up via the fd at some point. For KVM vcpu > threads, the signal arrives asynchronously. See sigbus_handler() > in cpus.c. Well TIL ;-) I wonder why the choice was made to re-use SIGBUS for this. I guess the meaning is semantically the same (some hardware fault) but surprising they are now asynchronously delivered. When it eventually arrives at the vCPU it won't be directly tied to what tripped up the machine checking logic to trigger? Maybe this was never always the case? I was slightly confused seeing sigbus_handler() only mentioned once in a sigaction call but grepping around I can now see sigfd_handler() directly queries the sigaction for a signal before invoking the handler which I guess makes sense. > > thanks > -- PMM -- Alex Bennée ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [question] mask SIGBUS in qemu main thread 2017-11-20 14:23 ` Alex Bennée @ 2017-11-20 14:33 ` Peter Maydell 0 siblings, 0 replies; 6+ messages in thread From: Peter Maydell @ 2017-11-20 14:33 UTC (permalink / raw) To: Alex Bennée Cc: gengdongjiu, QEMU Developers, Michael S. Tsirkin, Ingo Molnar, Wuquanming, Huangshaoyu On 20 November 2017 at 14:23, Alex Bennée <alex.bennee@linaro.org> wrote: > I wonder why the choice was made to re-use SIGBUS for this. I guess the > meaning is semantically the same (some hardware fault) but surprising > they are now asynchronously delivered. When it eventually arrives at the > vCPU it won't be directly tied to what tripped up the machine checking > logic to trigger? Maybe this was never always the case? I think the comments in cpus.c:sigbus_handler() mean "asynchronously" in the sense of "at any time, not just when we explicitly check" (in contrast to the main thread where we only process SIGBUS when we want to, via signalfd). In general though some RAS errors are not going to be synchronous-exceptions in the Arm ARM terms. thanks -- PMM ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-11-20 14:34 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-11-20 12:32 [Qemu-devel] [question] mask SIGBUS in qemu main thread gengdongjiu 2017-11-20 12:50 ` Alex Bennée 2017-11-20 13:00 ` Peter Maydell 2017-11-20 13:32 ` gengdongjiu 2017-11-20 14:23 ` Alex Bennée 2017-11-20 14:33 ` Peter Maydell
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).