On Sun, Mar 02, 2014 at 04:31:12PM +0200, Michael S. Tsirkin wrote:
> 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.
Also
arch/x86/include/asm/apicdef.h:#define APIC_XAPIC(x) ((x) >= 0x14)
> In any case, we really should also use old lapic version for
> compat machine types.
>
> --
> MST
