Mailing List Archive

On Tue, Nov 07, 2006 at 04:56:53PM -0500, Ben Thomas wrote:
> On a number of instances, it has proved quite useful to be able to
> easily examine more of the VCPU state. Specifically, the information
> contained in the runstate structure. This patch extends the
> returned information to contain the entire runstate structure.
> A simple usage example is a dom0 user-mode program that can dump all
> of the times for each VCPU (eg, running, blocked, runnable).

[snip]

> Index: xen-unstable.hg/xen/include/public/domctl.h
> ===================================================================
> --- xen-unstable.hg.orig/xen/include/public/domctl.h 2006-11-06 17:12:03.000000000 -0500
> +++ xen-unstable.hg/xen/include/public/domctl.h 2006-11-06 17:12:08.000000000 -0500
> @@ -15,6 +15,7 @@
> #endif
>
> #include "xen.h"
> +#include "vcpu.h"
>
> #define XEN_DOMCTL_INTERFACE_VERSION 0x00000004
>
> @@ -239,8 +240,8 @@
> uint8_t online; /* currently online (not hotplugged)? */
> uint8_t blocked; /* blocked waiting for an event? */
> uint8_t running; /* currently scheduled on its CPU? */
> - uint64_t cpu_time; /* total cpu time consumed (ns) */
> uint32_t cpu; /* current mapping */
> + vcpu_runstate_info_t runstate; /* VCPU runstate info (see vcpu.h) */
> };
> typedef struct xen_domctl_getvcpuinfo xen_domctl_getvcpuinfo_t;
> DEFINE_XEN_GUEST_HANDLE(xen_domctl_getvcpuinfo_t);

While I like the improved information reporting this change gives us, this is
breaking the HV <-> Dom0 management API...yet again. At very least the
XEN_DOMCTL_INTERFACE_VERSION version should be incremented, but personally
I'd like to see API & ABI stability maintained by leaving the existing
hypercall alone & adding a new hypercall which deals with extra data.

Regards,
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

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

Hi Dan,

I figured I'd get some comments on this one, so I decided to send it off
and see what came back...

A while back, I did ask about how to approach this and got the following
response (the author can id themselves if they wish):

"We do not guarantee API or ABI stability on the control-tool interfaces,
so after 3.0.3 has forked we can certainly take patches that extend the
VCPU information available to the tools in the cleanest way we can find."

But, times and circumstances change. I find the extra information useful.
I'm willing to do a moderate amount of work to contribute the change back
in whatever form is deemed most appropriate. So, let's see where this
settles out and I'll recast the patch and resubmit (if necessary).

Thanks,
-b


Daniel P. Berrange wrote:
> On Tue, Nov 07, 2006 at 04:56:53PM -0500, Ben Thomas wrote:
>
>>On a number of instances, it has proved quite useful to be able to
>>easily examine more of the VCPU state. Specifically, the information
>>contained in the runstate structure. This patch extends the
>>returned information to contain the entire runstate structure.
>>A simple usage example is a dom0 user-mode program that can dump all
>>of the times for each VCPU (eg, running, blocked, runnable).
>
>
> [snip]
>
>
>>Index: xen-unstable.hg/xen/include/public/domctl.h
>>===================================================================
>>--- xen-unstable.hg.orig/xen/include/public/domctl.h 2006-11-06 17:12:03.000000000 -0500
>>+++ xen-unstable.hg/xen/include/public/domctl.h 2006-11-06 17:12:08.000000000 -0500
>>@@ -15,6 +15,7 @@
>>#endif
>>
>> #include "xen.h"
>>+#include "vcpu.h"
>>
>> #define XEN_DOMCTL_INTERFACE_VERSION 0x00000004
>>
>>@@ -239,8 +240,8 @@
>> uint8_t online; /* currently online (not hotplugged)? */
>> uint8_t blocked; /* blocked waiting for an event? */
>> uint8_t running; /* currently scheduled on its CPU? */
>>- uint64_t cpu_time; /* total cpu time consumed (ns) */
>> uint32_t cpu; /* current mapping */
>>+ vcpu_runstate_info_t runstate; /* VCPU runstate info (see vcpu.h) */
>> };
>> typedef struct xen_domctl_getvcpuinfo xen_domctl_getvcpuinfo_t;
>> DEFINE_XEN_GUEST_HANDLE(xen_domctl_getvcpuinfo_t);
>
>
> While I like the improved information reporting this change gives us, this is
> breaking the HV <-> Dom0 management API...yet again. At very least the
> XEN_DOMCTL_INTERFACE_VERSION version should be incremented, but personally
> I'd like to see API & ABI stability maintained by leaving the existing
> hypercall alone & adding a new hypercall which deals with extra data.
>
> Regards,
> Dan.


