WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] portability issues

>>> Keir Fraser <keir@xxxxxxxxxxxxx> 21.06.07 11:58 >>>
>On 21/6/07 10:53, "Jan Beulich" <jbeulich@xxxxxxxxxx> 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).
>> 
>> 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


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

<Prev in Thread] Current Thread [Next in Thread>