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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20120320202546.GA29554@phenom.dumpdata.com>
Date:	Tue, 20 Mar 2012 16:25:46 -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 01:05:19PM -0700, Suresh Siddha wrote:
> On Tue, 2012-03-20 at 14:58 -0400, Konrad Rzeszutek Wilk wrote:
> > 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);
> 
> heh ;)
> 
> I was referring to setting up something little more valid. Like
> IO_APIC_reg_01 showing value of 0x00170020 etc. As the gsi computation
> actually refers to the number of redirection table entries supported by
> the IO-APIC.
> 
> Also does the dom0 see all the GSI's/io-apic's that the host sees or is
> it going to be just one io-apic? I was just wondering if the reg 01 need
> to be same as what the host sees?

It does not use the APIC mechanism at all. It only needs the GSI value
from the IOAPIC and LAPIC so that the ACPI can work. Then the ACPI _PRT values
are used to setup the GSI's (via hypercalls).

> 
> Anyways, instead of 0xfd, having sane fake register values will be a
> better start.

It could also at startup copy the original values and stick them in these copies.
That does mean using the memory allocator to allocate X copies for X IOAPICS. I
don't think the memory allocator is active at that stage since we using fixmaps.
Thoughts?
--
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/