Re: LOCKDEBUG kernel option crashes if vcpu > 1

[Cherry G. Mathew <cherry%zyx.in@localhost>]

>>>>> "Manuel" == Manuel Bouyer <bouyer%antioche.eu.org@localhost> writes:

    Manuel> On Fri, Nov 21, 2014 at 08:59:57PM +0530, Cherry G. Mathew wrote:
    >> >>>>> "Emmanuel" == Emmanuel Dreyfus <manu%netbsd.org@localhost> writes:
    >> 
    Emmanuel> On Tue, Nov 18, 2014 at 10:30:28PM +0530, Cherry G. Mathew wrote:
    >> >> Does the following patch work for you ?
    >> 
    Emmanuel> It does.
    >> 
    >> 
    >> Cool - I'll check it in unless anyone has reasonable objections.

    Manuel> Hello, it looks like your patch cause Xen (at last i386/PAE)
    Manuel> to panic at boot:
    Manuel> http://www-soc.lip6.fr/~bouyer/NetBSD-tests/xen/HEAD/

    Manuel> reverting this commit:
    Manuel> http://mail-index.netbsd.org/source-changes/2014/11/22/msg060804.html

    Manuel> fixes the problem for me.

    Manuel> At first glance, I'd say this is because the non-boot CPUs
    Manuel> are not properly xen_kpm_sync()'ed in this case. Waiting for
    Manuel> mp_online is probably way too late to call xen_kpm_sync().

 
Hmmm, looks like you're right. I did test it on PAE before committing
though, so that seems a bit odd.

    Manuel> Sorry, but I didn't clearly understand what the problem is
    Manuel> with the initial code. It looks like it's using a cpu_info
    Manuel> before it's fully initialised (especially the lock), right ?
    Manuel> If so, what's the problem with initialising the lock before
    Manuel> it's made available to CPU_INFO_FOREACH() ?

Yes, it's a per-cpu lock, which is being used before init.

    Manuel> The attached patch reverts your change, and moves
    Manuel> pmap-related initialisations to cpu_attach_common() where
    Manuel> ci_pmap and ci_tlbstate are already set.

Looks good to me - will you commit ?

-- 
Cherry