| Message ID | 20220304154032.2071585-1-ani@anisinha.ca (mailing list archive) |
|---|---|
| Headers | show |
| Series | hw/acpi: add indication for i8042 in IA-PC boot flags of the FADT table | expand |
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.
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(-)