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 12:06:25 -0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Mon, Jan 20, 2014 at 11:13:11PM +0100, Andreas Färber wrote:
> Am 20.01.2014 15:36, schrieb Eduardo Habkost:
> > This enables x2apic on the following CPU models: Conroe, Penryn,
> > Nehalem, Westmere, Opteron_G[12345].
> > 
> > Normally we try to keep the CPU model definitions as close as the real
> > CPUs as possible, but x2apic can be emulated by KVM without host CPU
> > support for x2apic, and it improves performance by reducing APIC access
> > overhead. x2apic emulation is available on KVM since 2009 (Linux
> > 2.6.32-rc1), there's no reason for not enabling x2apic by default when
> > running KVM.
> > 
> > About testing: Conroe, Penryn, Nehalem, Westemere and Opteron_G[123]
> > have x2apic enabled on RHEL-6 since RHEL-6.0, so the presence of x2apic
> > on those CPU models got lots of testing in the last few years. I want to
> > eventually enable x2apic on all other CPU models as well, but it will
> > require some testing to ensure it won't confuse guests.
> > 
> > This shouldn't affect TCG at all because features not supported by TCG
> > are automatically and silently disabled by QEMU when initializing the
> > CPU.
> > 
> > Signed-off-by: Eduardo Habkost <address@hidden>
> > ---
> > v1 was sent in September 2013:
> >   Message-Id: <address@hidden>
> >   http://article.gmane.org/gmane.comp.emulators.qemu/234541
> > 
> > It got an Acked-by from Gleb but it was ignored by all maintainers.
> > ---
> >  hw/i386/pc_piix.c |  9 +++++++++
> >  hw/i386/pc_q35.c  |  9 +++++++++
> >  target-i386/cpu.c | 37 +++++++++++++++++++------------------
> >  3 files changed, 37 insertions(+), 18 deletions(-)
> [...]
> > diff --git a/target-i386/cpu.c b/target-i386/cpu.c
> > index 0eea8c7..8f4dcfd 100644
> > --- a/target-i386/cpu.c
> > +++ b/target-i386/cpu.c
> > @@ -798,7 +798,7 @@ static x86_def_t builtin_x86_defs[] = {
> >               CPUID_MCE | CPUID_PAE | CPUID_MSR | CPUID_TSC | CPUID_PSE |
> >               CPUID_DE | CPUID_FP87,
> >          .features[FEAT_1_ECX] =
> > -            CPUID_EXT_SSSE3 | CPUID_EXT_SSE3,
> > +            CPUID_EXT_X2APIC | CPUID_EXT_SSSE3 | CPUID_EXT_SSE3,
> >          .features[FEAT_8000_0001_EDX] =
> >              CPUID_EXT2_LM | CPUID_EXT2_NX | CPUID_EXT2_SYSCALL,
> >          .features[FEAT_8000_0001_ECX] =
> [snip]
> 
> I remember discussing about this before, but don't see an email reply,
> so maybe it was on IRC?
> 
> 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.

I am not relying on it to make it "correct", I just noted that this
specific change won't affect TCG. If TCG had x2apic, I would want to
enable it by default on TCG mode as well.

> 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()?

If TCG one day implements it, it will get enabled in TCG mode, and we
will want that, won't we?

(I thought we had already settled for _not_ making the CPU models look
different on KVM and TCG mode, to keep things simple in the code, and
keep things simple in management code that needs to probe for CPU model
information.)

-- 
Eduardo



reply via email to

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