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:   Sun, 25 Jun 2023 19:54:27 +0800
From:   运辉崔 <cuiyunhui@...edance.com>
To:     Ard Biesheuvel <ardb@...nel.org>
Cc:     ron minnich <rminnich@...il.com>,
        Mark Rutland <mark.rutland@....com>,
        Lorenzo Pieralisi <lpieralisi@...nel.org>, rafael@...nel.org,
        lenb@...nel.org, jdelvare@...e.com, yc.hung@...iatek.com,
        angelogioacchino.delregno@...labora.com,
        allen-kh.cheng@...iatek.com, pierre-louis.bossart@...ux.intel.com,
        tinghan.shen@...iatek.com, linux-kernel@...r.kernel.org,
        linux-acpi@...r.kernel.org, geshijian@...edance.com,
        weidong.wd@...edance.com
Subject: Re: [External] Re: [PATCH] firmware: added a firmware information
 passing method FFI

Hi Ard,

On Sun, Jun 25, 2023 at 3:43 PM Ard Biesheuvel <ardb@...nel.org> wrote:
>
> acpi_os_ioremap() is used by all ACPI core code that needs to map MMIO
> regions or DRAM from AML code. AML does not pass memory type
> attributes, so we have to consult the EFI memory map for these.
>
> As I have explained to you multiple times, ACPI on arm64 is *broken*
> without the EFI memory map.
>

As Ron's suggested:
"...
It would be nice to separate those pieces on RISC-V; certainly they
were separate for a very long time in the x86 world (we had ACPI+SMM
on coreboot laptops without UEFI for example)
...
"

If it cannot be solved temporarily on arm64, then we cannot let it
continue to be bound in RISC-V.
And on the linux-next branch, RISC-V arch is not bound to EFI.
void *acpi_os_ioremap(acpi_physical_address phys, acpi_size size)
{
        return memremap(phys, size, MEMREMAP_WB);
}



>
> Incorrect. We are talking about any physical region here, not just
> DRAM. And some DRAM regions may not be covered by memblock.
>
It is very strange that so many devices can complete the hardware
description through DTS without the problem you mentioned.
Even if there is, then it shouldn't be the problem that this patch
should solve, should it?

> No, sorry. Please try to understand the objections that I am raising
> first. I am not saying this to annoy you, I am saying this because
> your approach is flawed.

The implementation is right in front of us, we need to support ACPI on
RISC-V based on coreboot.

Thanks,
Yunhui

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