[Libvir] Re: Proposal : add 3 functions to Libvirt API, for virtual CPUs

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. 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...). 4) Accessor macros: to be defined later. Veuillez répondre à veillard(a)redhat.com Pour : michel.ponceau(a)bull.net cc : libvir-list(a)redhat.com Objet : Re: Proposal : add 3 functions to Libvirt API, for virtual CPUs On Fri, Jun 30, 2006 at 04:00:45PM +0200, michel.ponceau(a)bull.net wrote: okay Can you explain more clearly what is the format of cpumap ? An example would be welcome, and that would be needed for the doc and maybe testing. What would happen if maplen is < or > than the number of CPU divided by 8 ? Hum ... now the problem with that API entry point is that we 'burn' the maximum 256 processors in the ABI, i.e. if we ever need to go past 256 client and servers need to be recompiled. Maybe this is not a real problem in practice but that's annoying. Is there existing APIs doing this kind of things (in POSIX for example), and what hard limit did they use ? Maybe int virDomainGetVcpusNr(virDomainPtr domain, int nr, virVcpuInfoPtr info, int maxCPU); Where the maxCPU is defined by the client as the number of real CPU it defined in its virVcpuInfoPtr and then an iteration over the virtual CPU defined in the domain is possible too. Of course if the domain uses many virtual CPUs this would become expensive but somehow I don't see that being the common use, I would rather guess the domains created use a few CPUs even if instantiated on a very large machine. This domain. Hum, there is already NUMA machines with more than 256 processors, it's annoying to define an API limit when you know it is already breakable. resource CPUs. usable. Hum, maybe some accessors should be provided in the API, letting the client code handle access and having to take care of indianness issues doesn't feel very nice. Something like the FD_CLR/FD_ISSET/FD_SET/FD_ZERO equivalents when using the select() POSIx call. Maybe that operation requires more than one hypervisor call to actually enable the processors. The simpler would be to look at the code in xend about what's needed there, maybe the kernel need to be made aware of that and I would expect this to be a xenstore operation. At least we know we can fallback to xend if the hypervisor call doesn't work directly. I don't know if virDomainGetVcpus should really be mutated into virDomainGetVcpusNr, I would certainly like to be able to keep that API extensible for more than 256 CPUs. Maybe I'm just too cautious there, I would really like feedback from others on this issue ! In the meantime sending the current set of patches you developped could allow to look closely at the 2 calls that I feel okay with. thanks and sorry it took so long ! Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/