On Mon, Apr 16, 2018 at 5:05 PM, Schmauss, Erik <erik.schmauss@xxxxxxxxx> wrote: > >> -----Original Message----- >> From: linux-acpi-owner@xxxxxxxxxxxxxxx [mailto:linux-acpi- >> owner@xxxxxxxxxxxxxxx] On Behalf Of Dan Williams >> Sent: Monday, April 16, 2018 4:22 PM >> To: Schmauss, Erik <erik.schmauss@xxxxxxxxx> >> Cc: Rafael J. Wysocki <rjw@xxxxxxxxxxxxx>; Linux ACPI <linux- >> acpi@xxxxxxxxxxxxxxx>; Moore, Robert <robert.moore@xxxxxxxxx>; linux- >> nvdimm <linux-nvdimm@xxxxxxxxxxxx>; Qemu Developers <qemu- >> devel@xxxxxxxxxx> >> Subject: Re: [PATCH v2 5/7] ACPICA: Integrate package handling with module- >> level code >> >> On Mon, Apr 16, 2018 at 4:15 PM, Schmauss, Erik <erik.schmauss@xxxxxxxxx> >> wrote: >> > [ trimming ] >> >> >> Rafael, we may want to hold back on the module-level code changes >> >> >> (the patches below) for rc1. Between this and the strange _TSS >> >> >> issue, it seems like there are a few more things to resolve before >> >> >> this is ready for kernel upstream. >> >> > >> > Hi Rafael, >> > >> >> > It looks like you are asking me to queue up reverts as per the >> >> > Dan's report, is that correct? >> > >> > This is indeed what I meant last week. However, I've looked into the >> > issue and Dan's qemu instance had AML that we no longer support. This >> > is because the ACPICA commit makes changes to the execution of AML >> > during table load to match windows AML interpreter behavior so this commit >> also got rid of support for executing code containing forward references (except >> for package elements). >> > >> > I've suggested a fix for the firmware in a separate email. So I would >> > say that this issue is resolved after if Dan can run his test successfully with the >> adjusted firmware. >> > >> > If Dan's test is successful, we don’t need to revert these changes >> > > Hi Dan, > >> I'm concerned about other qemu-kvm users that do not upgrade their hypervisor >> at the same pace as their guest kernel. Especially for cloud providers that may >> be running latest mainline kernel on older qemu-kvm this will look like a pure >> kernel regression. Is there a quick fix we can carry in the kernel to support these >> forward references, at least until we know that qemu-kvm is no longer shipping >> the broken AML? > > This is a very good point. Thanks for bringing this up! One option is for them to set > the global variable acpi_gbl_execute_tables_as_methods in include/acpi/acpixf.h to false. > This will effectively revert the new behavior in the AML interpreter and go back to the old way. > Since this is a global flag, we could have a command line option for Linux kernel to turn this > feature on. > > Out of curiosity, is this ACPI table somehow customized for your work? I have a collection > of acpi tables and your ACPI tables are the only ones that have an OperationRegion called > NRAM. What is the chance that others will be running Linux on the same tables as the one > you sent me? I don't think there's anything atypical about my particular setup. It creates two virtual NVDIMMs that each represent a 30GB address space. I suspect any user of the KVM NVDIMM virtualization would see the same problem. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
