This is a follow-up to [0].

Move arch_accept_memory(), which is only called by the EFI stub and
never by the decompressor on a non-EFI boot, into the EFI stub, and
avoid relying directly on decompressor APIs such as error().

Instead, call tdx_panic() on a failure to accept memory in a TDX guest.

This makes the decompressor's implementation of panic() obsolete, and
allows it to be removed. This is a prerequisite for dropping the
implementation of snprintf() from the EFI stub entirely, which is what
the series containing [0] implements.

[0] http://lore.kernel.org/r/20260909115530.1924665-13-ardb+git@google.com

Cc: Kiryl Shutsemau (Meta) <kas@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>

Ard Biesheuvel (3):
  x86/tdx: Share tdx_panic() with the EFI stub
  x86/boot: Move unaccepted memory handling out of the decompressor
  x86/boot: Drop unused implementation of panic()

 arch/x86/boot/compressed/error.c        | 19 ---------
 arch/x86/boot/compressed/error.h        |  1 -
 arch/x86/boot/compressed/mem.c          | 42 --------------------
 arch/x86/boot/compressed/sev.h          |  2 -
 arch/x86/coco/tdx/tdx-shared.c          | 35 ++++++++++++++++
 arch/x86/coco/tdx/tdx.c                 | 35 ----------------
 arch/x86/include/asm/sev.h              |  2 +
 arch/x86/include/asm/shared/tdx.h       |  1 +
 drivers/firmware/efi/libstub/x86-stub.c | 40 +++++++++++++++++++
 9 files changed, 78 insertions(+), 99 deletions(-)


base-commit: cee9395acd8043be0644b25c34bfa86623f2b935
-- 
2.47.3

Kiryl, 

On Mon, 2026-09-14 at 20:37 +0200, Ard Biesheuvel wrote:
> This is a follow-up to [0].
> 
> Move arch_accept_memory(), which is only called by the EFI stub and
> never by the decompressor on a non-EFI boot, into the EFI stub, and
> avoid relying directly on decompressor APIs such as error().
> 
> Instead, call tdx_panic() on a failure to accept memory in a TDX guest.

The TDG accept call can return:

TDX_OPERAND_INVALID - That would be a bug in Linux TDX code, we don't need to
pass it to the caller. Probably don't need to handle it.
TDX_PAGE_ALREADY_ACCEPTED - Potential security sensitive error that is the
guests fault.
TDX_PAGE_SIZE_MISMATCH - Already handled. Sort of. Not sure if it is robust to
S-EPT page size changes?
TDX_SUCCESS - Already handled
TDX_OPERAND_BUSY - Can happen from transient host side S-EPT locking. Or it
could be the guest's fault if they are accepting the same page from different
vCPUs at the same time, so the guest case is similar to
TDX_PAGE_ALREADY_ACCEPTED.

I guess the caller could care about TDX_PAGE_ALREADY_ACCEPTED errors. But SNP
doesn't do anything for this case. It seems like part of the problem is that we
are passing errors back that the caller can't feasibly handle.

On Wed, Sep 16, 2026 at 06:16:30PM +0000, Edgecombe, Rick P wrote:
> Kiryl, 
> 
> On Mon, 2026-09-14 at 20:37 +0200, Ard Biesheuvel wrote:
> > This is a follow-up to [0].
> > 
> > Move arch_accept_memory(), which is only called by the EFI stub and
> > never by the decompressor on a non-EFI boot, into the EFI stub, and
> > avoid relying directly on decompressor APIs such as error().
> > 
> > Instead, call tdx_panic() on a failure to accept memory in a TDX guest.
> 
> The TDG accept call can return:
> 
> TDX_OPERAND_INVALID - That would be a bug in Linux TDX code, we don't need to
> pass it to the caller. Probably don't need to handle it.
> TDX_PAGE_ALREADY_ACCEPTED - Potential security sensitive error that is the
> guests fault.

Yes, but it can also be safe in some contexts as we discussed before.

> TDX_PAGE_SIZE_MISMATCH - Already handled. Sort of. Not sure if it is robust to
> S-EPT page size changes?
> TDX_SUCCESS - Already handled
> TDX_OPERAND_BUSY - Can happen from transient host side S-EPT locking. Or it
> could be the guest's fault if they are accepting the same page from different
> vCPUs at the same time, so the guest case is similar to
> TDX_PAGE_ALREADY_ACCEPTED.
> 
> I guess the caller could care about TDX_PAGE_ALREADY_ACCEPTED errors. But SNP
> doesn't do anything for this case. It seems like part of the problem is that we
> are passing errors back that the caller can't feasibly handle.

