Re: [Qemu-devel] [PATCH] target-i386: enable x2apic by default on more recent CPU models

[Eduardo Habkost]

On Mon, Feb 17, 2014 at 03:58:13PM +0200, Michael S. Tsirkin wrote:
> On Tue, Feb 04, 2014 at 03:12:43PM +0100, Andreas Färber wrote:
> > Am 03.02.2014 20:01, schrieb Eduardo Habkost:
> > > On Tue, Jan 21, 2014 at 05:13:50PM +0100, Paolo Bonzini wrote:
> > >> Il 21/01/2014 16:51, Andreas Färber ha scritto:
> > >>>>> We already do that for other bits (e.g. XSAVE/OSXSAVE),
> > >>> Please point me to the commit, a search for xsave did not come up with a
> > >>> commit changing such a thing - either it did not go through my queue or
> > >>> it slipped me through: Bugs are no excuse to produce more bugs.
> > >>
> > >> I meant that "-cpu SandyBridge" with TCG produces a CPU that doesn't
> > >> have XSAVE.
> > >>
> > >>>>> and in fact it
> > >>>>> is the same that we do for KVM: the KVM_GET_SUPPORTED_CPUID result is
> > >>>>> used to trim the generic feature bits.
> > >>> Our model definitions are the place to put stuff that real CPUs have.
> > >>> Either the CPU has it or it doesn't. If it does, then this patch is
> > >>> fully correct and it's TCG's job to mask things out. If we're adding
> > >>> artificial flags to the generic model definitions just to make KVM
> > >>> faster, then it is wrong - we have a choice of post_initialize and
> > >>> realize hooks for that.
> > >>
> > >> It would make TCG faster as well, and there would be no reason
> > >> really to avoid the "artificial" x2apic on TCG, if TCG implemented
> > >> x2apic at all.
> > > 
> > > So, the discussion seem to have stalled.
> > > 
> > > Andreas, are you still against the patch, after the arguments from Paolo
> > > and me?
> > 
> > Yes, I am. I had proposed to discuss solutions at FOSDEM but Paolo was
> > not there, so no solution yet.
> 
> We have the weekly call tomorrow.
> Let's discuss there?

Sounds good to me.

> 
> > My main concern still is that if a CPU does not have a certain feature
> > we should not list it as one of its features but add it to its features
> > where sensible. Just because TCG filters it out today is not keeping
> > anyone from implementing it tomorrow, in which case the emulated CPUs
> > would suddenly gain the feature.
> 
> Why is this a problem?
> We will just have to make sure features stay consistent
> for old -M machine types.

To be exact, we just have to make sure features stay consistent if
"enforce" is used, and "enforce" doesn't even work with TCG today. And
once we make "enforce" work with TCG, all the CPUs affected by this
patch won't even run with TCG+enforce.

-- 
Eduardo