On Sun, Mar 02, 2014 at 09:56:50AM +0100, Paolo Bonzini wrote: > Il 02/03/2014 01:17, Gabriel L. Somlo ha scritto: > >Although, on KVM, it's simply hardcoded to 0x14 rather than exposing to > >the guest whatever the host CPU's apic version happens to be, or > >trying to match it to the CPU model: > > > > > >[somlo@foober kvm]$ grep -i version arch/x86/kvm/lapic.c > >... > >/* 14 is the version for Xeon and Pentium 8.4.8*/ > >#define APIC_VERSION (0x14UL | ((APIC_LVT_NUM - 1) << 16)) > >... > > > > > >I'd honestly prefer to stick to 0x14 (because it's simple :) ) > > I'd also prefer that, because I like having the same for KVM and > TCG, but I'm not sure it'd fly with others. :) > > >but if you're sure that's a bad idea, how about the struct x86_def_t > >rather than qdev ? > > > >So far, only OS X seems to even care at all about the version... > > Andreas, Michael, what do you think? > > Paolo
I note that OSX is not the only one that cares, Linux does this: static int modern_apic(void) { /* AMD systems use old APIC versions, so check the CPU */ if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD && boot_cpu_data.x86 >= 0xf) return 1; return lapic_get_version() >= 0x14; } So I think this commit should include some documentation analysing the reasons that this is a safe change. In any case, we really should also use old lapic version for compat machine types. -- MST