On 5/24/2022 2:57 PM, Gerd Hoffmann wrote:
Hi,
Hmm, hooking *vm* initialization into *vcpu* creation looks wrong to me.
That's because for TDX, it has to do VM-scope (feature) initialization
before creating vcpu. This is new to KVM and QEMU, that every feature is
vcpu-scope and configured per-vcpu before.
To minimize the change to QEMU, we want to utilize @cpu and @cpu->env to
grab the configuration info. That's why it goes this way.
Do you have any better idea on it?
Maybe it's a bit more work to add VM-scope initialization support to
qemu.
If just introducing VM-scope initialization to QEMU, it would be easy.
What matters is what needs to be done inside VM-scope initialization.
For TDX, we need to settle down the features that configured for the TD.
Typically, the features are attributes of cpu object, parsed from "-cpu"
option and stored in cpu object.
I cannot think up a clean solution for it, other than
1) implement the same attributes from cpu object to machine object, or
2) create a CPU object when initializing machine object and collect all
the info from "-cpu" and drop it in the end; then why not do it when
creating 1st vcpu like this patch.
That's what I can think up. Let's see if anyone has better idea.
But I expect that approach will work better long-term. You need
this mutex and the 'initialized' variable in your code to make sure it
runs only once because the way you hook it in is not ideal ...
[ disclaimer: I'm not that familiar with the kvm interface in qemu ]
take care,
Gerd
