On Tue, Feb 17, 2015 at 04:03:50PM -0500, John Ferlan wrote:
Add virDomainGetIOThreadsInfo in order to return a list of
virDomainIOThreadsInfoPtr structures which list the IOThread ID,
the CPU Affinity map, and associated resources for each IOThread
for the domain. For an active domain, the live data will be
returned, while for an inactive domain, the config data will be
returned. The resources data is expected to be the src path for
the disks that have an assigned iothread.
The API supports either the --live or --config flag, but not both.
Also added virDomainIOThreadsInfoFree in order to free the cpumap,
list of resources, and the array entry structure.
Signed-off-by: John Ferlan <jferlan(a)redhat.com>
---
include/libvirt/libvirt-domain.h | 23 +++++++++++-
src/driver-hypervisor.h | 8 +++-
src/libvirt-domain.c | 80 +++++++++++++++++++++++++++++++++++++++-
src/libvirt_public.syms | 6 +++
4 files changed, 114 insertions(+), 3 deletions(-)
/**
+ * virIOThreadsInfo:
s/Threads/Thread/ as it only contains info about one thread.
+ *
+ * The data structure for information about IOThreads in a domain
+ */
+typedef struct _virDomainIOThreadsInfo virDomainIOThreadsInfo;
+typedef virDomainIOThreadsInfo *virDomainIOThreadsInfoPtr;
+struct _virDomainIOThreadsInfo {
+ unsigned int iothread_id; /* IOThread ID */
Since iothread ids are sequential, starting from 1, this value will
always be the index in the array + 1.
+ unsigned char *cpumap; /* CPU map for thread */
+ int cpumaplen; /* cpumap size */
+ size_t nresources; /* count of resources using
IOThread */
+ char **resources; /* array of resources using IOThread */
"resources" is too vague.
Moreover, storing the source path here does not seem that much useful to
me, considering that the corresponding *Set API cannot change the
resources used by the thread (also, some disks don't even have a path).
Considering that the XML format is copying <vcpupin>, maybe this API
could have a similar signature? I.e.:
int
virDomainGetIOThreadPin(virDomainPtr domain,
unsigned int ncpumaps,
unsigned char *cpumaps,
unsigned int maplen,
unsigned int flags)
Or without the 'ncpumaps' parameter, so we don't need an API to get the
number of iothreads.
Another possibility is getting rid of the 'maplen' as well and return
the bitmap as formatted by virBitmapFormat (but the client app still
needs the node CPU count to interpret it correctly).
Jan