* [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).