From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: portability issues Date: Thu, 21 Jun 2007 11:16:05 +0100 Message-ID: <467A6C05.76E4.0078.0@novell.com> References: <467A66B3.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org >>> Keir Fraser 21.06.07 11:58 >>> >On 21/6/07 10:53, "Jan Beulich" wrote: > >>> (1) and (2): I want to kill off use of vcpu_guest_context in dom0 = tools, >>> make hvm save/restore a generic state load/save interface, and define >>> extensible structures at that interface (pass a stream of state chunks = back >>> and forth at the interface, each chunk having a size in its header, = and so >>> increasing the size of a chunk allows it to be naturally appended to = and >>> hence extended). >>=20 >> I wasn't concerned about the tools interface. The real compatibility = problem >> is VCPUOP_initialize. > >I don't see the problem. The guest will not be able to initialise = secondary >VCPU's sysenter/syscall state via this interface. So what? For (1), the guest will supply a too short guest_context structure, and currently Xen has no way of detecting this. I was proposing two possible solutions, neither of which seemed ideal to me. For (2), I am just not certain whether there isn't an alternative not = breaking the interface for pure 32-bits. Jan