Bug 504914 - Command "virsh schedinfo" can not deal with the boundary cap value correctly
Command "virsh schedinfo" can not deal with the boundary cap value correctly
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: libvirt (Show other bugs)
All Linux
medium Severity medium
: rc
: ---
Assigned To: Daniel Veillard
Virtualization Bugs
Depends On:
  Show dependency treegraph
Reported: 2009-06-09 22:26 EDT by Edward Wang
Modified: 2010-03-30 04:09 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-03-30 04:09:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
patch for the problems (1.42 KB, patch)
2009-11-17 10:21 EST, Daniel Veillard
no flags Details | Diff
detail information (12.81 KB, text/plain)
2009-12-28 22:52 EST, Alex Jia
no flags Details

  None (edit)
Description Edward Wang 2009-06-09 22:26:39 EDT
Description of problem:
The command "virsh schedinfo <domain>..." can not deal with the boundary "cap" value correctly.

Version-Release number of selected component (if applicable):
- libvirt: 0.6.3-6.el5

How reproducible:
100%, always.

Steps to Reproduce:
1, virsh define rhel5u3.xml 
2, virsh start rhel5u3
3, virsh schedinfo rhel5u3 --cap 65534
   ---> succeed as below:
   Scheduler : credit
   weight : 1
   cap : 65534
4, virsh schedinfo rhel5u3 --cap 65535
   ---> fail as below (still 65534):
   Scheduler : credit
   weight : 1
   cap : 65534
5, virsh schedinfo rhel5u3 --cap 65536
   ---> succeed since reaching the boundary value
   error: this function is not supported by the hypervisor: unsupported in xendConfigVersion
Actual results:
In step 4, when setting the cap to 65535, no error information (just like step 5 above) printed out, but the value "cap" is not changed.

Expected results:
It seems that the boundary value is 65536 from step 5, so step 4 should change the "cap" value successfully.

Additional info:
Comment 2 Daniel Veillard 2009-11-17 09:43:35 EST
Seems like a bug in the Xen hypervisor or 65535 is assumed to be a
no-op in the system call:

when tracing in xenHypervisorSetSchedulerParameters()

1271	        switch (op_sys.u.getschedulerid.sched_id){
1277	            int weight_set = 0;
1278	            int cap_set = 0;
1280	            memset(&op_dom, 0, sizeof(op_dom));
1281	            op_dom.cmd = XEN_V2_OP_SCHEDULER;
1282	            op_dom.domain = (domid_t) domain->id;
1283	            op_dom.u.getschedinfo.sched_id = XEN_SCHEDULER_CREDIT;
1284	            op_dom.u.getschedinfo.cmd = XEN_DOMCTL_SCHEDOP_putinfo;
1290	            op_dom.u.getschedinfo.u.credit.weight = 0;
1291	            op_dom.u.getschedinfo.u.credit.cap    = (uint16_t)~0U;
1293	            for (i = 0; i < nparams; i++) {
1294	                memset(&buf, 0, sizeof(buf));
1295	                if (STREQ (params[i].field, str_weight) &&
(gdb) p params[0]
$4 = {field = "cap\000:\000\000\0008*un:", '\0' <repeats 66 times>, type = 2, 
  value = {i = 65535, ui = 65535, l = 65535, ul = 65535, 
    d = 3.2378592100206092e-319, b = -1 '�'}}
(gdb) n
1305	                } else if (STREQ (params[i].field, str_cap) &&
1307	                    val = params[i].value.ui;
(gdb) p params[i].value.ui
$6 = 65535
(gdb) n
1308	                    if (val > USHRT_MAX) {
(gdb) p val
$7 = 65535

   Somehow the stest sounds right as 

/usr/include/limits.h:#  define USHRT_MAX	65535

1293	            for (i = 0; i < nparams; i++) {
1323	            ret = xenHypervisorDoV2Dom(priv->handle, &op_dom);
(gdb) p op_dom.u.getschedinfo.u.credit
$9 = {weight = 0, cap = 65535}
(gdb) n
1324	            if (ret < 0)
(gdb) p ret
$10 = 0
(gdb) n
1335	    return 0;
1336	}
xenUnifiedDomainSetSchedulerParameters (dom=0x122526c0, params=0x12255770, 
    nparams=1) at xen_unified.c:1280
1280	           if (ret == 0)
(gdb) c
Scheduler      : credit
weight         : 256
cap            : 65533

  So the hypervisor doesn't raise this as an out of bound error
but the value is just ignored. I guess the best is to cope locally with that
value I think by just allowing 0-65534 instead of 0-65535

  IMHO this is not a big deal, the fact that the correct erro message
ain't displayed for out of bound values is more annoying, it's overriden
by the xend driver. The best is to reverse the order of the drivers for
the scheduler setting call, as this isn't performance critical

Comment 3 Daniel Veillard 2009-11-17 10:21:13 EST
Created attachment 369899 [details]
patch for the problems
Comment 4 Daniel Veillard 2009-11-17 10:24:07 EST
The patch was also sent upstream


Comment 5 Daniel Veillard 2009-11-25 11:08:13 EST
libvirt-0.6.3-22.el5 has been built in dist-5E-qu-candidate with
the fixes,

Comment 7 Alex Jia 2009-12-28 22:50:35 EST
For the xen and kvm hypervisor,this operation will raise different result:
1.XEN hypervisor
cap can reach boundary value 65534 on xenpv and xenfv guest,but it exists extra
three problems:
a). when cap is an out of bound value such as cap=65535,duplicate error will be raised,and one is from xen,another is from libvirt,I think that xen's error should be catch by libvirt.then only raise a libvirt error.
b). sometimes weight can't reach boundary value 65535
this will raise a error "libvir: Xen error : failed Xen syscall  ioctl 3166208"
I will file a new bug.

c). a annoying error message is often raised, although change cap value successfully:
"libvir: Xen Daemon error : this function is not supported by the hypervisor: unsupported in xendConfigVersion < 4"

2.KVM hypervisor
this function is not supported by the kvm hypervisor.this will raise a error
"libvir: error : this function is not supported by the hypervisor: virDomainGetSchedulerType", I am not sure whether the error message is a correct

in addition:
a warning message is often raised on xen host(kvm not yet), if you import libvirt module or do some 'virsh' operation,may be I still need to file a new bug or the message is a correct behavior(my machine isn't a numa system):
"libnuma: Warning: /sys not mounted or no numa system. Assuming one node: No such file or directory"

Steps to Reproduce & component information:
see attachment.
Comment 8 Alex Jia 2009-12-28 22:52:01 EST
Created attachment 380727 [details]
detail information

detail information
Comment 9 Daniel Veillard 2010-01-04 04:11:23 EST
The credit scheduler is available only ion Xen, so this is to be tested only
in Xen.
The addition is not related to this bug, that's a warning only, it's separate
and I don't think it need "fixing" for 5.5 honnestly.

for points a) and c) while not ideal, I don't think it is worth spending more
time on this corner case this is specific to RHEL-5 Xen version

