linux-kernel - Re: [PATCH] x86: enable x2apic early at the first point

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090220090912.GA4632@redhat.com>
Date:	Fri, 20 Feb 2009 11:09:12 +0200
From:	Gleb Natapov <gleb@...hat.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Suresh Siddha <suresh.b.siddha@...el.com>,
	Yinghai Lu <yinghai@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86: enable x2apic early at the first point

On Fri, Feb 20, 2009 at 09:35:28AM +0100, Ingo Molnar wrote:
> 
> * Suresh Siddha <suresh.b.siddha@...el.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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/