public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Gleb Natapov <gleb@redhat.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Suresh Siddha <suresh.b.siddha@intel.com>,
	Yinghai Lu <yinghai@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] x86: enable x2apic early at the first point
Date: Fri, 20 Feb 2009 11:09:12 +0200	[thread overview]
Message-ID: <20090220090912.GA4632@redhat.com> (raw)
In-Reply-To: <20090220083528.GB24555@elte.hu>

On Fri, Feb 20, 2009 at 09:35:28AM +0100, Ingo Molnar wrote:
> 
> * Suresh Siddha <suresh.b.siddha@intel.com> wrote:
> 
> > On Thu, 2009-02-19 at 14:42 -0800, Yinghai Lu wrote:
> > > Ingo want to decouple that x2apic and intr_remapping.
> > > it seems it does work with x2apic without intr_remapping in one of setup.
> > 
> > x2apic with out intr-remapping is not architectural. Even when 
> > we have < 255 logical cpu's, logical x2apic id's will be 
> > greater than 16 bits even on a single/two socket systems and 
> > this will break interrupt delivery. Please look at the x2apic 
> > logical destination mode definition in the SDM (Section 
> > 9.7.2.3 and 9.7.2.4 in my copy of SDM Vol3a)
> >
This is what Intel doc says:
 It is likely that processor implementations may choose to support less
 than 16 bits of the cluster ID or less than 16-bits of the Logical ID
 in the Logical Destination Register.  However system software should be
 agnostic to the number of bits implemented in the cluster ID and logical
 ID sub-fields. The x2APIC hardware initialization will ensure that the
 appropriately initialized logical x2APIC IDs are available to system
 software and reads of non-implemented bits return zero.

KVM will implement 0 bits of cluster ID and will want to use x2apic without
implementing IR.

> > While it might work in certain configurations (for example, 
> > physical mode with < 8 bit apicids), it is not architectural 
> > and implementation dependent, which may break in future 
> > generations.
> > 
It will not break in future generation of KVM though.

> > And also, logical x2apic mode has more advantages compared to 
> > physical mode (like using lowest priority delivery mode etc).
> > 
> > I will post couple of patches, which revert's Gleb's patch and 
> > another fix for the early boot failure issue, tomorrow.
> 
If you'll revert my patch it will not be possible to use x2apic in
KVM (at least without KVM implementing interrupt remapping which is
unneeded otherwise) and x2apic interface is much better for vitalization.
Instead of reverting the patch it will be better to add check if x2apic
can be used without intr-remmaping (all CPUs belong to cluster 0) or
allow enabling of x2apic without IR if running as a guest.

--
			Gleb.

  reply	other threads:[~2009-02-20  9:12 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-19 21:50 [PATCH] x86: enable x2apic early at the first point Yinghai Lu
2009-02-19 22:13 ` Suresh Siddha
2009-02-19 22:42   ` Yinghai Lu
2009-02-19 23:28     ` Suresh Siddha
2009-02-20  8:35       ` Ingo Molnar
2009-02-20  9:09         ` Gleb Natapov [this message]
2009-02-20  9:41           ` Ingo Molnar
2009-02-20 10:58             ` Gleb Natapov
2009-02-20 11:06               ` Ingo Molnar
2009-02-20 11:06                 ` Gleb Natapov
2009-02-20 12:33                 ` Gleb Natapov
2009-02-20 12:59                   ` Ingo Molnar
2009-02-20  9:51 ` Ingo Molnar
2009-02-20  9:55   ` Ingo Molnar
2009-02-21 22:23     ` Suresh Siddha
2009-02-21 22:43       ` Yinghai Lu
2009-02-21 23:33         ` Suresh Siddha
2009-02-22 17:21       ` Ingo Molnar

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=20090220090912.GA4632@redhat.com \
    --to=gleb@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=suresh.b.siddha@intel.com \
    --cc=tglx@linutronix.de \
    --cc=yinghai@kernel.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