* Carb, Brian A <Brian.Carb@xxxxxxxxxx> [2006年06月15日 10:12]:
> Thanks Ryan,
>
> We're still seeing this problem as of changeset 10333 (which I believe
> includes that patch). 
Yeah, that was a long shot.
>
> It seems as if the "vcpus" value as shown by "xm list --long 0" command
> is getting set to 8, even when we boot dom0 with 16procs. In fact, vcpus
> is still set to 8 even if we boot hyperthreaded to a 32x. Since the
> release of procs with vcpu-set seems to key off this value, we can never
> release more than 7.
the vcpus value for dom0 should be the number of vcpus the domain is
configured to use; usually in the conf file. Domain0 is different since
it has no conf file being built by xen instead of Xend. In this case,
vcpus value is derived from max_vcpu_id, which is the highest vcpu
that as been initialized. For dom0, this value should be the
number of cpus xen enabled during boot.
vcpu-set uses the vcpu_avail variable which is initialized from the
vcpus variable, which, as mentioned able is determined by max_vcpu_id.
e.g. max_vcpu_id=7, vcpus = 8, vcpu_avail = (1 << 8)-1, or 0xff
I'd start fresh by clearing out xenstore:
rm /var/lib/xenstored/tdb
And rebooting.
It should never be the case where vcpus for dom0 is < online vcpus as
that means you are running vcpus that haven't been initialized
(max_vcpu_id indicates the max vcpu that has been allocated to run in
 the domain). It would be interesting if you can track what steps you
took to get the machine/xenstore into this state and file a bug. 
-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253 T/L: 678-9253
ryanh@xxxxxxxxxx
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel