From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: No kernel interface to reset a VCPU Date: Fri, 25 Sep 2009 20:54:08 +0200 Message-ID: <4ABD11D0.3000207@web.de> References: <4ABCD915.5090503@siemens.com> <20090925171356.GB30416@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEA934DC24B7527A4D2BCD90D" Cc: kvm-devel To: Gleb Natapov Return-path: Received: from fmmailgate03.web.de ([217.72.192.234]:42098 "EHLO fmmailgate03.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751923AbZIYS4p (ORCPT ); Fri, 25 Sep 2009 14:56:45 -0400 In-Reply-To: <20090925171356.GB30416@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEA934DC24B7527A4D2BCD90D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Gleb Natapov wrote: > On Fri, Sep 25, 2009 at 04:52:05PM +0200, Jan Kiszka wrote: >> Hi all, >> >> looks to me like there is no way to properly reset the boot processor.= >> The current pattern used by qemu[-kvm] is to reload all registers with= >> their reset values. But that does not affect the internal VCPU states >> the KVM keeps in the kernel. They are only reset during VCPU setup or >> after receiving a SIPI (and the latter only helps with secondary CPUs)= =2E >> > Userspace should have access to internal VCPU states too, otherwise > migration will not work. Good point. >=20 >> So the only way around it with the current kernel interface is to >> destroy/recreate the BSP on reset, right? /me is looking into such an >> approach now. > I don't think destroying/recreating vcpu will work. I don't remember=20 > exact details though. >=20 >> We stumbled over inconsistent VCPU states with our internal qemu-kvm >> tree. We have a legacy watchdog emulation here that triggered but fail= ed >> to bring up the system again. I wasn't able to create a similar case >> with a standard environment yet, but I think it is not unrealistic for= >> qemu-kvm as well. Hacking kvm_arch_vcpu_reset() into KVM that triggers= >> on the right register values "solved" the issue here. >> > Can you find the root cause of the problem? As I said above qemu should= > have full access to vcpu state for proper migration support. Not that I just had a closer look again and found our problem: arch.nmi_pending. I think the risk to be bitten by this on standard OSes is rather low. The reset issue we see is widely related to the special NMI-based watchdog here. The probability to see the pattern NMI-> guest handler -> NMI -> system-reset on ordinary systems is fairly low. Besides this hidden state may cause lost NMI events during migration or save/restore. Again a corner case. But it should be fixed. Will check where we could add this bit for userland read-out. > kvm_vcpu_reset()/kvm_apic_reset()/kvm_ioapic_reset()/kvm_pit_reset() is= > bad idea. Actually I want to add them one day. >=20 > -- > Gleb. Jan --------------enigEA934DC24B7527A4D2BCD90D 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.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkq9EdUACgkQitSsb3rl5xQuUQCfap4oEFjOtCMbW7e1pUspwIXu ooUAnRre60hSJlCJKsSdJlpZW9Hw5PsE =XRp/ -----END PGP SIGNATURE----- --------------enigEA934DC24B7527A4D2BCD90D--