linux-kernel - Re: Fw: drivers/xen/pci.c:31:25: fatal error: asm/pci

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] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.02.1508071021040.11337@kaball.uk.xensource.com>
Date:	Fri, 7 Aug 2015 10:41:15 +0100
From:	Stefano Stabellini <stefano.stabellini@...citrix.com>
To:	Boris Ostrovsky <boris.ostrovsky@...cle.com>
CC:	Robert Richter <robert.richter@...iumnetworks.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	David Vrabel <david.vrabel@...rix.com>,
	"Tomasz Nowicki" <tn@...ihalf.com>,
	Will Deacon <will.deacon@....com>,
	<xen-devel@...ts.xenproject.org>,
	<linux-arm-kernel@...ts.infradead.org>,
	<linux-kernel@...r.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@...citrix.com>,
	<shannon.zhao@...aro.org>, Ian Campbell <Ian.Campbell@...rix.com>
Subject: Re: Fw: drivers/xen/pci.c:31:25: fatal error: asm/pci_x86.h: No such
 file or directory

On Thu, 6 Aug 2015, Boris Ostrovsky wrote:
> On 08/06/2015 01:04 PM, Robert Richter wrote:
> > Boris,
> > 
> > we are working on acpi pci support for arm64. For this we are enabling
> > PCI_MMCONFIG on arm64 which breaks compiling drivers/xen/pci.c.
> > 
> > Looking into it there is x86 code in generic driver code introduced
> > with:
> > 
> >   8deb3eb1461e xen/mcfg: Call PHYSDEVOP_pci_mmcfg_reserved for MCFG areas.
> > 
> > This implements:
> > 
> > diff --git a/drivers/xen/pci.c b/drivers/xen/pci.c
> > index 18fff88254eb..d15f6e80479f 100644
> > --- a/drivers/xen/pci.c
> > +++ b/drivers/xen/pci.c
> > @@ -26,6 +26,7 @@
> >   #include <asm/xen/hypervisor.h>
> >   #include <asm/xen/hypercall.h>
> >   #include "../pci/pci.h"
> > +#include <asm/pci_x86.h>
> >     static bool __read_mostly pci_seg_supported = true;
> >   @@ -192,3 +193,49 @@ static int __init register_xen_pci_notifier(void)
> >   }
> >     arch_initcall(register_xen_pci_notifier);
> > +
> > +#ifdef CONFIG_PCI_MMCONFIG
> > +static int __init xen_mcfg_late(void)
> > +{
> > +       struct pci_mmcfg_region *cfg;
> > +       int rc;
> > +
> > +       if (!xen_initial_domain())
> > +               return 0;
> > +
> > +       if ((pci_probe & PCI_PROBE_MMCONF) == 0)
> > +               return 0;
> > [...]
> > 
> > There are no defines for pci_probe and PCI_PROBE_MMCONF other than for
> > the x86 architecture.
> > 
> > I see several ways to fix that:
> > 
> >   * moving code to arch/x86/pci/xen.c,
> 
> If this routine is not going to be used by ARM I think this would be the way
> to go. Stefano --- will this be needed by ARM?

Yes, I think it is most probable that this code will be needed on ARM,
even though we are still at the design doc stage for Xen and ACPI on ARM
at the moment.

Besides I think you should be able to compile this function on arm64
just fine. The hypercall should build without issues. If the problem is
just this one check, we should be able to rework it somehow.

Is there something equivalent to pci_probe on arm? If not, we could just
ifdef the check for x86.


> > 
> >   * make code dependent on arch X86,
> > 
> >   * make 'if (pci_probe & PCI_PROBE_MMCONF) ...' an arch function to be
> >     implemented by archs,
> 
> Otherwise I'd go with this.

Or this of course


> -boris
> 
> > 
> >   * reworking the code by removing the check (not sure if that could be
> >     done).
> > 
> > I don't think PCI_XEN is enabled yet for arm64, so we just disalbe it
> > for !X86 or move it to arch/x86. I suggest the latter. Is there any
> > preference you have?
> 
--
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/