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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
