From patchwork Thu Aug 18 14:25:05 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vitaly Kuznetsov X-Patchwork-Id: 12947221 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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 37E34C00140 for ; Thu, 18 Aug 2022 14:27:29 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 909799A2A2; Thu, 18 Aug 2022 14:27:21 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by gabe.freedesktop.org (Postfix) with ESMTPS id 10D82D8BAF for ; Thu, 18 Aug 2022 14:25:19 +0000 (UTC) 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=fC9YoAlYaRoz9rMPLE4asKIxjUKxEIVxQJ6T79z28gE=; b=XM21bH/1g4wFAKNBeZrYwb+ZSGEJZJuqtmwYpiGb19NYnjPutGSq0LKtF9VLYgJzV/eEC8 W2aNa+QW8ZwEq29KlQDlS8hY/gBRIeREFAgnWP7urrYLNyKTTg+Us78AWBTlSDS0AjlNrZ KuCHC22N4/Gdj3kFvwNt+HZYE35oxVM= 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 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 X-Scanned-By: MIMEDefang 2.85 on 10.11.54.8 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Stephen Hemminger , Haiyang Zhang , Dexuan Cui , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Michael Kelley , Deepak Rawat , "K. Y. Srinivasan" Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" 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/hyperv/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 -#define PCI_VENDOR_ID_MICROSOFT 0x1414 -#define PCI_DEVICE_ID_HYPERV_VIDEO 0x5353 - DEFINE_DRM_GEM_FOPS(hv_fops); static struct drm_driver hyperv_driver = { diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.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) -#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 = GUID_INIT(0xc376c1c3, 0xd276, 0x48d2, 0x90, 0xa9, \ 0xc0, 0x47, 0x48, 0x07, 0x2c, 0x60) +/* 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 */ From patchwork Thu Aug 18 14:25:06 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vitaly Kuznetsov X-Patchwork-Id: 12953901 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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 2CC90C00140 for ; Wed, 24 Aug 2022 19:08:13 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id C7302B8E27; Wed, 24 Aug 2022 19:08:09 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by gabe.freedesktop.org (Postfix) with ESMTPS id 7692CBAACE for ; Thu, 18 Aug 2022 14:25:18 +0000 (UTC) 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=LLHkOHpskLBhdOQCELAfMzjLuxK41Cq788s3q0r056g=; b=VOpAJG+famGn5IQDKVkwODMgyooX0V3F59OxZ6XIjwigHrSwI7kmZaB9ODv97ViQXjwOHE MUALjZSsrm6B0gGJk6wlumGQCUjyxrRYZCuBToMtk7WXw+9EHRFlO5wzKl3IAKH6sT3Mqt 9u+gSMxLcIsU4qeMJ4fJNBCI9ark+/Q= 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 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 X-Scanned-By: MIMEDefang 2.85 on 10.11.54.8 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Stephen Hemminger , Haiyang Zhang , Dexuan Cui , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Michael Kelley , Deepak Rawat , "K. Y. Srinivasan" Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" 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/hyperv/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 = drm_aperture_remove_conflicting_pci_framebuffers(pdev, &hyperv_driver); if (ret) { drm_err(dev, "Not able to remove boot fb\n"); - return ret; + goto error; } if (pci_request_region(pdev, 0, DRIVER_NAME) != 0) From patchwork Thu Aug 18 14:25:07 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vitaly Kuznetsov X-Patchwork-Id: 12947222 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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E0639C32772 for ; Thu, 18 Aug 2022 14:27:38 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 88EB6C195D; Thu, 18 Aug 2022 14:27:24 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by gabe.freedesktop.org (Postfix) with ESMTPS id 6641BB9C83 for ; Thu, 18 Aug 2022 14:25:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1660832725; 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=UaLCl/KDD1co3Hw2lUSWyZMPCUxgKha+JMJOGNAbX6cQSEHclQI/n/rS9gR/+8hvkzPYPo Nw+dHietkOVXlb4goUgm7veEtdN+nzvDbUK0QpXgnSfkmRhuMBfZV0IX42HeyfnqvZzpOV BQuQoLknDYeoW+l7BUK1Y0u9COW2S38= 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 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 X-Scanned-By: MIMEDefang 2.85 on 10.11.54.8 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Stephen Hemminger , Haiyang Zhang , Dexuan Cui , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Michael Kelley , Deepak Rawat , "K. Y. Srinivasan" Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" 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" @@ -2258,26 +2259,44 @@ static int vmbus_acpi_remove(struct acpi_device *device) static void vmbus_reserve_fb(void) { - int size; + resource_size_t start = 0, size; + struct pci_dev *pdev; + + if (efi_enabled(EFI_BOOT)) { + /* Gen2 VM: get FB base from EFI framebuffer */ + start = screen_info.lfb_base; + size = max_t(__u32, screen_info.lfb_size, 0x800000); + } else { + /* Gen1 VM: get FB base from PCI */ + pdev = 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 = pci_resource_start(pdev, 0); + size = 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 = max_t(__u32, screen_info.lfb_size, 0x800000); - else - size = max_t(__u32, screen_info.lfb_size, 0x4000000); - - for (; !fb_mmio && (size >= 0x100000); size >>= 1) { - fb_mmio = __request_region(hyperv_mmio, - screen_info.lfb_base, size, - fb_mmio_name, 0); - } - } + for (; !fb_mmio && (size >= 0x100000); size >>= 1) + fb_mmio = __request_region(hyperv_mmio, start, size, fb_mmio_name, 0); } /** From patchwork Thu Aug 18 14:25:08 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vitaly Kuznetsov X-Patchwork-Id: 12947211 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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 086E9C00140 for ; Thu, 18 Aug 2022 14:26:57 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id A272A2BB93; Thu, 18 Aug 2022 14:26:35 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by gabe.freedesktop.org (Postfix) with ESMTPS id DA765D8ACB for ; Thu, 18 Aug 2022 14:25:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1660832723; 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=A44TZ6ywblEVGWrq9Km+P+03t6fmdsBuLtXrkiAufqX+hbtwWpizZiLTcCMKGtlm9focKN 0elP2pHgfMH5VpRhMz4JvoIyeR5gZTHPhG5PPnlE9Q7UkS0hLWDmvnain/07PkHyizOAJM K/8+VY7ZJQ0djpD8ftlhuDX0eI8gTC4= 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 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 X-Scanned-By: MIMEDefang 2.85 on 10.11.54.8 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Stephen Hemminger , Haiyang Zhang , Dexuan Cui , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Michael Kelley , Deepak Rawat , "K. Y. Srinivasan" Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" 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 virtual VGA (prog-if 00 [VGA controller]) Flags: bus master, fast devsel, latency 0, IRQ 11 Memory at f8000000 (32-bit, non-prefetchable) [size=64M] ... hv_vmbus: registering driver hyperv_drm hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm] Synthvid Version major 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 framebuffer, 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 = dev_name(&device_obj->device); int retval; @@ -2363,6 +2363,14 @@ int vmbus_allocate_mmio(struct resource **new, struct hv_device *device_obj, range_max = iter->end; start = (range_min + align - 1) & ~(align - 1); for (; start + size - 1 <= range_max; start += align) { + end = start + size - 1; + + /* Skip the whole fb_mmio region if not fb_overlap_ok */ + if (!fb_overlap_ok && fb_mmio && + (((start >= fb_mmio->start) && (start <= fb_mmio->end)) || + ((end >= fb_mmio->start) && (end <= fb_mmio->end)))) + continue; + shadow = __request_region(iter, start, size, NULL, IORESOURCE_BUSY); if (!shadow)