linux-kernel - Re: [PATCH 2/2] xen/x86: Implement x86_apic

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:	Wed, 18 Apr 2012 17:03:09 -0400
From:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To:	"Zhang, Xiantao" <xiantao.zhang@...el.com>
Cc:	Lin Ming <mlin@...pku.edu.cn>, "mingo@...e.hu" <mingo@...e.hu>,
	"Siddha, Suresh B" <suresh.b.siddha@...el.com>,
	"jwboyer@...hat.com" <jwboyer@...hat.com>,
	"hpa@...or.com" <hpa@...or.com>,
	"yinghai@...nel.org" <yinghai@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] xen/x86: Implement x86_apic_ops

> > > > +unsigned int xen_io_apic_read(unsigned apic, unsigned reg) {
> > > > +       if (reg == 0x1)
> > > > +               return 0x00170020;
> > > > +       else if (reg == 0x0)
> > > > +               return apic << 24;
> > >
> > > Why is fixed value returned?
> > >
> > > Can't we implement it with hypercall(PHYSDEVOP_apic_read)?
> > 
> > We sure can. But this was meant to fix the regression - so I figured we would
> > do that later on. But the more important question is - do we actually need to
> > do the hypercall? We aren't using the IOAPIC for anything - we don't program
> > the pins from dom0.
> 
>  Actually, dom0 doesn't programe ioapic pins directly as you said,  but the work is done by dom0 in the indirect way.  For dom0,  I added a hypercall PHYSDEVOP_setup_gsi before, and with this hypercall, we can get rid of programing IOAPIC pins from dom0 and hypervisor helps to do the ioapic programming, but we still need to get correct GSI information from hypervisor, otherwise, the hypercall may meet issues.  

The GSI information (I think of the polarity and trigger, and as well
which PCI devices pins correspond to what interrupt) is retrieved via the ACPI _PRT.

The IO-APIC isn't used at all - instead the code in arch/x86/pci/xen.c is utilized
which does the appropiate lookup and invokes the proper hypercall to bind an
PIRQ (GSI) to an event channel (and the event channel is then binded to the Linux
IRQ subsystem).

The hypercall - PHYSDEVOP_apic_read can be implemented here - and I am
more than open for folks to submit a patch for it - but it does not affect
how GSI/IO-APIC programming is done. This will just report proper IO-APIC
information instead of the fabricated one.
--
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/