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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list