> On 8 Nov 2018, at 11:50, Paolo Bonzini <pbonz...@redhat.com> wrote:
>
> On 08/11/2018 01:45, Jim Mattson wrote:
>> I have no attachments to the current design. I had used a data[] blob,
>> because I didn't think userspace would have any need to know what was
>> in there. However, I am now seeing the error of my ways. For example,
>> the userspace instruction emulator needs to know the contents of the
>> vmcs12 to emulate instructions when in guest mode.
>
> Yeah, we're probably going to have to document the KVM vmcs12 structure,
> possibly moving it to uapi. But that's a different thing from
> save/restore state, which can use the 4K or 8K data[] blob.
>
> Paolo
But regardless of if we document vmcs12 or not, the current blob we have today
should be separated to well-defined blobs/structs (cached_vmcs12 and
cached_shadow_vmcs12)
and each blob should have a relevant flag that specifies it is valid (saved by
kernel or requested to be restored by userspace).
Additional future nested-state should be added as additional well-defined
blobs/structs with appropriate flags.
Then, in QEMU, each such well-defined blob/struct should have it’s own
subsection with a relevant .needed() method.
This will allow us to preserve required backwards compatibility.
Agreed?
-Liran
