Re: [Qemu-devel] [PATCH v2 5/7] ACPICA: Integrate package handling with module-level code

Re: [Qemu-devel] [PATCH v2 5/7] ACPICA: Integrate package handling with module-level code

[Dan Williams]

On Mon, Apr 16, 2018 at 4:15 PM, Schmauss, Erik <erik.schmauss@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

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?

Re: [Qemu-devel] [PATCH v2 5/7] ACPICA: Integrate package handling with module-level code

[Schmauss, Erik]

> -----Original Message-----
> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> owner@vger.kernel.org] On Behalf Of Dan Williams
> Sent: Monday, April 16, 2018 4:22 PM
> To: Schmauss, Erik <erik.schmauss@intel.com>
> Cc: Rafael J. Wysocki <rjw@rjwysocki.net>; Linux ACPI <linux-
> acpi@vger.kernel.org>; Moore, Robert <robert.moore@intel.com>; linux-
> nvdimm <linux-nvdimm@lists.01.org>; Qemu Developers <qemu-
> devel@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.schmauss@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?

Erik

> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of
> a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html

Re: [Qemu-devel] [PATCH v2 5/7] ACPICA: Integrate package handling with module-level code

[Dan Williams]

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