linux-kernel - Re: [PATCH] xen: do not clear and mask evtchns in __xen_evtchn_do

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: <alpine.DEB.2.00.1104051211420.16492@kaball-desktop>
Date:	Tue, 5 Apr 2011 12:19:27 +0100
From:	Stefano Stabellini <stefano.stabellini@...citrix.com>
To:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
CC:	Stefano Stabellini <Stefano.Stabellini@...citrix.com>,
	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Jeremy Fitzhardinge <Jeremy.Fitzhardinge@...rix.com>
Subject: Re: [PATCH] xen: do not clear and mask evtchns in
 __xen_evtchn_do_upcall

On Mon, 4 Apr 2011, Konrad Rzeszutek Wilk wrote:
> > I reworded this part of the commit message, see below updated patch.
> > 
> [looking]
> .. snip..
> > > Can you expand? As in for the GSI? Or for the MSI/MSI-X?
> > 
> > Linux on native would use handle_edge_irq for edge irqs and msis, and
> > handle_fasteoi_irq for everything else.
> 
> What about per_cpu one?
> 

That is the simplest case, we are already using the same semantic as in
the native code.


> > > OK. You need a big comment about this in the code. Explain
> > > why this is happening. B/c if you look at this from code
> > > it seems like wrong thing to do for gsi's (as in you would
> > > think handle_level_irq would the right choice).
> > 
> > Except handle_level_irq is not used anymore anywhere in the kernel, give
> > a look at arch/x86/kernel/apic/io_apic.c:ioapic_register_intr.
> 
> 'make_8259A_irq' ? But yeah, I don't think we will hit machines with
> that architecture anymore.

Actually I was looking at:

setup_IO_APIC_irqs -> __io_apic_setup_irqs -> io_apic_setup_irq_pin



> > Updated patch, rebased on 2.6.39-rc1 follows:
> > 
> > ---
> > 
> > 
> > commit 6978531913b45abf3aff048475a2174a2cdaf288
> > Author: Stefano Stabellini <stefano.stabellini@...citrix.com>
> > Date:   Tue Mar 29 14:15:06 2011 +0000
> > 
> >     xen: do not clear and mask evtchns in __xen_evtchn_do_upcall
> >     
> >     Change the irq handler of virqs and pirqs that don't need EOI (pirqs
> >     that correspond to physical edge interrupts) to handle_edge_irq.
> >     
> >     Use handle_fasteoi_irq for pirqs that need eoi (they generally
> >     correspond to level triggered irqs), no risk in loosing interrupts
> >     because we have to EOI the irq anyway.
> >     
> >     This change has the following benefits:
> >     
> >     - it uses the very same handlers that Linux would use on native for the
> >     same irqs (handle_edge_irq for edge irqs and msis, and
>                                                    ^^^-'MSIs/MSI-Xs'
> >     handle_fasteoi_irq for everything else);
> >     
> >     - it uses these handlers in the same way Linux would use them: it let
>                                                                            ^- 's'
> 
> >     Linux mask\unmask and ack the irq when Linux want to mask\unmask and ack
>                                                        ^- 's'
> >     the irq;
> >     
> >     See genericirq in the kernel docbook docs for more informations.
> 
> Say 'Documentation/DocBook/genericirq.tmpl'
> 
> [edit: The patch looks OK to me, but let me think about this some more over this
> week and sketch out the flow].

done

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