Maybe. I don't understand SNP model and why they don't care about errors
here.

Do you have a proposal here?

-- 
  Kiryl Shutsemau / Kirill A. Shutemov

+Yan 

On Thu, 2026-09-17 at 14:32 +0100, Kiryl Shutsemau wrote:
> > I guess the caller could care about TDX_PAGE_ALREADY_ACCEPTED errors. But
> > SNP
> > doesn't do anything for this case. It seems like part of the problem is that
> > we
> > are passing errors back that the caller can't feasibly handle.
> 
> Maybe. I don't understand SNP model and why they don't care about errors
> here.
> 
> Do you have a proposal here?

Yan pointed out that future TDX modules will not take an S-EPT entry lock on
accepting a NP S-EPT entry. However, I think this won't prevent guest caused
busys on re-accept attempts?


Here is a strawman proposal. Please consider critically.

TDX_PAGE_ALREADY_ACCEPTED: Zero memory that was re-accepted and treat it as a
success.

TDX_OPERAND_BUSY host contention: Loop and blame the host for any infinite
loops. It can be not unlike if the host zap's the EPT and the guest gets stuck
on infinite EPT violations. Except that the host does not get any notification
of the trouble it is causing... Some sort of TDX arch change to notify the host
of heavy guest-host contention could be worked on in the background?

TDX_OPERAND_BUSY guest contention: RW lock around accept. Normally take the lock
for read, and a single fallback attempt takes the lock for write.

Then I think all errors accept() would want to return to the callers are
handled.

The only thing I'm not sure about is TDX_PAGE_ALREADY_ACCEPTED. Some callers may
want a warning on that case. I think a warning is more in line with what we have
done in similar situations, rather than panic. But a warming would throw off the
EFI stub callers apparently.

On Fri, Sep 18, 2026 at 02:29:55AM +0800, Edgecombe, Rick P wrote:
> +Yan 
> 
> On Thu, 2026-09-17 at 14:32 +0100, Kiryl Shutsemau wrote:
> > > I guess the caller could care about TDX_PAGE_ALREADY_ACCEPTED errors. But
> > > SNP
> > > doesn't do anything for this case. It seems like part of the problem is that
> > > we
> > > are passing errors back that the caller can't feasibly handle.
> > 
> > Maybe. I don't understand SNP model and why they don't care about errors
> > here.
> > 
> > Do you have a proposal here?
> 
> Yan pointed out that future TDX modules will not take an S-EPT entry lock on
> accepting a NP S-EPT entry. However, I think this won't prevent guest caused
> busys on re-accept attempts?
Re-accept attempts may occur due to:
(a) two concurrent ACCEPT TDCALLs, where the one that arrives slightly later
    returns either TDACCEPT_ALREADY_ACCEPTED or TDX_OPERAND_BUSY.
(b) two successive ACCEPT TDCALLs on the same GPA.

Since Linux guest always invokes ACCEPT TDCALL before a memory access, and
accept_memory() always checks the unaccepted_table->bitmap before invoking the
ACCEPT TDCALL, case (b) should be impossible in practice, right?

Is case (a) a valid scenario, and does it actually occur in a Linux guest?

On Fri, Sep 18, 2026 at 10:12:10AM +0800, Yan Zhao wrote:
> On Fri, Sep 18, 2026 at 02:29:55AM +0800, Edgecombe, Rick P wrote:
> > +Yan 
> > 
> > On Thu, 2026-09-17 at 14:32 +0100, Kiryl Shutsemau wrote:
> > > > I guess the caller could care about TDX_PAGE_ALREADY_ACCEPTED errors. But
> > > > SNP
> > > > doesn't do anything for this case. It seems like part of the problem is that
> > > > we
> > > > are passing errors back that the caller can't feasibly handle.
> > > 
> > > Maybe. I don't understand SNP model and why they don't care about errors
> > > here.
> > > 
> > > Do you have a proposal here?
> > 
> > Yan pointed out that future TDX modules will not take an S-EPT entry lock on
> > accepting a NP S-EPT entry. However, I think this won't prevent guest caused
> > busys on re-accept attempts?
> Re-accept attempts may occur due to:
> (a) two concurrent ACCEPT TDCALLs, where the one that arrives slightly later
>     returns either TDACCEPT_ALREADY_ACCEPTED or TDX_OPERAND_BUSY.
> (b) two successive ACCEPT TDCALLs on the same GPA.
> 
> Since Linux guest always invokes ACCEPT TDCALL before a memory access, and
> accept_memory() always checks the unaccepted_table->bitmap before invoking the
> ACCEPT TDCALL, case (b) should be impossible in practice, right?
> 
> Is case (a) a valid scenario, and does it actually occur in a Linux guest?
Case (a) should be prevented by the unaccepted_memory_lock in accept_memory(),
right?

