linux-hyperv.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Deepak Rawat <drawat.floss@gmail.com>
To: Thomas Zimmermann <tzimmermann@suse.de>,
	linux-hyperv@vger.kernel.org, dri-devel@lists.freedesktop.org
Cc: Daniel Vetter <daniel@ffwll.ch>,
	Gerd Hoffmann <kraxel@redhat.com>,
	Sam Ravnborg <sam@ravnborg.org>, Dexuan Cui <decui@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	Wei Hu <weh@microsoft.com>,
	Tang Shaofeng <shaofeng.tang@intel.com>,
	Michael Kelley <mikelley@microsoft.com>
Subject: Re: [PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device
Date: Mon, 04 Jan 2021 18:27:24 -0800	[thread overview]
Message-ID: <4f7818f99734c0912325e1f3b6b80cb2a04df3ef.camel@gmail.com> (raw)
In-Reply-To: <2b49fcd2-38f7-dae5-2992-721a8bd142a2@suse.de>

On Mon, 2021-01-04 at 14:03 +0100, Thomas Zimmermann wrote:
> Hi,
> 
> I've been looking forward to this patchset. :) The code is really
> nice 
> already.

Thanks Thomas for the review.


> >   
> > +config DRM_HYPERV
> > +       tristate "DRM Support for hyperv synthetic video device"
> > +       depends on DRM && PCI && MMU && HYPERV
> > +       select DRM_KMS_HELPER
> > +       select DRM_GEM_SHMEM_HELPER
> 
> SHMEM helpers might not be a good choice, because you need this blit 
> code, which has a memcpy.
> 
> I guess it's easily possible to configure 16 MiB or more for the
> guest's 
> VRAM? If so, I suggest to use VRAM helpers. Guests will be able to 
> render into VRAM directly with the driver's memcpy. The driver will
> do 
> page flipping. The bochs driver would be an example.
> 
> Hyperv doesn't need buffer sharing with other devices, I guess?
> 

It's not possible to do page flip with this virtual device. The call to
SYNTHVID_VRAM_LOCATION is only honoured once. So unfortunately need to
use SHMEM helpers.

> > +#define PCI_VENDOR_ID_MICROSOFT 0x1414
> > +#define PCI_DEVICE_ID_HYPERV_VIDEO 0x5353
> > +
> > +struct hyperv_device {
> 
> Could this name lead to conflicts with other hyperv drivers? I
> suggest 
> to name it hyperv_drm_device.
> 
> 

Sure make sense to use hyperv_drm_device.

> > 
> > +
> > +struct synthvid_pointer_shape {
> 
> Do you have plans for adding cursor support?
> 

Yes I have tested with a prototype and cursor works. Will attempt this
in future iteration.

> > +
> > +       /* Negotiate the protocol version with host */
> > +       switch (vmbus_proto_version) {
> > +       case VERSION_WIN10:
> > +       case VERSION_WIN10_V5:
> > +               ret = synthvid_negotiate_ver(hdev,
> > SYNTHVID_VERSION_WIN10);
> > +               if (!ret)
> > +                       break;
> > +               fallthrough;
> > +       case VERSION_WIN8:
> > +       case VERSION_WIN8_1:
> > +               ret = synthvid_negotiate_ver(hdev,
> > SYNTHVID_VERSION_WIN8);
> > +               if (!ret)
> > +                       break;
> > +               fallthrough;
> > +       case VERSION_WS2008:
> > +       case VERSION_WIN7:
> > +               ret = synthvid_negotiate_ver(hdev,
> > SYNTHVID_VERSION_WIN7);
> > +               break;
> > +       default:
> > +               ret = synthvid_negotiate_ver(hdev,
> > SYNTHVID_VERSION_WIN10);
> 
> I don't get the logic of this switch statement. If the host is Win10,
> I'd expect the graphics device to use Win10's protocol, if the host
> is 
> Win8, the graphics device uses win8 protocols. So what's the point of
> the fallthroughs? Can there be newer versions of vmbus_proto_version 
> that only support older devices?
> 
> 

This is copied as it is from hyperv_fb driver. I suppose this is just
to accomodate newer version.
> 

Deepak


  reply	other threads:[~2021-01-05  2:28 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-02  6:03 [PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device Deepak Rawat
2021-01-02  6:03 ` [PATCH 2/2] MAINTAINERS: Add maintainer for hyperv " Deepak Rawat
2021-01-04 13:03 ` [PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic " Thomas Zimmermann
2021-01-05  2:27   ` Deepak Rawat [this message]
2021-01-05  8:07     ` Thomas Zimmermann
2021-01-05 11:04       ` Gerd Hoffmann
2021-01-05 11:30         ` Thomas Zimmermann
2021-01-06  4:01           ` Deepak Rawat
2023-04-04 13:20 ` Daniel Vetter
2023-04-04 16:07   ` Dexuan Cui

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4f7818f99734c0912325e1f3b6b80cb2a04df3ef.camel@gmail.com \
    --to=drawat.floss@gmail.com \
    --cc=daniel@ffwll.ch \
    --cc=decui@microsoft.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=haiyangz@microsoft.com \
    --cc=kraxel@redhat.com \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=mikelley@microsoft.com \
    --cc=sam@ravnborg.org \
    --cc=shaofeng.tang@intel.com \
    --cc=tzimmermann@suse.de \
    --cc=weh@microsoft.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).