Thanks a lot for all these information guys.
It's really helpful. I'll do some tests here, but as far as I could check
this is exactly what I need.
Rafael R Machado
2014-01-31 Laszlo Ersek <ler...@redhat.com>:
> On 01/31/14 18:21, Sergey Isakov wrote:
> > Hi,
> > EFI_ACPI_TABLE_PROTOCOL is to get ACPI tables while
> > ACPI_SDT_PROTOCOL is to analyze them.
> > Wishes,
> > Sergey
> >
> >
> > On 31 янв. 2014 г., at 18:29, Yao, Jiewen <jiewen....@intel.com
> > <mailto:jiewen....@intel.com>> wrote:
> >
> >> HI
> >> UEFI OS loader or OS kernel can get ACPI2.0 RSDP from UEFI
> >> configuration table via EFI_ACPI_20_TABLE_GUID. See UEFI2.4a spec,
> >> page 93.
> >> Then it can parse all ACPI information, like RSDP->XSDT->FADT->DSDT.
> >>
> >> I think you also use this way too.
> >>
> >> The limitation of ACPI_SDT_PROTOCOL is that: It is defined in PI spec,
> >> and not all platform BIOS produce it, as far as I know.
>
> My current understanding is that both sets of statements are correct.
>
> (i) EFI_ACPI_TABLE_PROTOCOL is good for installing new tables, and for
> removing some tables that have been installed with the same protocol
> instance. UninstallAcpiTable() takes the same TableKey as input that
> InstallAcpiTable() returned earlier.
>
> When tables are un-/installed like this, they are un-/linked under the
> RSDP (as Jiewen says).
>
> (ii) The absolute root / anchor for this "tree of tables" is
> gST->ConfigurationTable. (See PublishTables() in
> "MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c".) The
> entry with VendorGuid==gEfiAcpiTableGuid (or
> VendorGuid==gEfiAcpi10TableGuid) seems to point to the RSDP.
>
> According to the UEFI spec, after installing or uninstalling a table,
> with EFI_ACPI_TABLE_PROTOCOL, interested parties need to re-fetch this
> entry from gST->ConfigurationTable (ie. re-walk the entire chain).
>
> An example for locating the FACS, starting with gST->ConfigurationTable,
> is visible in FindAcpiFacsTable()
> [IntelFrameworkModulePkg/Universal/Acpi/AcpiS3SaveDxe/AcpiS3Save.c].
>
> (iii) EFI_ACPI_SDT_PROTOCOL *seems* suitable for analyzing/modifying
> tables that contain AML and have been (or are being) installed with
> EFI_ACPI_TABLE_PROTOCOL. GetAcpiTable() allows one to find out about all
> such tables, and RegisterNotify() allows for an InstallAcpiTable()
> callback.
>
> As soon as the TableKey is available, OpenSdt() can be called to
> retrieve an EFI_ACPI_HANDLE, which allows further GetChild() /
> GetOption() / FindPath() calls. This looks awesome. I believe it's
> basically an AML parser.
>
> For example, in OVMF I guess we could derive "structured information"
> from QEMU's DSDT/SSDT (once I post the download patch), should we be
> forced to do that.
>
> This discussion is proving very beneficial (even if I'm incorrect in
> some spots).
>
> Thanks!
> Laszlo
>
>
> ------------------------------------------------------------------------------
> WatchGuard Dimension instantly turns raw network data into actionable
> security intelligence. It gives you real-time visual feedback on key
> security issues and trends. Skip the complicated setup - simply import
> a virtual appliance and go from zero to informed in seconds.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
------------------------------------------------------------------------------
WatchGuard Dimension instantly turns raw network data into actionable
security intelligence. It gives you real-time visual feedback on key
security issues and trends. Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
