From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NFods-0000Le-8H for qemu-devel@nongnu.org; Wed, 02 Dec 2009 07:49:12 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NFodn-0000Hn-Do for qemu-devel@nongnu.org; Wed, 02 Dec 2009 07:49:11 -0500 Received: from [199.232.76.173] (port=56488 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NFodn-0000HQ-9p for qemu-devel@nongnu.org; Wed, 02 Dec 2009 07:49:07 -0500 Received: from mx1.redhat.com ([209.132.183.28]:58065) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NFodm-0008F1-Qy for qemu-devel@nongnu.org; Wed, 02 Dec 2009 07:49:07 -0500 Date: Wed, 2 Dec 2009 14:49:04 +0200 From: Gleb Natapov Message-ID: <20091202124904.GF9537@redhat.com> References: <1259671897-22232-1-git-send-email-glommer@redhat.com> <20091202105927.GB9537@redhat.com> <4B1657C0.20104@siemens.com> <20091202122250.GC9537@redhat.com> <4B165CC3.4060805@siemens.com> <20091202123039.GE9537@redhat.com> <4B165E87.7090503@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B165E87.7090503@siemens.com> Subject: [Qemu-devel] Re: [PATCH v2 0/11] List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: "qemu-devel@nongnu.org" , Glauber Costa , "avi@redhat.com" , "agraf@suse.de" , "aliguori@us.ibm.com" On Wed, Dec 02, 2009 at 01:33:11PM +0100, Jan Kiszka wrote: > Gleb Natapov wrote: > > On Wed, Dec 02, 2009 at 01:25:39PM +0100, Jan Kiszka wrote: > >> Gleb Natapov wrote: > >>> On Wed, Dec 02, 2009 at 01:04:16PM +0100, Jan Kiszka wrote: > >>>> Gleb Natapov wrote: > >>>>> On Tue, Dec 01, 2009 at 10:51:26AM -0200, Glauber Costa wrote: > >>>>>> This is a repost of the -smp series. Note that it depends on irqchip-in-kernel, > >>>>>> that is already in staging. Also, you'll have to enable the io-thread, for the time > >>>>>> being. > >>>>>> > >>>>>> >From the last version, main change is that I am not calling queue_work automatically > >>>>>> from vcpu ioctls. queue_work is only used currently for the gdb stub. > >>>>>> > >>>>>> All other uses were by-passed by the new qemu_register_vcpu_reset(), since most > >>>>>> of it uses (all racy) came from the reset handlers. > >>>>>> > >>>>> Looks good to me except one thing. I don't see how you are addressing > >>>>> the problem fixed by commit b8a7857071b477b28d3055e33ff0298fc91f329a > >>>>> in qemu-kvm. The problem is that mp_state can change in kernel between > >>>>> call to kvm_cpu_synchronize_state() and vcpu re-entry. In this case old > >>>>> mp_state will overwrite new one. > >>>> + nmi_pending > >>>> + sipi_vector > >>>> > >>>> These things need to be fixed at kernel level as discussed recently: > >>>> Asynchronous changes done by in-kernel subsystems need to be queued and > >>>> replayed with a higher priority than user space changes. User space need > >>>> to stop the vm if it does not want to be overruled. > >>>> > >>> Long term yes. Short term qemu need to work with existing kernels. > >> Avi's answer was different [1]. > >> > >> Jan > >> > >> [1] http://permalink.gmane.org/gmane.comp.emulators.kvm.devel/43288 > >> > > I don't think we can realistically fix all older kernels. Anyway if the > > workaround for the bug will not be done in qemu we need to fix it in kernel > > ASAP and start to propagate it to stable releases. > > > > Upstream could still easily deny in-kernel irqchip support if the host > kvm is not recent enough. qemu-kvm currently has a different policy /wrt > old kvm modules, so we may work around the mp_state and vcpu_events > issues there (just cleaner than so far). > There is no kernel (released or not) that has the bug fixed. So you say lets always disable everything that this patchset adds? -- Gleb.