From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=47014 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pi0Rd-0001kk-G0 for qemu-devel@nongnu.org; Wed, 26 Jan 2011 03:09:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pi0RX-0001x3-PN for qemu-devel@nongnu.org; Wed, 26 Jan 2011 03:09:37 -0500 Received: from fmmailgate02.web.de ([217.72.192.227]:46236) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pi0RX-0001wI-E4 for qemu-devel@nongnu.org; Wed, 26 Jan 2011 03:09:31 -0500 Message-ID: <4D3FD6B5.4030303@web.de> Date: Wed, 26 Jan 2011 09:09:25 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <39b9c54e6cd122cb613f5fb79502eb053609d237.1294648329.git.jan.kiszka@web.de> <20110124111728.GA29184@amt.cnet> <4D3D7254.1030102@web.de> In-Reply-To: <4D3D7254.1030102@web.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1F07E38BF8FE03DCF71077FB" 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) --------------enig1F07E38BF8FE03DCF71077FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 events >>> happening over a VCPU context in non-threaded mode get dispatched as >>> VCPU MCEs. >>> >>> We also need to call qemu_kvm_eat_signals in non-threaded mode now, s= o >>> 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_cp= u->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. >=20 > 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 >> >> But the SIGBUS handler for !IOTHREAD case should not ignore Action >> Required, since it might have been generated in vcpu context. >> >=20 > Yes, the sigbus handler will require some rework when we actually start= > 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 code properly. What did you mean? Jan --------------enig1F07E38BF8FE03DCF71077FB 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/ iEYEARECAAYFAk0/1rgACgkQitSsb3rl5xQcoQCg0jyrH7PyXO6GUcFJLfZBBuG/ RKUAoMvrqbEpMnmu6SwjCFSTfNV+fyJs =tqqk -----END PGP SIGNATURE----- --------------enig1F07E38BF8FE03DCF71077FB--