From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: nmi is broken? Date: Tue, 03 May 2011 12:36:01 +0300 Message-ID: <4DBFCC81.9080401@redhat.com> 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> <8739kxgoo0.fsf@devron.myhome.or.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jan Kiszka , kvm@vger.kernel.org To: OGAWA Hirofumi Return-path: Received: from mx1.redhat.com ([209.132.183.28]:22004 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751406Ab1ECJgH (ORCPT ); Tue, 3 May 2011 05:36:07 -0400 In-Reply-To: <8739kxgoo0.fsf@devron.myhome.or.jp> Sender: kvm-owner@vger.kernel.org List-ID: On 05/02/2011 05:30 PM, OGAWA Hirofumi wrote: > > > >> 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.) Okay. > 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? The issue with live migration is that we can't change the running configuration while the system is running, like adding the IMCR or changing the wiring. The hardware will be programmed for the old configuration and will likely fail with the new one. For example, the current wiring has the PIT output wired to PIC IRQ0 and IOAPIC INTI0; we need to change it to IOAPIC INTI2 instead. -- error compiling committee.c: too many arguments to function