[PATCH v2 0/2] hw/acpi: add indication for i8042 in IA-PC boot flags of the FADT table

Liav Albani posted 2 patches 2 years, 2 months ago
Test checkpatch failed
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20220221191323.617323-1-liavalb@gmail.com
Maintainers: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>, Paolo Bonzini <pbonzini@redhat.com>, Igor Mammedov <imammedo@redhat.com>, "Michael S. Tsirkin" <mst@redhat.com>, Eduardo Habkost <eduardo@habkost.net>, Richard Henderson <richard.henderson@linaro.org>, Ani Sinha <ani@anisinha.ca>
There is a newer version of this series
hw/acpi/aml-build.c         |  7 ++++++-
hw/i386/acpi-build.c        |  5 +++++
hw/i386/acpi-microvm.c      |  5 +++++
hw/isa/isa-bus.c            | 23 +++++++++++++++++++++++
include/hw/acpi/acpi-defs.h |  1 +
include/hw/isa/isa.h        |  1 +
6 files changed, 41 insertions(+), 1 deletion(-)
[PATCH v2 0/2] hw/acpi: add indication for i8042 in IA-PC boot flags of the FADT table
Posted by Liav Albani 2 years, 2 months ago
This can allow the guest OS to determine more easily if i8042 controller
is present in the system or not, so it doesn't need to do probing of the
controller, but just initialize it immediately, before enumerating the
ACPI AML namespace.

To allow "flexible" indication, I don't hardcode the bit at location 1
as on in the IA-PC boot flags, but try to search for i8042 on the ISA
bus to verify it exists in the system.

Why this is useful you might ask - this patch allows the guest OS to
probe and use the i8042 controller without decoding the ACPI AML blob
at all. For example, as a developer of the SerenityOS kernel, I might
want to allow people to not try to decode the ACPI AML namespace (for
now, we still don't support ACPI AML as it's a work in progress), but
still to not probe for the i8042 but just use it after looking in the
IA-PC boot flags in the ACPI FADT table.

A note about this version of the patch series: I changed the assertion
checking if the ISA bus exists to a if statement, because I can see how
in the future someone might want to run a x86 machine without an ISA bus
so we should not assert if someone calls the ISA check device existence
function but return FALSE gracefully.
If someone thinks this is wrong, I'm more than happy to discuss and fix
the code :)

Liav Albani (2):
  hw/isa: add function to check for existence of device by its type
  hw/acpi: add indication for i8042 in IA-PC boot flags of the FADT
    table

 hw/acpi/aml-build.c         |  7 ++++++-
 hw/i386/acpi-build.c        |  5 +++++
 hw/i386/acpi-microvm.c      |  5 +++++
 hw/isa/isa-bus.c            | 23 +++++++++++++++++++++++
 include/hw/acpi/acpi-defs.h |  1 +
 include/hw/isa/isa.h        |  1 +
 6 files changed, 41 insertions(+), 1 deletion(-)

-- 
2.35.1


Re: [PATCH v2 0/2] hw/acpi: add indication for i8042 in IA-PC boot flags of the FADT table
Posted by Ani Sinha 2 years, 2 months ago

On Mon, 21 Feb 2022, Liav Albani wrote:

> This can allow the guest OS to determine more easily if i8042 controller
> is present in the system or not, so it doesn't need to do probing of the
> controller, but just initialize it immediately, before enumerating the
> ACPI AML namespace.
>
> To allow "flexible" indication, I don't hardcode the bit at location 1
> as on in the IA-PC boot flags, but try to search for i8042 on the ISA
> bus to verify it exists in the system.
>
> Why this is useful you might ask - this patch allows the guest OS to
> probe and use the i8042 controller without decoding the ACPI AML blob
> at all. For example, as a developer of the SerenityOS kernel, I might
> want to allow people to not try to decode the ACPI AML namespace (for
> now, we still don't support ACPI AML as it's a work in progress), but
> still to not probe for the i8042 but just use it after looking in the
> IA-PC boot flags in the ACPI FADT table.
>
> A note about this version of the patch series: I changed the assertion
> checking if the ISA bus exists to a if statement, because I can see how
> in the future someone might want to run a x86 machine without an ISA bus
> so we should not assert if someone calls the ISA check device existence
> function but return FALSE gracefully.
> If someone thinks this is wrong, I'm more than happy to discuss and fix
> the code :)
>
> Liav Albani (2):
>   hw/isa: add function to check for existence of device by its type
>   hw/acpi: add indication for i8042 in IA-PC boot flags of the FADT
>     table
>
>  hw/acpi/aml-build.c         |  7 ++++++-
>  hw/i386/acpi-build.c        |  5 +++++
>  hw/i386/acpi-microvm.c      |  5 +++++
>  hw/isa/isa-bus.c            | 23 +++++++++++++++++++++++
>  include/hw/acpi/acpi-defs.h |  1 +
>  include/hw/isa/isa.h        |  1 +
>  6 files changed, 41 insertions(+), 1 deletion(-)
>

This change breaks bios-tables-test.c:

-[06Dh 0109   2]   Boot Flags (decoded below) : 0000
+[06Dh 0109   2]   Boot Flags (decoded below) : 0002
                Legacy Devices Supported (V2) : 0
-            8042 Present on ports 60/64 (V2) : 0
+            8042 Present on ports 60/64 (V2) : 1


acpi-test: Warning! FACP binary file mismatch. Actual
[aml:/tmp/aml-QXU0H1], Expected [aml:tests/data/acpi/q35/FACP].
See source file tests/qtest/bios-tables-test.c for instructions on how to
update expected files.
# GLib-DEBUG: posix_spawn avoided (fd close requested)
# GLib-DEBUG: posix_spawn avoided (fd close requested)
acpi-test: Warning! FACP mismatch. Actual [asl:/tmp/asl-9AV0H1.dsl,
aml:/tmp/aml-QXU0H1], Expected [asl:/tmp/asl-03P0H1.dsl,
aml:tests/data/acpi/q35/FACP].
**
ERROR:../tests/qtest/bios-tables-test.c:532:test_acpi_asl: assertion
failed: (all_tables_match)
Bail out! ERROR:../tests/qtest/bios-tables-test.c:532:test_acpi_asl:
assertion failed: (all_tables_match)
Aborted (core dumped)

Please fix it. The instrctions are in the header of
tests/test/bios-tables-test.c as the above indicates.

You can check the failure by running it something like this:

QTEST_QEMU_BINARY=/home/ani/workspace/qemu/build/qemu-system-x86_64
V=1 ./tests/qtest/bios-tables-test

V=1 will dump the asl diff between expected and actual.