On 07/30/20 18:33, Kumar G wrote:

Thank You Laszlo

-----Original Message-----

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.

Notify() is "serviced" in the context of the 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 ?

Correct.

The AML interpreter / executor is a part of the OS. AML "runs" because
the OS makes it run. The Notify() operation "calls into the OS" because
the kernel component that parses the Notify opcode, in the AML,
recognizes the opcode for what it is, and passes control to another
kernel component (a callback) that handles the particular notification.

AML is not native machine code, so it cannot pass control to the OS. The
OS interprets the AML opcodes as data, and dependent upon what it sees,
it passes control to other places in the OS.

Laszlo