|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] [PATCH 3/7] PCI multi-seg: adjust domctl interface
On 21/09/2011 06:10, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>>>> On 21.09.11 at 14:42, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
> wrote:
>> On Wed, 21 Sep 2011, Keir Fraser wrote:
>>> On 20/09/2011 08:18, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>>>
>>>> Again, a couple of directly related functions at once get adjusted to
>>>> account for the segment number.
>>>>
>>>> Do we need to bump XEN_DOMCTL_INTERFACE_VERSION for the changes to the
>>>> domctl interface (namely the renaming and bit-reassigment of the
>>>> machine_bdf member of two of the interface structures)? If so, this
>>>> can probably be done as the patch gets checked in (rather than me
>>>> having to re-submit)?
>>>
>>> Ian suggests we should keep compatibility with old qemu versions. Are any of
>>> these hypercall commands used by qemu?
>>>
>>
>> Before b4bb8b3f09d1c873f522f6aebe1f125a6d1854d0 xc_assign_device and
>> xc_deassign_device were called by qemu. Now they are called by libxl.
>
> Ian, Keir - what does that mean for my changes then? Do I need to
> re-spin them? Do I need to even introduce new domctl structures? Or
> just up the interface version (given that retaining compatibility with
> old qemu will be impossible anyway the first time the interface version
> gets changed, unless "old qemu" simply means
> git://xenbits.xensource.com/qemu-xen-unstable.git rather than my
> understanding of old, already built binaries)?
I don't know that old qemu compat matters until we are wanting to support
builds of upstream qemu. I'm not sure we are even quite there yet. So far,
all our 'old qemus' are tied to a specific hypervisor version. So I'm not
sure we have a problem, and probably your patch is fine.
-- Keir
> Jan
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|