qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [QEMU PATCH v2 0/2]: KVM: i386: Add support for save an


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [QEMU PATCH v2 0/2]: KVM: i386: Add support for save and restore nested state
Date: Thu, 8 Nov 2018 18:02:58 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0

On 08/11/2018 10:57, Liran Alon wrote:
> 
> 
>> On 8 Nov 2018, at 11:50, Paolo Bonzini <address@hidden> 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
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]