On 08/11/2018 10:57, Liran Alon wrote: > > >> On 8 Nov 2018, at 11:50, Paolo Bonzini <pbonzini@xxxxxxxxxx> 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. We are somewhat limited by the ABI of the released kernel versions, and it's unlikely that the structure will change in the short term. So I think it's okay if we just define that the first 4K of data are the VMCS and the second 8K are the shadow VMCS, whenever format=0 in the kvm_nested_state struct. Paolo > 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 >
