On Thu, Jun 24, 2021 at 09:11:11AM -0500, Michael Roth wrote:

  We don't need anything in setup_data/setup_header. We can access the
  CC blob table via EFI config table. However, parsing EFI config table
  early in uncompressed/proper kernel has the complications I mentioned in my
  initial response.

So since you want to parse the EFI table in the boot stage, that tells
me that you need the blob in the early, boot kernel too, correct?

This is where using a new boot_params field comes into
  play (similar to acpi_rsdp_addr), so boot/compressed can pass
  uncompressed/proper kernel a pointer to the pre-parsed CC blob so it doesn't
  need to re-parse EFI config table during early boot.

Ack.

For non-EFI case:

  We need a "proper" mechanism that bootloaders can use. My
  understanding is this would generally be via setup_data or
  setup_header, and that a direct boot_params field would be frowned
  upon.

So, you need to pass only an address, right?

How workable would it be if you had a cmdline option:

	cc_blob_address=0xb1a

with which you tell the kernel where that thing is?

Because then you can use this in both cases - EFI and !EFI.

Or is this blob platform-dependent and the EFI table contains it and
something needs to get it out of there, even if it were a user to
type in the cmdline cc_blob_address or some script when it comes to
containers...?

In any case, setup_data is kinda the generic way to pass arbitrary data
to the kernel so in this case, you can prioritize the EFI table in the
EFI case and fall back to setup_data if there's no EFI table...

So your understanding of the situation seems correct.

By bringing up the non-EFI case I only meant to point out that by using a
field in setup_header, we could re-use that field for the EFI case as well,
and wouldn't need a seperate boot_params field to handle the
boot/compressed->uncompressed passing of the pre-parsed CC blob address
in the EFI case. But I don't think it makes a big difference as far as
my stuff goes at least. Maybe for TDX though this needs more thought.

Yah, let's see what requirements they'd come back with.

Thx.

-- 
Regards/Gruss,
    Boris.

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