From nobody Fri Apr 10 23:22:59 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