[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87wny0edko.fsf@nanos.tec.linutronix.de>
Date: Wed, 02 Dec 2020 10:56:23 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Dexuan Cui <decui@...rosoft.com>, dwmw@...zon.co.uk,
x86@...nel.org, decui@...rosoft.com, mikelley@...rosoft.com,
linux-hyperv@...r.kernel.org
Cc: linux-kernel@...r.kernel.org, Tianyu.Lan@...rosoft.com,
vkuznets@...hat.com, kys@...rosoft.com, haiyangz@...rosoft.com,
sthemmin@...rosoft.com, wei.liu@...nel.org
Subject: Re: [PATCH] iommu/hyper-v: Fix panic on a host without the 15-bit APIC ID support
On Tue, Dec 01 2020 at 16:45, Dexuan Cui wrote:
> The commit f36a74b9345a itself is good, but it causes a panic in a
> Linux VM that runs on a Hyper-V host that doesn't have the 15-bit
> Extended APIC ID support:
> kernel BUG at arch/x86/kernel/apic/io_apic.c:2408!
This has nothing to do with the 15bit APIC ID support, really.
The point is that the select() function only matches when I/O APIC ID is
0, which is not guaranteed. That's independent of the 15bit extended
APIC ID feature. But the I/O-APIC ID is irrelevant on hyperv because
there is only one.
> This happens because the Hyper-V ioapic_ir_domain (which is defined in
> drivers/iommu/hyperv-iommu.c) can not be found. Fix the panic by
> properly claiming the only I/O APIC emulated by Hyper-V.
We don't fix a panic. We fix a bug in the code :)
I'll amend the changelog.
Thanks,
tglx
Powered by blists - more mailing lists