[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] portability issues


  • To: Jan Beulich <jbeulich@xxxxxxxxxx>
  • From: Keir Fraser <keir@xxxxxxxxxxxxx>
  • Date: Thu, 21 Jun 2007 11:37:58 +0100
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 21 Jun 2007 03:36:07 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acez8DvKeiJkPh/jEdyfwwAX8io7RQ==
  • Thread-topic: [Xen-devel] portability issues

On 21/6/07 11:16, "Jan Beulich" <jbeulich@xxxxxxxxxx> 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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.