All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Liran Alon <liran.alon@oracle.com>
Cc: qemu-devel@nongnu.org, pbonzini@redhat.com, mtosatti@redhat.com,
	rth@twiddle.net, ehabkost@redhat.com, kvm@vger.kernel.org,
	jmattson@google.com, maran.wilson@oracle.com,
	Nikita Leshenko <nikita.leshchenko@oracle.com>
Subject: Re: [QEMU PATCH v3 7/9] KVM: i386: Add support for save and restore nested state
Date: Tue, 18 Jun 2019 16:48:17 +0100	[thread overview]
Message-ID: <20190618154817.GI2850@work-vm> (raw)
In-Reply-To: <32C4B530-A135-475B-B6AF-9288D372920D@oracle.com>

* Liran Alon (liran.alon@oracle.com) wrote:
> 
> > On 18 Jun 2019, at 12:03, Dr. David Alan Gilbert <dgilbert@redhat.com> wrote:
> > 
> > * Liran Alon (liran.alon@oracle.com) wrote:
> >> 
> >> +static const VMStateDescription vmstate_vmx_vmcs12 = {
> >> +	.name = "cpu/kvm_nested_state/vmx/vmcs12",
> >> +	.version_id = 1,
> >> +	.minimum_version_id = 1,
> >> +	.needed = vmx_vmcs12_needed,
> >> +	.fields = (VMStateField[]) {
> >> +	    VMSTATE_UINT8_ARRAY(data.vmx[0].vmcs12,
> >> +	                        struct kvm_nested_state, 0x1000),
> > 
> > Where did that magic 0x1000 come from?
> 
> Currently, KVM folks (including myself), haven’t decided yet to expose vmcs12 struct layout to userspace but instead to still leave it opaque.
> The formal size of this size is VMCS12_SIZE (defined in kernel as 0x1000). I was wondering if we wish to expose VMCS12_SIZE constant to userspace or not.
> So currently I defined these __u8 arrays as 0x1000. But in case Paolo agrees to expose VMCS12_SIZE, we can use that instead.

Well if it's not defined it's bound to change at some state!
Also, do we need to clear it before we get it from the kernel - e.g.
is the kernel guaranteed to give us 0x1000 ?

Dave

> -Liran
> 
> > --
> > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

WARNING: multiple messages have this Message-ID (diff)
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Liran Alon <liran.alon@oracle.com>
Cc: ehabkost@redhat.com, kvm@vger.kernel.org,
	maran.wilson@oracle.com, mtosatti@redhat.com,
	qemu-devel@nongnu.org,
	Nikita Leshenko <nikita.leshchenko@oracle.com>,
	pbonzini@redhat.com, jmattson@google.com, rth@twiddle.net
Subject: Re: [Qemu-devel] [QEMU PATCH v3 7/9] KVM: i386: Add support for save and restore nested state
Date: Tue, 18 Jun 2019 16:48:17 +0100	[thread overview]
Message-ID: <20190618154817.GI2850@work-vm> (raw)
In-Reply-To: <32C4B530-A135-475B-B6AF-9288D372920D@oracle.com>

* Liran Alon (liran.alon@oracle.com) wrote:
> 
> > On 18 Jun 2019, at 12:03, Dr. David Alan Gilbert <dgilbert@redhat.com> wrote:
> > 
> > * Liran Alon (liran.alon@oracle.com) wrote:
> >> 
> >> +static const VMStateDescription vmstate_vmx_vmcs12 = {
> >> +	.name = "cpu/kvm_nested_state/vmx/vmcs12",
> >> +	.version_id = 1,
> >> +	.minimum_version_id = 1,
> >> +	.needed = vmx_vmcs12_needed,
> >> +	.fields = (VMStateField[]) {
> >> +	    VMSTATE_UINT8_ARRAY(data.vmx[0].vmcs12,
> >> +	                        struct kvm_nested_state, 0x1000),
> > 
> > Where did that magic 0x1000 come from?
> 
> Currently, KVM folks (including myself), haven’t decided yet to expose vmcs12 struct layout to userspace but instead to still leave it opaque.
> The formal size of this size is VMCS12_SIZE (defined in kernel as 0x1000). I was wondering if we wish to expose VMCS12_SIZE constant to userspace or not.
> So currently I defined these __u8 arrays as 0x1000. But in case Paolo agrees to expose VMCS12_SIZE, we can use that instead.

Well if it's not defined it's bound to change at some state!
Also, do we need to clear it before we get it from the kernel - e.g.
is the kernel guaranteed to give us 0x1000 ?

Dave

> -Liran
> 
> > --
> > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK


  reply	other threads:[~2019-06-18 15:48 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-17 17:56 [QEMU PATCH v3 0/9]: KVM: i386: Add support for save and restore of nested state Liran Alon
2019-06-17 17:56 ` [Qemu-devel] " Liran Alon
2019-06-17 17:56 ` [QEMU PATCH v3 1/9] KVM: Introduce kvm_arch_destroy_vcpu() Liran Alon
2019-06-17 17:56   ` [Qemu-devel] " Liran Alon
2019-06-18 22:15   ` Maran Wilson
2019-06-18 22:15     ` Maran Wilson
2019-06-17 17:56 ` [QEMU PATCH v3 2/9] KVM: i386: Use symbolic constant for #DB/#BP exception constants Liran Alon
2019-06-17 17:56   ` [Qemu-devel] " Liran Alon
2019-06-17 17:56 ` [QEMU PATCH v3 3/9] KVM: i386: Re-inject #DB to guest with updated DR6 Liran Alon
2019-06-17 17:56   ` [Qemu-devel] " Liran Alon
2019-06-17 17:56 ` [QEMU PATCH v3 4/9] KVM: i386: Block migration for vCPUs exposed with nested virtualization Liran Alon
2019-06-17 17:56   ` [Qemu-devel] " Liran Alon
2019-06-18  8:44   ` Dr. David Alan Gilbert
2019-06-18  8:44     ` [Qemu-devel] " Dr. David Alan Gilbert
2019-06-18 22:16   ` Maran Wilson
2019-06-18 22:16     ` Maran Wilson
2019-06-17 17:56 ` [QEMU PATCH v3 5/9] linux-headers: i386: Modify struct kvm_nested_state to have explicit fields for data Liran Alon
2019-06-17 17:56   ` [Qemu-devel] " Liran Alon
2019-06-18 22:16   ` Maran Wilson
2019-06-18 22:16     ` Maran Wilson
2019-06-17 17:56 ` [QEMU PATCH v3 6/9] vmstate: Add support for kernel integer types Liran Alon
2019-06-17 17:56   ` [Qemu-devel] " Liran Alon
2019-06-18  8:55   ` Dr. David Alan Gilbert
2019-06-18  8:55     ` [Qemu-devel] " Dr. David Alan Gilbert
2019-06-18 15:36     ` Liran Alon
2019-06-18 15:36       ` [Qemu-devel] " Liran Alon
2019-06-18 15:42       ` Dr. David Alan Gilbert
2019-06-18 15:42         ` [Qemu-devel] " Dr. David Alan Gilbert
2019-06-18 16:44         ` Paolo Bonzini
2019-06-18 16:44           ` [Qemu-devel] " Paolo Bonzini
2019-06-17 17:56 ` [QEMU PATCH v3 7/9] KVM: i386: Add support for save and restore nested state Liran Alon
2019-06-17 17:56   ` [Qemu-devel] " Liran Alon
2019-06-18  9:03   ` Dr. David Alan Gilbert
2019-06-18  9:03     ` [Qemu-devel] " Dr. David Alan Gilbert
2019-06-18 15:40     ` Liran Alon
2019-06-18 15:40       ` [Qemu-devel] " Liran Alon
2019-06-18 15:48       ` Dr. David Alan Gilbert [this message]
2019-06-18 15:48         ` Dr. David Alan Gilbert
2019-06-18 15:50         ` Liran Alon
2019-06-18 15:50           ` [Qemu-devel] " Liran Alon
2019-06-18 16:16         ` Paolo Bonzini
2019-06-18 16:16           ` [Qemu-devel] " Paolo Bonzini
2019-06-18 22:16   ` Maran Wilson
2019-06-18 22:16     ` Maran Wilson
2019-06-17 17:56 ` [QEMU PATCH v3 8/9] KVM: i386: Add support for KVM_CAP_EXCEPTION_PAYLOAD Liran Alon
2019-06-17 17:56   ` [Qemu-devel] " Liran Alon
2019-06-18  9:07   ` Dr. David Alan Gilbert
2019-06-18  9:07     ` [Qemu-devel] " Dr. David Alan Gilbert
2019-06-18 15:45     ` Liran Alon
2019-06-18 15:45       ` [Qemu-devel] " Liran Alon
2019-06-17 17:56 ` [QEMU PATCH v3 9/9] KVM: i386: Remove VMX migration blocker Liran Alon
2019-06-17 17:56   ` [Qemu-devel] " Liran Alon
2019-06-18 22:17   ` Maran Wilson
2019-06-18 22:17     ` Maran Wilson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190618154817.GI2850@work-vm \
    --to=dgilbert@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=jmattson@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=liran.alon@oracle.com \
    --cc=maran.wilson@oracle.com \
    --cc=mtosatti@redhat.com \
    --cc=nikita.leshchenko@oracle.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.