For b) that mean the hypercall failed, that should be completely reproductible
on a given machine, either the hypercall is supported or not, if it's variable
on a given it's a Xen bug.

Comment 10 Daniel Veillard 2010-01-04 09:57:30 EST
The warning is a bug in numactl:


Comment 11 Alex Jia 2010-01-05 21:41:00 EST
Hi,Daniel,you are right.some problems isn't related to this bug,the bug focus on cap whether can reach boundary value correctly.I retest it with libvirt-0.6.3-28.el5 on RHEL-5.5,This bug has been fixed,set bug status to VERIFIED.

Steps to Reproduce:

[root@dhcp-66-70-62 ~]# virsh schedinfo rhel5u5_x86_64_xenpv --cap -1
error: invalid argument in xenHypervisorSetSchedulerParameters: Credit scheduler cap parameter (-1) is out of range (0-65534)

[root@dhcp-66-70-62 ~]# virsh schedinfo rhel5u5_x86_64_xenpv --cap 65535
error: invalid argument in xenHypervisorSetSchedulerParameters: Credit scheduler cap parameter (65535) is out of range (0-65534)

[root@dhcp-66-70-62 ~]# virsh schedinfo rhel5u5_x86_64_xenpv --cap 0
Scheduler      : credit
weight         : 256
cap            : 0

[root@dhcp-66-70-62 ~]# virsh schedinfo rhel5u5_x86_64_xenpv --cap 65534
Scheduler      : credit
weight         : 256
cap            : 65534

Version-Release number of selected component (if applicable):

[root@dhcp-66-70-62 ~]# uname -a
Linux dhcp-66-70-62.nay.redhat.com 2.6.18-183.el5xen #1 SMP Mon Dec 21 18:46:14 EST 2009 x86_64 x86_64 x86_64 GNU/Linux
[root@dhcp-66-70-62 ~]# rpm -qa|grep libvirt
[root@dhcp-66-70-62 ~]# rpm -qa|grep xen

BTW,weight boundary value seems to exist problem.I am tracing the problem.
Comment 14 Daniel Veillard 2010-01-12 03:22:19 EST
Atsushi SAKAI <sakaia@jp.fujitsu.com> told me that the bug at the xen
level is:

> The problematic code is follows.
> Problem code (still continues on latet upstream Xen).
> http://xenbits.xen.org/xen-3.4-testing.hg?file/a7b2d4e03a1f/xen/common/sched_credit.c
> 678        if ( op->u.credit.cap != (uint16_t)~0U )
> 679            sdom->cap = op->u.credit.cap;

Comment 15 Johnny Liu 2010-02-01 02:54:11 EST
This bug is verified PASS with libvirt-0.6.3-31.el5 on
RHEL-5.5-Server-x86_64-xen with xenpv guest
Comment 18 errata-xmlrpc 2010-03-30 04:09:39 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.