On Mon, Apr 16, 2018 at 5:05 PM, Schmauss, Erik <erik.schma...@intel.com> wrote: > >> -----Original Message----- >> From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi- >> ow...@vger.kernel.org] On Behalf Of Dan Williams >> Sent: Monday, April 16, 2018 4:22 PM >> To: Schmauss, Erik <erik.schma...@intel.com> >> Cc: Rafael J. Wysocki <r...@rjwysocki.net>; Linux ACPI <linux- >> a...@vger.kernel.org>; Moore, Robert <robert.mo...@intel.com>; linux- >> nvdimm <linux-nvd...@lists.01.org>; Qemu Developers <qemu- >> de...@nongnu.org> >> 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.schma...@intel.com> >> 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.