From 0efb5be8b6a893c99d6ef16128ffe1beeb89181e Mon Sep 17 00:00:00 2001 From: Sasha Levin Date: Sun, 25 Sep 2022 10:30:27 -0400 Subject: [PATCH] Fixes for 4.9 Signed-off-by: Sasha Levin --- ...-allocate-anything-besides-framebuff.patch | 101 ++++++++++++++++++ queue-4.9/series | 1 + 2 files changed, 102 insertions(+) create mode 100644 queue-4.9/drivers-hv-never-allocate-anything-besides-framebuff.patch diff --git a/queue-4.9/drivers-hv-never-allocate-anything-besides-framebuff.patch b/queue-4.9/drivers-hv-never-allocate-anything-besides-framebuff.patch new file mode 100644 index 00000000000..a283358509e --- /dev/null +++ b/queue-4.9/drivers-hv-never-allocate-anything-besides-framebuff.patch @@ -0,0 +1,101 @@ +From 1b206da4fd0bdb362ce2d9b6876630edd4267c38 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 27 Aug 2022 15:03:45 +0200 +Subject: Drivers: hv: Never allocate anything besides framebuffer from + framebuffer memory region + +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 3248aa7a35b3..cb3e22f10d68 100644 +--- a/drivers/hv/vmbus_drv.c ++++ b/drivers/hv/vmbus_drv.c +@@ -1186,7 +1186,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; + +@@ -1221,6 +1221,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 + diff --git a/queue-4.9/series b/queue-4.9/series index ccd50b4e018..96492be4dcf 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -26,3 +26,4 @@ net-sunhme-fix-packet-reception-for-len-rx_copy_thre.patch serial-create-uart_xmit_advance.patch serial-tegra-use-uart_xmit_advance-fixes-icount.tx-accounting.patch s390-dasd-fix-oops-in-dasd_alias_get_start_dev-due-to-missing-pavgroup.patch +drivers-hv-never-allocate-anything-besides-framebuff.patch -- 2.47.3