From: Oleksandr <olekstysh@gmail.com>
To: Juergen Gross <jgross@suse.com>,
xen-devel@lists.xenproject.org, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org
Cc: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>,
David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>
Subject: Re: [PATCH v2 14/19] xen/drmfront: use xenbus_setup_ring() and xenbus_teardown_ring()
Date: Fri, 29 Apr 2022 19:10:03 +0300 [thread overview]
Message-ID: <e2e1f5c0-e78e-fa1e-bdee-54b5aeaba957@gmail.com> (raw)
In-Reply-To: <20220428082743.16593-15-jgross@suse.com>
On 28.04.22 11:27, Juergen Gross wrote:
Hello Juergen, all
> Simplify drmfront's ring creation and removal via xenbus_setup_ring()
> and xenbus_teardown_ring().
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
I am not familiar with DRM bits of this driver, but a little bit
familiar with Xen bits this patch only touches and I have environment to
test.
Xen specific changes looks good to me. Also I didn't see any specific to
this series issues when testing virtulized display driver except one I
have already pointed out in PATCH v2 08/19.
root@salvator-x-h3-4x2g-xt-domu:~# dmesg | grep drm
[ 0.158190] [drm] Registering XEN PV vdispl
[ 0.159620] [drm] Connector device/vdispl/0/0: resolution 1920x1080
[ 0.159888] [drm] Have 1 connector(s)
[ 0.289069] [drm] Creating Xen PV DRM Display Unit
[ 0.289873] [drm] Initialized xendrm-du 1.0.0 20180221 for vdispl-0
on minor 0
[ 0.289918] [drm] Initialized xendrm-du 1.0.0 20180221 on minor 0
root@generic-armv8-xt-dom0:~# xenstore-ls -f | grep vdispl
/local/domain/1/backend/vdispl = ""
/local/domain/1/backend/vdispl/2 = ""
/local/domain/1/backend/vdispl/2/0 = ""
/local/domain/1/backend/vdispl/2/0/frontend =
"/local/domain/2/device/vdispl/0"
/local/domain/1/backend/vdispl/2/0/frontend-id = "2"
/local/domain/1/backend/vdispl/2/0/online = "1"
/local/domain/1/backend/vdispl/2/0/state = "4"
/local/domain/2/device/vdispl = ""
/local/domain/2/device/vdispl/0 = ""
/local/domain/2/device/vdispl/0/backend =
"/local/domain/1/backend/vdispl/2/0"
/local/domain/2/device/vdispl/0/backend-id = "1"
/local/domain/2/device/vdispl/0/state = "4"
/local/domain/2/device/vdispl/0/be-alloc = "0"
/local/domain/2/device/vdispl/0/0 = ""
/local/domain/2/device/vdispl/0/0/resolution = "1920x1080"
/local/domain/2/device/vdispl/0/0/unique-id = "HDMI-A-1"
/local/domain/2/device/vdispl/0/0/req-ring-ref = "8"
/local/domain/2/device/vdispl/0/0/req-event-channel = "7"
/local/domain/2/device/vdispl/0/0/evt-ring-ref = "9"
/local/domain/2/device/vdispl/0/0/evt-event-channel = "8"
/libxl/2/device/vdispl = ""
/libxl/2/device/vdispl/0 = ""
/libxl/2/device/vdispl/0/frontend = "/local/domain/2/device/vdispl/0"
/libxl/2/device/vdispl/0/backend = "/local/domain/1/backend/vdispl/2/0"
/libxl/2/device/vdispl/0/frontend-id = "2"
/libxl/2/device/vdispl/0/online = "1"
/libxl/2/device/vdispl/0/state = "1"
It worth mentioning I noticed one issue, but I believe it is not related
to your series.
root@salvator-x-h3-4x2g-xt-domu:~# modetest -M xendrm-du -s 31:1920x1080
[ 62.431887] ------------[ cut here ]------------
[ 62.431940] WARNING: CPU: 0 PID: 244 at
drivers/gpu/drm/drm_gem.c:1055 drm_gem_mmap_obj+0x16c/0x180
[ 62.432000] Modules linked in:
[ 62.432025] CPU: 0 PID: 244 Comm: modetest Tainted: G W
5.18.0-rc4-yocto-standard-00096-g936342d8fae2 #1
[ 62.432067] Hardware name: XENVM-4.17 (DT)
[ 62.432089] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS
BTYPE=--)
[ 62.432126] pc : drm_gem_mmap_obj+0x16c/0x180
[ 62.432153] lr : drm_gem_mmap_obj+0x78/0x180
[ 62.432178] sp : ffff800009da3bb0
[ 62.432196] x29: ffff800009da3bb0 x28: 0000000000000008 x27:
ffff0001c3a56780
[ 62.432237] x26: ffff0001c3a56f00 x25: 00000000000007e9 x24:
ffff0001c23dec00
[ 62.432279] x23: ffff0001c0c98000 x22: ffff0001c2162b80 x21:
0000000000000000
[ 62.432320] x20: ffff0001c3a56780 x19: ffff0001c23dea00 x18:
0000000000000001
[ 62.432355] x17: 0000000000000000 x16: 0000000000000000 x15:
000000000003603c
[ 62.432394] x14: 0000000000000000 x13: 0000000000000000 x12:
0000000000000000
[ 62.432430] x11: 0000000000100000 x10: 0000ffff88071000 x9 :
ffff0001c0f17e70
[ 62.432470] x8 : ffff8001f65ce000 x7 : 0000000000000001 x6 :
ffff0001c388a000
[ 62.432505] x5 : ffff800009da3a10 x4 : 0000000000000090 x3 :
0000000010046400
[ 62.432539] x2 : 00000000000007e9 x1 : 9b0023a536f4f400 x0 :
00000000100000fb
[ 62.432579] Call trace:
[ 62.432593] drm_gem_mmap_obj+0x16c/0x180
[ 62.432617] drm_gem_mmap+0x128/0x228
[ 62.432641] mmap_region+0x384/0x5a0
[ 62.432667] do_mmap+0x354/0x4f0
[ 62.432687] vm_mmap_pgoff+0xdc/0x108
[ 62.432710] ksys_mmap_pgoff+0x1b8/0x208
[ 62.432734] __arm64_sys_mmap+0x30/0x48
[ 62.432760] invoke_syscall+0x44/0x108
[ 62.432783] el0_svc_common.constprop.0+0xcc/0xf0
[ 62.432811] do_el0_svc+0x24/0x88
[ 62.432831] el0_svc+0x2c/0x88
[ 62.432855] el0t_64_sync_handler+0xb0/0xb8
[ 62.432875] el0t_64_sync+0x18c/0x190
[ 62.432898] ---[ end trace 0000000000000000 ]---
setting mode 1920x1080-60.00Hz@XR24 on connectors 31, crtc 34
Although we see that WARNING, the application still works. Looking into
the code, I assume that problem is that frontend doesn't set the
VM_DONTEXPAND flag in mmap callback.
This diff fixes an issue in my environment:
index 5a5bf4e..e31554d 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_gem.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_gem.c
@@ -71,7 +71,7 @@ static int xen_drm_front_gem_object_mmap(struct
drm_gem_object *gem_obj,
* the whole buffer.
*/
vma->vm_flags &= ~VM_PFNMAP;
- vma->vm_flags |= VM_MIXEDMAP;
+ vma->vm_flags |= VM_MIXEDMAP | VM_DONTEXPAND;
vma->vm_pgoff = 0;
/*
I am not 100% sure whether it is a proper fix, so I would kindly ask DRM
folks to confirm. I will be able to send a formal patch then.
> ---
> drivers/gpu/drm/xen/xen_drm_front_evtchnl.c | 43 ++++++---------------
> 1 file changed, 11 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/gpu/drm/xen/xen_drm_front_evtchnl.c b/drivers/gpu/drm/xen/xen_drm_front_evtchnl.c
> index 4006568b9e32..e52afd792346 100644
> --- a/drivers/gpu/drm/xen/xen_drm_front_evtchnl.c
> +++ b/drivers/gpu/drm/xen/xen_drm_front_evtchnl.c
> @@ -123,12 +123,12 @@ static irqreturn_t evtchnl_interrupt_evt(int irq, void *dev_id)
> static void evtchnl_free(struct xen_drm_front_info *front_info,
> struct xen_drm_front_evtchnl *evtchnl)
> {
> - unsigned long page = 0;
> + void *page = NULL;
>
> if (evtchnl->type == EVTCHNL_TYPE_REQ)
> - page = (unsigned long)evtchnl->u.req.ring.sring;
> + page = evtchnl->u.req.ring.sring;
> else if (evtchnl->type == EVTCHNL_TYPE_EVT)
> - page = (unsigned long)evtchnl->u.evt.page;
> + page = evtchnl->u.evt.page;
> if (!page)
> return;
>
> @@ -147,8 +147,7 @@ static void evtchnl_free(struct xen_drm_front_info *front_info,
> xenbus_free_evtchn(front_info->xb_dev, evtchnl->port);
>
> /* end access and free the page */
> - if (evtchnl->gref != INVALID_GRANT_REF)
> - gnttab_end_foreign_access(evtchnl->gref, page);
> + xenbus_teardown_ring(&page, 1, &evtchnl->gref);
>
> memset(evtchnl, 0, sizeof(*evtchnl));
> }
> @@ -158,8 +157,7 @@ static int evtchnl_alloc(struct xen_drm_front_info *front_info, int index,
> enum xen_drm_front_evtchnl_type type)
> {
> struct xenbus_device *xb_dev = front_info->xb_dev;
> - unsigned long page;
> - grant_ref_t gref;
> + void *page;
> irq_handler_t handler;
> int ret;
>
> @@ -168,44 +166,25 @@ static int evtchnl_alloc(struct xen_drm_front_info *front_info, int index,
> evtchnl->index = index;
> evtchnl->front_info = front_info;
> evtchnl->state = EVTCHNL_STATE_DISCONNECTED;
> - evtchnl->gref = INVALID_GRANT_REF;
>
> - page = get_zeroed_page(GFP_NOIO | __GFP_HIGH);
> - if (!page) {
> - ret = -ENOMEM;
> + ret = xenbus_setup_ring(xb_dev, GFP_NOIO | __GFP_HIGH, &page,
> + 1, &evtchnl->gref);
> + if (ret)
> goto fail;
> - }
>
> if (type == EVTCHNL_TYPE_REQ) {
> struct xen_displif_sring *sring;
>
> init_completion(&evtchnl->u.req.completion);
> mutex_init(&evtchnl->u.req.req_io_lock);
> - sring = (struct xen_displif_sring *)page;
> - SHARED_RING_INIT(sring);
> - FRONT_RING_INIT(&evtchnl->u.req.ring, sring, XEN_PAGE_SIZE);
> -
> - ret = xenbus_grant_ring(xb_dev, sring, 1, &gref);
> - if (ret < 0) {
> - evtchnl->u.req.ring.sring = NULL;
> - free_page(page);
> - goto fail;
> - }
> + sring = page;
> + XEN_FRONT_RING_INIT(&evtchnl->u.req.ring, sring, XEN_PAGE_SIZE);
>
> handler = evtchnl_interrupt_ctrl;
> } else {
> - ret = gnttab_grant_foreign_access(xb_dev->otherend_id,
> - virt_to_gfn((void *)page), 0);
> - if (ret < 0) {
> - free_page(page);
> - goto fail;
> - }
> -
> - evtchnl->u.evt.page = (struct xendispl_event_page *)page;
> - gref = ret;
> + evtchnl->u.evt.page = page;
> handler = evtchnl_interrupt_evt;
> }
> - evtchnl->gref = gref;
>
> ret = xenbus_alloc_evtchn(xb_dev, &evtchnl->port);
> if (ret < 0)
--
Regards,
Oleksandr Tyshchenko
next prev parent reply other threads:[~2022-04-29 16:10 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-28 8:27 [PATCH v2 00/19] xen: simplify frontend side ring setup Juergen Gross
2022-04-28 8:27 ` [PATCH v2 01/19] xen/blkfront: switch blkfront to use INVALID_GRANT_REF Juergen Gross
2022-04-28 8:27 ` [PATCH v2 02/19] xen/netfront: switch netfront " Juergen Gross
2022-04-28 8:27 ` [PATCH v2 03/19] xen/scsifront: remove unused GRANT_INVALID_REF definition Juergen Gross
2022-04-28 8:27 ` [PATCH v2 04/19] xen/usb: switch xen-hcd to use INVALID_GRANT_REF Juergen Gross
2022-04-28 8:27 ` [PATCH v2 05/19] xen/drm: switch xen_drm_front " Juergen Gross
2022-04-28 8:27 ` [PATCH v2 06/19] xen/sound: switch xen_snd_front " Juergen Gross
2022-04-28 8:27 ` [PATCH v2 07/19] xen/dmabuf: switch gntdev-dmabuf " Juergen Gross
2022-04-28 8:27 ` [PATCH v2 08/19] xen/shbuf: switch xen-front-pgdir-shbuf " Juergen Gross
[not found] ` <CAPD2p-nisRgMOzy+w2jx5ULfZTyv4MqtG0wkV9jNn3wNg415sQ@mail.gmail.com>
2022-04-29 15:28 ` Oleksandr
2022-05-02 13:31 ` Juergen Gross
2022-05-02 13:52 ` Oleksandr
2022-05-02 13:28 ` Juergen Gross
2022-04-28 8:27 ` [PATCH v2 09/19] xen: update ring.h Juergen Gross
2022-04-28 8:27 ` [PATCH v2 10/19] xen/xenbus: add xenbus_setup_ring() service function Juergen Gross
2022-04-28 8:27 ` [PATCH v2 11/19] xen/blkfront: use xenbus_setup_ring() and xenbus_teardown_ring() Juergen Gross
2022-04-28 8:27 ` [PATCH v2 12/19] xen/netfront: " Juergen Gross
2022-04-28 8:27 ` [PATCH v2 13/19] xen/tpmfront: " Juergen Gross
2022-04-28 8:27 ` [PATCH v2 14/19] xen/drmfront: " Juergen Gross
2022-04-29 16:10 ` Oleksandr [this message]
2022-04-28 8:27 ` [PATCH v2 15/19] xen/pcifront: " Juergen Gross
2022-04-28 8:27 ` [PATCH v2 16/19] xen/scsifront: " Juergen Gross
2022-04-28 8:27 ` [PATCH v2 17/19] xen/usbfront: " Juergen Gross
2022-04-28 8:27 ` [PATCH v2 18/19] xen/sndfront: " Juergen Gross
2022-04-29 18:07 ` Oleksandr
2022-04-28 8:27 ` [PATCH v2 19/19] xen/xenbus: eliminate xenbus_grant_ring() Juergen Gross
2022-04-29 15:10 ` Oleksandr
2022-05-02 13:30 ` Juergen Gross
2022-05-02 14:12 ` Oleksandr
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=e2e1f5c0-e78e-fa1e-bdee-54b5aeaba957@gmail.com \
--to=olekstysh@gmail.com \
--cc=airlied@linux.ie \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=jgross@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleksandr_andrushchenko@epam.com \
--cc=xen-devel@lists.xenproject.org \
/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