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: Eduardo Habkost
Subject: Re: [Qemu-devel] [PATCH] target-i386: enable x2apic by default on more recent CPU models
Date: Tue, 21 Jan 2014 14:20:53 -0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Tue, Jan 21, 2014 at 04:51:42PM +0100, Andreas Färber wrote:
> Am 21.01.2014 11:03, schrieb Paolo Bonzini:
> > Il 20/01/2014 23:13, Andreas Färber ha scritto:
> >> I don't like the argument that we can put arbitrary stuff in our model
> >> definitions and rely on TCG not having implemented it to make it
> >> correct. Is x2apic something that TCG can never implement for some
> >> reason? Then that needs a better explanation. Otherwise, is there no
> >> criteria we can add this flag for when kvm_enabled()?
> > 
> > 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.
> 
> > 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.

I see this as a trade-off between 3 things:

1) Having the behavior of CPU models simple (having the predictable
   results not depending on things like kvm_enabled());
2) Having reasonable defaults out of the box;
3) Having the CPU models match real CPUs as closely as possible.

We can't have the three at the same time. Which item are we going to
let go?

Your suggestion seems to kill item 1 (and I thought we didn't want to).

To me 1 and 2 are more important: 1 is important to help us solve the
serious issues we have in the libvirt/QEMU interaction; 2 is important
because (I assume) we want to have good performance out of the box. I
see 3 as just a theoretical exercise that doesn't give us any benefit.


-- 
Eduardo



reply via email to

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