> From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of

> Laszlo Ersek

> Sent: Thursday, July 30, 2020 5:52 PM

> +Igor, some comments below

>

> My (rusty) understanding is that hardware signals the OS with "general

> purpose IO" and/or SCI (ACPI) interrupt. Then the OS invokes General

> Purpose Event handlers (GPE handlers) from ACPI. In turn the GPE handlers

> in ACPI parse the event, and invoke the proper OS functionality via Notify().

>

> So basically the hardware only tells the OS via SCI that "something ACPI

> happened". The OS passes this to ACPI for handling (GPE handlers), which in

> turn dispatch the event back to the proper OS handler, via Notify().

Okay, so my understanding seems to be ok here. Notify() is getting called in context of OS.

> > - Is this correct acpi tables are static piece of code, having no

> > thread/execution context, All execution in done from OS

>

> No, this is not correct. AML methods can run in parallel, they can (and need

> to) do explicit locking (there are ASL primitives for this). AML methods have

> local variables, but they also operate on global objects in the ACPI

> namespace (operation regions, device registers, ...) so serialization in ACPI is

> important, if multiple hardware events can occur concurrently.

Let me rephrase myself here, when BIOS provides ACPI table to OS

then  OS's threads will call the AML methods, for sure many OS threads can access AML methods at the same time.

But on its own, ACPI table has no way to call itself.

Example, in case of hardware interrupt or event, which is caught by OS and OS calls GPE methods, which

will call Notify() of acpi table and corresponding device will be notified.

Here without involving OS, Notify can not be executed, right I am ?

Thanks and Warm regards

Kumar G

> Thanks

> Laszlo