On Fri, Jun 05, 2026, Ackerley Tng wrote:
> Sean Christopherson <[email protected]> writes:
>
> >
> > [...snip...]
> >
> >> Was kvm_arch_vm_finalize_vcpus() supposed to be for finalizing vCPUs
> >> instead?
> >>
> >> The awkward part is that kvm_arch_vm_finalize_vcpus() is called from
> >> __vm_create_with_vcpus().
> >>
> >> While building this POC to test conversions [1] I only wanted to create
> >> the vm and vcpus and didn't want to finalize yet, since I still needed
> >> to do more mappings in the guest (and I needed the vm pointer to do
> >> mappings in the guest).
> >
> > Hmm, I would argue this is a flaw in the selftests infrastructure. IMO, as
> > a
> > developer, it's quite surprising that the current value of a global variable
> > doesn't show up in the VM automagically. I totally understand why selftests
> > work that way, but it's certainly odd and annoying. If _that_ were solved,
> > then
> > the kludginess of what you're doing goes away.
> >
> > The other way this could be solved is by adding support for annotating
> > globals
> > with a __shared flag, a la the kernel's __bss_decrypted, so that loading
> > memory
> > into the VM can automatically mark the associated globals' pages as shared.
> >
>
> More generally, is your opinion that tests should not have to add extra
> memslots?
I don't care? What I care about is making it as easy and intuitive as possible
for people to write tests, and to minimize maintenance costs.
> If I wanted a shared page, would I have to do
>
> static __shared test_page[4096] = {0};
>
> and then rely on ELF loading to put that in the guest for me? Are there
> some compiler flags/how will I require that test_page be page aligned?
Compilere and linker shenanigans.
> If I mark 10 globals as __shared, would the compiler automatically
> consolidate the shared memory together?
Yes, follow the __bss_decrypted breadcrumbs.
#define __bss_decrypted __section(".bss..decrypted")
> I think it's a bit constraining to require that all guest memory be set
> up statically. It's nice to have but I'd like another option...
You do have options, they just require more work.
> Many tests use vm_userspace_mem_region_add(), CoCo tests that require
> finalizing shouldn't be disallowed that option.
What does that have to do with finalizing the VM?
> >> It's also possible to have some kvm_vm_finalize() call that can be
> >> explicitly and manually invoked from selftests just for CoCo selftests.
> >
> > Why bother? It's obviously possible to all kvm_arch_vm_finalize_vcpus()
> > directly.
>
> Works for me to call directly. Do you mean kvm_arch_vm_finalize_vcpus()
> is the right function where the TD is finalized?
>
> For tests that need to do more setup after creating a vm, is the only
> way out to call __vm_create() then vm_vcpu_add() to avoid premature
> finalization in __vm_create_with_vcpus() when
> kvm_arch_vm_finalize_vcpus() is called?
Depends on what you're doing. Sometimes, the answer will be yes. That's why
there are "low level" APIs, so that some tests can do fancy things, while most
tests can leave the details to the infrastructure.
If there's a recurring problem, or we anticipate one, then we can and should
figure out how to minimize the pain so that tests don't have to deal with the
same boilerplate issues over and over. Hence the __shared idea.
