Re: nmi is broken?

[Avi Kivity <avi@redhat.com>]

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