linux-kernel - Re: [PATCH 06/10] x86/PCI: Enable scanning of all pci functions

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, 13 May 2009 10:23:16 -0700
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	Ingo Molnar <mingo@...e.hu>,
	the arch/x86 maintainers <x86@...nel.org>,
	Matthew Wilcox <willy@...ux.intel.com>,
	Joerg Roedel <joerg.roedel@....com>,
	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Xen-devel <xen-devel@...ts.xensource.com>,
	Alex Nixon <alex.nixon@...rix.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com>
Subject: Re: [PATCH 06/10] x86/PCI: Enable scanning of all pci functions

On Wed, 13 May 2009 10:08:20 -0700
Jeremy Fitzhardinge <jeremy@...p.org> wrote:

> Jesse Barnes wrote:
> > On Tue, 12 May 2009 14:48:07 -0700
> > Jeremy Fitzhardinge <jeremy@...p.org> wrote:
> >
> >   
> >> From: Alex Nixon <alex.nixon@...rix.com>
> >>
> >> Xen may want to enable scanning of all pci functions - if for
> >> example the device at function 0 is not passed through to the
> >> guest, but the device at function 1 is.
> >>
> >> [Impact: allow passthrough of just some PCI functions.]
> >> Signed-off-by: Alex Nixon <alex.nixon@...rix.com>
> >> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com>
> >> Reviewed-by: "H. Peter Anvin" <hpa@...or.com>
> >> Reviewed-by: Matthew Wilcox <willy@...ux.intel.com>
> >> ---
> >>  arch/x86/include/asm/pci.h |    8 +++++++-
> >>  arch/x86/pci/common.c      |    1 +
> >>  2 files changed, 8 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/arch/x86/include/asm/pci.h
> >> b/arch/x86/include/asm/pci.h index b51a1e8..092706e 100644
> >> --- a/arch/x86/include/asm/pci.h
> >> +++ b/arch/x86/include/asm/pci.h
> >> @@ -21,6 +21,7 @@ struct pci_sysdata {
> >>  extern int pci_routeirq;
> >>  extern int noioapicquirk;
> >>  extern int noioapicreroute;
> >> +extern int pci_scan_all_fns;
> >>  
> >>  /* scan a bus after allocating a pci_sysdata for it */
> >>  extern struct pci_bus *pci_scan_bus_on_node(int busno, struct
> >> pci_ops *ops, @@ -48,7 +49,11 @@ extern unsigned int
> >> pcibios_assign_all_busses(void); #else
> >>  #define pcibios_assign_all_busses()	0
> >>  #endif
> >> -#define pcibios_scan_all_fns(a, b)	0
> >> +
> >> +static inline int pcibios_scan_all_fns(struct pci_bus *bus, int
> >> devfn) +{
> >> +	return pci_scan_all_fns;
> >> +}
> >>  
> >>  extern unsigned long pci_mem_start;
> >>  #define PCIBIOS_MIN_IO		0x1000
> >> @@ -130,6 +135,7 @@ extern void pci_iommu_alloc(void);
> >>  
> >>  /* generic pci stuff */
> >>  #include <asm-generic/pci.h>
> >> +#undef pcibios_scan_all_fns
> >>     
> >
> > This is a little gross... But then I don't see any places where it's
> > actually defined to something true either.
> 
> I've got some code to set it in a series I haven't posted yet.
> 
> >   Maybe it should be a weak
> > function or a new HAVE_FOO define instead.
> >   
> 
> I'd probably go the weak function path if I were to do either of
> those, but do you think it would be significantly better?

Well it would avoid the #undef, which is the gross part.  But since
it's just a boolean, you could also do

#ifndef PCI_SCAN_ALL_FNS
#define PCI_SCAN_ALL_FNS 0
#endif

in the generic code, then just set it to 1 before asm-generic/pci.h
gets included.  That would mean updating arch code though.

Anyway it's not a big deal, this code is already ugly (a 0 define for
all arches?  why?) so you shouldn't have to spend too much time
cleaning it up.

-- 
Jesse Barnes, Intel Open Source Technology Center
--
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/