[RFC PATCH v2 0/8] ACPI/IORT: Support for IORT RMR node
by Shameer Kolothum
RFC v1 --> v2:
- Added a generic interface for IOMMU drivers to retrieve all the
RMR info associated with a given IOMMU.
- SMMUv3 driver gets the RMR list during probe() and installs
bypass STEs for all the SIDs in the RMR list. This is to keep
the ongoing traffic alive(if any) during SMMUv3 reset. This is
based on the suggestions received for v1 to take care of the
EFI framebuffer use case. Only sanity tested for now.
- During the probe/attach device, SMMUv3 driver reserves any
RMR region associated with the device such that there is a unity
mapping for them in SMMU.
---
The series adds support to IORT RMR nodes specified in IORT
Revision E -ARM DEN 0049E[0]. RMR nodes are used to describe memory
ranges that are used by endpoints and require a unity mapping
in SMMU.
We have faced issues with 3408iMR RAID controller cards which
fail to boot when SMMU is enabled. This is because these controllers
make use of host memory for various caching related purposes and when
SMMU is enabled the iMR firmware fails to access these memory regions
as there is no mapping for them. IORT RMR provides a way for UEFI to
describe and report these memory regions so that the kernel can make
a unity mapping for these in SMMU.
RFC because, Patch #1 is to update the actbl2.h and should be done
through acpica update. I have send out a pull request[1] for that.
Tests:
With a UEFI, that reports the RMR for the dev,
....
[16F0h 5872 1] Type : 06
[16F1h 5873 2] Length : 007C
[16F3h 5875 1] Revision : 00
[1038h 0056 2] Reserved : 00000000
[1038h 0056 2] Identifier : 00000000
[16F8h 5880 4] Mapping Count : 00000001
[16FCh 5884 4] Mapping Offset : 00000040
[1700h 5888 4] Number of RMR Descriptors : 00000002
[1704h 5892 4] RMR Descriptor Offset : 00000018
[1708h 5896 8] Base Address of RMR : 0000E6400000
[1710h 5904 8] Length of RMR : 000000100000
[1718h 5912 4] Reserved : 00000000
[171Ch 5916 8] Base Address of RMR : 0000000027B00000
[1724h 5924 8] Length of RMR : 0000000000C00000
[172Ch 5932 4] Reserved : 00000000
[1730h 5936 4] Input base : 00000000
[1734h 5940 4] ID Count : 00000001
[1738h 5944 4] Output Base : 00000003
[173Ch 5948 4] Output Reference : 00000064
[1740h 5952 4] Flags (decoded below) : 00000001
Single Mapping : 1
...
Without the series the RAID controller initialization fails as
below,
...
[ 12.631117] megaraid_sas 0000:03:00.0: FW supports sync cache : Yes
[ 12.637360] megaraid_sas 0000:03:00.0: megasas_disable_intr_fusion is called outbound_intr_mask:0x40000009
[ 18.776377] megaraid_sas 0000:03:00.0: Init cmd return status FAILED for SCSI host 0
[ 23.019383] megaraid_sas 0000:03:00.0: Waiting for FW to come to ready state
[ 106.684281] megaraid_sas 0000:03:00.0: FW in FAULT state, Fault code:0x10000 subcode:0x0 func:megasas_transition_to_ready
[ 106.695186] megaraid_sas 0000:03:00.0: System Register set:
[ 106.889787] megaraid_sas 0000:03:00.0: Failed to transition controller to ready for scsi0.
[ 106.910475] megaraid_sas 0000:03:00.0: Failed from megasas_init_fw 6407
estuary:/$
With the series, now the kernel has direct mapping for the dev as
below,
estuary:/$ cat /sys/kernel/iommu_groups/0/reserved_regions
0x0000000008000000 0x00000000080fffff msi
0x0000000027b00000 0x00000000286fffff direct
0x00000000e6400000 0x00000000e64fffff direct
estuary:/$
....
[ 12.254318] megaraid_sas 0000:03:00.0: megasas_disable_intr_fusion is called outbound_intr_mask:0x40000009
[ 12.739089] megaraid_sas 0000:03:00.0: FW provided supportMaxExtLDs: 0 max_lds: 32
[ 12.746628] megaraid_sas 0000:03:00.0: controller type : iMR(0MB)
[ 12.752694] megaraid_sas 0000:03:00.0: Online Controller Reset(OCR) : Enabled
[ 12.759798] megaraid_sas 0000:03:00.0: Secure JBOD support : Yes
[ 12.765778] megaraid_sas 0000:03:00.0: NVMe passthru support : Yes
[ 12.771931] megaraid_sas 0000:03:00.0: FW provided TM TaskAbort/Reset timeou: 6 secs/60 secs
[ 12.780503] megaraid_sas 0000:03:00.0: JBOD sequence map support : Yes
[ 12.787000] megaraid_sas 0000:03:00.0: PCI Lane Margining support : No
[ 12.819179] megaraid_sas 0000:03:00.0: NVME page size : (4096)
[ 12.825672] megaraid_sas 0000:03:00.0: megasas_enable_intr_fusion is called outbound_intr_mask:0x40000000
[ 12.835199] megaraid_sas 0000:03:00.0: INIT adapter done
[ 12.873932] megaraid_sas 0000:03:00.0: pci id : (0x1000)/(0x0017)/(0x19e5)/(0xd213)
[ 12.881644] megaraid_sas 0000:03:00.0: unevenspan support : no
[ 12.887451] megaraid_sas 0000:03:00.0: firmware crash dump : no
[ 12.893344] megaraid_sas 0000:03:00.0: JBOD sequence map : enabled
RAID controller init is now success and can detect the drives
attached as well.
Thanks,
Shameer
[0]. https://developer.arm.com/documentation/den0049/latest/
[1]. https://github.com/acpica/acpica/pull/638
Shameer Kolothum (8):
ACPICA: IORT: Update for revision E
ACPI/IORT: Add support for RMR node parsing
iommu/dma: Introduce generic helper to retrieve RMR info
ACPI/IORT: Add RMR memory regions reservation helper
iommu/arm-smmu-v3: Introduce strtab init helper
iommu/arm-smmu-v3: Add bypass flag to arm_smmu_write_strtab_ent()
iommu/arm-smmu-v3: Get associated RMR info and install bypass STE
iommu/arm-smmu-v3: Reserve any RMR regions associated with a dev
drivers/acpi/arm64/iort.c | 182 +++++++++++++++++++-
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 112 ++++++++++--
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 2 +
drivers/iommu/dma-iommu.c | 39 +++++
include/acpi/actbl2.h | 25 ++-
include/linux/acpi_iort.h | 6 +
include/linux/dma-iommu.h | 7 +
include/linux/iommu.h | 16 ++
8 files changed, 367 insertions(+), 22 deletions(-)
--
2.17.1
6 months, 4 weeks
How to Connect With online homework help in USA Experts
by jamesthmas92＠gmail.com
MyAssignmentHelpAU is the best writing service provider and offers help with your assignments, essays, coursework, reports and research papers in USA. Our in-house team of writers can provide perfect solutions even if you require urgent online homework help and ensure that you submit the best homework assignments within the deadline. Our services guarantee confidentiality, free revisions, and 100% plagiarism-free solutions for every student at the market best price.
More info: - https://www.myassignmenthelpau.com/us/homework-help-usa
6 months, 4 weeks
[pm:bleeding-edge] BUILD SUCCESS d2e6cdcbaeb304fff490aa7e0fd814e3bbeb0b6a
by kernel test robot
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
branch HEAD: d2e6cdcbaeb304fff490aa7e0fd814e3bbeb0b6a Merge branch 'acpi-misc' into bleeding-edge
elapsed time: 727m
configs tested: 94
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
riscv allmodconfig
riscv allyesconfig
s390 debug_defconfig
sh sh7763rdp_defconfig
arm pleb_defconfig
arm vexpress_defconfig
arm trizeps4_defconfig
m68k mvme16x_defconfig
mips malta_defconfig
sparc sparc64_defconfig
powerpc tqm8560_defconfig
s390 defconfig
sh landisk_defconfig
parisc alldefconfig
arc axs103_smp_defconfig
powerpc pmac32_defconfig
sh rts7751r2dplus_defconfig
mips workpad_defconfig
arm axm55xx_defconfig
arm64 alldefconfig
arm neponset_defconfig
mips maltaaprp_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
parisc allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 tinyconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20210318
i386 randconfig-a005-20210318
i386 randconfig-a003-20210318
i386 randconfig-a002-20210318
i386 randconfig-a006-20210318
i386 randconfig-a004-20210318
x86_64 randconfig-a011-20210318
x86_64 randconfig-a016-20210318
x86_64 randconfig-a013-20210318
x86_64 randconfig-a015-20210318
x86_64 randconfig-a014-20210318
x86_64 randconfig-a012-20210318
i386 randconfig-a013-20210318
i386 randconfig-a016-20210318
i386 randconfig-a011-20210318
i386 randconfig-a014-20210318
i386 randconfig-a015-20210318
i386 randconfig-a012-20210318
riscv nommu_k210_defconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a006-20210318
x86_64 randconfig-a001-20210318
x86_64 randconfig-a005-20210318
x86_64 randconfig-a002-20210318
x86_64 randconfig-a003-20210318
x86_64 randconfig-a004-20210318
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
7 months
Re: [PATCH v2 1/1] ACPI: scan: Use unique number for instance_no
by Rafael J. Wysocki
On Fri, Mar 19, 2021 at 7:33 PM Andy Shevchenko
<andriy.shevchenko(a)linux.intel.com> wrote:
>
> Current mechanism of incrementing and decrementing plain integer
> to get a next free instance_no when creating an ACPI device is buggy.
>
> The simple integer and operations line increment and decrement
> on top of it can't cover the possible gaps during run time. The
> arbitrary instantiation and elimination of the devices is racy
But it isn't racy AFAICS. It always happens under acpi_device_lock().
> and after a couple of iterations with unequal amount of devices
> being added and removed we may reproduce a bug:
7 months
Re: [PATCH] include: acpi: A typo fix in the file cppc_acpi.h
by Rafael J. Wysocki
On Wed, Mar 17, 2021 at 6:17 AM Randy Dunlap <rdunlap(a)infradead.org> wrote:
>
> On 3/16/21 10:06 PM, Bhaskar Chowdhury wrote:
> >
> > s/folowing/following/
> >
> > Signed-off-by: Bhaskar Chowdhury <unixbhaskar(a)gmail.com>
>
> Acked-by: Randy Dunlap <rdunlap(a)infradead.org>
>
> > ---
> > include/acpi/cppc_acpi.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/include/acpi/cppc_acpi.h b/include/acpi/cppc_acpi.h
> > index c7fc4524e151..d174721bab33 100644
> > --- a/include/acpi/cppc_acpi.h
> > +++ b/include/acpi/cppc_acpi.h
> > @@ -31,7 +31,7 @@
> > #define CMD_READ 0
> > #define CMD_WRITE 1
> >
> > -/* Each register has the folowing format. */
> > +/* Each register has the following format. */
> > struct cpc_reg {
> > u8 descriptor;
> > u16 length;
> > --
Applied as 5.13 material with a minor edit in the subject, thanks!
7 months
[pm:bleeding-edge] BUILD SUCCESS 1d06e15a1e4072f063de489f8dd7ca6a5eb35f8c
by kernel test robot
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
branch HEAD: 1d06e15a1e4072f063de489f8dd7ca6a5eb35f8c Merge branch 'pm-cpufreq' into bleeding-edge
elapsed time: 726m
configs tested: 94
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
x86_64 allyesconfig
riscv allmodconfig
i386 allyesconfig
riscv allyesconfig
arc axs101_defconfig
sh defconfig
ia64 generic_defconfig
m68k mvme147_defconfig
arm vt8500_v6_v7_defconfig
powerpc maple_defconfig
powerpc adder875_defconfig
sh kfr2r09_defconfig
arm lpc32xx_defconfig
s390 alldefconfig
sh sh7724_generic_defconfig
mips malta_qemu_32r6_defconfig
mips rb532_defconfig
sh se7721_defconfig
sh magicpanelr2_defconfig
powerpc tqm8xx_defconfig
arm socfpga_defconfig
mips ath79_defconfig
xtensa cadence_csp_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
parisc allyesconfig
s390 defconfig
sparc allyesconfig
sparc defconfig
i386 tinyconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20210318
i386 randconfig-a005-20210318
i386 randconfig-a003-20210318
i386 randconfig-a002-20210318
i386 randconfig-a006-20210318
i386 randconfig-a004-20210318
x86_64 randconfig-a011-20210318
x86_64 randconfig-a016-20210318
x86_64 randconfig-a013-20210318
x86_64 randconfig-a015-20210318
x86_64 randconfig-a014-20210318
x86_64 randconfig-a012-20210318
i386 randconfig-a013-20210318
i386 randconfig-a016-20210318
i386 randconfig-a011-20210318
i386 randconfig-a014-20210318
i386 randconfig-a015-20210318
i386 randconfig-a012-20210318
riscv nommu_k210_defconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a006-20210318
x86_64 randconfig-a001-20210318
x86_64 randconfig-a005-20210318
x86_64 randconfig-a002-20210318
x86_64 randconfig-a003-20210318
x86_64 randconfig-a004-20210318
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
7 months
Re: [PATCH 1/1] ACPI: fix acpi table use after free
by Rafael J. Wysocki
On Wed, Mar 17, 2021 at 11:28 PM George Kennedy
<george.kennedy(a)oracle.com> wrote:
>
>
>
> On 3/17/2021 4:14 PM, Rafael J. Wysocki wrote:
> > On Monday, March 15, 2021 5:19:29 PM CET Rafael J. Wysocki wrote:
> >> On Sun, Mar 14, 2021 at 8:00 PM Mike Rapoport <rppt(a)linux.ibm.com> wrote:
> >>> On Thu, Mar 11, 2021 at 04:36:31PM +0100, Rafael J. Wysocki wrote:
> >>>> On Wed, Mar 10, 2021 at 8:47 PM David Hildenbrand <david(a)redhat.com> wrote:
> >>>>>> There is some care that should be taken to make sure we get the order
> >>>>>> right, but I don't see a fundamental issue here.
> >>>> Me neither.
> >>>>
> >>>>>> If I understand correctly, Rafael's concern is about changing the parts of
> >>>>>> ACPICA that should be OS agnostic, so I think we just need another place to
> >>>>>> call memblock_reserve() rather than acpi_tb_install_table_with_override().
> >>>> Something like this.
> >>>>
> >>>> There is also the problem that memblock_reserve() needs to be called
> >>>> for all of the tables early enough, which will require some reordering
> >>>> of the early init code.
> >>>>
> >>>>>> Since the reservation should be done early in x86::setup_arch() (and
> >>>>>> probably in arm64::setup_arch()) we might just have a function that parses
> >>>>>> table headers and reserves them, similarly to how we parse the tables
> >>>>>> during KASLR setup.
> >>>> Right.
> >>> I've looked at it a bit more and we do something like the patch below that
> >>> nearly duplicates acpi_tb_parse_root_table() which is not very nice.
> >> It looks to me that the code need not be duplicated (see below).
> >>
> >>> Besides, reserving ACPI tables early and then calling acpi_table_init()
> >>> (and acpi_tb_parse_root_table() again would mean doing the dance with
> >>> early_memremap() twice for no good reason.
> >> That'd be simply inefficient which is kind of acceptable to me to start with.
> >>
> >> And I changing the ACPICA code can be avoided at least initially, it
> >> by itself would be a good enough reason.
> >>
> >>> I believe the most effective way to deal with this would be to have a
> >>> function that does parsing, reservation and installs the tables supplied by
> >>> the firmware which can be called really early and then another function
> >>> that overrides tables if needed a some later point.
> >> I agree that this should be the direction to go into.
> > So maybe something like the patch below?
>
> Do you want me to try it out in the failing setup?
Yes, please!
7 months
Re: [PATCH 1/1] ACPI: fix acpi table use after free
by Rafael J. Wysocki
On Thu, Mar 18, 2021 at 8:25 AM Mike Rapoport <rppt(a)linux.ibm.com> wrote:
>
> On Wed, Mar 17, 2021 at 09:14:37PM +0100, Rafael J. Wysocki wrote:
> > On Monday, March 15, 2021 5:19:29 PM CET Rafael J. Wysocki wrote:
> > > On Sun, Mar 14, 2021 at 8:00 PM Mike Rapoport <rppt(a)linux.ibm.com> wrote:
> > > >
> > > > On Thu, Mar 11, 2021 at 04:36:31PM +0100, Rafael J. Wysocki wrote:
> > > > > On Wed, Mar 10, 2021 at 8:47 PM David Hildenbrand <david(a)redhat.com> wrote:
> > > > > > >
> > > > > > > There is some care that should be taken to make sure we get the order
> > > > > > > right, but I don't see a fundamental issue here.
> > > > >
> > > > > Me neither.
> > > > >
> > > > > > > If I understand correctly, Rafael's concern is about changing the parts of
> > > > > > > ACPICA that should be OS agnostic, so I think we just need another place to
> > > > > > > call memblock_reserve() rather than acpi_tb_install_table_with_override().
> > > > >
> > > > > Something like this.
> > > > >
> > > > > There is also the problem that memblock_reserve() needs to be called
> > > > > for all of the tables early enough, which will require some reordering
> > > > > of the early init code.
> > > > >
> > > > > > > Since the reservation should be done early in x86::setup_arch() (and
> > > > > > > probably in arm64::setup_arch()) we might just have a function that parses
> > > > > > > table headers and reserves them, similarly to how we parse the tables
> > > > > > > during KASLR setup.
> > > > >
> > > > > Right.
> > > >
> > > > I've looked at it a bit more and we do something like the patch below that
> > > > nearly duplicates acpi_tb_parse_root_table() which is not very nice.
> > >
> > > It looks to me that the code need not be duplicated (see below).
> > >
> > > > Besides, reserving ACPI tables early and then calling acpi_table_init()
> > > > (and acpi_tb_parse_root_table() again would mean doing the dance with
> > > > early_memremap() twice for no good reason.
> > >
> > > That'd be simply inefficient which is kind of acceptable to me to start with.
> > >
> > > And I changing the ACPICA code can be avoided at least initially, it
> > > by itself would be a good enough reason.
> > >
> > > > I believe the most effective way to deal with this would be to have a
> > > > function that does parsing, reservation and installs the tables supplied by
> > > > the firmware which can be called really early and then another function
> > > > that overrides tables if needed a some later point.
> > >
> > > I agree that this should be the direction to go into.
> >
> > So maybe something like the patch below?
> >
> > I'm not sure if acpi_boot_table_prepare() gets called early enough, though.
>
> To be 100% safe it should be called before e820__memblock_setup().
OK
> It is possible to call memblock_reserve() at any time, even before the actual
> memory is detected as long as all reservations fit into the static array
> that currently has 128 entries on x86.
>
> As e820__memblock_setup() essentially enables memblock allocations,
> theoretically the memory occupied by ACPI tables can be allocated even in
> x86::setup_arch() unless it is reserved before e820__memblock_setup().
>
> > Also this still may not play well with initrd-based table overrides. Erik, do
> > you have any insights here?
> >
> > And ia64 needs to be updated too.
>
> I think arm64 as well.
Right.
> > ---
> > arch/x86/kernel/acpi/boot.c | 12 +++++++++---
> > arch/x86/kernel/setup.c | 3 +++
> > drivers/acpi/tables.c | 24 +++++++++++++++++++++---
> > include/linux/acpi.h | 9 +++++++--
> > 4 files changed, 40 insertions(+), 8 deletions(-)
> >
> > Index: linux-pm/arch/x86/kernel/acpi/boot.c
> > ===================================================================
> > --- linux-pm.orig/arch/x86/kernel/acpi/boot.c
> > +++ linux-pm/arch/x86/kernel/acpi/boot.c
> > @@ -1541,7 +1541,7 @@ static const struct dmi_system_id acpi_d
> > * ...
> > */
> >
> > -void __init acpi_boot_table_init(void)
> > +void __init acpi_boot_table_prepare(void)
> > {
> > dmi_check_system(acpi_dmi_table);
> >
> > @@ -1554,10 +1554,16 @@ void __init acpi_boot_table_init(void)
> > /*
> > * Initialize the ACPI boot-time table parser.
> > */
> > - if (acpi_table_init()) {
> > + if (acpi_table_prepare())
> > disable_acpi();
> > +}
> > +
> > +void __init acpi_boot_table_init(void)
> > +{
> > + if (acpi_disabled)
> > return;
> > - }
> > +
> > + acpi_table_init();
> >
> > acpi_table_parse(ACPI_SIG_BOOT, acpi_parse_sbf);
> >
> > Index: linux-pm/arch/x86/kernel/setup.c
> > ===================================================================
> > --- linux-pm.orig/arch/x86/kernel/setup.c
> > +++ linux-pm/arch/x86/kernel/setup.c
> > @@ -1070,6 +1070,9 @@ void __init setup_arch(char **cmdline_p)
> > /* preallocate 4k for mptable mpc */
> > e820__memblock_alloc_reserved_mpc_new();
> >
> > + /* Look for ACPI tables and reserve memory occupied by them. */
> > + acpi_boot_table_prepare();
> > +
> > #ifdef CONFIG_X86_CHECK_BIOS_CORRUPTION
> > setup_bios_corruption_check();
> > #endif
> > Index: linux-pm/include/linux/acpi.h
> > ===================================================================
> > --- linux-pm.orig/include/linux/acpi.h
> > +++ linux-pm/include/linux/acpi.h
> > @@ -222,11 +222,13 @@ void __iomem *__acpi_map_table(unsigned
> > void __acpi_unmap_table(void __iomem *map, unsigned long size);
> > int early_acpi_boot_init(void);
> > int acpi_boot_init (void);
> > +void acpi_boot_table_prepare (void);
> > void acpi_boot_table_init (void);
>
> Not related to this patch, but it feels to me like there are too many
> acpi_boot_something() :)
Well, there was one initially, but it has been split for a few times
due to ordering issues similar to the one at hand.
It could be cleaned up I suppose, though.
7 months
Re: [PATCH 1/1] ACPI: fix acpi table use after free
by Rafael J. Wysocki
On Sun, Mar 14, 2021 at 8:00 PM Mike Rapoport <rppt(a)linux.ibm.com> wrote:
>
> On Thu, Mar 11, 2021 at 04:36:31PM +0100, Rafael J. Wysocki wrote:
> > On Wed, Mar 10, 2021 at 8:47 PM David Hildenbrand <david(a)redhat.com> wrote:
> > > >
> > > > There is some care that should be taken to make sure we get the order
> > > > right, but I don't see a fundamental issue here.
> >
> > Me neither.
> >
> > > > If I understand correctly, Rafael's concern is about changing the parts of
> > > > ACPICA that should be OS agnostic, so I think we just need another place to
> > > > call memblock_reserve() rather than acpi_tb_install_table_with_override().
> >
> > Something like this.
> >
> > There is also the problem that memblock_reserve() needs to be called
> > for all of the tables early enough, which will require some reordering
> > of the early init code.
> >
> > > > Since the reservation should be done early in x86::setup_arch() (and
> > > > probably in arm64::setup_arch()) we might just have a function that parses
> > > > table headers and reserves them, similarly to how we parse the tables
> > > > during KASLR setup.
> >
> > Right.
>
> I've looked at it a bit more and we do something like the patch below that
> nearly duplicates acpi_tb_parse_root_table() which is not very nice.
It looks to me that the code need not be duplicated (see below).
> Besides, reserving ACPI tables early and then calling acpi_table_init()
> (and acpi_tb_parse_root_table() again would mean doing the dance with
> early_memremap() twice for no good reason.
That'd be simply inefficient which is kind of acceptable to me to start with.
And I changing the ACPICA code can be avoided at least initially, it
by itself would be a good enough reason.
> I believe the most effective way to deal with this would be to have a
> function that does parsing, reservation and installs the tables supplied by
> the firmware which can be called really early and then another function
> that overrides tables if needed a some later point.
I agree that this should be the direction to go into.
However, it looks to me that something like the following could be
done to start with:
(a) Make __acpi_map_table() call memblock_reserve() in addition to
early_memremap().
My assumption here is that the memblock_reserve() will simply be
ignored if it is called too late.
(b) Introduce acpi_reserve_tables() as something like
void __init acpi_table_reserve(void)
{
acpi_initialize_tables(initial_tables, ACPI_MAX_TABLES, 0);
}
Because initial_tables is passed to acpi_initialize_tables() above and
allow_resize is 0, the array used by it will simply get overwritten
when acpi_table_init() gets called.
(c) Make setup_arch() call acpi_table_reserve() like in the original
patch from George.
Would that work?
If so, I'll cut a patch along these lines.
7 months
[pm:bleeding-edge] BUILD SUCCESS 1a7a93e88ae21b39d09117d5a0dde26db783ff92
by kernel test robot
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
branch HEAD: 1a7a93e88ae21b39d09117d5a0dde26db783ff92 Merge branch 'acpi-drivers' into linux-next
elapsed time: 722m
configs tested: 157
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
x86_64 allyesconfig
riscv allmodconfig
i386 allyesconfig
riscv allyesconfig
openrisc alldefconfig
powerpc redwood_defconfig
arm lart_defconfig
arc vdk_hs38_smp_defconfig
arm realview_defconfig
sh se7343_defconfig
nds32 allnoconfig
mips malta_qemu_32r6_defconfig
ia64 tiger_defconfig
arm vt8500_v6_v7_defconfig
sh se7722_defconfig
m68k apollo_defconfig
sh espt_defconfig
arm footbridge_defconfig
powerpc taishan_defconfig
arm hackkit_defconfig
arc allyesconfig
arm gemini_defconfig
sh j2_defconfig
arm vf610m4_defconfig
powerpc pmac32_defconfig
powerpc maple_defconfig
arc defconfig
sh se7724_defconfig
arm omap1_defconfig
sh sh7770_generic_defconfig
arm multi_v7_defconfig
powerpc akebono_defconfig
mips loongson1b_defconfig
arc haps_hs_defconfig
arm u8500_defconfig
sh se7705_defconfig
h8300 h8s-sim_defconfig
mips bcm47xx_defconfig
ia64 alldefconfig
nios2 3c120_defconfig
parisc generic-32bit_defconfig
powerpc ppc6xx_defconfig
microblaze mmu_defconfig
csky alldefconfig
powerpc storcenter_defconfig
powerpc ppc64_defconfig
mips ip27_defconfig
sh r7785rp_defconfig
arm lubbock_defconfig
mips maltaup_xpa_defconfig
arm spear13xx_defconfig
arm spear6xx_defconfig
arm lpc32xx_defconfig
arm tegra_defconfig
arm neponset_defconfig
arc nsimosci_hs_defconfig
xtensa generic_kc705_defconfig
sh edosk7760_defconfig
openrisc defconfig
powerpc bamboo_defconfig
powerpc mpc85xx_cds_defconfig
powerpc bluestone_defconfig
mips tb0219_defconfig
arm assabet_defconfig
mips pistachio_defconfig
mips decstation_64_defconfig
powerpc sam440ep_defconfig
powerpc walnut_defconfig
arm vexpress_defconfig
mips bmips_be_defconfig
arm imote2_defconfig
m68k atari_defconfig
powerpc lite5200b_defconfig
powerpc wii_defconfig
sh shmin_defconfig
arm alldefconfig
arm aspeed_g4_defconfig
i386 alldefconfig
powerpc mpc8540_ads_defconfig
um i386_defconfig
mips bigsur_defconfig
powerpc ep8248e_defconfig
powerpc cm5200_defconfig
mips loongson1c_defconfig
sparc64 defconfig
arm mps2_defconfig
powerpc pseries_defconfig
arm trizeps4_defconfig
sh edosk7705_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
parisc allyesconfig
s390 defconfig
sparc allyesconfig
sparc defconfig
i386 tinyconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20210316
i386 randconfig-a005-20210316
i386 randconfig-a002-20210316
i386 randconfig-a003-20210316
i386 randconfig-a004-20210316
i386 randconfig-a006-20210316
x86_64 randconfig-a011-20210316
x86_64 randconfig-a016-20210316
x86_64 randconfig-a013-20210316
x86_64 randconfig-a014-20210316
x86_64 randconfig-a015-20210316
x86_64 randconfig-a012-20210316
i386 randconfig-a013-20210316
i386 randconfig-a016-20210316
i386 randconfig-a011-20210316
i386 randconfig-a012-20210316
i386 randconfig-a015-20210316
i386 randconfig-a014-20210316
riscv nommu_k210_defconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a006-20210316
x86_64 randconfig-a001-20210316
x86_64 randconfig-a005-20210316
x86_64 randconfig-a004-20210316
x86_64 randconfig-a003-20210316
x86_64 randconfig-a002-20210316
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
7 months
