linux-kernel - Re: [PATCH 1/2] x86, ioapic: Reserve only 128 bytes for IOAPICs

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]

Date:	Thu, 25 Aug 2011 16:33:44 -0700
From:	Suresh Siddha <suresh.b.siddha@...el.com>
To:	Bjorn Helgaas <bhelgaas@...gle.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	"RalfJungralfjung-e@....de" <RalfJungralfjung-e@....de>,
	Cyrill Gorcunov <gorcunov@...nvz.org>,
	Yinghai Lu <yinghai@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] x86, ioapic: Reserve only 128 bytes for IOAPICs

On Thu, 2011-08-25 at 16:05 -0700, Bjorn Helgaas wrote:
> Previously we reserved 1024 bytes, but that's more space than the IOAPIC
> consumes, and it can cause conflicts with nearby devices.  The known
> requirement is 68 bytes (sizeof(struct io_apic)), and rounding up to a
> power-of-2 gives us 128.
> 

Bjorn, Given the info from Intel that most of its io-apic
implementations has registers up to 0xff offset (reserved), does
reserving just the 128 bytes for the io-apic cause any address conflicts
if the next 128 bytes are allocated (by the OS) for any other device.

Or OS doesn't allocate this range to any other device and its only the
bios which allocates the addresses in this range and OS just ensures
that there are no conflicts?

thanks,
suresh

> The bug reported below is caused by the following assignments (the IOAPIC
> power-on default and the watchdog address recommended in the AMD SP5100
> BIOS Developer's Guide):
> 
>   IOAPIC[0]        at [mem 0xfec00000-0xfec003ff]
>   SP5100 TCO timer at [mem 0xfec000f0-0xfec000f7]
> 
> Reported-by: Ralf Jung ralfjung-e@....de
> Reference: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638863
> Cc: Cyrill Gorcunov <gorcunov@...nvz.org>
> Cc: Yinghai Lu <yinghai@...nel.org>
> Signed-off-by: Bjorn Helgaas <bhelgaas@...gle.com>
> ---
>  arch/x86/include/asm/apicdef.h |    7 ++++---
>  1 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/include/asm/apicdef.h b/arch/x86/include/asm/apicdef.h
> index 34595d5..855a18a 100644
> --- a/arch/x86/include/asm/apicdef.h
> +++ b/arch/x86/include/asm/apicdef.h
> @@ -12,10 +12,11 @@
>  #define	APIC_DEFAULT_PHYS_BASE		0xfee00000
>  
>  /*
> - * This is the IO-APIC register space as specified
> - * by Intel docs:
> + * I/O APICs are accessed indirectly via an index/data pair and an EOI
> + * register.  For example, see sec 13.5.1, "APIC Register Map," in the
> + * Intel ICH10 datasheet and the struct io_apic definition.
>   */
> -#define IO_APIC_SLOT_SIZE		1024
> +#define IO_APIC_SLOT_SIZE		128
>  
>  #define	APIC_ID		0x20
>  
> 


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