From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: qemu-kvm requires apic initialized before vcpu main loop Date: Thu, 10 Dec 2009 09:12:35 +0100 Message-ID: <4B20AD73.2050500@web.de> References: <20091209174654.GA28056@amt.cnet> <4B1FEB2A.3090906@siemens.com> <20091209192333.GC8739@redhat.com> <4B200412.5090005@web.de> <20091209205006.GD8739@redhat.com> <4B201030.9030906@web.de> <20091210063617.GN7645@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1C374B923442468CDFC41D47" Cc: Marcelo Tosatti , Avi Kivity , Glauber de Oliveira Costa , kvm To: Gleb Natapov Return-path: Received: from fmmailgate03.web.de ([217.72.192.234]:40304 "EHLO fmmailgate03.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760450AbZLJIMa (ORCPT ); Thu, 10 Dec 2009 03:12:30 -0500 In-Reply-To: <20091210063617.GN7645@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1C374B923442468CDFC41D47 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Gleb Natapov wrote: > On Wed, Dec 09, 2009 at 10:01:36PM +0100, Jan Kiszka wrote: >> Gleb Natapov wrote: >>> On Wed, Dec 09, 2009 at 09:09:54PM +0100, Jan Kiszka wrote: >>>> Gleb Natapov wrote: >>>>> On Wed, Dec 09, 2009 at 07:23:38PM +0100, Jan Kiszka wrote: >>>>>> Marcelo Tosatti wrote: >>>>>>> Otherwise a zero apic base is loaded into KVM, which results >>>>>>> in interrupts being lost until a proper apic base with enabled=20 >>>>>>> bit set is loaded. >>>>>>> >>>>>>> Fixes WinXP migration in qemu-kvm origin/next. >>>>>>> >>>>>>> Signed-off-by: Marcelo Tosatti >>>>>>> >>>>>>> diff --git a/hw/apic.c b/hw/apic.c >>>>>>> index 627ff98..45a4d2b 100644 >>>>>>> --- a/hw/apic.c >>>>>>> +++ b/hw/apic.c >>>>>>> @@ -1131,6 +1131,11 @@ int apic_init(CPUState *env) >>>>>>> vmstate_register(s->idx, &vmstate_apic, s); >>>>>>> qemu_register_reset(apic_reset, s); >>>>>>> =20 >>>>>>> + /* apic_reset must be called before the vcpu threads are ini= tialized and load=20 >>>>>>> + * registers, in qemu-kvm. >>>>>>> + */ >>>>>>> + apic_reset(s); >>>>>>> + >>>>>>> local_apics[s->idx] =3D s; >>>>>>> return 0; >>>>>>> } >>>>>> Heals the issue I saw with Win2003 Server as well. >>>>>> >>>>>> Looks all a bit messy though. Hope we can establish a more regular= and >>>>>> less fragile model on the midterm. I wonder if it wouldn't be bett= er to >>>>>> do write-back of the local APIC state along with the register stat= e on >>>>>> vmrun (and only there!). The same would apply to things like mpsta= te, >>>>> Write back of mp state there is a bug and introduce races. Do write= back >>>>> of the whole APIC state there looks like a recipe for disaster. >>>> Please read the full suggestion: We will only write-back if we were >>>> going through a reset or vmload before. That removes the ugly kvm ho= oks >>>> from generic code and ensures proper ordering /wrt other write-backs= =2E >>>> IMHO, anything else will continue to cause headache like the above t= o us. >>>> >>> We can't postpone APIC loading till vmrun. This will race with >>> devices/other vcpus sending interrupts to the vcpu. APIC state of all= >>> vcpus should be up-to-date _before_ any vcpu or main loop starts >>> running. >> Simple to solve, just add another write-back point: vm_start. >> > So what's the point to have write-back for APIC in vmrun? It is always > wrong to do it there. Write-back is arch-specific and will never show up directly in vmrun or other generic code. Will update my original patch to make this discussion more concrete. Jan --------------enig1C374B923442468CDFC41D47 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 iEYEARECAAYFAksgrXMACgkQitSsb3rl5xTQKQCfbsmtW6sz7nXstxI5BjcvGqg2 W7cAoIILzKa0O5AkfvSQUWTr4pfIcc/G =TsWq -----END PGP SIGNATURE----- --------------enig1C374B923442468CDFC41D47--