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: <4814FED5.4090509@zytor.com>
Date:	Sun, 27 Apr 2008 15:31:49 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
CC:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Breakage caused by unreviewed patch in x86 tree

James Bottomley wrote:
>>> Yes, that's the one ... but I believe a class of the xAPICs also used a
>>> similar principle.
>> I certainly have never seen a system on which the APIC has been mapped 
>> cacheable.  I would be very interested in the details, so if you could 
>> elaborate that would be extremely useful.
> 
> Not really ... I just remember when the SAPIC and later the xAPIC
> details were published as novel nearly a decade ago, I remember saying
> that some of the voyager interrupt controllers had been using a similar
> method for years.
> 

Well, I just looked up the xAPIC spec, and it states very clearly:

APIC registers are memory-mapped to a 4-KByte region of the processor’s 
physical address space with an initial starting address of FEE00000H. 
For correct APIC operation, this address space must be mapped to an area 
of memory that has been designated as strong uncacheable (UC). See 
Section 10.3, “Methods of Caching Available.”

So any use of cacheline-related bus cycles is generated by the LAPIC and 
doesn't affect the CPU <-> LAPIC interface.

	-hpa


--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