On Aug 25, 2014, at 6:03 PM, Laszlo Ersek <[email protected]> wrote:
> On 08/26/14 02:12, Jordan Justen wrote:
>> On Mon, Aug 25, 2014 at 4:27 PM, Laszlo Ersek <[email protected]> wrote:
>>> On 08/26/14 00:24, Jordan Justen wrote:
>>>> On Fri, Aug 8, 2014 at 7:08 PM, Laszlo Ersek <[email protected]> wrote:
>>>>> Recent changes in the QEMU ACPI table generator have shown that our
>>>>> limited client for that interface is insufficient and/or brittle.
>>>>>
>>>>> Implement the full interface utilizing OrderedCollectionLib for addressing
>>>>> fw_cfg blobs by name.
>>>>>
>>>>> In addition, we stop using EFI_ACPI_TABLE_PROTOCOL in the QEMU loader
>>>>> client, because:
>>>>> - splitting the blobs for EFI_ACPI_TABLE_PROTOCOL is just untenable short
>>>>> of a complete ACPI parser,
>>>>> - and it is fully sufficient to install the RSD PTR as an EFI
>>>>> configuration table for the guest OS to see everything.
>>>>>
>>>>> In short, for this interface, EFI_ACPI_TABLE_PROTOCOL is an unwanted and
>>>>> restrictive convenience; let's stop using it.
>>>>
>>>> Hmm. Been through a few rounds of this for Xen. It's QEMU's turn now? :)
>>>>
>>>> Is this required?
>>>
>>> Depends on how good (how accurate) ACPI tables you want to have in your
>>> VMs. For a few qemu releases now, qemu has been the "master" of ACPI
>>> payload generation. SeaBIOS too has kept its own builtin tables, yes,
>>> but when the QEMU generated payload is available, it interprets this
>>> linker/loader script just the same.
>>>
>>> If you want PCI hotplug, pvpanic support; or, going forward, memory
>>> hotplug, then yes, those things need ACPI support, and the ACPI stuff
>>> for them is now developed in QEMU (and dynamically generated by it,
>>> dependent on the actual hardware config).
>>>
>>>> What happens if another driver uses EFI_ACPI_TABLE_PROTOCOL? We now
>>>> have two drivers that want to install the pointer.
>>>
>>> Yes, I checked that. The UEFI spec says that whenever you install a
>>> configuration table that's already present (by GUID), the reference is
>>> updated.
>>>
>>> InstallConfigurationTable()
>>>
>>> [...]
>>> * If Guid is present in the System Table, and Table is not NULL, then
>>> the (Guid, Table) pair is updated with the new Table value.
>>> [...]
>>>
>>> For this reason, the first thing InstallAllQemuLinkedTables() does is
>>> check, with EfiGetSystemConfigurationTable(), for the presence of any of
>>> the ACPI GUIDs in the config table.
>>>
>>> There's no "absolute" cure against another driver in OVMF just grabbing
>>> EFI_ACPI_TABLE_PROTOCOL and installing its own stuff (which would then
>>> completely hide the tables installed by this patchset, because
>>> "MdeModulePkg/Universal/Acpi/AcpiTableDxe" would simply replace QEMU's
>>> RSD PTR's address in the UEFI config table with its own).
>>>
>>> But ACPI tables are not randomly installed in OVMF, we keep it
>>> centralized in AcpiTableDxe.
>>
>> I don't agree with this statement. Rather, I would say that OVMF
>> follows the EDK II method of publishing tables, which means
>> EFI_ACPI_TABLE_PROTOCOL.
>>
>> In the past we were a good little sample platform, and provided the
>> ACPI tables directly. Well, that is less and less the case. But, is it
>> a good idea to stop using EFI_ACPI_TABLE_PROTOCOL?
>
> No. It's not a good idea.
>
> But if we want to support the qemu interface, in the manner that
> interface has been intended, then I can see no way around avoiding
> EFI_ACPI_TABLE_PROTOCOL.
>
> The only way you could reliably fish out tables, operation regions etc.
> from the qemu payload would be to write a near-full ACPI interpreter.
> The goal of the interface is the polar opposite, ie. to require the
> firmware to know the least possible about ACPI table specifics.
>
I wonder if there are other cases when the platform “knows more” than the edk2
driver producing the ACPI tables? Maybe having a PCD feature flag to turn off
ACPI table production in the modules would make sense?
Thanks,
Andrew Fish
>> What about MdeModulePkg/Universal/Network/IScsiDxe/IScsiIbft.c, which
>> uses EFI_ACPI_TABLE_PROTOCOL?
>
> Good find.
>
>> Do we need to keep monitoring which EDK II drivers decide to use
>> EFI_ACPI_TABLE_PROTOCOL,
>
> I guess so.
>
>> or can we find a way to make these work
>> together?
>
> I doubt it.
>
> The current in-tree solution is probably as good as it gets with
> EFI_ACPI_TABLE_PROTOCOL. It would co-operate with IScsiIbft.c, but (if
> you read the TPM thread I linked from qemu-devel) it would install a
> broken TCPA table from QEMU, for example.
>
>> If the answer is no, then I wonder if this is something that
>> UEFI or EDK II needs to consider.
>
> Maybe it is.
>
> As far as the UEFI spec goes, EFI_ACPI_TABLE_PROTOCOL looks like the
> canonical way.
>
> RSD PTR being referenced in the config table is not even part of the
> UEFI spec (if I searched it right); it's described in the ACPI spec. The
> UEFI spec only names the relevant GUIDs, but doesn't explain how to use
> them.
>
> In any case, under the IBFT example you name, we have a conflict because
> ACPI tables have two genuine, distinct sources. IBFT comes from the
> firmware, while the rest would come from QEMU.
>
> (I don't know if IBFT could be provided by QEMU. The ACPI 5.1 spec
> doesn't describe the table. Googling led me to a license acceptance
> window at Microsoft's site, which I closed.)
>
> In practice, IBFT seems less important than the tables that QEMU does
> offer -- embedded in blobs -- eg. I forgot to mention VCPU hotplug.
>
> Thanks,
> Laszlo
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds. Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> edk2-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
