All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleksandr <olekstysh@gmail.com>
To: Juergen Gross <jgross@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v2 08/19] xen/shbuf: switch xen-front-pgdir-shbuf to use INVALID_GRANT_REF
Date: Fri, 29 Apr 2022 18:28:34 +0300	[thread overview]
Message-ID: <b05fe983-8f9e-da3d-1bf0-e121ba969ae3@gmail.com> (raw)
In-Reply-To: <CAPD2p-nisRgMOzy+w2jx5ULfZTyv4MqtG0wkV9jNn3wNg415sQ@mail.gmail.com>


Hello Juergen


On 28.04.22 21:03, Oleksandr Tyshchenko wrote:
>
>
> On Thu, Apr 28, 2022 at 11:28 AM Juergen Gross <jgross@suse.com 
> <mailto:jgross@suse.com>> wrote:
>
> Hello Juergen
>
> [sorry for the possible format issue]
>
>     Instead of using a private macro for an invalid grant reference use
>     the common one.
>
>     Signed-off-by: Juergen Gross <jgross@suse.com
>     <mailto:jgross@suse.com>>
>     ---
>      drivers/xen/xen-front-pgdir-shbuf.c | 17 ++++-------------
>      1 file changed, 4 insertions(+), 13 deletions(-)
>
>     diff --git a/drivers/xen/xen-front-pgdir-shbuf.c
>     b/drivers/xen/xen-front-pgdir-shbuf.c
>     index a959dee21134..fa2921d4fbfc 100644
>     --- a/drivers/xen/xen-front-pgdir-shbuf.c
>     +++ b/drivers/xen/xen-front-pgdir-shbuf.c
>     @@ -21,15 +21,6 @@
>
>      #include <xen/xen-front-pgdir-shbuf.h>
>
>     -#ifndef GRANT_INVALID_REF
>     -/*
>     - * FIXME: usage of grant reference 0 as invalid grant reference:
>     - * grant reference 0 is valid, but never exposed to a PV driver,
>     - * because of the fact it is already in use/reserved by the PV
>     console.
>     - */
>     -#define GRANT_INVALID_REF      0
>     -#endif
>     -
>      /**
>       * This structure represents the structure of a shared page
>       * that contains grant references to the pages of the shared
>     @@ -83,7 +74,7 @@ grant_ref_t
>      xen_front_pgdir_shbuf_get_dir_start(struct xen_front_pgdir_shbuf
>     *buf)
>      {
>             if (!buf->grefs)
>     -               return GRANT_INVALID_REF;
>     +               return INVALID_GRANT_REF;
>
>             return buf->grefs[0];
>      }
>     @@ -142,7 +133,7 @@ void xen_front_pgdir_shbuf_free(struct
>     xen_front_pgdir_shbuf *buf)
>                     int i;
>
>                     for (i = 0; i < buf->num_grefs; i++)
>     -                       if (buf->grefs[i] != GRANT_INVALID_REF)
>     +                       if (buf->grefs[i] != INVALID_GRANT_REF)
>     gnttab_end_foreign_access(buf->grefs[i], 0UL);
>             }
>             kfree(buf->grefs);
>     @@ -355,7 +346,7 @@ static void backend_fill_page_dir(struct
>     xen_front_pgdir_shbuf *buf)
>             }
>             /* Last page must say there is no more pages. */
>             page_dir = (struct xen_page_directory *)ptr;
>     -       page_dir->gref_dir_next_page = GRANT_INVALID_REF;
>     +       page_dir->gref_dir_next_page = INVALID_GRANT_REF;
>      }
>
>      /**
>     @@ -384,7 +375,7 @@ static void guest_fill_page_dir(struct
>     xen_front_pgdir_shbuf *buf)
>
>                     if (grefs_left <= XEN_NUM_GREFS_PER_PAGE) {
>                             to_copy = grefs_left;
>     -                       page_dir->gref_dir_next_page =
>     GRANT_INVALID_REF;
>     +                       page_dir->gref_dir_next_page =
>     INVALID_GRANT_REF;
>
>
> I faced an issue with testing PV Sound with the current series.
>
> root@salvator-x-h3-4x2g-xt-domu:~# aplay /media/MoodyLoop.wav
> Playing WAVE '/media/MoodyLoop.wav' : Signed 16 bit Little Endian, 
> Rate 44100 Hz, Stereo
> (XEN) common/grant_table.c:1053:d1v2 Bad ref 0xffffffff for d6
>
> Here we have an interesting situation. PV Sound frontend uses this 
> xen-front-pgdir-shbuf framework. Technically, this patch changes 
> page_dir->gref_dir_next_page (reference to the next page describing 
> page directory) from 0 to 0xffffffff here.
> #define INVALID_GRANT_REF  ((grant_ref_t)-1)
>
> But according to the protocol (sndif.h), "0" means that there are no 
> more pages in the list and the user space backend expects only that 
> value. So receiving 0xffffffff it assumes there are pages in the list 
> and trying to process...
> https://elixir.bootlin.com/linux/v5.18-rc4/source/include/xen/interface/io/sndif.h#L650
>
>
> I think, the same is relevant to backend_fill_page_dir() as well.


In addition to what I said yesterday:

PV Display also uses this xen-front-pgdir-shbuf framework. It's protocol 
(displif.h) also mentions the same as sndif.h if the context of 
gref_dir_next_page:

  * gref_dir_next_page - grant_ref_t, reference to the next page describing
  *   page directory. Must be 0 if there are no more pages in the list.


With that local change both PV devices work in my environment.

diff --git a/drivers/xen/xen-front-pgdir-shbuf.c 
b/drivers/xen/xen-front-pgdir-shbuf.c
index fa2921d..ad4a88e 100644
--- a/drivers/xen/xen-front-pgdir-shbuf.c
+++ b/drivers/xen/xen-front-pgdir-shbuf.c
@@ -346,7 +346,7 @@ static void backend_fill_page_dir(struct 
xen_front_pgdir_shbuf *buf)
         }
         /* Last page must say there is no more pages. */
         page_dir = (struct xen_page_directory *)ptr;