On Fri, Sep 18, 2026 at 01:28:56PM +0800, Yan Zhao wrote:
> On Fri, Sep 18, 2026 at 10:12:10AM +0800, Yan Zhao wrote:
> > On Fri, Sep 18, 2026 at 02:29:55AM +0800, Edgecombe, Rick P wrote:
> > > +Yan 
> > > 
> > > On Thu, 2026-09-17 at 14:32 +0100, Kiryl Shutsemau wrote:
> > > > > I guess the caller could care about TDX_PAGE_ALREADY_ACCEPTED errors. But
> > > > > SNP
> > > > > doesn't do anything for this case. It seems like part of the problem is that
> > > > > we
> > > > > are passing errors back that the caller can't feasibly handle.
> > > > 
> > > > Maybe. I don't understand SNP model and why they don't care about errors
> > > > here.
> > > > 
> > > > Do you have a proposal here?
> > > 
> > > Yan pointed out that future TDX modules will not take an S-EPT entry lock on
> > > accepting a NP S-EPT entry. However, I think this won't prevent guest caused
> > > busys on re-accept attempts?
> > Re-accept attempts may occur due to:
> > (a) two concurrent ACCEPT TDCALLs, where the one that arrives slightly later
> >     returns either TDACCEPT_ALREADY_ACCEPTED or TDX_OPERAND_BUSY.
> > (b) two successive ACCEPT TDCALLs on the same GPA.
> > 
> > Since Linux guest always invokes ACCEPT TDCALL before a memory access, and
> > accept_memory() always checks the unaccepted_table->bitmap before invoking the
> > ACCEPT TDCALL, case (b) should be impossible in practice, right?
> > 
> > Is case (a) a valid scenario, and does it actually occur in a Linux guest?
> Case (a) should be prevented by the unaccepted_memory_lock in accept_memory(),
> right?

Right, for accept_memory().

The lock itself is dropped around the TDCALL, but the range stays on
accepting_list until the bits are cleared, and the overlap check is done
in unit_size granularity, so a second caller for the same unit spins
until the first one is done and then finds the bits clear. Both (a) and
(b) are covered there.

There is a second ACCEPT issuer that does not look at the bitmap at
all: shared->private conversion in tdx_enc_status_changed().

It does not need the bitmap because the memory came from the page
allocator or memblock and got accepted before it was handed out. It also
has no per-range serialization; mem_enc_lock is only taken for read. So
ALREADY_ACCEPTED on that path means either the guest converted the same
range twice (a double-free class of bug) or the VMM acked MapGPA(shared)
but never removed the private page. Either way the page there is the one
the guest accepted earlier, and the failure already comes back as -EIO
rather than a panic.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov

