[Libvir] Extending libvirt to probe NUMA topology

[beth kon]

Daniel Veillard wrote:

>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
>
>  
>
That sounds fine. Thanks for the offer, Daniel!

-- 
Elizabeth Kon (Beth)
IBM Linux Technology Center
Open Hypervisor Team
email: eak at us.ibm.com