From nobody Fri Apr 10 21:55:15 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7930CC32772 for ; Thu, 18 Aug 2022 14:25:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245287AbiHROZ2 (ORCPT ); Thu, 18 Aug 2022 10:25:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49252 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S245470AbiHROZS (ORCPT ); Thu, 18 Aug 2022 10:25:18 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E5D43AB199 for ; Thu, 18 Aug 2022 07:25:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1660832717; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=fC9YoAlYaRoz9rMPLE4asKIxjUKxEIVxQJ6T79z28gE=; b=iITi0cbIeU/ujdrEfv0S83il+OW4Q/IZPQOTHLlwUuGjg719oKmgwRQr+jKRJN2cVSjW5G b3nuPMliCYiuwgg99h2AOQo7oUyXpYDckKGG6EMir1gegU1AW58XLU1nw/luwW1F7zG0qS EZW7tx8xm0XWxBG6igraEfGpSRrottI= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-314-OWqI_6zNN1yrtVMK_mhfMQ-1; Thu, 18 Aug 2022 10:25:13 -0400 X-MC-Unique: OWqI_6zNN1yrtVMK_mhfMQ-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 47E79811E80; Thu, 18 Aug 2022 14:25:13 +0000 (UTC) Received: from fedora.redhat.com (unknown [10.40.194.62]) by smtp.corp.redhat.com (Postfix) with ESMTP id 52F1DC15BBA; Thu, 18 Aug 2022 14:25:11 +0000 (UTC) From: Vitaly Kuznetsov To: linux-hyperv@vger.kernel.org Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Wei Liu , Deepak Rawat , "K. Y. Srinivasan" , Haiyang Zhang , Stephen Hemminger , Dexuan Cui , Michael Kelley Subject: [PATCH v1 1/4] Drivers: hv: Move legacy Hyper-V PCI video device's ids to linux/hyperv.h Date: Thu, 18 Aug 2022 16:25:05 +0200 Message-Id: <20220818142508.402273-2-vkuznets@redhat.com> In-Reply-To: <20220818142508.402273-1-vkuznets@redhat.com> References: <20220818142508.402273-1-vkuznets@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.85 on 10.11.54.8 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" There are already two places in kernel with PCI_VENDOR_ID_MICROSOFT/ PCI_DEVICE_ID_HYPERV_VIDEO and there's a need to use these from core Vmbus code. Move the defines to a common header. No functional change. Signed-off-by: Vitaly Kuznetsov --- drivers/gpu/drm/hyperv/hyperv_drm_drv.c | 3 --- drivers/video/fbdev/hyperv_fb.c | 4 ---- include/linux/hyperv.h | 4 ++++ 3 files changed, 4 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c b/drivers/gpu/drm/hype= rv/hyperv_drm_drv.c index 4a8941fa0815..46f6c454b820 100644 --- a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c +++ b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c @@ -23,9 +23,6 @@ #define DRIVER_MAJOR 1 #define DRIVER_MINOR 0 =20 -#define PCI_VENDOR_ID_MICROSOFT 0x1414 -#define PCI_DEVICE_ID_HYPERV_VIDEO 0x5353 - DEFINE_DRM_GEM_FOPS(hv_fops); =20 static struct drm_driver hyperv_driver =3D { diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_f= b.c index 886c564787f1..b58b445bb529 100644 --- a/drivers/video/fbdev/hyperv_fb.c +++ b/drivers/video/fbdev/hyperv_fb.c @@ -74,10 +74,6 @@ #define SYNTHVID_DEPTH_WIN8 32 #define SYNTHVID_FB_SIZE_WIN8 (8 * 1024 * 1024) =20 -#define PCI_VENDOR_ID_MICROSOFT 0x1414 -#define PCI_DEVICE_ID_HYPERV_VIDEO 0x5353 - - enum pipe_msg_type { PIPE_MSG_INVALID, PIPE_MSG_DATA, diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h index 3b42264333ef..4bb39a8f1af7 100644 --- a/include/linux/hyperv.h +++ b/include/linux/hyperv.h @@ -1516,6 +1516,10 @@ void vmbus_free_mmio(resource_size_t start, resource= _size_t size); .guid =3D GUID_INIT(0xc376c1c3, 0xd276, 0x48d2, 0x90, 0xa9, \ 0xc0, 0x47, 0x48, 0x07, 0x2c, 0x60) =20 +/* Legacy Hyper-V PCI video device */ +#define PCI_VENDOR_ID_MICROSOFT 0x1414 +#define PCI_DEVICE_ID_HYPERV_VIDEO 0x5353 + /* * Common header for Hyper-V ICs */ --=20 2.37.1 From nobody Fri Apr 10 21:55:15 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 357CCC00140 for ; Thu, 18 Aug 2022 14:25:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343532AbiHROZd (ORCPT ); Thu, 18 Aug 2022 10:25:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49286 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343525AbiHROZX (ORCPT ); Thu, 18 Aug 2022 10:25:23 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6C7C1B2DB4 for ; Thu, 18 Aug 2022 07:25:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1660832721; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LLHkOHpskLBhdOQCELAfMzjLuxK41Cq788s3q0r056g=; b=IFdXA8P64B4XizHQL+lyGHd0xDZ3sAnoJbBQo4kwMsq6LZz8RKWztC9adsec5IosVja4b3 IBpUjC8R6owfYf9NXFeVVRSa2Z/bq3HmhnjQTn3ONjfFoX9SVHmthDB7znsEC3DvybioRp r89QHxQ0AwArUgC3UyIyfjb79CIw4jA= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-125-fQYrB49ePfeQ3WwQzOBzXQ-1; Thu, 18 Aug 2022 10:25:16 -0400 X-MC-Unique: fQYrB49ePfeQ3WwQzOBzXQ-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 8B78B811E76; Thu, 18 Aug 2022 14:25:15 +0000 (UTC) Received: from fedora.redhat.com (unknown [10.40.194.62]) by smtp.corp.redhat.com (Postfix) with ESMTP id 85E16C15BB8; Thu, 18 Aug 2022 14:25:13 +0000 (UTC) From: Vitaly Kuznetsov To: linux-hyperv@vger.kernel.org Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Wei Liu , Deepak Rawat , "K. Y. Srinivasan" , Haiyang Zhang , Stephen Hemminger , Dexuan Cui , Michael Kelley Subject: [PATCH v1 2/4] drm/hyperv: Don't forget to put PCI device when removing conflicting FB fails Date: Thu, 18 Aug 2022 16:25:06 +0200 Message-Id: <20220818142508.402273-3-vkuznets@redhat.com> In-Reply-To: <20220818142508.402273-1-vkuznets@redhat.com> References: <20220818142508.402273-1-vkuznets@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.85 on 10.11.54.8 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" When drm_aperture_remove_conflicting_pci_framebuffers() fails, 'pdev' needs to be released with pci_dev_put(). Fixes: 76c56a5affeb ("drm/hyperv: Add DRM driver for hyperv synthetic video= device") Signed-off-by: Vitaly Kuznetsov --- drivers/gpu/drm/hyperv/hyperv_drm_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c b/drivers/gpu/drm/hype= rv/hyperv_drm_drv.c index 46f6c454b820..ca4e517b95ca 100644 --- a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c +++ b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c @@ -82,7 +82,7 @@ static int hyperv_setup_gen1(struct hyperv_drm_device *hv) ret =3D drm_aperture_remove_conflicting_pci_framebuffers(pdev, &hyperv_dr= iver); if (ret) { drm_err(dev, "Not able to remove boot fb\n"); - return ret; + goto error; } =20 if (pci_request_region(pdev, 0, DRIVER_NAME) !=3D 0) --=20 2.37.1 From nobody Fri Apr 10 21:55:15 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 52C8AC00140 for ; Thu, 18 Aug 2022 14:25:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343529AbiHROZb (ORCPT ); Thu, 18 Aug 2022 10:25:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49272 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343514AbiHROZV (ORCPT ); Thu, 18 Aug 2022 10:25:21 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 905ABB2DB5 for ; Thu, 18 Aug 2022 07:25:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1660832719; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jIDqzcZGlp+4QMAFK7ua+1esufE/cwW7LaxUX2qJezI=; b=HF2sHS2QB7trB1W9DP4fZoIPU49d3Mhj/F+O+O6lkr2k9lWJ1Eq6mC/+47scqFBaWR20Q2 kKBk0arMdJs79RrmR+fjv+v341agEQW7OngyeLDRs1ejlglIYGaDjC2XnPelyej02zRQoN +KTUIaO5uwVP1EWaHRAM41LFRgEl1og= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-448-Vd7tPDnuO9-Q7pC41Cs1Pg-1; Thu, 18 Aug 2022 10:25:18 -0400 X-MC-Unique: Vd7tPDnuO9-Q7pC41Cs1Pg-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id C7DD51C05132; Thu, 18 Aug 2022 14:25:17 +0000 (UTC) Received: from fedora.redhat.com (unknown [10.40.194.62]) by smtp.corp.redhat.com (Postfix) with ESMTP id D99D5C15BB8; Thu, 18 Aug 2022 14:25:15 +0000 (UTC) From: Vitaly Kuznetsov To: linux-hyperv@vger.kernel.org Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Wei Liu , Deepak Rawat , "K. Y. Srinivasan" , Haiyang Zhang , Stephen Hemminger , Dexuan Cui , Michael Kelley Subject: [PATCH v1 3/4] Drivers: hv: Always reserve framebuffer region for Gen1 VMs Date: Thu, 18 Aug 2022 16:25:07 +0200 Message-Id: <20220818142508.402273-4-vkuznets@redhat.com> In-Reply-To: <20220818142508.402273-1-vkuznets@redhat.com> References: <20220818142508.402273-1-vkuznets@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.85 on 10.11.54.8 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" vmbus_reserve_fb() tries reserving framebuffer region iff screen_info.lfb_base is set. Gen2 VMs seem to have it set by EFI fb but on Gen1 VM it is observed to be zero. In fact, we do not need to rely on some other video driver setting it correctly as Gen1 VMs have a dedicated PCI device to look at. Both Hyper-V DRM and Hyper-V FB drivers get framebuffer base from this PCI device already so Vmbus driver can do the same trick. Check for legacy PCI video device presence and reserve the whole region for framebuffer. Signed-off-by: Vitaly Kuznetsov --- drivers/hv/vmbus_drv.c | 47 +++++++++++++++++++++++++++++------------- 1 file changed, 33 insertions(+), 14 deletions(-) diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c index 547ae334e5cd..6edaeefa2c3c 100644 --- a/drivers/hv/vmbus_drv.c +++ b/drivers/hv/vmbus_drv.c @@ -35,6 +35,7 @@ #include #include #include +#include #include #include "hyperv_vmbus.h" =20 @@ -2258,26 +2259,44 @@ static int vmbus_acpi_remove(struct acpi_device *de= vice) =20 static void vmbus_reserve_fb(void) { - int size; + resource_size_t start =3D 0, size; + struct pci_dev *pdev; + + if (efi_enabled(EFI_BOOT)) { + /* Gen2 VM: get FB base from EFI framebuffer */ + start =3D screen_info.lfb_base; + size =3D max_t(__u32, screen_info.lfb_size, 0x800000); + } else { + /* Gen1 VM: get FB base from PCI */ + pdev =3D pci_get_device(PCI_VENDOR_ID_MICROSOFT, + PCI_DEVICE_ID_HYPERV_VIDEO, NULL); + if (!pdev) + return; + + if (!(pdev->resource[0].flags & IORESOURCE_MEM)) + return; + + start =3D pci_resource_start(pdev, 0); + size =3D pci_resource_len(pdev, 0); + + /* + * Release the PCI device so hyperv_drm or hyperv_fb driver can + * grab it later. + */ + pci_dev_put(pdev); + } + + if (!start) + return; + /* * Make a claim for the frame buffer in the resource tree under the * first node, which will be the one below 4GB. The length seems to * be underreported, particularly in a Generation 1 VM. So start out * reserving a larger area and make it smaller until it succeeds. */ - - if (screen_info.lfb_base) { - if (efi_enabled(EFI_BOOT)) - size =3D max_t(__u32, screen_info.lfb_size, 0x800000); - else - size =3D max_t(__u32, screen_info.lfb_size, 0x4000000); - - for (; !fb_mmio && (size >=3D 0x100000); size >>=3D 1) { - fb_mmio =3D __request_region(hyperv_mmio, - screen_info.lfb_base, size, - fb_mmio_name, 0); - } - } + for (; !fb_mmio && (size >=3D 0x100000); size >>=3D 1) + fb_mmio =3D __request_region(hyperv_mmio, start, size, fb_mmio_name, 0); } =20 /** --=20 2.37.1 From nobody Fri Apr 10 21:55:15 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 21B59C00140 for ; Thu, 18 Aug 2022 14:25:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245164AbiHROZg (ORCPT ); Thu, 18 Aug 2022 10:25:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49302 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244870AbiHROZX (ORCPT ); Thu, 18 Aug 2022 10:25:23 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F0FA5AB199 for ; Thu, 18 Aug 2022 07:25:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1660832722; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=V3EBiorc36K9lFac0YV8mycE+/askbIgPzPBST6q2Ao=; b=GWskFMMZi2PKwYwviFoXbH1xEenV70rrUAugo5HNr/bZjibPgzJ/LXvZ1sHaMJlN5GJAks itHbbUfzS7aWBtrly1EyU8RrnUEVHSCGJs5o/7x9b1JRd20JB4k/G/irfFIaqcXqImabr5 5CZbizCc58/BM0boMrIOZvNb/uYJcYk= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-222-mL-b56yZPmavJRyjnPYJZg-1; Thu, 18 Aug 2022 10:25:21 -0400 X-MC-Unique: mL-b56yZPmavJRyjnPYJZg-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 5E22B3C01DE7; Thu, 18 Aug 2022 14:25:20 +0000 (UTC) Received: from fedora.redhat.com (unknown [10.40.194.62]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0EF31C15BB8; Thu, 18 Aug 2022 14:25:17 +0000 (UTC) From: Vitaly Kuznetsov To: linux-hyperv@vger.kernel.org Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Wei Liu , Deepak Rawat , "K. Y. Srinivasan" , Haiyang Zhang , Stephen Hemminger , Dexuan Cui , Michael Kelley Subject: [PATCH v1 4/4] Drivers: hv: Never allocate anything besides framebuffer from framebuffer memory region Date: Thu, 18 Aug 2022 16:25:08 +0200 Message-Id: <20220818142508.402273-5-vkuznets@redhat.com> In-Reply-To: <20220818142508.402273-1-vkuznets@redhat.com> References: <20220818142508.402273-1-vkuznets@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.85 on 10.11.54.8 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Passed through PCI device sometimes misbehave on Gen1 VMs when Hyper-V DRM driver is also loaded. Looking at IOMEM assignment, we can see e.g. $ cat /proc/iomem ... f8000000-fffbffff : PCI Bus 0000:00 f8000000-fbffffff : 0000:00:08.0 f8000000-f8001fff : bb8c4f33-2ba2-4808-9f7f-02f3b4da22fe ... fe0000000-fffffffff : PCI Bus 0000:00 fe0000000-fe07fffff : bb8c4f33-2ba2-4808-9f7f-02f3b4da22fe fe0000000-fe07fffff : 2ba2:00:02.0 fe0000000-fe07fffff : mlx4_core the interesting part is the 'f8000000' region as it is actually the VM's framebuffer: $ lspci -v ... 0000:00:08.0 VGA compatible controller: Microsoft Corporation Hyper-V virtu= al VGA (prog-if 00 [VGA controller]) Flags: bus master, fast devsel, latency 0, IRQ 11 Memory at f8000000 (32-bit, non-prefetchable) [size=3D64M] ... hv_vmbus: registering driver hyperv_drm hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm] Synthvid Version ma= jor 3, minor 5 hyperv_drm 0000:00:08.0: vgaarb: deactivate vga console hyperv_drm 0000:00:08.0: BAR 0: can't reserve [mem 0xf8000000-0xfbffffff] hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm] Cannot request fram= ebuffer, boot fb still active? Note: "Cannot request framebuffer" is not a fatal error in hyperv_setup_gen1() as the code assumes there's some other framebuffer device there but we actually have some other PCI device (mlx4 in this case) config space there! The problem appears to be that vmbus_allocate_mmio() can allocate from the reserved framebuffer region (fb_overlap_ok), however, if the request to allocate MMIO comes from some other device before framebuffer region is taken, it can happily use framebuffer region for it. Note, Gen2 VMs are usually unaffected by the issue because framebuffer region is already taken by EFI fb (in case kernel supports it) but Gen1 VMs may have this region unclaimed by the time Hyper-V PCI pass-through driver tries allocating MMIO space if Hyper-V DRM/FB drivers load after it. Devices can be brought up in any sequence so let's resolve the issue by always ignoring 'fb_mmio' region for non-FB requests, even if the region is unclaimed. Signed-off-by: Vitaly Kuznetsov --- drivers/hv/vmbus_drv.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c index 6edaeefa2c3c..54ace5c6b990 100644 --- a/drivers/hv/vmbus_drv.c +++ b/drivers/hv/vmbus_drv.c @@ -2328,7 +2328,7 @@ int vmbus_allocate_mmio(struct resource **new, struct= hv_device *device_obj, bool fb_overlap_ok) { struct resource *iter, *shadow; - resource_size_t range_min, range_max, start; + resource_size_t range_min, range_max, start, end; const char *dev_n =3D dev_name(&device_obj->device); int retval; =20 @@ -2363,6 +2363,14 @@ int vmbus_allocate_mmio(struct resource **new, struc= t hv_device *device_obj, range_max =3D iter->end; start =3D (range_min + align - 1) & ~(align - 1); for (; start + size - 1 <=3D range_max; start +=3D align) { + end =3D start + size - 1; + + /* Skip the whole fb_mmio region if not fb_overlap_ok */ + if (!fb_overlap_ok && fb_mmio && + (((start >=3D fb_mmio->start) && (start <=3D fb_mmio->end)) || + ((end >=3D fb_mmio->start) && (end <=3D fb_mmio->end)))) + continue; + shadow =3D __request_region(iter, start, size, NULL, IORESOURCE_BUSY); if (!shadow) --=20 2.37.1