From mboxrd@z Thu Jan 1 00:00:00 1970 From: OGAWA Hirofumi Subject: Re: nmi is broken? Date: Mon, 02 May 2011 23:30:55 +0900 Message-ID: <8739kxgoo0.fsf@devron.myhome.or.jp> References: <87sjtbe7fz.fsf@devron.myhome.or.jp> <877hak1t1s.fsf@devron.myhome.or.jp> <4DB3C6D3.9040703@redhat.com> <4DB41696.6060606@web.de> <4DB7DA11.8040503@redhat.com> <871v0njhab.fsf@devron.myhome.or.jp> <4DB93A6D.3010703@redhat.com> <87sjt2ij8b.fsf@devron.myhome.or.jp> <87k4eeihdu.fsf@devron.myhome.or.jp> <87mxj7urb0.fsf@devron.myhome.or.jp> <4DBE6F6B.6090103@redhat.com> Mime-Version: 1.0 Content-Type: text/plain Cc: Jan Kiszka , kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from mail.parknet.co.jp ([210.171.160.6]:49441 "EHLO mail.parknet.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757862Ab1EBObA (ORCPT ); Mon, 2 May 2011 10:31:00 -0400 In-Reply-To: <4DBE6F6B.6090103@redhat.com> (Avi Kivity's message of "Mon, 02 May 2011 11:46:35 +0300") Sender: kvm-owner@vger.kernel.org List-ID: Avi Kivity writes: > On 05/01/2011 04:45 AM, OGAWA Hirofumi wrote: >> > >> > Hm.., if smp was enabled, what configuration model is used by kvm? I >> > think this configuration model can't work on smp. >> >> As far as I can see, kvm is not configured (from MADT and some of >> behaviors) like you said. > > We may well have an error there; and our NMI-from-PIT emulation bypasses > all the wiring I described, so we may be emulating a configuration that > can't possibly exist on hardware. > >> So, I think there are some solutions, a) current behavior is right (I >> don't know why it's right though), b) fix the behavior of IO-APIC and >> MADT like you said, then linux can detect it, c) change the model to >> like mpspec figure 5-2, d) other. >> >> My suggestion is c) if there is no good d). Because current behavior >> looks like almost c), and non-legacy chipsets are using c) model as far >> as I know. > > You're probably right. However we can't just change it, we need to make > it an option, keeping the current configuration as the default. This is > so that live migration can work, and because 5-2 requires a new > kernel/user interface, to set IMCR.E0. > > Looking at figures 3-3 and 3-4 of the mpspec, the current model supports > 3-3 but not 3-4. Do we report that IMCR exists in the mptables? I don't think we have to implement IMCR, because it seems to be an optional. In fact, physical hardwares which I have don't report IMCR in mptables. (I don't see the benefit to implement it on recent chipsets even if it's possible. The virtual wire mode seems to be enough.) I don't know about live migration of kvm. If we said the wiring is like figure 5-2, what is required for the live migration? It was required only if IMCR was required? Thanks. -- OGAWA Hirofumi