[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v4 2/2] xen: delay xen_hvm_init_time_ops() if kdump is boot on vcpu>=32
- To: Dongli Zhang <dongli.zhang@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx, x86@xxxxxxxxxx
- From: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
- Date: Fri, 11 Mar 2022 09:19:46 -0500
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=AzwRPKJCYGsACE2zdpPOVzAzmw0WG+/nFrwAUQxVVdM=; b=WdKM/WTJqUgoI2Uhefg3yNtdZxnMgW/17SsOFvdPhJzFAh7fqEYp1hUUa+5VxbkBBmOOAL/mWcpEHBCOocgA5EXXia11P04cigjc8TsKTi3MxYIvrtH+VYtqDRpiOW5wcg9mSq1Bn6Wo8FNOHzgTlX6EziqZkvoXlyuXP1QiJCo3D9KcVcF212OU7yV6XMiNM+J5ayTwrE4pYSzFQ0s6O+Cyf4hwqMPAmE2/G953JaLgY+4dLhlE6LfQhfXVuAsv/rqCMuH9mL4ETqAsb9EcrScn504fgx8wdUnkqW/myM7pdD0bYlE9gr4PHPkfG7WtLijL4SkPJ9sXVZWE28cGDQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZuiljGe1Bzf1BoPM4f0NM4YEZDagoBkrKgf2wKIZGfcZZ/79yuL7rh6GMyVU8PVlNGlf90pWZvNn8VVXHwaFGXGjmZG+akCATQrkhY6wYLTSvW5KkeWTtzNJ9Cgy/mocw9qOFqIy4va0fCodYDDVD+Cu2R2FTrRA/UUmJ1/Bq8/sPhkXab2KjSlxb2iI5Pb/4DIwgIDdEg9Mnmyr+4oKxoTtQwPemiiNnFZKdBpRAaMbGHApOzPaEWd+/sAfgaCHPF1L5Y/vgJfdmgpixNk3y4ZQOPjV5SJyByxhRnTKoRG7ssiGhhsqfcwmPbVE6nrFkji7Y4y0tYd/wNxi1kDY+Q==
- Cc: linux-kernel@xxxxxxxxxxxxxxx, jgross@xxxxxxxx, sstabellini@xxxxxxxxxx, tglx@xxxxxxxxxxxxx, mingo@xxxxxxxxxx, bp@xxxxxxxxx, dave.hansen@xxxxxxxxxxxxxxx, joe.jin@xxxxxxxxxx
- Delivery-date: Fri, 11 Mar 2022 14:20:32 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 3/2/22 11:40 AM, Dongli Zhang wrote:
The sched_clock() can be used very early since commit 857baa87b642
("sched/clock: Enable sched clock early"). In addition, with commit
38669ba205d1 ("x86/xen/time: Output xen sched_clock time from 0"), kdump
kernel in Xen HVM guest may panic at very early stage when accessing
&__this_cpu_read(xen_vcpu)->time as in below:
setup_arch()
-> init_hypervisor_platform()
-> x86_init.hyper.init_platform = xen_hvm_guest_init()
-> xen_hvm_init_time_ops()
-> xen_clocksource_read()
-> src = &__this_cpu_read(xen_vcpu)->time;
This is because Xen HVM supports at most MAX_VIRT_CPUS=32 'vcpu_info'
embedded inside 'shared_info' during early stage until xen_vcpu_setup() is
used to allocate/relocate 'vcpu_info' for boot cpu at arbitrary address.
However, when Xen HVM guest panic on vcpu >= 32, since
xen_vcpu_info_reset(0) would set per_cpu(xen_vcpu, cpu) = NULL when
vcpu >= 32, xen_clocksource_read() on vcpu >= 32 would panic.
This patch calls xen_hvm_init_time_ops() again later in
xen_hvm_smp_prepare_boot_cpu() after the 'vcpu_info' for boot vcpu is
registered when the boot vcpu is >= 32.
This issue can be reproduced on purpose via below command at the guest
side when kdump/kexec is enabled:
"taskset -c 33 echo c > /proc/sysrq-trigger"
The bugfix for PVM is not implemented due to the lack of testing
environment.
Cc: Joe Jin <joe.jin@xxxxxxxxxx>
Signed-off-by: Dongli Zhang <dongli.zhang@xxxxxxxxxx>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
Applied to for-linus-5.18 (with return path adjusted)
|
