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@redhat.com Pour : michel.ponceau@bull.net cc : libvir-list@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@bull.net 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@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/