Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp833235rwb; Mon, 26 Sep 2022 06:29:23 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6VKrT7fRtykxfFoXc84PUO85+TGhOIxdWi4I5UpUTiFt8sLyc7pKsXejGHdFFGOqKq7pay X-Received: by 2002:a17:906:8a66:b0:781:714a:1f2a with SMTP id hy6-20020a1709068a6600b00781714a1f2amr18396687ejc.205.1664198963698; Mon, 26 Sep 2022 06:29:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1664198963; cv=none; d=google.com; s=arc-20160816; b=a+ss4naSQ3NDoRcxWIPPN92WHR8KPThCpgcd9mvptMi7cOU/GhmM3FF/8q1/mgynl2 npkROyNYaBX1DDJSet7Krb9OLfQwq97JQqySQV8VevO1DypLvq9qgEzYdUkQDrCidD+Y fdkNmTjJg55WaxOWZmorxs1LHOYV+y6cDHEZgs0nxJ9bf/qshSLpDnpEEFgauFZAdOuz p+TD9cm8A+0YmNvjs7e0TcxUUfRtVwjELlXRvs8JKmMgVRu416Pi+It9gVf8lMDS82v8 HAD2P1LQx400Oxy5dlfzAvnnJgo844LhWQ1Bl0Jc66HwnSzs+HUwmS6sXtBQK4yqyXz+ BGiw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=p2d/3BSGK6E/sU/ioY+c62qZTeXvhwzIoNNTPH0w9NA=; b=SA4Jznd8OY/XvTSrg2zmZGBx1pQpTqW8qn3xtyHYr4y9nerGPnAF/9fvN/jbF1l3MA HwTlrERDrDz9WIQLXfpH/s7iEvayKHo9qvT1yA1dyzCZYyzHb5EmfOLEfoUoxbo/65uX t8S/Ucl/n8SAeLKKBZY9NG7vV2t14xQynZ2aXuVNAExBZLqtXyltEamlb0zZdRm6IhbL cUQ81YMg6iuxJ/S/kIk+QBaUcp3XuxUR+FUlvUhORNoy75JEJLh+5xHnYAWRpLP6yYjm XswqnHRg+Pk2wR9C5bzuoX/Rf569XZYjlaYD6u+zrA3fRQOm9SKgVdbs84PQOYPJ+z5C iRIA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=QteQ670l; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b12-20020a1709065e4c00b0072f42bb813csi12891348eju.134.2022.09.26.06.28.57; Mon, 26 Sep 2022 06:29:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=QteQ670l; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236742AbiIZMX4 (ORCPT + 99 others); Mon, 26 Sep 2022 08:23:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35052 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237146AbiIZMXV (ORCPT ); Mon, 26 Sep 2022 08:23:21 -0400 Received: from sin.source.kernel.org (sin.source.kernel.org [IPv6:2604:1380:40e1:4800::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1EE055A3DD; Mon, 26 Sep 2022 04:05:15 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id E598BCE1122; Mon, 26 Sep 2022 10:51:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E5C61C433C1; Mon, 26 Sep 2022 10:51:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1664189477; bh=F0QpExpqRDTwj0Px6tY3UgvVq9CTES248BvTZVN/jfE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=QteQ670lN0iUnUFm7QgQa8JgxM3qVBLh9xQCPn4bjc6cQAfXlIvyvSP7i0AxV5QjX XJAPvtim76HHQ3LATpShdLtFPlKMYFGEW9kCdC8vPOXJxSyLB0rFXfbjLzxTN9cbZp 10p/4OeFkNTEusqi62fQXm71u+Hm4o0tIxbJC5kQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Michael Kelley , Vitaly Kuznetsov , Wei Liu , Sasha Levin Subject: [PATCH 5.19 171/207] Drivers: hv: Never allocate anything besides framebuffer from framebuffer memory region Date: Mon, 26 Sep 2022 12:12:40 +0200 Message-Id: <20220926100814.314587683@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220926100806.522017616@linuxfoundation.org> References: <20220926100806.522017616@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Vitaly Kuznetsov [ Upstream commit f0880e2cb7e1f8039a048fdd01ce45ab77247221 ] 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 use dedicated framebuffer region to serve any MMIO request from any device. The semantics one might assume of a parameter named "fb_overlap_ok" aren't implemented because !fb_overlap_ok essentially has no effect. The existing semantics are really "prefer_fb_overlap". This patch implements the expected and needed semantics, which is to not allocate from the frame buffer space when !fb_overlap_ok. 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. Reviewed-by: Michael Kelley Signed-off-by: Vitaly Kuznetsov Link: https://lore.kernel.org/r/20220827130345.1320254-4-vkuznets@redhat.com Signed-off-by: Wei Liu Signed-off-by: Sasha Levin --- 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 547ae334e5cd..027029efb008 100644 --- a/drivers/hv/vmbus_drv.c +++ b/drivers/hv/vmbus_drv.c @@ -2309,7 +2309,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; @@ -2344,6 +2344,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) -- 2.35.1