Re: [Xen-devel] [PATCH] RFC: Use memops for mem paging, sharing, and access, instead of domctls

["Andres Lagar-Cavilla" <andres@xxxxxxxxxxxxxxxx>]

> On Wed, Jan 11, Andres Lagar-Cavilla wrote:
>
>> +++ b/xen/include/public/domctl.h
>
>> +/* Use for teardown/setup of helper<->hypervisor interface for paging,
>> + * access and sharing.*/
>>  struct xen_domctl_mem_event_op {
>>      uint32_t       op;           /* XEN_DOMCTL_MEM_EVENT_OP_*_* */
>>      uint32_t       mode;         /* XEN_DOMCTL_MEM_EVENT_OP_* */
>>
>> -    union {
>> -        /* OP_ENABLE IN:  Virtual address of shared page */
>> -        uint64_aligned_t shared_addr;
>> -        /* PAGING_PREP IN: buffer to immediately fill page in */
>> -        uint64_aligned_t buffer;
>> -    } u;
>> +    uint64_aligned_t shared_addr;  /* IN:  Virtual address of shared
>> page */
>>      uint64_aligned_t ring_addr;    /* IN:  Virtual address of ring page
>> */
>>
>> -    /* Other OPs */
>> -    uint64_aligned_t gfn;          /* IN:  gfn of page being operated
>> on */
>> +    /* For binary backwards compatibility */
>> +    uint64_aligned_t pad;
>>  };
>
> Assuming this struct is routed through libxc, and libxc gets a new
> SONAME for every release, doesnt this mean that every old binary has to
> be recompiled anyway for the new release?
> If so, the padding is not needed.
Agreed, basically. Waiting to hear from tools maintainers about best
approach to libxc.

It seems that there aren't that many users relying on a fixed ABI, so we
can (still, until 4.2) change things. But obviously I want to be careful.

Andres
>
> Olaf
>
>



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