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?
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?
If I mark 10 globals as __shared, would the compiler automatically
consolidate the shared memory together?
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...
Many tests use vm_userspace_mem_region_add(), CoCo tests that require
finalizing shouldn't be disallowed that option.
>> Would calling tdx_vm_finalize() from within vcpu_run(), just once, be
>> too magical?
>
> Yes.
>
>> 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?