[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] RE: [Xen-users] Xen in a 32 way system



Isn't it a bug that we don't check for -EINVAL in the line here:
        for (i = 0; i < NR_CPUS; i++) {
                rc = HYPERVISOR_vcpu_op(VCPUOP_is_up, i, NULL);
                if (rc == -ENOENT)
                        break;
                cpu_set(i, cpu_possible_map);
        }

If NR_CPUS in Linux is bigger than 32, then rc = -EINVAL, not -ENOENT
when it returns from the vcpu_op, because the first check is to see if
vcpuid is >=32...

Checking if (rc < 0) would be better, I should think... 
                 

--
Mats 

> -----Original Message-----
> From: Pablo Montesinos [mailto:pablomontesinos@xxxxxxxxx] 
> Sent: 01 June 2006 18:30
> To: Keir Fraser
> Cc: Petersson, Mats; Uros Trebec; 
> xen-devel@xxxxxxxxxxxxxxxxxxx; Puthiyaparambil, Aravindh; 
> Ryan Harper; xen-users@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] RE: [Xen-users] Xen in a 32 way system
> 
> The reason why I wanted to use a 2.6.16 kernel is the 
> following. When I installed this morning the "vanilla 
> unstable" version I downloaded, it created only one kernel, 
> 2.6.16.13-xen. I booted the system with it, and it didn't 
> work well because of some network card, but RHEL acutally 
> booted. I didnt check the output while it booted, but I 
> assumed that it was using all the cpus. So I reconfigured the 
> kernel with my kernel config, and I got the crash.
> 
> I am inserting some extra code in XEN to check how many cpus 
> it is seeing. But this is the first time I look into XEN's 
> code, so I am going very slow.
> 
> Thanks,
> Pablo
> 
> On 6/1/06, Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> wrote:
> >
> > On 1 Jun 2006, at 18:00, Petersson, Mats wrote:
> >
> > > The line you have the BUG in is a VCPUOP_initialize, 
> which ends up 
> > > in
> > > .../xen/common/domain.c: do_vcpu_op(), where it does 
> essentially the 
> > > first thing is a check:
> > >       if ((vcpuid < 0) || (vcpuid >= MAX_VIRT_CPUS))
> > >               return -EINVAL;
> > >
> > > And I think this check will fail if vcpuid is 32, unless 
> > > MAX_VIRT_CPUS is not the standard value in . RSI is 32 (0x20)
> >
> > Our smpboot.c in Linux should only try to initialise 
> context for cpus 
> > in cpu_possible_map. And that map is initialised by 
> querying Xen about 
> > the state of each VCPU. So it's unclear how you can end up getting 
> > this crash. Looks like it needs some more tracing added...
> >
> >   -- Keir
> >
> >
> 
> 


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.