From mboxrd@z Thu Jan  1 00:00:00 1970
From: Keir Fraser <keir@xensource.com>
Subject: Re: portability issues
Date: Thu, 21 Jun 2007 11:37:58 +0100
Message-ID: <C2A01396.11054%keir@xensource.com>
References: <467A6C05.76E4.0078.0@novell.com>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xensource.com>
In-Reply-To: <467A6C05.76E4.0078.0@novell.com>
List-Unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: Jan Beulich <jbeulich@novell.com>
Cc: xen-devel@lists.xensource.com
List-Id: xen-devel@lists.xenproject.org

On 21/6/07 11:16, "Jan Beulich" <jbeulich@novell.com> wrote:

>> 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.

I'm proposing we do not change the guest_context structure at all. Instead
the tools will get at this extra state via a generalised form of the current
hvm save/restore interface. The guest itself will always have to set the
callback via the callback_op hypercall.

 -- Keir