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] [PATCH] getvcpuinfo additional information

To: Ben Thomas <bthomas@xxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] getvcpuinfo additional information
From: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Date: Wed, 8 Nov 2006 00:08:54 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 07 Nov 2006 16:09:13 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <455109C6.9000002@xxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <45510125.10606@xxxxxxxxxxxxxxx> <20061107221915.GD25965@xxxxxxxxxx> <455109C6.9000002@xxxxxxxxxxxxxxx>
Reply-to: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.1i
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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

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