Description of problem: Upstream xend supports unpinning a vcpu with something that would be "xm vcpu-pin DOM VCPU all". It also supports passing "all" instead of the vcpu number. Our xm supports that, but it's undocumented. Xend already has everything that's needed, so this is entirely located in the xm command line. Version-Release number of selected component (if applicable): 3.0.3-105.el5 Steps to Reproduce: 1. xm vcpu-pin DOMAIN 0 0 2. xm vcpu-list 3. xm vcpu-pin DOMAIN all all 4. xm vcpu-list Actual results: Step 3 fails, step 4 shows no change. Expected results: Step 3 should pass, and the second vcpu-list should show that the effect of step 1 has been undone. Additional info: Upstream c/s 14364 and 15264.
I've changed the summary of this bug to show that this is an issue with the xm command. The libvirt supported way to "unpin" is to re-pin a vcpu to all cpus with a command like this virsh vcpupin <dom> 0,1,2,3,... On a side note an 'all' keyword would be nice in libvirt as well...
Created attachment 408273 [details] Support of 'all' keyword to unpin a vcpu using the xm command I did testing with RHEL-5 x86_64 PV guest with one VCPU set the following results: 1. xm create rhel5-64pv 2. xm vcpu-list rhel5-64pv - domain was showing affinity 'any cpu' 3. xm vcpu-pin rhel5-64pv 0 0 4. xm vcpu-list rhel5-64pv - domain was showing affinity '0' 5. xm vcpu-pin rhel5-64pv all all 6. xm vcpu-list rhel5-64pv - domain was showing affinity 'any cpu' So, since the affinity output was the same in case of step 2 (before pinning) and step 6 (after unpinning) as tested on my x86_64 dom0 it's working fine. As correctly stated, it's basically backport of upstream c/s 14364 and 15264 but most of the code from 15264 have been already in our codebase so that's reason why it was working fine with libvirt daemon. Michal
It's actually not impossible with the xm command, it's just not documented. To unpin with xm you can do "xm vcpu-pin <dom> all 0-<(nr_cpus-1)>", or even just use some large number if you don't want to check how many cpus you have, e.g. "xm vcpu-pin <dom> all 0-255". I recommend we close this as NOTABUG, and then we can consider improving the interface and documentation for libvirt's virsh under a different bug.
I changed the subject, but I still think it's worth fixing this. We can also clone it for libvirt.
(In reply to comment #4) > I changed the subject, but I still think it's worth fixing this. We can also > clone it for libvirt. Actually, since I did the backport for this one already I think it's good to have. The patch is done and also sent to the list already so I agree with Paolo since it's no big undertaking to just apply it since it's already done and tested. Basically since Xen HV support max. 64 VCPUs with this patch applied "xm vcpu-pin <dom> all all" basically does "xm vcpu-pin <dom> all all" which is no problem here since as far as I know and like already stated in this comment, Xen HV supports only 64 VCPUs. Michal
This patch addresses pcpus, not vcpus. So having 'all' hard coded to 64 is incorrect since we support up to 256 pcpus on x86_64. To illustrate, if you did "xm vcpu-pin <dom> all all" then with this patch that translates to "xm vcpu-pin <dom> all 0-63" If you system had, for example, 128 pcpus and you ran this "all all" command on your VMs under the assumption that afterwards no vcpu would be affiliated to any particular cpu, then your assumption would be wrong. You would in fact be only using the first 64 pcpus of your system for those VMs. Therefore the patch is wrong as it stands, and I've already NACKed it as such on the list.
(In reply to comment #6) > This patch addresses pcpus, not vcpus. So having 'all' hard coded to 64 is > incorrect since we support up to 256 pcpus on x86_64. To illustrate, if you > did > > "xm vcpu-pin <dom> all all" > > then with this patch that translates to > > "xm vcpu-pin <dom> all 0-63" > > If you system had, for example, 128 pcpus and you ran this "all all" command on > your VMs under the assumption that afterwards no vcpu would be affiliated to > any particular cpu, then your assumption would be wrong. You would in fact be > only using the first 64 pcpus of your system for those VMs. Therefore the > patch is wrong as it stands, and I've already NACKed it as such on the list. Right, ok. In fact it was a feature request but since we support up to 256 PCPUs for x86_64 (as I was thinking we do just 64 PCPUs). Closing as NOTABUG. Michal