From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M0v0S-0003f5-5K for qemu-devel@nongnu.org; Mon, 04 May 2009 06:02:40 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M0v0M-0003dx-QK for qemu-devel@nongnu.org; Mon, 04 May 2009 06:02:38 -0400 Received: from [199.232.76.173] (port=40399 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M0v0M-0003dm-DO for qemu-devel@nongnu.org; Mon, 04 May 2009 06:02:34 -0400 Received: from mx2.redhat.com ([66.187.237.31]:53105) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M0v0L-0004cb-OA for qemu-devel@nongnu.org; Mon, 04 May 2009 06:02:34 -0400 Message-ID: <49FEBD13.7070501@redhat.com> Date: Mon, 04 May 2009 13:01:55 +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> <49FEB186.8030605@redhat.com> <49FEB55F.4060603@siemens.com> In-Reply-To: <49FEB55F.4060603@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: >> >>> 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'? >> > > Separate chip, not part of the CPU. Some 486 system used to have this IIRC. > > Yes, you're right. Maybe we can have a vcpu reset callback for the lapic. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.