--
------------------------------------------------------------------------
Ben Thomas Virtual Iron Software
bthomas@virtualiron.com Tower 1, Floor 2
978-849-1214 900 Chelmsford Street
Lowell, MA 01851

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

On Tue, Nov 07, 2006 at 05:33:42PM -0500, Ben Thomas wrote:
> I figured I'd get some comments on this one, so I decided to send it off
> and see what came back...
>
> A while back, I did ask about how to approach this and got the following
> response (the author can id themselves if they wish):
>
> "We do not guarantee API or ABI stability on the control-tool interfaces,
> so after 3.0.3 has forked we can certainly take patches that extend the
> VCPU information available to the tools in the cleanest way we can find."

That's ok - I understand why XenSource want to reserve the right to change
ABI at any time. If its neccessary to do it again here we have ability
to add versioning checks in libvirt to deal with it - but if there is a
way to maintain compatability without over-complicating the code I think
its worth a try.

> But, times and circumstances change. I find the extra information useful.
> I'm willing to do a moderate amount of work to contribute the change back
> in whatever form is deemed most appropriate. So, let's see where this
> settles out and I'll recast the patch and resubmit (if necessary).


> Daniel P. Berrange wrote:
> >On Tue, Nov 07, 2006 at 04:56:53PM -0500, Ben Thomas wrote:
> >
> >>On a number of instances, it has proved quite useful to be able to
> >>easily examine more of the VCPU state. Specifically, the information
> >>contained in the runstate structure. This patch extends the
> >>returned information to contain the entire runstate structure.
> >>A simple usage example is a dom0 user-mode program that can dump all
> >>of the times for each VCPU (eg, running, blocked, runnable).
> >
> >
> >[snip]
> >
> >
> >>Index: xen-unstable.hg/xen/include/public/domctl.h
> >>===================================================================
> >>--- xen-unstable.hg.orig/xen/include/public/domctl.h 2006-11-06
> >>17:12:03.000000000 -0500
> >>+++ xen-unstable.hg/xen/include/public/domctl.h 2006-11-06
> >>17:12:08.000000000 -0500
> >>@@ -15,6 +15,7 @@
> >>#endif
> >>
> >>#include "xen.h"
> >>+#include "vcpu.h"
> >>
> >>#define XEN_DOMCTL_INTERFACE_VERSION 0x00000004
> >>
> >>@@ -239,8 +240,8 @@
> >> uint8_t online; /* currently online (not
> >> hotplugged)? */
> >> uint8_t blocked; /* blocked waiting for an event? */
> >> uint8_t running; /* currently scheduled on its CPU?
> >> */
> >>- uint64_t cpu_time; /* total cpu time consumed (ns) */
> >> uint32_t cpu; /* current mapping */
> >>+ vcpu_runstate_info_t runstate; /* VCPU runstate info (see vcpu.h)
> >>*/
> >>};
> >>typedef struct xen_domctl_getvcpuinfo xen_domctl_getvcpuinfo_t;
> >>DEFINE_XEN_GUEST_HANDLE(xen_domctl_getvcpuinfo_t);
> >
> >
> >While I like the improved information reporting this change gives us, this
> >is
> >breaking the HV <-> Dom0 management API...yet again. At very least the
> >XEN_DOMCTL_INTERFACE_VERSION version should be incremented, but personally
> >I'd like to see API & ABI stability maintained by leaving the existing
> >hypercall alone & adding a new hypercall which deals with extra data.

Regards,
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

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