Patch "Drivers: hv: Never allocate anything besides framebuffer from framebuffer memory region" has been added to the 4.14-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    Drivers: hv: Never allocate anything besides framebuffer from framebuffer memory region

to the 4.14-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     drivers-hv-never-allocate-anything-besides-framebuff.patch
and it can be found in the queue-4.14 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit cbfa55f2991bad429123a4c52577f067e64d943d
Author: Vitaly Kuznetsov <vkuznets@xxxxxxxxxx>
Date:   Sat Aug 27 15:03:45 2022 +0200

    Drivers: hv: Never allocate anything besides framebuffer from framebuffer memory region
    
    [ 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 <mikelley@xxxxxxxxxxxxx>
    Signed-off-by: Vitaly Kuznetsov <vkuznets@xxxxxxxxxx>
    Link: https://lore.kernel.org/r/20220827130345.1320254-4-vkuznets@xxxxxxxxxx
    Signed-off-by: Wei Liu <wei.liu@xxxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index cdf7d39362fd..1c09b1a787f6 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -1426,7 +1426,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;
 
@@ -1461,6 +1461,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)



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux