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 libvirt.h :
#define LIBVIR_VERSION_NUMBER @LIBVIRT_VERSION_NUMBER@
Veuillez répondre à veillard@xxxxxxxxxx
Pour : michel.ponceau@xxxxxxxx
cc : libvir-list@xxxxxxxxxx
Objet : Re: Proposal : add 3 functions to Libvirt API, for virtual CPUs
On Tue, Jul 11, 2006 at 04:14:12PM +0200, michel.ponceau@xxxxxxxx wrote:
> Corrections on proposal:
> 1) PinVcpus
> Replace:
> * @cpumap: pointer to a bit map of real CPUs (format in virVcpuInfo)
> * @maplen: length of cpumap, in 8-bit bytes
> by:
> * @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
> Replace:
> unsigned char cpumap[VIR_MAX_CPUS/8]; /* Bit map of usable real CPUs.
> by:
> unsigned char cpumap[]; /* Bit map of usable real CPUs.
> Variable length: it may be less or greater than size of CPU map in
> 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 level
to grow over that value. What we could do is define a default of 256 available
in the structure and allow an extra parameter which could point to a larger
array like the following:
- restore VIR_MAX_CPUS as VIR_STD_MAX_CPUS 256
- virDomainGetVcpus(virDomainPtr domain, virVcpuInfoPtr info, int maxinfo,
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 respectively
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
error.
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 special
cases we have an extension capability with relatively clear definitions. it's
a bitstrange but I think that should cover most case as best as possible
> 4) Accessor macros: to be defined later.
okay,
Daniel
--
Daniel Veillard | Red Hat http://redhat.com/
veillard@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/