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

Osier Yang jyang at redhat.com
Thu Oct 11 04:02:05 UTC 2012


On 2012年10月11日 05:23, Eric Blake wrote:
> 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?

Agreed. A single-API and allocating the cpumap inside libvirt without
the need to known the maplen avoids the race.

But a flags support won't bite us, assuming someone just want to get
the cpumap of the onlined CPUs, or offlined CPUs.

So how about:

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

Regards,
Osier




More information about the libvir-list mailing list