Avi Kivity <avi@xxxxxxxxxx> 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 <hirofumi@xxxxxxxxxxxxxxxxxx> -- 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