On Fri, 18 Sep 2026, at 12:45, Kiryl Shutsemau wrote:
> On Fri, Sep 18, 2026 at 01:28:56PM +0800, Yan Zhao wrote:
>> On Fri, Sep 18, 2026 at 10:12:10AM +0800, Yan Zhao wrote:
>> > On Fri, Sep 18, 2026 at 02:29:55AM +0800, Edgecombe, Rick P wrote:
>> > > +Yan 
>> > > 
>> > > On Thu, 2026-09-17 at 14:32 +0100, Kiryl Shutsemau wrote:
>> > > > > I guess the caller could care about TDX_PAGE_ALREADY_ACCEPTED errors. But
>> > > > > SNP
>> > > > > doesn't do anything for this case. It seems like part of the problem is that
>> > > > > we
>> > > > > are passing errors back that the caller can't feasibly handle.
>> > > > 
>> > > > Maybe. I don't understand SNP model and why they don't care about errors
>> > > > here.
>> > > > 
>> > > > Do you have a proposal here?
>> > > 
>> > > Yan pointed out that future TDX modules will not take an S-EPT entry lock on
>> > > accepting a NP S-EPT entry. However, I think this won't prevent guest caused
>> > > busys on re-accept attempts?
>> > Re-accept attempts may occur due to:
>> > (a) two concurrent ACCEPT TDCALLs, where the one that arrives slightly later
>> >     returns either TDACCEPT_ALREADY_ACCEPTED or TDX_OPERAND_BUSY.
>> > (b) two successive ACCEPT TDCALLs on the same GPA.
>> > 
>> > Since Linux guest always invokes ACCEPT TDCALL before a memory access, and
>> > accept_memory() always checks the unaccepted_table->bitmap before invoking the
>> > ACCEPT TDCALL, case (b) should be impossible in practice, right?
>> > 
>> > Is case (a) a valid scenario, and does it actually occur in a Linux guest?
>> Case (a) should be prevented by the unaccepted_memory_lock in accept_memory(),
>> right?
>
> Right, for accept_memory().
>
> The lock itself is dropped around the TDCALL, but the range stays on
> accepting_list until the bits are cleared, and the overlap check is done
> in unit_size granularity, so a second caller for the same unit spins
> until the first one is done and then finds the bits clear. Both (a) and
> (b) are covered there.
>
> There is a second ACCEPT issuer that does not look at the bitmap at
> all: shared->private conversion in tdx_enc_status_changed().
>
> It does not need the bitmap because the memory came from the page
> allocator or memblock and got accepted before it was handed out. It also
> has no per-range serialization; mem_enc_lock is only taken for read. So
> ALREADY_ACCEPTED on that path means either the guest converted the same
> range twice (a double-free class of bug) or the VMM acked MapGPA(shared)
> but never removed the private page. Either way the page there is the one
> the guest accepted earlier, and the failure already comes back as -EIO
> rather than a panic.
>

Is there any way we could make some progress here?

Ultimately, the thing I am after is to get rid of the call from the
decompressor to EFI stub's snprintf(), which I want to remove. For
the time being, I am more than happy leaving the memory acceptance where
it is, and just dropping the call to snprintf().

On Wed, Sep 23, 2026 at 04:34:47PM +0200, Ard Biesheuvel wrote:
> 
> 
> On Fri, 18 Sep 2026, at 12:45, Kiryl Shutsemau wrote:
> > On Fri, Sep 18, 2026 at 01:28:56PM +0800, Yan Zhao wrote:
> >> On Fri, Sep 18, 2026 at 10:12:10AM +0800, Yan Zhao wrote:
> >> > On Fri, Sep 18, 2026 at 02:29:55AM +0800, Edgecombe, Rick P wrote:
> >> > > +Yan 
> >> > > 
> >> > > On Thu, 2026-09-17 at 14:32 +0100, Kiryl Shutsemau wrote:
> >> > > > > I guess the caller could care about TDX_PAGE_ALREADY_ACCEPTED errors. But
> >> > > > > SNP
> >> > > > > doesn't do anything for this case. It seems like part of the problem is that
> >> > > > > we
> >> > > > > are passing errors back that the caller can't feasibly handle.
> >> > > > 
> >> > > > Maybe. I don't understand SNP model and why they don't care about errors
> >> > > > here.
> >> > > > 
> >> > > > Do you have a proposal here?
> >> > > 
> >> > > Yan pointed out that future TDX modules will not take an S-EPT entry lock on
> >> > > accepting a NP S-EPT entry. However, I think this won't prevent guest caused
> >> > > busys on re-accept attempts?
> >> > Re-accept attempts may occur due to:
> >> > (a) two concurrent ACCEPT TDCALLs, where the one that arrives slightly later
> >> >     returns either TDACCEPT_ALREADY_ACCEPTED or TDX_OPERAND_BUSY.
> >> > (b) two successive ACCEPT TDCALLs on the same GPA.
> >> > 
> >> > Since Linux guest always invokes ACCEPT TDCALL before a memory access, and
> >> > accept_memory() always checks the unaccepted_table->bitmap before invoking the
> >> > ACCEPT TDCALL, case (b) should be impossible in practice, right?
> >> > 
> >> > Is case (a) a valid scenario, and does it actually occur in a Linux guest?
> >> Case (a) should be prevented by the unaccepted_memory_lock in accept_memory(),
> >> right?
> >
> > Right, for accept_memory().
> >
> > The lock itself is dropped around the TDCALL, but the range stays on
> > accepting_list until the bits are cleared, and the overlap check is done
> > in unit_size granularity, so a second caller for the same unit spins
> > until the first one is done and then finds the bits clear. Both (a) and
> > (b) are covered there.
> >
> > There is a second ACCEPT issuer that does not look at the bitmap at
> > all: shared->private conversion in tdx_enc_status_changed().
> >
> > It does not need the bitmap because the memory came from the page
> > allocator or memblock and got accepted before it was handed out. It also
> > has no per-range serialization; mem_enc_lock is only taken for read. So
> > ALREADY_ACCEPTED on that path means either the guest converted the same
> > range twice (a double-free class of bug) or the VMM acked MapGPA(shared)
> > but never removed the private page. Either way the page there is the one
> > the guest accepted earlier, and the failure already comes back as -EIO
> > rather than a panic.
> >
> 
> Is there any way we could make some progress here?
> 
> Ultimately, the thing I am after is to get rid of the call from the
> decompressor to EFI stub's snprintf(), which I want to remove. For
> the time being, I am more than happy leaving the memory acceptance where
> it is, and just dropping the call to snprintf().

