From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:35047) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RBhuj-0001AL-MC for qemu-devel@nongnu.org; Thu, 06 Oct 2011 02:58:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RBhui-0005gd-8X for qemu-devel@nongnu.org; Thu, 06 Oct 2011 02:58:41 -0400 Received: from fmmailgate02.web.de ([217.72.192.227]:55245) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RBhuh-0005gQ-SV for qemu-devel@nongnu.org; Thu, 06 Oct 2011 02:58:40 -0400 Message-ID: <4E8D5199.8030306@web.de> Date: Thu, 06 Oct 2011 08:58:33 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1317726818-8514-1-git-send-email-pingfank@linux.vnet.com> <1317726818-8514-4-git-send-email-pingfank@linux.vnet.com> <4E8B3794.9040301@web.de> <4E8C38F3.2070504@web.de> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5FE58B75F983D21CC85EF47B" Sender: jan.kiszka@web.de Subject: Re: [Qemu-devel] [PATCH 2/2] LAPIC: make lapic support cpu hotplug List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: liu ping fan Cc: aliguori@us.ibm.com, pingfank@linux.vnet.ibm.com, kvm@vger.kernel.org, qemu-devel@nongnu.org, ryanh@us.ibm.com, avi@redhat.com This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5FE58B75F983D21CC85EF47B Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2011-10-06 03:13, liu ping fan wrote: > On Wed, Oct 5, 2011 at 7:01 PM, Jan Kiszka wrote: >> On 2011-10-05 12:26, liu ping fan wrote: >>>> > And make the creation of apic as part of cpu initialization, so >>>>> apic's state has been ready, before setting kvm_apic. >>>> >>>> There is no kvm-apic upstream yet, so it's hard to judge why we need= >>>> this here. If we do, this has to be a separate patch. But I seriousl= y >>>> doubt we need it (my hack worked without it, and that was not becaus= e of >>>> its hack nature). >>>> >>>> Sorry, I did not explain it clearly. What I mean is that =93env->api= c_state=94 >>> must be prepared >>> before qemu_kvm_cpu_thread_fn() -> ... -> kvm_put_sregs(), where we g= et >>> apic_base by >>> =93 sregs.apic_base =3D cpu_get_apic_base(env->apic_state);=94 >>> and then call =93kvm_vcpu_ioctl(env, KVM_SET_SREGS, &sregs);=94 which= will >>> finally affect the >>> kvm_apic structure in kernel. >>> >>> But as current code, in pc_new_cpu(), we call apic_init() to initiali= ze >>> apic_state, after cpu_init(), >>> so we can not guarantee the order of apic_state initializaion and the= >>> setting to kernel. >>> >>> Because LAPIC is part of x86 chip, I want to move it into cpu_x86_ini= t(), >>> and ensure apic_init() >>> called before thread =93qemu_kvm_cpu_thread_fn()=94 creation. >> >> The LAPIC is part of the CPU, the classic APIC was a dedicated chip. > Sorry, a little puzzle. I think x86 interrupt system consists of two > parts: IOAPIC/LAPIC. > For we have "hw/ioapic.c" to simulate IOAPIC, I think "hw/apic.c" > takes the role as LAPIC, > especially that we create an APICState instance for each CPUX86State, > just like each LAPIC > for x86 CPU in real machine. > So we can consider apic_init() to create a LAPIC instance, rather than > create a "classic APIC"? >=20 > I guess If there is lack of something in IOAPIC/LAPIC bus topology, > that will be the arbitrator of ICC bus, right? > So "the classic APIC was a dedicated chip" what you said, play this > role, right? > Could you tell me a sample chipset of APIC, and I can increase my > knowledge about it, thanks. The 82489DX was used as a discrete APIC on 486 SMP systems. >=20 >> >> For various reasons, a safer approach for creating a new CPU is to sto= p >> the machine, add the new device models, run cpu_synchronize_post_init = on >> that new cpu (looks like you missed that) and then resume everything. >> See >> http://git.kiszka.org/?p=3Dqemu-kvm.git;a=3Dcommitdiff;h=3Dbe8f21c6b54= eac82f7add7ee9d4ecf9cb8ebb320 >> > Great job. And I am interesting about it. Could you give some sample > reason about why we need to stop > the machine, or list all of the reasons, so we can resolve it one by > one. I can not figure out such scenes by myself. > From my view, especially for KVM, the creation of vcpu are protected > well by lock mechanism from other > vcpu threads in kernel, so we need not to stop all of the threads. Maybe I was seeing ghosts: I thought that there is a race window between VCPU_CREATE and the last initialization IOCTL when we allow other VCPUs to interact with the new one already. However, I do not find the scenario again ATM. But if you want to move the VCPU resource initialization completely over the VCPU thread, you also have to handle env->halted in that context. See [1] for this topic and associated todos. And don't forget the cpu_synchronize_post_init. Running this after each VCPU creation directly should also obsolete cpu_synchronize_all_post_init= =2E Jan [1] http://thread.gmane.org/gmane.comp.emulators.qemu/100806 --------------enig5FE58B75F983D21CC85EF47B 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.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6NUZwACgkQitSsb3rl5xQuPACfXsB+dkxi4d+ih2V8gsK4aEMr I3oAn3DOIEmyxI7YoxnV5qZzWvihOWIC =zYJm -----END PGP SIGNATURE----- --------------enig5FE58B75F983D21CC85EF47B--