[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.
Xen-devel mailing list