On Fri, Jun 25, 2021 at 01:14:17PM -0500, Michael Roth wrote:

So non-EFI case would rely purely on the setup_data entry for both (though
we could still use boot_params->cc_blob_address to avoid the need to scan
setup_data list in proper kernel as well, but scanning it early on doesn't
have the same issues as with EFI config table so it's not really
necessary there).

Yeah, sure, we can simply always use boot_params->cc_blob_address just
like acpi_rsdp_addr and always put the CC blob address there.

I opted to give setup_data precedence over EFI, since if a bootloader goes
the extra mile of packaging up a setup_data argument instead of just leaving
it to firmware/EFI config table, it might be out of some extra need.  For
example, if we do have a shared definition for both SEV and TDX, maybe the
bootloader needs to synthesize multiple EFI table entries, and a unified
setup_data will be easier for the kernel to consume than replicating that same
work, and maybe over time the fallback can be deprecated. And containers will
more than likely prefer setup_data approach, which might drive future changes
that aren't in lockstep with EFI definitions as well.

Yah, that makes perfect sense. And you/Brijesh should put the gist of
that in a comment over the code so that people are aware. The less we
rely on firmware, the better.

Brijesh can correct me if I'm wrong, but I believe that's the intent, and the
setup_data approach definitely seems workable for that aspect.

Oki doki, I think we're all on the same page then. :-)

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette