qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Andreas Färber" <afaerber@suse.de>
To: Eduardo Habkost <ehabkost@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>, Bandan Das <bsd@redhat.com>,
	qemu-devel@nongnu.org, Anthony Liguori <aliguori@amazon.com>,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] target-i386: enable x2apic by default on more recent CPU models
Date: Tue, 04 Feb 2014 15:12:43 +0100	[thread overview]
Message-ID: <52F0F55B.5050103@suse.de> (raw)
In-Reply-To: <20140203190114.GL24353@otherpad.lan.raisama.net>

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.

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. 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	other threads:[~2014-02-04 14:13 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-20 14:36 [Qemu-devel] [PATCH] target-i386: enable x2apic by default on more recent CPU models Eduardo Habkost
2014-01-20 16:27 ` Andreas Färber
2014-01-20 16:50   ` Eduardo Habkost
2014-01-20 22:18     ` Andreas Färber
2014-01-20 22:13 ` Andreas Färber
2014-01-21 10:03   ` Paolo Bonzini
2014-01-21 14:06     ` Eduardo Habkost
2014-01-21 15:51     ` Andreas Färber
2014-01-21 16:13       ` Paolo Bonzini
2014-02-03 19:01         ` Eduardo Habkost
2014-02-04 14:12           ` Andreas Färber [this message]
2014-02-06 14:33             ` [Qemu-devel] Enabling x2apic by default in KvM (was Re: [PATCH] target-i386: enable x2apic by default on more recent CPU models) Eduardo Habkost
2014-02-17 13:58             ` [Qemu-devel] [PATCH] target-i386: enable x2apic by default on more recent CPU models Michael S. Tsirkin
2014-02-17 14:47               ` Eduardo Habkost
2014-02-17 16:17               ` Andreas Färber
2014-02-17 17:27                 ` Eduardo Habkost
2014-01-21 16:20       ` Eduardo Habkost
2014-01-21 14:06   ` Eduardo Habkost
  -- strict thread matches above, loose matches on Subject: below --
2013-09-20 19:15 [Qemu-devel] [PATCH] target-i386: Enable " Eduardo Habkost
2013-09-22  6:36 ` Gleb Natapov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52F0F55B.5050103@suse.de \
    --to=afaerber@suse.de \
    --cc=aliguori@amazon.com \
    --cc=bsd@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).