linux-kernel - Re: Info: mapping multiple BARs. Your kernel is fine.

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 for Android: free password hash cracker in your pocket

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

Message-ID: <1395322983.2721.12.camel@rzhang1-mobl4>
Date:	Thu, 20 Mar 2014 21:43:03 +0800
From:	Zhang Rui <rui.zhang@...el.com>
To:	"Yan, Zheng" <zheng.z.yan@...el.com>
Cc:	Stephane Eranian <eranian@...gle.com>,
	"Lu, Aaron" <aaron.lu@...el.com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Borislav Petkov <bp@...en8.de>,
	lkml <linux-kernel@...r.kernel.org>,
	"x86@...nel.org" <x86@...nel.org>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Linux PCI <linux-pci@...r.kernel.org>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	Yinghai Lu <yinghai@...nel.org>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: Info: mapping multiple BARs. Your kernel is fine.

On Thu, 2014-03-20 at 16:16 +0800, Yan, Zheng wrote:
> On 03/20/2014 03:53 PM, Zhang, Rui wrote:
> > The resource length is also hardcoded to 0x6000, right?
> > This is probably a problem, because
> > only if the resource length read from PCI config space is larger than 0x4000,
> > drivers/pnp/quirks.c will detect the conflict and disable the PNP0C02
> > resource 0xfed10000 - 0xfed13fff, and the PCI device can request this
> > resource successfully.
> > In order to check this, can you please attach the dmesg output after boot?
> 
> maybe the issue can be fixed by below untested patch
> 
> ---
> diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.c b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
> index fd5e883..2b3d834 100644
> --- a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
> +++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
> @@ -1701,7 +1701,7 @@ static struct uncore_event_desc snb_uncore_imc_events[] = {
>  #define SNB_UNCORE_PCI_IMC_BAR_OFFSET		0x48
>  
>  /* page size multiple covering all config regs */
> -#define SNB_UNCORE_PCI_IMC_MAP_SIZE		0x6000
> +#define SNB_UNCORE_PCI_IMC_MAP_SIZE		0x8
>  
>  #define SNB_UNCORE_PCI_IMC_DATA_READS		0x1
>  #define SNB_UNCORE_PCI_IMC_DATA_READS_BASE	0x5050
> @@ -1736,7 +1736,8 @@ static void snb_uncore_imc_init_box(struct intel_uncore_box *box)
>  
>  	addr &= ~(PAGE_SIZE - 1);
>  
> -	box->io_addr = ioremap(addr, SNB_UNCORE_PCI_IMC_MAP_SIZE);
> +	box->io_addr = ioremap(addr + SNB_UNCORE_PCI_IMC_CTR_BASE,
> +			       SNB_UNCORE_PCI_IMC_MAP_SIZE);

you're remapping 0xfed15050 - 0xfed1b04f instead of 0xfed10000 -
0xfed15fff ?
I do not quite understand this, but apparently this is not a FIX.
If it works for this problem, it is because 0xfed15050 - 0xfed1b04f
happens to be not conflict with any resource reserved by PNP system
driver, on this machine.

thanks,
rui

>  	box->hrtimer_duration = UNCORE_SNB_IMC_HRTIMER_INTERVAL;
>  }
>  
> @@ -1832,7 +1833,7 @@ static int snb_uncore_imc_event_init(struct perf_event *event)
>  	}
>  
>  	/* must be done before validate_group */
> -	event->hw.event_base = base;
> +	event->hw.event_base = base - SNB_UNCORE_PCI_IMC_CTR_BASE;
>  	event->hw.config = cfg;
>  	event->hw.idx = idx;
>  


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