Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Thomas Gleixner <tglx@linutronix.de>
To:     Dexuan Cui <decui@microsoft.com>, dwmw@amazon.co.uk,
        x86@kernel.org, decui@microsoft.com, mikelley@microsoft.com,
        linux-hyperv@vger.kernel.org
Cc:     linux-kernel@vger.kernel.org, Tianyu.Lan@microsoft.com,
        vkuznets@redhat.com, kys@microsoft.com, haiyangz@microsoft.com,
        sthemmin@microsoft.com, wei.liu@kernel.org
Subject: Re: [PATCH] iommu/hyper-v: Fix panic on a host without the 15-bit APIC ID support
In-Reply-To: <20201202004510.1818-1-decui@microsoft.com>
References: <20201202004510.1818-1-decui@microsoft.com>
Date:   Wed, 02 Dec 2020 10:56:23 +0100
Message-ID: <87wny0edko.fsf@nanos.tec.linutronix.de>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

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