linux-kernel - Re: [Patch v4 0/8] Consolidate ACPI PCI root common code into ACPI core

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: <1433437026.24429.38.camel@deneb.redhat.com>
Date:	Thu, 04 Jun 2015 12:57:06 -0400
From:	Mark Salter <msalter@...hat.com>
To:	Jiang Liu <jiang.liu@...ux.intel.com>
Cc:	Hanjun Guo <hanjun.guo@...aro.org>, Al Stone <ahs3@...hat.com>,
	"Rafael J . Wysocki" <rjw@...ysocki.net>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Marc Zyngier <marc.zyngier@....com>,
	Liviu Dudau <Liviu.Dudau@....com>,
	Yijing Wang <wangyijing@...wei.com>,
	Lv Zheng <lv.zheng@...el.com>,
	"lenb @ kernel . org" <lenb@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>, linux-pci@...r.kernel.org,
	linux-acpi@...r.kernel.org, "x86 @ kernel . org" <x86@...nel.org>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [Patch v4 0/8] Consolidate ACPI PCI root common code into ACPI
 core

On Fri, 2015-06-05 at 00:29 +0800, Jiang Liu wrote:
> On 2015/6/4 23:51, Mark Salter wrote:
> > On Thu, 2015-06-04 at 14:41 +0800, Jiang Liu wrote:
> >> On 2015/6/4 14:31, Hanjun Guo wrote:
> >>> Hi Jiang,
> >>>
> >>> On 2015年06月04日 09:54, Jiang Liu wrote:
> >>>> On 2015/6/4 4:27, Al Stone wrote:
> >>>>> On 06/02/2015 12:12 AM, Jiang Liu wrote:
> >>>>>> This patch set consolidates common code to support ACPI PCI root on x86
> >>>>>> and IA64 platforms into ACPI core, to reproduce duplicated code and
> >>>>>> simplify maintenance. And a patch set based on this to support ACPI
> >>>>>> based
> >>>>>> PCIe host bridge on ARM64 has been posted at:
> >>>>>
> >>>>> Link is missing (or it's a typo of some flavor).
> >>>> HI Al,
> >>>>     Sorry, I missed the link. It has been posted at:
> >>>> https://lkml.org/lkml/2015/5/26/207
> >>>
> >>> I failed to get io resources for PCI hostbridge  when I was testing PCI
> >>> on ARM64 QEMU, I debugged this for quite a while, and finally found out
> >>> that ACPI resource parsing for IO is not suitable for ARM64, because io
> >>> space for x86 is 64K, but 16M for ARM64.
> >>>
> >>> This issue is only found when the firmware representing the io resource
> >>> using the type ACPI_RESOURCE_TYPE_ADDRESS32, so the io address will
> >>> greater than 64k.
> >>>
> >>> In drivers/acpi/resource.c:
> >>>
> >>> static void acpi_dev_ioresource_flags(struct resource *res, u64 len,
> >>>                                       u8 io_decode, u8 translation_type)
> >>> {
> >>>         res->flags = IORESOURCE_IO;
> >>>
> >>> [...]
> >>>
> >>>         if (res->end >= 0x10003)
> >>>                 res->flags |= IORESOURCE_DISABLED | IORESOURCE_UNSET;
> >>>
> >>> [...]
> >>> }
> >>>
> >>> so the code will filter out res->end >= 0x10003, and in my case, it will
> >>> more than 64K, so we can't get the IO resources.
> >>>
> >>> I got a question, why we use if (res->end >= 0x10003) here?
> >>> I mean 64k will be 0x10000, and in that case, we should use
> >>> if (res->end >= 0x10000) here, not 0x10003, any history behind that?
> >>
> >> Hi Hanjun,
> >> This is a special tricky for x86. You may read a dword(four bytes) from
> >> IO port 0xffff, so the effective io port space is 0x10003 bytes.
> >>
> > 
> > Is there something in ACPI spec which would limit PCI IO space to 64K?
> > PCI itself allows 32-bit IO addresses and at least some arm64 platforms
> > use PCI bus addresses above 64K for IO transactions. From a PCI view,
> > the (res->end >= 0x10003) check doesn't make sense. Am I missing
> > something?
> HI Mark,
> 	Something interesting here. According to my understanding,
> the actually limitations are
> 1) the maximum size for each IO port space is 64k,

PCI bridges may support a full 4GiB IO space on a single bus.

See drivers/pci/probe.c:pci_read_bridge_io() where it checks to see if
bridge supports 32-bit IO space.

> 2) each PCI segment may only have one IO port space assigned at most.
> 
> Other than those, it's flexible for system designer to:
> 1) have multiple IO port spaces, each is 64K at most.
> 2) CPU may use MMIO transactions to access PCI IO space, and PCI host
>    bridge will do the translation from CPU side MMIO address to PCI side
>    IO port address.


> For example, we may have following configuration on IA64 platforms:
> 1) CPU side physical address [0x100000000-0x100010000] maps to IO space
>    [0x00000-0x10000] on PCI segment 0
> 2) CPU side physical address [0x100010000-0x100020000] maps to IO space
>    [0x00000-0x10000] on PCI segment 1
> And ACPI resource descriptor provides 'translation_offset' to support
> such an usage case. Hope this helps:)
> Thanks!
> Gerry
> > 
> > 
> > 


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