RE: [RFC PATCH 10/15] virt: tdx-guest: Set up and accept private MMIO ranges

[Duan, Zhenzhong]

>-----Original Message-----
>From: Li, Xiaoyao <xiaoyao.li@xxxxxxxxx>
>On 9/24/2026 12:10 PM, Zhenzhong Duan wrote:
>> Build private MMIO descriptors from the TDI report using the PCI TSM
>> MMIO helpers and accept each private range through TDG.MMIO.ACCEPT.
>>
>> Keep the descriptors while the device remains locked and tear them
>> down on acceptance failure and during unlock.
>
>1. The changelog talks what it does but not why the patch is needed and
>what is
>the design consideration. E.g.,
>
> - why choose to setup MMIO in the .run callback instead of .lock?
>
> - is tdx_tdi_mmio_teardown() safe for MMIO partial acceptance? when
>current
>"run" fails with partial MMIO acceptance, can the second "run" work well?

After thinking about this further, a second .run() attempt cannot recover
from partial MMIO acceptance with the current implementation. It starts
accepting ranges from the beginning, so it will encounter a re-acceptance
error on the first range successfully accepted by the previous attempt,
before reaching the range that originally failed.

When .run() fails, the device is not accepted for driver attachment, so
there should be no driver MMIO accesses. Therefore, removing the
guest-side MMIO resource entries and freeing the descriptors in
tdx_tdi_mmio_teardown() should be safe. However, this cleanup does not
undo the MMIO acceptance already performed by the TDX module.

There is no TDG.MMIO.UNACCEPT ABI to roll back those successful
acceptances. Recovery therefore requires unlocking the device through
the UNBIND hypercall, which asks the host to tear down the associated
MMIO mappings, before locking and accepting the device again.