Mailing List Archive: IA32 vcpu-pin broken?

Hi,

I want dom0 and a guest to be on the same physical cpu. I have booted
dom0 with 1 cpu and also modified /etc/xen/xend-config.sxp to say
"dom0-cpus 1".

I cannot pin the dom0 cpu however, I can pin the guest cpu to be the
same as dom0 pcpu. However, the moment I start running an app in the
guest, dom0 pcpu changes to something else.

I know it used to work before. I am using the xen-unstable from Aug
29th. (there is a patch for IA64 on dom0 pinning, but nothing for IA32)

Before xm vcpu-list

Name ID VCPU CPU State
Time(s) CPU Affinity

Domain-0 0 0 1 r--
2254.4 any cpu

Domain-0 0 1 - --p
0.0 any cpu

Domain-0 0 2 - --p
0.0 any cpu

Domain-0 0 3 - --p
0.0 any cpu

Guest1 2 0 1 -b-
2244.2 2

After xm vcpu-list

Name ID VCPU CPU State
Time(s) CPU Affinity

Domain-0 0 0 3 r--
2254.4 any cpu

Domain-0 0 1 - --p
0.0 any cpu

Domain-0 0 2 - --p
0.0 any cpu

Domain-0 0 3 - --p
0.0 any cpu

Guest1 2 0 1 -b-
2244.2 2

Thanks

Padma

On Mon, Sep 18, 2006 at 09:36:57AM -0700, Apparao, Padmashree K wrote:
> I want dom0 and a guest to be on the same physical cpu. I have booted dom0
> with 1 cpu and also modified /etc/xen/xend-config.sxp to say "dom0-cpus
> 1".
>
> I cannot pin the dom0 cpu however, I can pin the guest cpu to be the same
> as dom0 pcpu. However, the moment I start running an app in the guest,
> dom0 pcpu changes to something else.
>
> I know it used to work before. I am using the xen-unstable from Aug 29^th.
> (there is a patch for IA64 on dom0 pinning, but nothing for IA32)

It looks like the code in xen/common/domctl.c for
XEN_DOMCTL_getvcpuaffinity now rejects all operations
on the current VCPU (DOM0 VCPU0 on a UP dom0). Before,
it used to leave this up to the per-scheduler implementation
of set_affinity. The credit scheduler implementation allows
a new mask which contained the current cpu in it in this case.

See snipped from xen/common/domctl.c:

[...]
if ( op->cmd == XEN_DOMCTL_setvcpuaffinity )
{
if ( v == current )
{
ret = -EINVAL;
put_domain(d);
break;
}
[...]

So assuming the right checks still exist in the per-scheduler
implementations of set_affinity, we could remove this check.

Argueably though, we should just extend the IA64 patch to x86.
It should be trivial to do so. The changeset in question is
11453:019b7c756ddb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel