RE: [RFC PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device

[Dexuan Cui <decui@microsoft.com>]

> From: linux-hyperv-owner@vger.kernel.org
> <linux-hyperv-owner@vger.kernel.org> On Behalf Of Deepak Rawat
> Sent: Monday, June 22, 2020 11:49 PM
> > [...]
> > Some quick comments:
> > 1. hyperv_vmbus_probe() assumes the existence of the PCI device,
> > which
> > is not true in a Hyper-V Generation-2 VM.
> 
> I guess that mean for Gen-2 VM need to rely on vmbus_allocate_mmio to
> get the VRAM memory? From what I understand the pci interface anyway
> maps to vmbus.

In a Hyper-V Generaton-2 VM, there is not the legacy Hyper-V PCI framebuffer
device, so we have to call vmbus_allocate_mmio() to get a proper MMIO 
range and use that as the VRAM memory.

BTW, what's the equivlent of FB_DEFERRED_IO in DRM? Have the patch
implemented the similar thing for DRM like this for FB in this patch:
d21987d709e8 ("video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver")

There is also another important performance improvement patch:
3a6fb6c4255c ("video: hyperv: hyperv_fb: Use physical memory for fb on HyperV Gen 1 VMs.")
Is the same idea applicable to this DRM patch?

The pci-hyperv FB driver and this DRM driver should not try to load at
the same time. Not sure what should be done to make sure that won't happen.

> > 2. It looks some other functionality in the hyperv_fb driver has not
> > been
> > implemented in this new driver either, e.g. the handling of the
> > SYNTHVID_FEATURE_CHANGE msg.
> 
> I deliberately left this and things seems to work without this, maybe I
> need to do more testing. I don't really understand the use-case
> of SYNTHVID_FEATURE_CHANGE. I observed this message was received just
> after vmbus connect and DRM is not yet initialized so no point updating
> the situation. Even otherwise situation (mode, damage, etc.) is
> triggered from user-space, not sure what to update. But will definitely
> clarify on this.

When Linux VM updates the VRAM, Linux should notify the host of the
dirty rectangle, and then the host refreshes the rectangle in the VM
Connectin window so the user sees the updated part of the screen.

I remember when the user closes the VM Connection window, the host
sends the VM a msg with msg->feature_chg.is_dirt_needed=0, so the VM
doesn't have to notify the host of the dirty rectangle; when the VM
Connection program runs again, the VM will receive a msg with
msg->feature_chg.is_dirt_needed=1.

Thanks,
-- Dexuan