From: Thomas Zimmermann Sent: Tuesday, September 30, 2025
8:04 AM
>
> Hi
>
> Am 16.09.25 um 17:00 schrieb Michael Kelley:
> > From: Thomas Zimmermann Sent: Tuesday, September 16,
> > 2025 1:31 AM
> >> Hi
> >>
> >> Am 09.09.25 um 05:29 schr
;
> + pr_warn("Deprecated: use Hyper-V DRM driver instead\n");
> +
> if (fb_modesetting_disabled("hyper_fb"))
> return -ENODEV;
>
> --
> 2.49.0
Reviewed-by: Michael Kelley
el.org
> +S: Obsolete
> +T: git git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux.git
> +F: drivers/video/fbdev/hyperv_fb.c
> +
> HYPERBUS SUPPORT
> M: Vignesh Raghavendra
> R: Tudor Ambarus
> --
> 2.49.0
Reviewed-by: Michael Kelley
From: Thomas Zimmermann Sent: Tuesday, September 16, 2025
1:31 AM
>
> Hi
>
> Am 09.09.25 um 05:29 schrieb Michael Kelley:
> > From: Michael Kelley Sent: Thursday, September 4, 2025 10:36 PM
> >> From: Thomas Zimmermann Sent: Thursday, September 4,
> >>
From: Prasanna Kumar T S M Sent: Thursday, September
11, 2025 9:28 AM
>
> Hi Michael,
>
> On 10-09-2025 20:55, Michael Kelley wrote:
> > From: Thomas Zimmermann Sent: Wednesday, September
> 10, 2025 2:36 AM
> >>
> >> Hi
> >>
> >> Am
From: Thomas Zimmermann Sent: Wednesday, September 10,
2025 2:36 AM
>
> Hi
>
> Am 09.09.25 um 18:58 schrieb Prasanna Kumar T S M:
> > The Hyper-V DRM driver is available since kernel version 5.14 and
> > provides full KMS support along with fbdev emulation via the DRM fbdev
> > helpers. This ma
From: Michael Kelley Sent: Thursday, September 4, 2025 10:36 PM
>
> From: Thomas Zimmermann Sent: Thursday, September 4,
> 2025 7:56 AM
> >
> > Compositors often depend on vblanks to limit their display-update
> > rate. Without, they see vblank events ASAP, which
earlier testing. I'll keep running this
test kernel for a while to see if anything anomalous occurs.
For Patches 1, 2, and 4 of the series on a Hyper-V guest,
Tested-by: Michael Kelley
[4]
https://lore.kernel.org/dri-devel/20250523161522.409504-1-mhkli...@outlook.com/T/#m2e288dddaf7b3c025bb
From: Mukesh R Sent: Wednesday, September 3, 2025
7:17 PM
>
> On 9/2/25 07:42, Michael Kelley wrote:
> > From: Mukesh Rathor Sent: Wednesday, August
> > 27, 2025 6:00 PM
> >>
> >> At present, drivers/Makefile will subst =m to =y for CONFIG_HYPERV for hv
&g
From: Javier Martinez Canillas Sent: Tuesday, September 2,
2025 8:41 AM
>
> Thomas Zimmermann writes:
>
> [...]
>
> >>
> >> I'm not familiar with hyperv to know whether is a problem or not for the
> >> host to not be notified that the guest display is disabled. But I thought
> >> that should
From: Mukesh Rathor Sent: Wednesday, August 27,
2025 6:00 PM
Same comment about patch "Subject:" prefix.
> CONFIG_HYPERV is an umbrella config option involved in enabling hyperv
s/hyperv/Hyper-V/
> support and build of modules like hyperv-balloon, hyperv-vmbus, etc..
With CONFIG_HYPERV and C
From: Mukesh Rathor Sent: Wednesday, August 27,
2025 6:00 PM
>
Even though this patch touches multiple subdirectories under "drivers",
I'd suggest the patch "Subject:" prefix should be "Drivers: hv:" (not
"hyper-v:")
to be consistent with historical usage.
> Somehow vmbus driver is hinged on
From: Mukesh Rathor Sent: Wednesday, August 27,
2025 6:00 PM
>
> At present, drivers/Makefile will subst =m to =y for CONFIG_HYPERV for hv
> subdir. Also, drivers/hv/Makefile replaces =m to =y to build in
> hv_common.c that is needed for the drivers. Moreover, vmbus driver is
> built if CONFIG_H
From: Michael Kelley Sent: Thursday, June 5, 2025 10:39 AM
>
> From: Thomas Zimmermann Sent: Thursday, June 5, 2025
> 8:36 AM
> >
> > Hi
> >
> > Am 04.06.25 um 23:43 schrieb Michael Kelley:
> > [...]
> > > Nonetheless, there's an underlyi
From: Thomas Zimmermann Sent: Thursday, June 5, 2025 8:36
AM
>
> Hi
>
> Am 04.06.25 um 23:43 schrieb Michael Kelley:
> [...]
> > Nonetheless, there's an underlying issue. A main cause of the difference
> > is the number of messages to Hyper-V to update dirty r
From: Michael Kelley Sent: Tuesday, June 3, 2025 10:25 AM
>
> From: David Hildenbrand Sent: Tuesday, June 3, 2025 12:55
> AM
> >
> > On 03.06.25 03:49, Michael Kelley wrote:
> > > From: David Hildenbrand Sent: Monday, June 2, 2025
> > > 2:48 AM
>
From: Simona Vetter Sent: Wednesday, June 4, 2025 7:46
AM
>
> On Wed, Jun 04, 2025 at 10:12:45AM +0200, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 03.06.25 um 19:50 schrieb Michael Kelley:
> > > From: Thomas Zimmermann Sent: Monday, June 2, 2025
> > &
From: Thomas Zimmermann Sent: Monday, June 2, 2025 11:25
PM
>
> Hi
>
> Am 03.06.25 um 03:49 schrieb Michael Kelley:
> [...]
> >> Will the VMA have VM_PFNMAP or VM_MIXEDMAP set? PFN_SPECIAL is a
> >> horrible hack.
> >>
> >> In another thread,
From: David Hildenbrand Sent: Tuesday, June 3, 2025 12:55 AM
>
> On 03.06.25 03:49, Michael Kelley wrote:
> > From: David Hildenbrand Sent: Monday, June 2, 2025 2:48
> > AM
> >>
> >> On 23.05.25 18:15, mhkelle...@gmail.com wrote:
> >>> From: Mich
From: David Hildenbrand Sent: Monday, June 2, 2025 2:48 AM
>
> On 23.05.25 18:15, mhkelle...@gmail.com wrote:
> > From: Michael Kelley
> >
> > Current defio code works only for framebuffer memory that is allocated
> > with vmalloc(). The code assumes that the under
From: Alistair Popple Sent: Wednesday, May 28, 2025 11:32
PM
>
> All PFN_* pfn_t flags have been removed. Therefore there is no longer
> a need for the pfn_t type and all uses can be replaced with normal
> pfns.
>
> Signed-off-by: Alistair Popple
> Reviewed-by: Christoph Hellwig
> ---
> arch
Arnd --
Your commit a07b50d80ab62 ("hyperv: avoid dependency on screen_info") [1]
introduced a subtle bug. The commit message says, in part:
Similarly, the vmbus_drv code marks the original EFI framebuffer as
reserved, but this is not required if there is no sysfb.
This statement turns out
From: Christoph Hellwig Sent: Thursday, April 10, 2025 12:42 AM
>
> On Wed, Apr 09, 2025 at 02:10:26PM +, Michael Kelley wrote:
> > Hmmm. What's the reference to "as told last time"? I don't think I've had
> > this conversation before.
>
>
From: Christoph Hellwig Sent: Wednesday, April 9, 2025 3:50 AM
>
> On Tue, Apr 08, 2025 at 11:36:44AM -0700, mhkelle...@gmail.com wrote:
> > From: Michael Kelley
> >
> > Export vmf_insert_mixed_mkwrite() for use by fbdev deferred I/O code,
>
> But they are usi
From: Helge Deller Sent: Saturday, March 8, 2025 6:59 PM
>
> On 2/19/25 00:01, mhkelle...@gmail.com wrote:
> > From: Michael Kelley
> >
[snip]
> >
> > Reported-by: Thomas Tai
> > Fixes: c25a19afb81c ("fbdev/hyperv_fb: Do not clear global screen
o_cleanup(info);
>
> - unregister_framebuffer(info);
> cancel_delayed_work_sync(&par->dwork);
>
> vmbus_close(hdev->channel);
> hv_set_drvdata(hdev, NULL);
> -
> - hvfb_putmem(info);
> - framebuffer_release(info);
> }
>
> static int hvfb_suspend(struct hv_device *hdev)
> --
> 2.43.0
Reviewed-by: Michael Kelley
Tested-by: Michael Kelley
> vmbus_close(hdev->channel);
> error1:
> @@ -1226,7 +1226,7 @@ static void hvfb_remove(struct hv_device *hdev)
> vmbus_close(hdev->channel);
> hv_set_drvdata(hdev, NULL);
>
> - hvfb_putmem(hdev, info);
> + hvfb_putmem(info);
> framebuffer_release(info);
> }
>
> --
> 2.43.0
Reviewed-by: Michael Kelley
Tested-by: Michael Kelley
From: Saurabh Sengar
>
> When a Hyper-V framebuffer device is unbind, hyperv_fb driver tries to
> release the framebuffer forcefully. If this framebuffer is in use it
> produce the following WARN and hence this framebuffer is never released.
>
> [ 44.111220] WARNING: CPU: 35 PID: 1882 at
> dr
From: Saurabh Singh Sengar Sent: Monday, February
24, 2025 5:30 AM
>
> On Mon, Feb 24, 2025 at 12:38:22AM +, Michael Kelley wrote:
> > From: Saurabh Singh Sengar Sent: Sunday,
> > February 23, 2025 6:10 AM
> > >
> > > On Sat, Feb 22, 2025 at 08
From: Saurabh Singh Sengar Sent: Sunday, February
23, 2025 6:10 AM
>
> On Sat, Feb 22, 2025 at 08:16:53PM +, Michael Kelley wrote:
> > From: Saurabh Singh Sengar Sent: Saturday,
> > February 22, 2025 9:27 AM
> > >
[anip]
> > >
> > > I
From: Saurabh Singh Sengar Sent: Saturday,
February 22, 2025 9:27 AM
>
> On Wed, Feb 19, 2025 at 05:22:36AM +, Michael Kelley wrote:
> > From: Saurabh Sengar Sent: Saturday, February
> > 15,
> 2025 1:21 AM
> > >
> > > When a Hyper-V framebuffer devi
From: Saurabh Sengar Sent: Saturday, February 15,
2025 1:21 AM
>
> When a Hyper-V framebuffer device is unbind, hyperv_fb driver tries to
> release the framebuffer forcefully. If this framebuffer is in use it
> produce the following WARN and hence this framebuffer is never released.
>
> [ 44.
From: Michael Kelley Sent: Monday, February 10, 2025
1:36 PM
>
> From: thomas@oracle.com Sent: Monday, February
> 10, 2025 7:08 AM
> >
> >
> >
> > >> Then the question is why the efifb driver doesn't work in the kdump
> > >> ker
From: Saurabh Singh Sengar Sent: Wednesday,
February 12, 2025 7:07 PM
>
> On Thu, Feb 13, 2025 at 01:35:22AM +, Michael Kelley wrote:
> > From: Saurabh Singh Sengar Sent: Monday,
> > February 10, 2025 8:52 AM
> > >
> > [snip]
> > > > > >
From: Saurabh Singh Sengar Sent: Monday, February
10, 2025 8:52 AM
>
[snip]
> > > >
> > > > While we are at it, I want to mention that I also observed below WARN
> > > > while removing the hyperv_fb, but that needs a separate fix.
> > > >
> > > >
> > > > [ 44.111220] WARNING: CPU: 35 PID: 1882
From: Maxim Levitsky Sent: Monday, February 10, 2025 3:57
PM
>
> On Mon, 2025-02-10 at 21:35 +, Michael Kelley wrote:
> > From: thomas@oracle.com Sent: Monday, February
> > 10, 2025 7:08 AM
> > >
> > >
> > > > > Then the questio
From: Thomas Zimmermann Sent: Monday, February 10, 2025
11:35 PM
>
> Hi
>
> Am 10.02.25 um 20:34 schrieb mhkelle...@gmail.com:
> > From: Michael Kelley
> >
> > When a Hyper-V DRM device is probed, the driver allocates MMIO space for
> > the vram, and maps
From: Saurabh Singh Sengar Sent: Monday, February
10, 2025 8:52 AM
>
> On Mon, Feb 10, 2025 at 06:58:25AM -0800, Saurabh Singh Sengar wrote:
> > On Mon, Feb 10, 2025 at 02:28:35PM +0000, Michael Kelley wrote:
> > > From: Saurabh Singh Sengar Sent: Monday,
> >
From: Saurabh Singh Sengar Sent: Monday, February
10, 2025 7:33 PM
>
> On Mon, Feb 10, 2025 at 11:34:41AM -0800, mhkelle...@gmail.com wrote:
> > From: Michael Kelley
> >
> > When a Hyper-V DRM device is probed, the driver allocates MMIO space for
> > the vram,
From: thomas@oracle.com Sent: Monday, February 10,
2025 7:08 AM
>
>
>
> >> Then the question is why the efifb driver doesn't work in the kdump
> >> kernel. Actually, it *does* work in many cases. I built the 6.13.0 kernel
> >> on the Oracle Linux 9.4 system, and transferred the kernel imag
From: Saurabh Singh Sengar Sent: Monday, February
10, 2025 4:41 AM
>
> On Sun, Feb 09, 2025 at 03:52:52PM -0800, mhkelle...@gmail.com wrote:
> > From: Michael Kelley
> >
> > When a Hyper-V framebuffer device is removed, or the driver is unbound
> > from a devic
? __pfx_kthread+0x10/0x10
> [ 605.238519] ret_from_fork_asm+0x1a/0x30
> [ 605.239833]
> [ 605.240855] hv_vmbus: probe failed for device 5620e0c7-8062-4dce-aeb7-
> 520c7ef76171 (-110)
> [ 605.243404] hyperv_fb 5620e0c7-8062-4dce-aeb7-520c7ef76171: probe with
> driver hyper
From: Michael Kelley Sent: Thursday, February 6, 2025
1:00 PM
>
> From: Michael Kelley
> >
> > From: Thomas Tai Sent: Thursday, January 30, 2025
> > 12:44 PM
> > >
> > > > -----Original Message-
> > > > From: Michael
From: Michael Kelley
>
> From: Thomas Tai Sent: Thursday, January 30, 2025
> 12:44 PM
> >
> > > -Original Message-----
> > > From: Michael Kelley Sent: Thursday, January 30,
> > > 2025 3:20 PM
> > >
> > > From:
From: Thomas Tai Sent: Thursday, January 30, 2025 12:44
PM
>
> > -Original Message-
> > From: Michael Kelley
> > Sent: Thursday, January 30, 2025 3:20 PM
> > To: Thomas Tai ; mhkelle...@gmail.com;
> > haiya...@microsoft.com; wei@kernel.org; d
From: Thomas Tai Sent: Thursday, January 30, 2025 10:50
AM
>
> Sorry for the typo in the subject title. It should have been 'hyperv_fb soft
> lockup on
> Azure Gen2 VM when taking kdump or executing kexec'
>
> Thomas
>
> >
> > Hi Michael,
> >
> > We see an issue with the mainline kernel on th
we can have very simple / safe ones, while others are
> destructive in nature.
>
> An example of a good behaving notifier that is destructive is the
> Hyper-V one, that destroys an essential host-guest interface (called
> "vmbus connection"). What happens if we trigger this
From: Wei Liu Sent: Friday, March 1, 2024 1:26 AM
>
> On Fri, Feb 09, 2024 at 04:53:37PM +0100, Helge Deller wrote:
> > On 2/9/24 16:23, Michael Kelley wrote:
> > > From: Thomas Zimmermann Sent: Thursday, February 1,
> > > 2024 12:17 AM
> [...]
>
From: Thomas Zimmermann Sent: Thursday, February 1, 2024
12:17 AM
>
> Hi
>
> Am 01.02.24 um 07:00 schrieb mhkelle...@gmail.com:
> > From: Michael Kelley
> >
> > A recent commit removing the use of screen_info introduced a logic
> > error. The error c
From: Nischala Yelchuri Sent: Wednesday,
November 1, 2023 9:02 AM
>
It's customary for the patch "Subject:" line to have a prefix indicating the
area of the code being modified. This patch touches on multiple Hyper-V
drivers, so there's not a clear choice for prefix. I would suggest using
"Dri
ers/gpu/drm/hyperv/hyperv_drm_drv.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
> b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
> index a7d2c92d6c6a..8026118c6e03 100644
> --- a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
> +++ b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
> @@ -7,6 +7,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> --
> 2.25.1
Reviewed-by: Michael Kelley
From: Petr Tesarik Sent: Tuesday, May 9, 2023
2:18 AM
>
> The software IO TLB was designed with the assumption that it is not
> used much, especially on 64-bit systems, so a small fixed memory
> area (currently 64 MiB) is sufficient to handle the few cases which
> still require a bounce buffer.
&&
>x * y * screen_depth / 8 > SYNTHVID_FB_SIZE_WIN8)) {
> pr_err("Screen resolution option is out of range: skipped\n");
> - return;
> + goto out;
> }
>
> screen_width = x;
> screen_height = y;
> - return;
> +
> +out:
> + kfree(optbuf);
> }
>
> /*
> --
> 2.39.2
Reviewed-by: Michael Kelley
->apertures->ranges[0].size,
> - false, KBUILD_MODNAME);
> + aperture_remove_conflicting_devices(base, size, false, KBUILD_MODNAME);
>
> if (gen2vm) {
> /* framebuffer is reallocated, clear screen_info to avoid
> misuse from kexec */
> --
> 2.39.0
Reviewed-by: Michael Kelley
g_init(hv);
> if (ret)
> goto err_vmbus_close;
> --
> 2.31.1
Reviewed-by: Michael Kelley
ndpacket(struct hv_device
> *hdev,
> struct synthvid_msg
> VM_PKT_DATA_INBAND, 0);
>
> if (ret)
> - drm_err(&hv->dev, "Unable to send packet via vmbus\n");
> + drm_err_ratelimited(&hv->dev, "Unable to send packet via vmbus;
> error %d\n", ret);
>
> return ret;
> }
> --
> 1.8.3.1
Reviewed-by: Michael Kelley
uffers(pdev,
> &hyperv_driver);
> + pci_dev_put(pdev);
> + if (ret) {
> + drm_err(dev, "Not able to remove boot fb\n");
> + return ret;
> + }
> + }
>
> hv->fb_size = (unsigned long)hv->mmio_megabytes * 1024 * 1024;
>
> --
> 2.34.1
Reviewed-by: Michael Kelley
/* 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.37.1
Other than my musings on the commit message,
Reviewed-by: Michael Kelley
;& (size >= 0x10); size >>= 1) {
> - fb_mmio = __request_region(hyperv_mmio,
> - screen_info.lfb_base, size,
> -fb_mmio_name, 0);
> - }
> - }
> + for (; !fb_mmio && (size >= 0x10); size >>= 1)
> + fb_mmio = __request_region(hyperv_mmio, start, size,
> fb_mmio_name, 0);
> }
>
> /**
> --
> 2.37.1
Reviewed-by: Michael Kelley
DEVICE_ID_ICE_1712 0x1712
> #define PCI_DEVICE_ID_VT1724 0x1724
>
> +#define PCI_VENDOR_ID_MICROSOFT 0x1414
> +#define PCI_DEVICE_ID_HYPERV_VIDEO 0x5353
> +
> #define PCI_VENDOR_ID_OXSEMI 0x1415
> #define PCI_DEVICE_ID_OXSEMI_12PCI8400x8403
> #define PCI_DEVICE_ID_OXSEMI_PCIe840 0xC000
> --
> 2.37.1
Reviewed-by: Michael Kelley
From: Vitaly Kuznetsov Sent: Thursday, August 18, 2022
7:25 AM
>
> 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.
FWIW, in a Gen1 VM, whether screen_info.lfb_base is set
From: Vitaly Kuznetsov Sent: Thursday, August 18, 2022
7:25 AM
>
> 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
From: Vitaly Kuznetsov Sent: Thursday, August 18, 2022
7:25 AM
>
> 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
hould be on a0ab5abced55. As you noted,
this patch won't apply cleanly on stable kernel versions that lack that commit,
so we'll need a separate patch for stable if we want to make the fix there.
> Signed-off-by: Christophe JAILLET
All that said, the fix looks good, so
Reviewed-by: Mich
fo->apertures->ranges[0].base,
> info->apertures->ranges[0].size,
> - KBUILD_MODNAME, false);
> + false, KBUILD_MODNAME);
>
> if (gen2vm) {
> /* framebuffer is reallocated, clear screen_info to avoid
> misuse from
> kexec */
> --
> 2.36.1
For the Hyper-V frame buffer driver:
Reviewed-by: Michael Kelley
From: Pavel Machek Sent: Wednesday, May 4, 2022 10:23 AM
>
> Hi!
>
> > Linux code for running as a Hyper-V guest includes special cases for the
> > first released versions of Hyper-V: 2008 and 2008R2/Windows 7. These
> > versions were very thinly used for running Linux guests when first
> > rele
the code by removing the negotiation of the VMbus protocol
versions required for these releases of Hyper-V, and by removing the
special case code for handling these VMbus protocol versions.
Signed-off-by: Michael Kelley
---
drivers/hv/channel_mgmt.c | 29 +--
drivers/hv
effective production usage of Linux guests.
The negotiation of the VMbus protocol versions required by these old
Hyper-V versions has been removed from the VMbus driver. So now remove
the handling of these VMbus protocol versions from the storvsc driver.
Signed-off-by: Michael Kelley
---
drivers
Linux guests.
The negotiation of the VMbus protocol versions required by these old
Hyper-V versions has been removed from the VMbus driver. So now remove
the handling of these VMbus protocol versions from the hyperv_fb driver.
Signed-off-by: Michael Kelley
---
drivers/video/fbdev/hyperv_fb.c | 23
Linux guests.
The negotiation of the VMbus protocol versions required by these old
Hyper-V versions has been removed from the VMbus driver. So now remove
the handling of these VMbus protocol versions from the DRM Hyper-V
driver.
Signed-off-by: Michael Kelley
---
drivers/gpu/drm/hyperv
the Hyper-V team within
Microsoft, we're already past the point that it has any value.
Michael Kelley (4):
Drivers: hv: vmbus: Remove support for Hyper-V 2008 and Hyper-V
2008R2/Win7
scsi: storvsc: Remove support for Hyper-V 2008 and 2008R2/Win7
video: hyperv_fb: Remove support f
From: Yanming Liu Sent: Wednesday, January 19, 2022 12:14
PM
>
> On Thu, Jan 20, 2022 at 2:12 AM Michael Kelley (LINUX)
> wrote:
> >
> > From: Wei Liu Sent: Friday, January 14, 2022 11:13 AM
> > >
> > > On Mon, Jan 10, 2022 at 01:44:19AM +0100, Andrea P
From: Wei Liu Sent: Sunday, January 23, 2022 1:56 PM
>
> On Sun, Jan 16, 2022 at 09:53:06PM +, Haiyang Zhang wrote:
> >
> >
> > > -Original Message-
> > > From: Michael Kelley (LINUX)
> > > Sent: Sunday, January 16, 2022 2:19 PM
> &
From: Wei Liu Sent: Friday, January 14, 2022 11:13 AM
>
> On Mon, Jan 10, 2022 at 01:44:19AM +0100, Andrea Parri wrote:
> > (Extending Cc: list,)
> >
> > On Sun, Jan 09, 2022 at 05:55:16PM +0800, Yanming Liu wrote:
> > > Commit adae1e931acd ("Drivers: hv: vmbus: Copy packets sent by Hyper-V
> > >
creen resolution from
Hyper-V host")
Signed-off-by: Michael Kelley
---
drivers/video/fbdev/hyperv_fb.c | 16 +++-
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
index 23999df..c8e0ea2 100644
--- a/dri
From: Joe Perches Sent: Tuesday, April 20, 2021 12:59 PM
>
> On Tue, 2021-04-20 at 08:44 -0700, Michael Kelley wrote:
> > Due to a full ring buffer, the driver may be unable to send updates to
> > the Hyper-V host. But outputing the error message can make the problem
> &g
.
Break the cycle by rate limiting the error message. Also output
the error code for additional diagnosability.
Signed-off-by: Michael Kelley
---
drivers/video/fbdev/hyperv_fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video
kfree(info->apertures) calls in hvfb_getmem().
This will allow framebuffer_release() to free the memory, which follows
the pattern of other fbdev drivers.
Modulo this revision to the commit message, which Wei Liu can
probably incorporate,
Reviewed-by: Michael Kelley
>
> Signed-off-by: Lv Yun
From: Lv Yunlong Sent: Tuesday, March 23, 2021 12:34
AM
>
> In function hvfb_probe in hyperv_fb.c, it calls hvfb_getmem(hdev, info)
> and return err when info->apertures is freed.
>
> In the error1 label of hvfb_probe, info->apertures will be freed twice
> by framebuffer_release(info).
>
> My
for performance. This is also required for
> + * VM Connect to display properly for ARM64 Linux VM, as the host also
> + * maps the VRAM cacheable.
> + */
> + fb_virt = ioremap_cache(par->mem->start, screen_fb_size);
> if (!fb_virt)
> goto err2;
>
> --
> 2.19.1
Reviewed-by: Michael Kelley
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
| 2 +-
> mm/percpu.c| 2 +-
> mm/vmalloc.c | 4 ++--
> net/bridge/netfilter/ebtables.c| 6 ++
> sound/core/memalloc.c | 2 +-
> sound/core/pcm_memory.c | 2 +-
>
-
> arch/x86/include/asm/pgtable_types.h | 2 --
> 2 files changed, 1 insertion(+), 3 deletions(-)
>
Reviewed-by: Michael Kelley
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
: Wei Hu
> ---
> v2: Incorporated review comments form h...@lst.de, Michael Kelley and
> Dexuan Cui
> - Use dma_alloc_coherent to allocate large contiguous memory
> - Use phys_addr_t for physical addresses
> - Corrected a few spelling errors and minor clea
From: Wei Hu Sent: Friday, December 6, 2019 3:32 AM
>
> On Hyper-V, Generation 1 VMs can directly use VM's physical memory for
> their framebuffers. This can improve the efficiency of framebuffer and
> overall performence for VM. The physical memory assigned to framebuffer
> must be contiguous. W
goto out;
> + ret = -ETIMEDOUT;
> + goto out;
> }
>
> if (msg->resolution_resp.resolution_count == 0) {
> --
> 2.20.1
Reviewed-by: Michael Kelley
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
space to CMA allocator at boot time. For
> example:
> cma=130m
> This gives 130MB memory to CAM allocator that can be allocated to
> framebuffer. If this fails, we fall back to the old way of using
> mmio for framebuffer.
>
> Signed-off-by: Wei Hu
> ---
> v2: Inc
From: Wei Hu Sent: Tuesday, October 22, 2019 4:11 AM
>
> On Hyper-V, Generation 1 VMs can directly use VM's physical memory for
> their framebuffers. This can improve the efficiency of framebuffer and
> overall performence for VM. The physical memory assigned to framebuffer
> must be contiguous.
From: Michael Kelley Sent: Wednesday, September 18,
2019 2:48 PM
> >
> > Without deferred IO support, hyperv_fb driver informs the host to refresh
> > the entire guest frame buffer at fixed rate, e.g. at 20Hz, no matter there
> > is screen update or not. This patch
n doing the on-demand refresh. This can be optimized in the
> future with help from host. For now the host performance gain from deferred
> IO outweighs the shadow copy impact in the guest.
>
> Signed-off-by: Wei Hu
> ---
> v2: Incorporated review comments from Michael Kelley
n doing the on-demand refresh. This can be optimized in the
> future with help from host. For now the host performance gain from deferred
> IO outweighs the shadow copy impact in the guest.
>
> Signed-off-by: Wei Hu
> ---
> v2: Incorporated review comments from Michael Kelley
n doing the on-demand refresh. This can be optimized in the
> future with help from host. For now the host performance gain from deferred
> IO outweighs the shadow copy impact in the guest.
>
> Signed-off-by: Wei Hu
> ---
> v2: Incorporated review comments from Michael Kelley
array.
>
> v3:
> - Corrected the synthvid major and minor version comparison problem.
>
> v4:
> - Changed function name to synthvid_ver_ge().
>
> drivers/video/fbdev/hyperv_fb.c | 159 +---
> 1 file changed, 147 insertions(+), 12 deletions(-)
>
Reviewed-by: Michael Kelley
n doing the on-demand refresh. This can be optimized in the
> future with help from host. For now the host performance gain from deferred
> IO outweighs the shadow copy impact in the guest.
>
> v2: Incorporated review comments from Michael Kelley
> - Increased dirty rectangle
From: Wei Hu Sent: Tuesday, August 27, 2019 4:09 AM
>
> Beginning from Windows 10 RS5+, VM screen resolution is obtained from host.
> The "video=hyperv_fb" boot time option is not needed, but still can be
> used to overwrite what the host specifies. The VM resolution on the host
> could be set by
From: Wei Hu Sent: Wednesday, August 21, 2019 4:59 AM
>
> > From: Michael Kelley
> > Sent: Monday, August 19, 2019 6:41 AM
> > To: Wei Hu ; rdun...@infradead.org; shc_w...@mail.ru;
>
> > > - msg.dirt.rect[0].x1 = 0;
> > > - msg.dirt.rect[0].y1 = 0;
&g
he host
> could be set by executing the powershell "set-vmvideo" command.
>
> v2:
> - Implemented fallback when version negotiation failed.
> - Defined full size for supported_resolution array.
>
> Signed-off-by: Iouri Tarassov
> Signed-off-by: Wei Hu
> Rev
From: Wei Hu Sent: Tuesday, August 13, 2019 2:55 AM
>
> Beginning from Windows 10 RS5+, VM screen resolution is obtained from host.
> The "video=hyperv_fb" boot time option is not needed, but still can be
> used to overwrite the VM resolution. The VM resolution on the host could be
I would word
From: Wei Hu Sent: Tuesday, August 13, 2019 3:37 AM
>
> Without deferred IO support, hyperv_fb driver informs the host to refresh
> the entire guest frame buffer at fixed rate, e.g. at 20Hz, no matter there
> is screen update or not. This patch supports defered IO for screens in
s/defered/deferr
98 matches
Mail list logo
