[Libvir] Re: Proposal : add 3 functions to Libvirt API, for virtual CPUs
michel.ponceau at bull.net
michel.ponceau at bull.net
Tue Jul 11 15:29:52 UTC 2006
1) PinVcpu : I consider the size of CPU map in bytes, that is (max_nb_CPUs
+ 7) / 8 .
2) CPU map cut into standard + extension : It would be more simple to let
each Libvirt user modify the value of VIR_MAX_CPUS in private libvirt.h.
It could be similar to the version number update, from libvirt.h.in to
#define LIBVIR_VERSION_NUMBER @LIBVIRT_VERSION_NUMBER@
Veuillez répondre à veillard at redhat.com
Pour : michel.ponceau at bull.net
cc : libvir-list at redhat.com
Objet : Re: Proposal : add 3 functions to Libvirt API, for virtual CPUs
On Tue, Jul 11, 2006 at 04:14:12PM +0200, michel.ponceau at bull.net wrote:
> Corrections on proposal:
> 1) PinVcpus
> * @cpumap: pointer to a bit map of real CPUs (format in virVcpuInfo)
> * @maplen: length of cpumap, in 8-bit bytes
> * @cpumap: pointer to a bit map of real CPUs (in 8-bit bytes).
> * Each bit set to 1 means that corresponding CPU is usable.
> * Bytes are stored in little-endian order: CPU0-7, 8-15...
> * In each byte, lowest CPU number is least significant bit.
> * @maplen: number of bytes in cpumap, from 1 up to size of CPU map in
> * underlying virtualization system (Xen...).
> * If maplen < size, missing bytes are set to zero.
> * If maplen > size, failure code is returned.
Okay, that's sensible I guess except for maplen it can go from
1 to size + 7 div 8 not up to size , right ?
> 2) GetVcpu
> Add 4rth argument:
> * @maplen: number of bytes in cpumap field of virVcpuInfo
> virDomainGetVcpus(virDomainPtr domain, virVcpuInfoPtr info, int maxinfo,
> int maplen)
> 3) Structure VcpuInfo
> Suppress: #define VIR_MAX_CPUS 256
> unsigned char cpumap[VIR_MAX_CPUS/8]; /* Bit map of usable real
> unsigned char cpumap; /* Bit map of usable real CPUs.
> Variable length: it may be less or greater than size of CPU map
> underlying virtualization system (Xen...).
Hum, I could see compilers righteously complaining about
unsigned char cpumap;
in a structure. Maybe we should default to 256 / 8 but allow at the API
to grow over that value. What we could do is define a default of 256
in the structure and allow an extra parameter which could point to a
array like the following:
- restore VIR_MAX_CPUS as VIR_STD_MAX_CPUS 256
- virDomainGetVcpus(virDomainPtr domain, virVcpuInfoPtr info, int
char *lcpumap, int lmaplen);
lcpumap and lmaplen being extra arguments for very large arrays
for most use case, we will fit in 256 processors, those will be
NULL and 0, but assuming we have more than 256 processors:
+ maxinfo > VIR_STD_MAX_CPUS
+ lcpumap points to a array of bytes, they are interpreted as an
array of cpumap of ((maxinfo + 7) div 8) bytes each. So
if lmaplen != ((maxinfo + 7) div 8) * maxinfo then there is an
in that case the cpumap structures of info are not filled on return.
We still have a relatively simple API for the common case, and for
cases we have an extension capability with relatively clear definitions.
a bitstrange but I think that should cover most case as best as possible
> 4) Accessor macros: to be defined later.
Daniel Veillard | Red Hat http://redhat.com/
veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the libvir-list