Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <71578392-63ed-02a9-24da-2adf8cce38c7@huawei.com>
Date:   Mon, 3 Jul 2023 11:44:26 +0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.1.2
To:     <tglx@linutronix.de>
CC:     <arjan@linux.intel.com>, <ashok.raj@intel.com>,
        <ashok.raj@linux.intel.com>, <ebiederm@xmission.com>,
        <linux-kernel@vger.kernel.org>, <mario.limonciello@amd.com>,
        <thomas.lendacky@amd.com>, <tony.luck@intel.com>,
        <tonyb@cybernetics.com>, <x86@kernel.org>,
        yangerkun <yangerkun@huawei.com>
References: <20230615193330.608657211@linutronix.de>
Content-Language: en-US
From:   Baokun Li <libaokun1@huawei.com>
Subject: [BUG REPORT] Triggering a panic in an x86 virtual machine does not
 wait
In-Reply-To: <20230615193330.608657211@linutronix.de>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

When I manually trigger panic in a qume x86 VM with

        `echo c > /proc/sysrq-trigger`,

  I find that the VM will probably reboot directly, but the 
PANIC_TIMEOUT is 0.
This prevents us from exporting the vmcore via panic, and even if we succeed
in panic exporting the vmcore, the processes in the vmcore are mostly
stop_this_cpu(). By dichotomizing we found the patch that introduced the
behavior change

    45e34c8af58f ("x86/smp: Put CPUs into INIT on shutdown if possible"),

can anyone help to see what is happening?

Thanks!
-- 
With Best Regards,
Baokun Li
.