From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M0uEi-00067s-7w for qemu-devel@nongnu.org; Mon, 04 May 2009 05:13:20 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M0uEd-000608-3I for qemu-devel@nongnu.org; Mon, 04 May 2009 05:13:19 -0400 Received: from [199.232.76.173] (port=46181 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M0uEc-0005zt-SE for qemu-devel@nongnu.org; Mon, 04 May 2009 05:13:14 -0400 Received: from mx2.redhat.com ([66.187.237.31]:59497) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M0uEc-0003o7-8I for qemu-devel@nongnu.org; Mon, 04 May 2009 05:13:14 -0400 Message-ID: <49FEB186.8030605@redhat.com> Date: Mon, 04 May 2009 12:12:38 +0300 From: Avi Kivity MIME-Version: 1.0 References: <20090501211717.24514.23246.stgit@mchn012c.ww002.siemens.net> <20090501211721.24514.10182.stgit@mchn012c.ww002.siemens.net> <49FDBF20.1020207@redhat.com> <49FEAD2E.6080706@siemens.com> In-Reply-To: <49FEAD2E.6080706@siemens.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 8/8] kvm: Rework VCPU reset List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Anthony Liguori , qemu-devel@nongnu.org Jan Kiszka wrote: > Avi Kivity wrote: > >> Jan Kiszka wrote: >> >>> Use standard callback with highest order to synchronize VCPU on reset >>> after all device callbacks were execute. This allows to remove the >>> special kvm hook in qemu_system_reset. >>> >>> >> Is this needed for the lapic reset callback? >> >> If so, we can express the dependency explicitly rather than with a >> priority, by having cpu reset notifiers invoked when the cpu is reset. >> In the case of the lapic, I don't think we need an abstract mechanism; >> the lapic is part of the cpu, not some random device. >> >> Maybe we should even save/load it as part of the cpu. >> >> > > QEMU is not only providing the LAPIC, but also covering the old > dedicated version. That makes at least HW instantiating a bit more complex. > > What do you mean by 'old dedicated version'? -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.