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.

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            |  11 ++++++++++-
 hw/i386/acpi-build.c           |   9 +++++++++
 hw/i386/acpi-microvm.c         |   9 +++++++++
 include/hw/acpi/acpi-defs.h    |   1 +
 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
 8 files changed, 29 insertions(+), 1 deletion(-)

-- 
2.35.1

On Mon, Feb 28, 2022 at 10:17:30PM +0200, 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.

OK still waiting for v5.

> 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            |  11 ++++++++++-
>  hw/i386/acpi-build.c           |   9 +++++++++
>  hw/i386/acpi-microvm.c         |   9 +++++++++
>  include/hw/acpi/acpi-defs.h    |   1 +
>  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
>  8 files changed, 29 insertions(+), 1 deletion(-)
> 
> -- 
> 2.35.1

On Fri, Mar 4, 2022 at 3:56 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Mon, Feb 28, 2022 at 10:17:30PM +0200, 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.
>
> OK still waiting for v5.

Since the time is tight, I could quickly make the changes in patch 2
and send it over. I believe 8th is the last date for new changes.

On Fri, Mar 04, 2022 at 04:04:13PM +0530, Ani Sinha wrote:
> On Fri, Mar 4, 2022 at 3:56 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > On Mon, Feb 28, 2022 at 10:17:30PM +0200, 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.
> >
> > OK still waiting for v5.
> 
> Since the time is tight, I could quickly make the changes in patch 2
> and send it over.

Sure.

> I believe 8th is the last date for new changes.

Yes.

-- 
MST