All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Zhai, Edwin" <edwin.zhai@intel.com>
To: Anthony Liguori <aliguori@linux.vnet.ibm.com>
Cc: xen-devel@lists.xensource.com, "Zhai, Edwin" <edwin.zhai@intel.com>
Subject: Re: [PATCH 4/8] HVM save restore: vcpu context support
Date: Fri, 12 Jan 2007 09:59:08 +0800	[thread overview]
Message-ID: <20070112015908.GH6153@edwin-srv.sh.intel.com> (raw)
In-Reply-To: <45A6761A.7020609@linux.vnet.ibm.com>

On Thu, Jan 11, 2007 at 11:38:34AM -0600, Anthony Liguori wrote:
> Zhai, Edwin wrote:
> >[PATCH 4/8] HVM save restore: vcpu context support
> >
> >Signed-off-by: Zhai Edwin <edwin.zhai@intel.com>
> >
> > typedef uint64_t tsc_timestamp_t; /* RDTSC timestamp */
> >+
> >+/*
> >+ * World vmcs state
> >+ */
> >+struct vmcs_data {
> >+    uint64_t  eip;        /* execution pointer */
> >+    uint64_t  esp;        /* stack pointer */
> >+    uint64_t  eflags;     /* flags register */
> >+    uint64_t  cr0;
> >+    uint64_t  cr3;        /* page table directory */
> >+    uint64_t  cr4;
> >+    uint32_t  idtr_limit; /* idt */
> >+    uint64_t  idtr_base;
> 
> If I read the code correctly, vmcs_data ends up becoming part of:
> 
> +
> +#define HVM_CTXT_SIZE        6144
> +typedef struct hvm_domain_context {
> +    uint32_t cur;
> +    uint32_t size;
> +    uint8_t data[HVM_CTXT_SIZE];
> +} hvm_domain_context_t;
> +DEFINE_XEN_GUEST_HANDLE(hvm_domain_context_t);

vmcs_data ends up as part of vcpu_guest_context. hvm_domain_context is a long 
buffer for saving dev state in HV.

> 
> Which then gets saved to disk.  My first concern would be that struct 
> vmcs_data is not padding safe.  How idtr_limit gets padding may change 
> in future versions of GCC which would break the save format.
> 
> The second is how HVM_CTXT_SIZE gets defined.  Not sure there's a great 

i just define a big enough buffer for hvm context and handle overflow.

the data true length dynamically increase when more vcpus come out, so seems
hard to let control panel know it. 

> way to address though (although the first issue is definitely fixable).
> 
> Regards,
> 
> Anthony Liguori
> 

-- 
best rgds,
edwin

  reply	other threads:[~2007-01-12  1:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-11 14:10 [PATCH 4/8] HVM save restore: vcpu context support Zhai, Edwin
2007-01-11 17:38 ` Anthony Liguori
2007-01-12  1:59   ` Zhai, Edwin [this message]
2007-01-19 15:30 ` Petersson, Mats
2007-01-19 15:39   ` Tim Deegan
2007-01-19 15:45     ` Petersson, Mats
2007-01-19 15:54       ` Keir Fraser

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=20070112015908.GH6153@edwin-srv.sh.intel.com \
    --to=edwin.zhai@intel.com \
    --cc=aliguori@linux.vnet.ibm.com \
    --cc=xen-devel@lists.xensource.com \
    /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.