Hi, When I tested xm vcpu-pin command, I encountered the following strange problem. I encountered it on x86, but I didn''t encounter it on ia64. On x86: # xm vcpu-list Name ID VCPU CPU State Time(s) CPU Affinity Domain-0 0 0 0 -b- 31.3 any cpu Domain-0 0 1 1 r-- 30.1 any cpu # xm vcpu-pin Domain-0 0 64 # xm vcpu-list Name ID VCPU CPU State Time(s) CPU Affinity Domain-0 0 0 0 -b- 31.5 0 Domain-0 0 1 1 r-- 31.1 any cpu # xm vcpu-pin Domain-0 0 65 # xm vcpu-list Name ID VCPU CPU State Time(s) CPU Affinity Domain-0 0 0 1 -b- 32.0 1 Domain-0 0 1 0 r-- 31.6 any cpu On ia64: # xm vcpu-list Name ID VCPU CPU State Time(s) CPU Affinity Domain-0 0 0 0 r-- 13.2 any cpu Domain-0 0 1 1 -b- 10.8 any cpu # xm vcpu-pin Domain-0 0 64 Error: Cannot pin vcpu: 0 to cpu: [64] - (22, ''Invalid argument'') Usage: xm vcpu-pin <Domain> <VCPU|all> <CPUs|all> Set which CPUs a VCPU can use. # xm vcpu-list Name ID VCPU CPU State Time(s) CPU Affinity Domain-0 0 0 0 r-- 13.5 any cpu Domain-0 0 1 1 -b- 11.0 any cpu # xm vcpu-pin Domain-0 0 65 Error: Cannot pin vcpu: 0 to cpu: [65] - (22, ''Invalid argument'') Usage: xm vcpu-pin <Domain> <VCPU|all> <CPUs|all> Set which CPUs a VCPU can use. # xm vcpu-list Name ID VCPU CPU State Time(s) CPU Affinity Domain-0 0 0 0 r-- 13.7 any cpu Domain-0 0 1 1 -b- 11.3 any cpu I could not understand why the problem occurs. But I would like to solve the problem, so I send an ad hoc patch. If you can solve the problem, I hope that the problem is solved by your patch. Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com> Best regards, Kan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 19/2/08 09:45, "Masaki Kanno" <kanno.masaki@jp.fujitsu.com> wrote:> I could not understand why the problem occurs. But I would like to > solve the problem, so I send an ad hoc patch. If you can solve the > problem, I hope that the problem is solved by your patch.In C, shifting by more bits than the width of the value being shifted is undefined. This explains the difference in behaviour between ia64 and x86. Your patch seems sensible. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tue, 19 Feb 2008 09:50:33 +0000, Keir Fraser wrote:>On 19/2/08 09:45, "Masaki Kanno" <kanno.masaki@jp.fujitsu.com> wrote: > >> I could not understand why the problem occurs. But I would like to >> solve the problem, so I send an ad hoc patch. If you can solve the >> problem, I hope that the problem is solved by your patch. > >In C, shifting by more bits than the width of the value being shifted is >undefined. This explains the difference in behaviour between ia64 and x86. >Your patch seems sensible.Well, then could you apply my patch? Best regards, Kan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
It''s in the queue On 20/2/08 02:30, "Masaki Kanno" <kanno.masaki@jp.fujitsu.com> wrote:> Tue, 19 Feb 2008 09:50:33 +0000, Keir Fraser wrote: > >> On 19/2/08 09:45, "Masaki Kanno" <kanno.masaki@jp.fujitsu.com> wrote: >> >>> I could not understand why the problem occurs. But I would like to >>> solve the problem, so I send an ad hoc patch. If you can solve the >>> problem, I hope that the problem is solved by your patch. >> >> In C, shifting by more bits than the width of the value being shifted is >> undefined. This explains the difference in behaviour between ia64 and x86. >> Your patch seems sensible. > > Well, then could you apply my patch? > > Best regards, > Kan > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Seemingly Similar Threads
- [PATCH] Fix argument check of xm reboot command (3)
- [Xen-ia64-devel] [PATCH][RFC] Fix error message for xm create command
- [PATCH] Fix help messages of xm vcpu-list/uptime
- [PATCH] Fix xm vcpu-set command for when wrong number of VCPU is given
- Question about ACMError