On Wed, Sep 16, 2026 at 11:41:19AM -0400, Zack Rusin wrote: > > I acked 1/2, but I don't like where 2/2 does the conversion. > > I saw that, thank you. Since I'll be respinning v2 of this I can go > ahead and drop the unused DECLARE_PER_CPU_DECRYPTED in that one if you > want as well.
Yes, please. > I went through the linked thread, including the dropped 2022 > Quote-buffer alias approach and the 2024 netvsc work's kexec > regression, fix and re-review discussion. I will keep TDX vmalloc > support out of this series and correct the explanation to cover alias > consistency, direct-map splitting and load_unaligned_zeropad(), > including removing the suggestion that per-page GPA lookup alone > resolves it. > > After tracing the boot paths, I think there are two distinct pieces > here. The SEV boot GHCB needs .bss..decrypted before BSS is cleared, > whereas the SMP per-CPU instances do not exist until > setup_per_cpu_areas(). KVM then registers its boot-CPU per-CPU buffers > in smp_prepare_boot_cpu(), so the common conversion needs the early > primitive you proposed. A shared early_initcall would be too late for > KVM. The UP registration path probably also needs handling separately Agreed on all of that. Leave .bss..decrypted alone in this series; the SEV boot GHCB pins its conversion to the startup code and nothing on TDX needs it today. With the primitive called before smp_prepare_boot_cpu() there is no readiness state to track. For the vmalloc-backed case, I would rather not handle it at all. Force the embed allocator when memory encryption is on: ignore percpu_alloc=page with a warning and don't fall back to page mode if embed fails, just let it hit the existing panic. On 64-bit embed only fails on memblock exhaustion at boot or when the NUMA groups spread over more than 3/4 of vmalloc space. Neither happens in a guest. > My suggestion would be to do one of two things (or at least I think > those two options are realistic to me, given that I'm no expert here): > - add the central per-CPU infrastructure and migrate KVM/VMware > together, removing both loops and putting the TDX vmalloc rejection > and readiness state in common code. Would you and the KVM maintainers > be happy with that first, and generalizing .bss..decrypted separately > while preserving its earliest SEV setup? afaict the latter also needs > to broaden the annotation and linker guards, and changes kvmclock > storage and sharing on TDX-only builds. > - a smaller VMware fix using a separately allocated, direct-mapped > page per CPU while the common infrastructure is developed. Using the > normal allocator would also defer ordinary-guest registration, unless > I kept their current static storage as a second path. This option > would retain caller-managed sharing and buffer lifetime handling. > > The second option is, of course, easier for me, but I'm happy to do > the first to get steal-time storage working for us. Do you have any > thoughts on this? The first one, please. It is the better long-term shape and it removes the KVM loop as well, so the per-CPU section finally does what its name says. -- Kiryl Shutsemau / Kirill A. Shutemov
