linux-kernel - Re: 3.2.1 Unable to reset IRR messages on boot

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: <20120320185841.GF29554@phenom.dumpdata.com>
Date:	Tue, 20 Mar 2012 14:58:41 -0400
From:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To:	Suresh Siddha <suresh.b.siddha@...el.com>
Cc:	Josh Boyer <jwboyer@...hat.com>, Ingo Molnar <mingo@...e.hu>,
	"H. Peter Anvin" <hpa@...or.com>, yinghai@...nel.org,
	linux-kernel@...r.kernel.org, kernel-team@...oraproject.org,
	midgoon@...il.com
Subject: Re: 3.2.1 Unable to reset IRR messages on boot

On Tue, Mar 20, 2012 at 11:12:58AM -0700, Suresh Siddha wrote:
> On Tue, 2012-03-20 at 05:40 -0400, Konrad Rzeszutek Wilk wrote:
> > I think there are three ways of fixing this:
> > 
> >  1). Revert Suresh's patch and look at just removing the "Unable to reset IRR" warning
> >     (perhaps by being conditional on running in kexec-env?).
> > 
> >  2). Make the Xen layer fake out an IOAPIC - so instead of 0xffffff, make sure to
> >      clear the three bits that Suresh' patch is testing for (Ewwwww, I don't actually
> >      like that - that stinks of a hack).
> > 
> >  3). Rework Suresh's patch - to only remove the IOAPIC entry if there is no
> >      INT_SRV_OVR that depend on it. I made a stab at it and here is draft patch, that
> >      looks to work on my boxes that have more than one IOAPIC and are booting under Xen:
> >      But I am not 100% confident about it so would appreciate somebody looking at it.
> > 
> 
> Thanks for looking at this Konrad. This issue is not just specific to
> INT_SRC_OVR per-say.
> 
> Issue is that Xen though it doesn't use IO-APIC, it does depend on
> proper IO-APIC parsing for various things like getting proper gsi_top,
> INT_SRV_OVR entries etc.
> 
> I think Xen should be setting up a valid dummy IO-APIC mapping instead
> of working around.

Then this fixes the issue - thought if there are more checks in the future
it will have to be redone..:

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 988828b..b8e2794 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1859,6 +1859,7 @@ pgd_t * __init xen_setup_kernel_pagetable(pgd_t *pgd,
 #endif	/* CONFIG_X86_64 */
 
 static unsigned char dummy_mapping[PAGE_SIZE] __page_aligned_bss;
+static unsigned char fake_ioapic_mapping[PAGE_SIZE] __page_aligned_bss;
 
 static void xen_set_fixmap(unsigned idx, phys_addr_t phys, pgprot_t prot)
 {
@@ -1899,7 +1900,7 @@ static void xen_set_fixmap(unsigned idx, phys_addr_t phys, pgprot_t prot)
 		 * We just don't map the IO APIC - all access is via
 		 * hypercalls.  Keep the address in the pte for reference.
 		 */
-		pte = pfn_pte(PFN_DOWN(__pa(dummy_mapping)), PAGE_KERNEL);
+		pte = pfn_pte(PFN_DOWN(__pa(fake_ioapic_mapping)), PAGE_KERNEL);
 		break;
 #endif
 
@@ -2064,6 +2065,7 @@ void __init xen_init_mmu_ops(void)
 	pv_mmu_ops = xen_mmu_ops;
 
 	memset(dummy_mapping, 0xff, PAGE_SIZE);
+	memset(fake_ioapic_mapping, 0xfd, PAGE_SIZE);
 }
 
 /* Protected by xen_reservation_lock. */
> 
> thanks,
> suresh
--
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/