[libvirt] [RFC] New API to retrieve node CPU map

Eric Blake eblake at redhat.com
Wed Oct 10 21:23:48 UTC 2012


On 10/10/2012 09:18 AM, Viktor Mihajlovski wrote:
> Hi,
> 
> in order to use the APIs listed below it is necessary for a client to
> know the maximum number of node CPUs which is passed via the maplen
> argument.
> 
> virDomainGetEmulatorPinInfo
> virDomainGetVcpuPinInfo
> virDomainGetVcpus
> virDomainPinEmulator
> virDomainPinVcpu
> virDomainPinVcpuFlags
> 
> The current approach uses virNodeGetInfo to determine the maximum CPU
> number. This can lead to incorrect results if not all node CPUs are
> online. The maximum CPU number should always be the number of CPUs
> present on the host, regardless of their online/offline state.
> 

> This is not a display problem only, because it is also not possible to
> explicitly pin the virtual CPU to host CPUs 0 and 2, due to the
> truncated CPU mask.

Indeed, offline host cpus introduce lots of oddities.  Your idea of a
new API makes sense, although there's still some details to work out.

> 
> PROPOSAL:
> 
> To help solve the issue above I suggest two new public API functions:
> 
> int
> virNodeGetCpuNum(virConnectPtr conn);
> 
> returning the number of present CPUs on the host or -1 upon failure
> and
> 
> int
> virNodeGetCpuMap(virConnectPtr conn, unsigned char * cpumap, int maplen);

Lately, we have been favoring APIs that auto-allocate, instead of making
the user call two separate APIs and risk a race where the answer from
the first call is no longer matching reality during the second call.
That is, if I hot[un]plug a CPU in between the two proposed API calls,
will my maplen of the second call as learned from the first call still
be accurate?  And why should I have to call two functions?

I think it might be better to write:

int
virNodeGetCpuMap(virConnectPtr conn, unsigned char **cpumap);

where *cpumap will be malloc'd by libvirt and the return value be the
maplen (also allow cpumap==NULL on entry to just query the map len
without also allocating).  Then the result is -1/maplen instead of -1/0
for failure/success.

> 
> returning the number of present CPUs or -1 on failure and storing a bit
> map of real CPUs as described in virDomainPinVcpu in cpumap. The bits in
> the bit map are set to 1 for online CPUs and set to 0 for offline CPUs.
> 
> Implementation is facilitated by the function nodeGetCPUmap in nodeinfo.c.
> 
> Clients can use virNodeGetCpuNum to properly determine the maximum
> number of node CPUs and the online/offline information.
> 
> Thanks for your comments.

Are you interested in writing patches to implement this new API, if
others agree with my alternate single-API signature?

-- 
Eric Blake   eblake at redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 617 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20121010/a61df987/attachment-0001.sig>


More information about the libvir-list mailing list