From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=55270 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pi48m-0006pz-O6 for qemu-devel@nongnu.org; Wed, 26 Jan 2011 07:06:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pi48i-0007zr-KF for qemu-devel@nongnu.org; Wed, 26 Jan 2011 07:06:24 -0500 Received: from fmmailgate03.web.de ([217.72.192.234]:38322) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pi48i-0007xg-6e for qemu-devel@nongnu.org; Wed, 26 Jan 2011 07:06:20 -0500 Message-ID: <4D400E36.6090009@web.de> Date: Wed, 26 Jan 2011 13:06:14 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <39b9c54e6cd122cb613f5fb79502eb053609d237.1294648329.git.jan.kiszka@web.de> <20110124111728.GA29184@amt.cnet> <4D3D7254.1030102@web.de> <4D3FD6B5.4030303@web.de> <20110126120113.GB25302@amt.cnet> In-Reply-To: <20110126120113.GB25302@amt.cnet> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig769CC05CAD586EE35464F92A" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: [PATCH 07/18] kvm: Add MCE signal support for !CONFIG_IOTHREAD List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Marcelo Tosatti Cc: Huang Ying , Avi Kivity , kvm@vger.kernel.org, qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig769CC05CAD586EE35464F92A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2011-01-26 13:01, Marcelo Tosatti wrote: > On Wed, Jan 26, 2011 at 09:09:25AM +0100, Jan Kiszka wrote: >> On 2011-01-24 13:36, Jan Kiszka wrote: >>> On 2011-01-24 12:17, Marcelo Tosatti wrote: >>>> On Mon, Jan 10, 2011 at 09:32:00AM +0100, Jan Kiszka wrote: >>>>> From: Jan Kiszka >>>>> >>>>> Currently, we only configure and process MCE-related SIGBUS events = if >>>>> CONFIG_IOTHREAD is enabled. Fix this by factoring out the required >>>>> handler registration and system configuration. Make sure that event= s >>>>> happening over a VCPU context in non-threaded mode get dispatched a= s >>>>> VCPU MCEs. >>>>> >>>>> We also need to call qemu_kvm_eat_signals in non-threaded mode now,= so >>>>> move it (unmodified) and add the required Windows stub. >>>>> >>>>> Signed-off-by: Jan Kiszka >>>>> CC: Huang Ying >>>>> --- >>>>> cpus.c | 200 +++++++++++++++++++++++++++++++++++++++-------------= ----------- >>>>> 1 files changed, 124 insertions(+), 76 deletions(-) >>>>> >>>>> diff --git a/cpus.c b/cpus.c >>>>> index 6da0f8f..b6f1cfb 100644 >>>>> --- a/cpus.c >>>>> +++ b/cpus.c >>>>> @@ -34,9 +34,6 @@ >>>>> =20 >>>>> #include "cpus.h" >>>>> #include "compatfd.h" >>>>> -#ifdef CONFIG_LINUX >>>>> -#include >>>>> -#endif >>>>> =20 >>>>> #ifdef SIGRTMIN >>>>> #define SIG_IPI (SIGRTMIN+4) >>>>> @@ -44,10 +41,24 @@ >>>>> #define SIG_IPI SIGUSR1 >>>>> #endif >>>>> =20 >>>> >>>>> @@ -912,6 +954,8 @@ static int qemu_cpu_exec(CPUState *env) >>>>> =20 >>>>> bool cpu_exec_all(void) >>>>> { >>>>> + int r; >>>>> + >>>>> if (next_cpu =3D=3D NULL) >>>>> next_cpu =3D first_cpu; >>>>> for (; next_cpu !=3D NULL && !exit_request; next_cpu =3D next_= cpu->next_cpu) { >>>>> @@ -923,7 +967,11 @@ bool cpu_exec_all(void) >>>>> if (qemu_alarm_pending()) >>>>> break; >>>>> if (cpu_can_run(env)) { >>>>> - if (qemu_cpu_exec(env) =3D=3D EXCP_DEBUG) { >>>>> + r =3D qemu_cpu_exec(env); >>>>> + if (kvm_enabled()) { >>>>> + qemu_kvm_eat_signals(env); >>>>> + } >>>>> + if (r =3D=3D EXCP_DEBUG) { >>>>> break; >>>>> } >>>> >>>> SIGBUS should be processed outside of vcpu execution context, think = of a >>>> non MCE SIGBUS while vm is stopped. Could use signalfd for that. >>> >>> signalfd - that's the missing bit. I was thinking of how to handle >>> SIGBUS events raised outside the vcpu context. We need to handle them= >>> synchronously, and signalfd should allow this. >> >> This was straightforward. But now I wonder what actually makes this >> pattern work. Doesn't the kernel force-inject SIGBUS, i.e. ignores any= >> blocking? Or does this only apply to BUS_MCEERR_AR? >=20 > SIGBUS is only forced if BUS_MCEERR_AR and the poisoned memory was not = accessed=20 > on behalf of the guest (say directly by qemu). OK. I didn't find this detail in the kernel code on first glance, only force_sig(SIGBUS, current). >=20 >>>> But the SIGBUS handler for !IOTHREAD case should not ignore Action >>>> Required, since it might have been generated in vcpu context. >>>> >>> >>> Yes, the sigbus handler will require some rework when we actually sta= rt >>> using it for !IOTHREAD. >> >> And this no longer makes sense to me. The current version simply uses >> the same sigbus handler for both modes, an that forwards the error cod= e >> properly. What did you mean? >=20 > There are two handlers, kvm_on_sigbus and kvm_on_sigbus_vcpu. > kvm_on_sigbus, the handler for iothread, dies on BUS_MCEERR_AR (which > will be generated if poisoned memory is accessed on behalf of vcpu). It= > should be handled with !CONFIG_IOTHREAD. Just as with iothread, vcpu-triggered SIGBUS events are processes by qemu_kvm_eat_signals, not the signal handler. Jan --------------enig769CC05CAD586EE35464F92A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk1ADjgACgkQitSsb3rl5xR4rgCg5RSCZpfbQe1g09oXa6zionQ/ n7AAoMvk2GUrWdDTUI/8eQIGevFLGcaY =efqi -----END PGP SIGNATURE----- --------------enig769CC05CAD586EE35464F92A--