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.

Changelog:
v7:
fixed a compilation issue. the fix was not committed when running "make check"
v6:
addressed comments from v5. added microvm changes too as a part of this series.
v5:
Addressed review comments from v4. Also got rid of microvm changes. Will send
them in a separate patch.



Ani Sinha (1):
  hw/acpi/microvm: turn on 8042 bit in FADT boot architecture flags if
    present

Liav Albani (3):
  tests/acpi: i386: allow FACP acpi table changes
  hw/acpi: add indication for i8042 in IA-PC boot flags of the FADT
    table
  tests/acpi: i386: update FACP table differences

 hw/acpi/aml-build.c            |   8 +++++++-
 hw/i386/acpi-build.c           |   8 ++++++++
 hw/i386/acpi-microvm.c         |   6 ++++++
 include/hw/acpi/acpi-defs.h    |   1 +
 include/hw/input/i8042.h       |  15 +++++++++++++++
 tests/data/acpi/q35/FACP       | Bin 244 -> 244 bytes
 tests/data/acpi/q35/FACP.nosmm | Bin 244 -> 244 bytes
 tests/data/acpi/q35/FACP.slic  | Bin 244 -> 244 bytes
 tests/data/acpi/q35/FACP.xapic | Bin 244 -> 244 bytes
 9 files changed, 37 insertions(+), 1 deletion(-)

-- 
2.25.1

On Fri, Mar 04, 2022 at 09:10:28PM +0530, Ani Sinha 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.

I wonder how will such a guest work on an existing qemu release then.

> Changelog:
> v7:
> fixed a compilation issue. the fix was not committed when running "make check"
> v6:
> addressed comments from v5. added microvm changes too as a part of this series.
> v5:
> Addressed review comments from v4. Also got rid of microvm changes. Will send
> them in a separate patch.
> 
> 
> 
> Ani Sinha (1):
>   hw/acpi/microvm: turn on 8042 bit in FADT boot architecture flags if
>     present
> 
> Liav Albani (3):
>   tests/acpi: i386: allow FACP acpi table changes
>   hw/acpi: add indication for i8042 in IA-PC boot flags of the FADT
>     table
>   tests/acpi: i386: update FACP table differences
> 
>  hw/acpi/aml-build.c            |   8 +++++++-
>  hw/i386/acpi-build.c           |   8 ++++++++
>  hw/i386/acpi-microvm.c         |   6 ++++++
>  include/hw/acpi/acpi-defs.h    |   1 +
>  include/hw/input/i8042.h       |  15 +++++++++++++++
>  tests/data/acpi/q35/FACP       | Bin 244 -> 244 bytes
>  tests/data/acpi/q35/FACP.nosmm | Bin 244 -> 244 bytes
>  tests/data/acpi/q35/FACP.slic  | Bin 244 -> 244 bytes
>  tests/data/acpi/q35/FACP.xapic | Bin 244 -> 244 bytes
>  9 files changed, 37 insertions(+), 1 deletion(-)
> 
> -- 
> 2.25.1

On Mon, Mar 7, 2022 at 3:06 AM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Fri, Mar 04, 2022 at 09:10:28PM +0530, Ani Sinha 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.
>
> I wonder how will such a guest work on an existing qemu release then.

I do not know about other such guests but looking at Serenity OS which
is the reason of motivation of this work, it seems to work by sending
commands to the command IO port:

https://github.com/SerenityOS/serenity/blob/455224d4766df886a43c19e9c015533c025d40dd/Kernel/Devices/HID/I8042Controller.cpp#L34

>  do_wait_then_write(I8042Port::Command, I8042Command::ReadConfiguration); result.is_error())
> do_write(I8042Port::Command, I8042Command::TestPS2Controller);

etc.