qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH] target-i386: enable x2apic by default on more recent CPU models
Date: Mon, 17 Feb 2014 15:58:13 +0200

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?

> 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.

> So my question still is, what rule can
> we apply for enabling x2apic? (something like greater or equal this
> family, etc. - then we can put it in your post_initialize hook so that
> users can still override it)
> 
> Regards,
> Andreas
> 
> -- 
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



reply via email to

[Prev in Thread] Current Thread [Next in Thread]