linux-kernel - Re: [Bugfix v3] x86/PCI/ACPI: Fix regression caused by commit 63f1789ec716

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: <CAErSpo5aMwv5thgx+6195Cg+AM7FEeNJ_KDJj-pVCWGQp70XMg@mail.gmail.com>
Date:	Thu, 9 Apr 2015 17:00:08 -0500
From:	Bjorn Helgaas <bhelgaas@...gle.com>
To:	"Rafael J. Wysocki" <rjw@...ysocki.net>
Cc:	Jiang Liu <jiang.liu@...ux.intel.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	"x86@...nel.org" <x86@...nel.org>, Len Brown <lenb@...nel.org>,
	Lv Zheng <lv.zheng@...el.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>
Subject: Re: [Bugfix v3] x86/PCI/ACPI: Fix regression caused by commit 63f1789ec716

On Thu, Apr 9, 2015 at 4:37 PM, Rafael J. Wysocki <rjw@...ysocki.net> wrote:
> On Thursday, April 09, 2015 10:50:02 AM Jiang Liu wrote:
>> On 2015/4/9 7:44, Rafael J. Wysocki wrote:
>> > On Wednesday, April 08, 2015 01:48:46 PM Jiang Liu wrote:
>> >> On 2015/4/7 8:28, Rafael J. Wysocki wrote:
>> >>> On Friday, April 03, 2015 10:04:11 PM Bjorn Helgaas wrote:
>> >>>> Hi Jiang,
>> >> <snip>
>> >>>>> Currently acpi_dev_filter_resource_type() is only used by ACPI pci
>> >>>>> host bridge and IOAPIC driver, so it shouldn't affect other drivers.
>> >>>>
>> >>>> We should assume it will eventually be used for all ACPI devices,
>> >>>> shouldn't we?
>> >>>
>> >>> I'm not sure about that, really.  In fact, I'd restrict its use to devices
>> >>> types that actually can "produce" resources (ie. do not require the resources
>> >>> to be provided by their ancestors or to be available from a global pool).
>> >>>
>> >>> Otherwise we're pretty much guaranteed to get into trouble.
>> >>>
>> >>> And all of the above rules need to be documented in the kernel source tree
>> >>> or people will get confused.
>> >> Hi Rafael,
>> >>     How about following comments for acpi_dev_filter_resource_type()?
>> >> Thanks!
>> >> Gerry
>> >> --------------------------------------------------------------------
>> >> /**
>> >>  * According to ACPI specifications, Consumer/Producer flag in ACPI resource
>> >>  * descriptor means:
>> >>  *      1(CONSUMER): This device consumes this resource
>> >>  *      0(PRODUCER): This device produces and consumes this resource
>> >>  * But for ACPI PCI host bridge, it is interpreted in another way:
>> >
>> > So first of all, this leads to a question: Why is it interpreted for ACPI PCI
>> > host bridges differently?
>> >
>> > Is it something we've figured out from experience, or is there a standard
>> > mandating that?
>> Hi Rafael,
>>       I think we got this knowledge by experiences. PCI FW spec only
>> states _CRS reports resources assigned to the host bridge by firmware.
>> There's no statement about whether the resource is consumed by host
>> bridge itself or provided to it's child bus/devices. On x86/IA64 side,
>> the main resource consumed by PCI host bridge is IOPORT 0xCF8-0xCFF,
>> but not sure about ARM64 side. So how about:
>
> This:
>
>> PCI Firmware specification states that _CRS reports resources
>> assigned to the host bridge, but there's no way to tell whether
>> the resource is consumed by host bridge itself or provided to
>> its child bus/devices.
>
> looks OK to me, but I'd replace the below with something like:
>
> "However, experience shows, that in the PCI host bridge case firmware writers
>  expect the resource to be provided to devices on the bus (below the bridge) for
>  consumption entirely if its Consumer/Producer flag is clear.  That expectation
>  is reflected by the code in this routine as follows:".

What a mess.  The spec is regrettably lacking in Consumer/Producer
specifics.  But I don't see what's confusing about the descriptors
that have Consumer/Producer bits.

QWord, DWord, and Word descriptors don't seem to have a
Consumer/Producer bit, but they do contain _TRA, so they must be
intended for bridge windows.  Can they also be used for device
registers?  I don't know.

The Extended Address descriptor has a Consumer/Producer bit, and I
would interpret the spec to mean that if the flag is clear (the device
produces and consumes this resource), the resource is available on the
bus below the bridge, i.e., the bridge consumes the resource on its
upstream side and produces it on its downstream side.  If the bit were
set (the device only consumes the resource), I would expect that to
mean the descriptor is for bridge registers like 0xcf8/0xcfc that
never appear on the downstream side.

Maybe I'm reading the spec too naively, but this doesn't seem a matter
of experience.

>> So according to experiences, PCI host bridge
>> interprets Consumer/Producer flag as below to tell whether the resource
>> is consumed by host bridge itself.

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