From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Zhai, Edwin" Subject: Re: [PATCH 4/8] HVM save restore: vcpu context support Date: Fri, 12 Jan 2007 09:59:08 +0800 Message-ID: <20070112015908.GH6153@edwin-srv.sh.intel.com> References: <20070111141037.GA2889@edwin-gen.sh.intel.com> <45A6761A.7020609@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <45A6761A.7020609@linux.vnet.ibm.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Anthony Liguori Cc: xen-devel@lists.xensource.com, "Zhai, Edwin" List-Id: xen-devel@lists.xenproject.org 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 > > > > 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