Please go ahead with the move. Rick's questions are about what
tdx_accept_memory() should return, not about where the caller lives,
and can be sorted out separately.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov

On Thu, 2026-09-24 at 12:46 +0100, Kiryl Shutsemau wrote:
> > Is there any way we could make some progress here?
> > 
> > Ultimately, the thing I am after is to get rid of the call from the
> > decompressor to EFI stub's snprintf(), which I want to remove. For
> > the time being, I am more than happy leaving the memory acceptance where
> > it is, and just dropping the call to snprintf().
> 
> Please go ahead with the move. Rick's questions are about what
> tdx_accept_memory() should return, not about where the caller lives,
> and can be sorted out separately.

Yep. I tried to do a quick smoke test and got a similar build error as Boris. I
guess you will send a new revision?

ld: warning: orphan section `.altinstructions' from
`drivers/firmware/efi/libstub/x86-stub.stub.o' being placed in section
`.altinstructions'
ld: warning: orphan section `.altinstr_replacement' from
`drivers/firmware/efi/libstub/x86-stub.stub.o' being placed in section
`.altinstr_replacement'
ld: Unexpected GOT/PLT entries detected!
ld: Unexpected run-time procedure linkages detected!
ld: Unexpected run-time relocations (.rela) detected!
ld: arch/x86/boot/compressed/tdx-shared.o: in function `tdx_panic.cold':
tdx-shared.c:(.text.unlikely+0xc): undefined reference to `__fortify_panic'
ld: tdx-shared.c:(.text.unlikely+0x1e): undefined reference to `__fortify_panic'
ld: drivers/firmware/efi/libstub/x86-stub.stub.o: in function
`arch_accept_memory':
x86-stub.c:(.text+0x17f5): undefined reference to `pv_ops'
ld: drivers/firmware/efi/libstub/x86-stub.stub.o:(.altinstr_replacement+0x1):
undefined reference to `BUG_func'
ld: arch/x86/boot/compressed/vmlinux: hidden symbol `__SCK__WARN_trap' isn't
defined
ld: final link failed: bad value

On Fri, 25 Sep 2026, at 01:30, Edgecombe, Rick P wrote:
> On Thu, 2026-09-24 at 12:46 +0100, Kiryl Shutsemau wrote:
>> > Is there any way we could make some progress here?
>> > 
>> > Ultimately, the thing I am after is to get rid of the call from the
>> > decompressor to EFI stub's snprintf(), which I want to remove. For
>> > the time being, I am more than happy leaving the memory acceptance where
>> > it is, and just dropping the call to snprintf().
>> 
>> Please go ahead with the move. Rick's questions are about what
>> tdx_accept_memory() should return, not about where the caller lives,
>> and can be sorted out separately.
>
> Yep. I tried to do a quick smoke test and got a similar build error as Boris. I
> guess you will send a new revision?
>

Yes, thanks for testing.

On Thu, 17 Sep 2026, at 20:29, Edgecombe, Rick P wrote:
> +Yan 
>
> On Thu, 2026-09-17 at 14:32 +0100, Kiryl Shutsemau wrote:
>> > I guess the caller could care about TDX_PAGE_ALREADY_ACCEPTED errors. But
>> > SNP
>> > doesn't do anything for this case. It seems like part of the problem is that
>> > we
>> > are passing errors back that the caller can't feasibly handle.
>> 
>> Maybe. I don't understand SNP model and why they don't care about errors
>> here.
>> 
>> Do you have a proposal here?
>
> Yan pointed out that future TDX modules will not take an S-EPT entry lock on
> accepting a NP S-EPT entry. However, I think this won't prevent guest caused
> busys on re-accept attempts?
>
>
> Here is a strawman proposal. Please consider critically.
>
> TDX_PAGE_ALREADY_ACCEPTED: Zero memory that was re-accepted and treat it as a
> success.
>
> TDX_OPERAND_BUSY host contention: Loop and blame the host for any infinite
> loops. It can be not unlike if the host zap's the EPT and the guest gets stuck
> on infinite EPT violations. Except that the host does not get any notification
> of the trouble it is causing... Some sort of TDX arch change to notify the host
> of heavy guest-host contention could be worked on in the background?
>
> TDX_OPERAND_BUSY guest contention: RW lock around accept. Normally take the lock
> for read, and a single fallback attempt takes the lock for write.
>
> Then I think all errors accept() would want to return to the callers are
> handled.
>
> The only thing I'm not sure about is TDX_PAGE_ALREADY_ACCEPTED. Some callers may
> want a warning on that case. I think a warning is more in line with what we have
> done in similar situations, rather than panic. But a warming would throw off the
> EFI stub callers apparently.

The memory acceptance occurs after ExitBootServices(), and so there is little the
EFI stub can do at this point except maybe set a variable with an error message
and reset the system. If that is better than a panic(), this is something we can
consider.

However, I'd like to avoid going off into the weeds here with something that was
intended to simply move some logic from one place to the other. The current code
prints an error to the UART I/O port (rather than the PV console TDX uses when
running in the decompressor) and then loops forever. Is that something we could
retain for this series, and then continue the above discussion in the context of
a separate series based on top of that?

On Fri, 2026-09-18 at 01:19 +0200, Ard Biesheuvel wrote:
> The memory acceptance occurs after ExitBootServices(), and so there is little the
> EFI stub can do at this point except maybe set a variable with an error message
> and reset the system. If that is better than a panic(), this is something we can
> consider.
> 
> However, I'd like to avoid going off into the weeds here with something that was
> intended to simply move some logic from one place to the other. The current code
> prints an error to the UART I/O port (rather than the PV console TDX uses when
> running in the decompressor) and then loops forever. Is that something we could
> retain for this series, and then continue the above discussion in the context of
> a separate series based on top of that?

Uhh, yea. I guess I don't see a strong reason. This definitely has some aspects
unrelated to removing panic() from that EFI stub. I thought we might find an
alternative simpler solution quickly.

+ Rick and linux-coco

On Mon, Sep 14, 2026 at 08:37:46PM +0200, Ard Biesheuvel wrote:
> This is a follow-up to [0].
> 
> Move arch_accept_memory(), which is only called by the EFI stub and
> never by the decompressor on a non-EFI boot, into the EFI stub, and
> avoid relying directly on decompressor APIs such as error().
> 
> Instead, call tdx_panic() on a failure to accept memory in a TDX guest.
> 
> This makes the decompressor's implementation of panic() obsolete, and
> allows it to be removed. This is a prerequisite for dropping the
> implementation of snprintf() from the EFI stub entirely, which is what
> the series containing [0] implements.
> 
> [0] http://lore.kernel.org/r/20260909115530.1924665-13-ardb+git@google.com
> 
> Cc: Kiryl Shutsemau (Meta) <kas@kernel.org>
> Cc: Borislav Petkov <bp@alien8.de>
> 
> Ard Biesheuvel (3):
>   x86/tdx: Share tdx_panic() with the EFI stub
>   x86/boot: Move unaccepted memory handling out of the decompressor
>   x86/boot: Drop unused implementation of panic()
> 
>  arch/x86/boot/compressed/error.c        | 19 ---------
>  arch/x86/boot/compressed/error.h        |  1 -
>  arch/x86/boot/compressed/mem.c          | 42 --------------------
>  arch/x86/boot/compressed/sev.h          |  2 -
>  arch/x86/coco/tdx/tdx-shared.c          | 35 ++++++++++++++++
>  arch/x86/coco/tdx/tdx.c                 | 35 ----------------
>  arch/x86/include/asm/sev.h              |  2 +
>  arch/x86/include/asm/shared/tdx.h       |  1 +
>  drivers/firmware/efi/libstub/x86-stub.c | 40 +++++++++++++++++++
>  9 files changed, 78 insertions(+), 99 deletions(-)
> 
> 
> base-commit: cee9395acd8043be0644b25c34bfa86623f2b935
> -- 
> 2.47.3
> 

-- 
Regards/Gruss,
    Boris.

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