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

31 Jul 2006

      I hope I will find a way to post the patches prepared by Michel Ponceau 
before the end of the week.
Jean-Paul

"Daniel P. Berrange" <berrange@redhat.com>
Envoyé par : libvir-list-bounces@redhat.com
29/07/2006 09:35
Veuillez répondre à "Daniel P. Berrange"

        Pour :  Jim Fehlig <jfehlig@novell.com>
        cc :    libvir-list@redhat.com
        Objet : Re: [Libvir] Re: Proposal : add 3 functions to Libvirt API,     for 
virtual CPUs

On Fri, Jul 28, 2006 at 03:18:17PM -0600, Jim Fehlig wrote:
...
Has any progress been made on this proposal?  I don't see anything in 
current CVS.  This functionality would be useful for Xen-CIM project.
...
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.
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@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 Fri, Jun 30, 2006 at 04:00:45PM +0200, michel.ponceau@bull.net 
wrote:
...
For our administration, we need the following actions, while 
concerned
domain is running:
1) Change the number of virtual CPUs.
2) Change the pinning (affinity) of a virtual CPU on real CPUs.
3) Get detailed information for each virtual CPU.
Currently there is no Libvirt function provided for that. We suggest 
to
add the following 3 functions (in libvirt.c):
/**
 * virDomainSetVcpus:
 * @domain: pointer to domain object, or NULL for Domain0
 * @nvcpus: the new number of virtual CPUs for this domain
 *
 * Dynamically change the number of virtual CPUs used by the domain.
 * Note that this call may fail if the underlying virtualization
hypervisor
 * does not support it or if growing the number is arbitrary limited.
 * This function requires priviledged access to the hypervisor.
 *
 * Returns 0 in case of success, -1 in case of failure.
 */
int virDomainSetVcpus(virDomainPtr domain, unsigned int nvcpus)
okay
...
/**
 * virDomainPinVcpu:
 * @domain: pointer to domain object, or NULL for Domain0
 * @vcpu: virtual CPU number
 * @cpumap: pointer to a bit map of real CPUs (format in virVcpuInfo)
 * @maplen: length of cpumap, in 8-bit bytes
 *
 * Dynamically change the real CPUs which can be allocated to a 
virtual
CPU.
 * This function requires priviledged access to the hypervisor.
 *
 * Returns 0 in case of success, -1 in case of failure.
 */
int virDomainPinVcpu(virDomainPtr domain, unsigned int vcpu,
                 unsigned char *cpumap, int maplen)
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 ?
...
/**
 * virDomainGetVcpus:
 * @domain: pointer to domain object, or NULL for Domain0
 * @info: pointer to an array of virVcpuInfo structures
 * @maxinfo: number of structures in info array
 *
 * Extract information about virtual CPUs of a domain, store it in 
info
array.
 *
 * Returns the number of info filled in case of success, -1 in case 
of
failure.
 */
int virDomainGetVcpus(virDomainPtr domain, virVcpuInfoPtr info, int
maxinfo)
Hum ... now the problem with that API entry point is that we 'burn'
...
...
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
IIRC Michel Ponceau might have started on some prototype code, but he
didn't post it to the list yet & is apparently on vacation for another
couple of weeks (according to his email auto-responder). If no one else
has started work on it in the meantime, I'm planning to get working on
it when I return from vacation Aug 4th since I also need it for the
virt-manager application.

Regards,
Dan.

the
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
...
with the following structure (in libvirt.h):
/**
 * virVcpuInfo: structure for information about a virtual CPU in a 
domain.
 */
#define VIR_MAX_CPUS            256
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.
...
typedef enum {
    VIR_VCPU_OFFLINE    = 0,    /* the virtual CPU is offline */
    VIR_VCPU_RUNNING    = 1,    /* the virtual CPU is running */
    VIR_VCPU_BLOCKED    = 2,    /* the virtual CPU is blocked on 
resource
*/
} virVcpuState;
typedef struct _virVcpuInfo virVcpuInfo;
struct _virVcpuInfo {
    unsigned int number;        /* virtual CPU number */
    int state;                  /* value from virVcpuState */
    unsigned long long cpuTime; /* CPU time used, in nanoseconds */
    int cpu;                    /* real CPU number, or -1 if offline 
*/
    unsigned char cpumap[VIR_MAX_CPUS/8]; /* Bit map of usable real 
CPUs.
                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
*/
};
typedef virVcpuInfo *virVcpuInfoPtr;
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.
...
I have successfully tried those functions via Xen hypervisor, except 
for
the first (SetVcpus) where hypervisor operation DOM0_MAX_VCPUS fails
(maybe it is not possible on a running domain ?). That function was
successful via Xen daemon.
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@redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
------------------------------------------------------------------------
...
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 
-=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 
-=| 

--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

jean-paul.pigache＠bull.net

tags

participants (1)