[Libvir] Extending libvirt to probe NUMA topology

[Daniel Veillard]

On Tue, Sep 11, 2007 at 03:08:46AM +0100, Daniel P. Berrange wrote:
> On Mon, Sep 10, 2007 at 09:52:46PM -0400, beth kon wrote:
> > Daniel,
> > 
> > I'm taking a stab at this work and want to be sure I'm taking the right 
> > approach. I'm new to xen and even newer to libvirt, so have a bit of a 
> > learning curve.

  I suggest the following: I make all the libvirt specific infrastructure
work to plug the new calls which is where I will be the most efficient,
and I let you plug code to talk to Xen which is where you will be more
up to date and able to test, okay ?

> > For the topology information, I assume that this will be a call through 
> > xend, similar to  xenDaemonNodeGetInfo. It would seem natural to somehow 
> > extend the xenDaemonNodeGetInfo with this additional information except 
> > that you suggested having the output in XML. Can you explain why you 
> > chose XML?
> 
> We have to maintain 100% ABI & API compatability against older releases
> of libvirt. This means that once we add a function, struct or other 
> definition in the header files it cannot ever be changed again. So this
> means we can't change the virNodeInfo struct to add NUMA info.
> 
> For this reason we tend to keep struct's just for use in APIs where the
> performance is critical, or data set is unlikely to ever change. So far
> we only use structs for virDomainInfo, virNodeInfo, virSchedParam and
> virVcpuInfo at this time. For more descriptive data we format information
> into an XML document. This makes it very easy to add new XML elements and
> attributes to represent new data items. The same compatability rules apply
> to XML though - once we add an attribute or element it can never be removed
> from the spec. Currently we think putting the NUMA info into XML is the
> best approach since it is not performance critical.
> 
> 
> There are two ways to implement it with Xen - either talk to XenD and
> extract the topology there, or make direct hypercalls. For now it is
> probably easiest to talk to XenD, since this isn't performance critical.

  Agreed, we could use the hypervisor calls but that means extending
that module which is already a bit painful for all the backward compatibility
workaround. Xend access should be simpler, at least in a first implementation.

  I will try to come later today with a first patch defining the framework
and leaving functions to fill for the new calls in the xend_internal.c 
backend.

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/