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?

Reply via email to