Il 08/09/2013 13:52, Gleb Natapov ha scritto:
On Thu, Sep 05, 2013 at 03:06:22PM +0200, Paolo Bonzini wrote:
QEMU moves state from CPUArchState to struct kvm_xsave and back when it
invokes the KVM_*_XSAVE ioctls. Because it doesn't treat the XSAVE
region as an opaque blob, it might be
On Mon, Sep 09, 2013 at 10:51:58AM +0200, Paolo Bonzini wrote:
Il 08/09/2013 13:52, Gleb Natapov ha scritto:
On Thu, Sep 05, 2013 at 03:06:22PM +0200, Paolo Bonzini wrote:
QEMU moves state from CPUArchState to struct kvm_xsave and back when it
invokes the KVM_*_XSAVE ioctls. Because it
Il 09/09/2013 11:18, Gleb Natapov ha scritto:
On Mon, Sep 09, 2013 at 10:51:58AM +0200, Paolo Bonzini wrote:
Il 08/09/2013 13:52, Gleb Natapov ha scritto:
On Thu, Sep 05, 2013 at 03:06:22PM +0200, Paolo Bonzini wrote:
QEMU moves state from CPUArchState to struct kvm_xsave and back when it
On Mon, Sep 09, 2013 at 11:50:03AM +0200, Paolo Bonzini wrote:
Il 09/09/2013 11:18, Gleb Natapov ha scritto:
On Mon, Sep 09, 2013 at 10:51:58AM +0200, Paolo Bonzini wrote:
Il 08/09/2013 13:52, Gleb Natapov ha scritto:
On Thu, Sep 05, 2013 at 03:06:22PM +0200, Paolo Bonzini wrote:
QEMU
Il 09/09/2013 12:41, Gleb Natapov ha scritto:
In fact, perhaps even XSTATE_SUPPORTED is not restrictive enough here,
and we should hide all features that are not visible in CPUID. It is
okay, however, to test it in cpu_post_load.
The kernel should not even return state that is not visible in
On Thu, Sep 05, 2013 at 03:06:22PM +0200, Paolo Bonzini wrote:
QEMU moves state from CPUArchState to struct kvm_xsave and back when it
invokes the KVM_*_XSAVE ioctls. Because it doesn't treat the XSAVE
region as an opaque blob, it might be impossible to set some state on
the destination if
QEMU moves state from CPUArchState to struct kvm_xsave and back when it
invokes the KVM_*_XSAVE ioctls. Because it doesn't treat the XSAVE
region as an opaque blob, it might be impossible to set some state on
the destination if migrating to an older version.
This patch blocks migration if it