-       page_dir->gref_dir_next_page = INVALID_GRANT_REF;
+       page_dir->gref_dir_next_page = 0;
  }

  /**
@@ -375,7 +375,7 @@ static void guest_fill_page_dir(struct 
xen_front_pgdir_shbuf *buf)

                 if (grefs_left <= XEN_NUM_GREFS_PER_PAGE) {
                         to_copy = grefs_left;
-                       page_dir->gref_dir_next_page = INVALID_GRANT_REF;
+                       page_dir->gref_dir_next_page = 0;
                 } else {
                         to_copy = XEN_NUM_GREFS_PER_PAGE;
                         page_dir->gref_dir_next_page = buf->grefs[i + 1];
(END)



>
>                     } else {
>                             to_copy = XEN_NUM_GREFS_PER_PAGE;
>                             page_dir->gref_dir_next_page =
>     buf->grefs[i + 1];
>     -- 
>     2.34.1
>
>
>
>
> -- 
> Regards,
>
> Oleksandr Tyshchenko

-- 
Regards,

Oleksandr Tyshchenko



  reply	other threads:[~2022-04-29 15:29 UTC|newest]

Thread overview: 36+ 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 ` 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   ` Juergen Gross
2022-04-28  8:27 ` [PATCH v2 06/19] xen/sound: switch xen_snd_front " Juergen Gross
2022-04-28  8:27   ` 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
2022-04-28 18:03   ` Oleksandr Tyshchenko
2022-04-29 15:28     ` Oleksandr [this message]
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-28  8:27   ` Juergen Gross
2022-04-29 16:10   ` Oleksandr
2022-04-29 16:10     ` Oleksandr
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-28  8:27   ` 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=b05fe983-8f9e-da3d-1bf0-e121ba969ae3@gmail.com \
    --to=olekstysh@gmail.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=jgross@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sstabellini@kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.