On Thu, 16 Jan 2020 at 16:28, Peter Maydell <peter.maydell@xxxxxxxxxx> wrote: > This function (kvm_arch_on_sigbus_vcpu()) will be called in two contexts: > > (1) in the vcpu thread: > * the real SIGBUS handler sigbus_handler() sets a flag and arranges > for an immediate vcpu exit > * the vcpu thread reads the flag on exit from KVM_RUN and > calls kvm_arch_on_sigbus_vcpu() directly > * the error could be MCEERR_AR or MCEERR_AO > (2) MCE errors on other threads: > * here SIGBUS is blocked, so MCEERR_AR (action-required) > errors will cause the kernel to just kill the QEMU process > * MCEERR_AO errors will be handled via the iothread's use > of signalfd(), so kvm_on_sigbus() will get called from > the main thread, and it will call kvm_arch_on_sigbus_vcpu() > * in this case the passed in CPUState will (arbitrarily) be that > for the first vCPU > > For MCEERR_AR, the code here looks correct -- we know this is > only going to happen for the relevant vCPU so we can go ahead > and do the "record it in the ACPI table and tell the guest" bit. > > But shouldn't we be doing something with the MCEERR_AO too? > That of course will be trickier because we're not necessarily > in the vcpu thread, but it would be nice to let the guest > know about it. An IRC discussion with Paolo came to the conclusion that the nicest approach here would be for kvm_on_sigbus() to use run_on_cpu() to call the whole of kvm_arch_on_sigbus_vcpu() in the vcpu thread for the cpu it gets passed. Then the code here would not have to worry about the "not on the right thread" case. This would be a refactoring of the x86 code, which currently does the run_on_cpu inside its implementation, in cpu_x86_inject_mce(). thanks -- PMM
