linux-kernel - Re: [PATCH v2 08/13] ACPICA: Hardware: Add optimized access bit width support

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: <574771BB.7030307@oracle.com>
Date:	Thu, 26 May 2016 17:59:23 -0400
From:	Boris Ostrovsky <boris.ostrovsky@...cle.com>
To:	Jan Beulich <jbeulich@...e.com>
Cc:	ian.jackson@...citrix.com, zetalog@...il.com, len.brown@...el.com,
	lv.zheng@...el.com, rafael.j.wysocki@...el.com,
	robert.moore@...el.com, xen-devel@...ts.xen.org, rjw@...ysocki.net,
	linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 08/13] ACPICA: Hardware: Add optimized access bit width
 support

On 05/26/2016 12:55 PM, Boris Ostrovsky wrote:
> On 05/26/2016 12:26 PM, Jan Beulich wrote:
>>>>> Boris Ostrovsky <boris.ostrovsky@...cle.com> 05/25/16 9:17 PM >>>
>>> On 05/05/2016 12:58 AM, Lv Zheng wrote:
>>>> +static u8
>>>> +acpi_hw_get_access_bit_width(struct acpi_generic_address *reg, u8 max_bit_width)
>>>> +{
>>>> +    u64 address;
>>>> +
>>>> +    if (!reg->access_width) {
>>>> +        /*
>>>> +         * Detect old register descriptors where only the bit_width field
>>>> +         * makes senses. The target address is copied to handle possible
>>>> +         * alignment issues.
>>>> +         */
>>>> +        ACPI_MOVE_64_TO_64(&address, &reg->address);
>>>> +        if (!reg->bit_offset && reg->bit_width &&
>>>> +            ACPI_IS_POWER_OF_TWO(reg->bit_width) &&
>>>> +            ACPI_IS_ALIGNED(reg->bit_width, 8) &&
>>>> +            ACPI_IS_ALIGNED(address, reg->bit_width)) {
>>>> +            return (reg->bit_width);
>>>> +        } else {
>>>> +            if (reg->space_id == ACPI_ADR_SPACE_SYSTEM_IO) {
>>>> +                return (32);
>>> This (together with "... Add access_width/bit_offset support in
>>> acpi_hw_write") breaks Xen guests using older QEMU which doesn't support
>>> 4-byte IO accesses.
>>>
>>> Why not return "reg->bit_width?:max_bit_width" ? This will preserve
>>> original behavior.
>> Did you figure out why we get here in the first place, instead of taking the
>> first "return"? I.e. isn't the issue the apparently wrong use of the second
>> ACPI_IS_ALIGNED() above? Afaict it ought to be
>> ACPI_IS_ALIGNED(address, reg->bit_width / 8)...
> We are trying to access address 0x...b004 (PM1a control) so yes, fixing
> alignment check would probably resolve the problem that we are seeing now.
>
> However, for compatibility purposes we may consider not doing any checks
> and simply return bit_width if access_width is not available.


Interestingly enough I bisected what I thought was a completely
different problem to this patch as well.

Something is messed up with 32-bit dom0 booting (so no QEMU) on one
machine in my pool.  First error that I see is
    pcieport 0000:00:02.0: can't find IRQ for PCI INT A; probably buggy
MP table

I'll look at this tomorrow, hopefully.

-boris