[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] libxl: arm: Allow grant mappings for backends running on Dom0


  • To: Viresh Kumar <viresh.kumar@xxxxxxxxxx>
  • From: Anthony PERARD <anthony.perard@xxxxxxxxxx>
  • Date: Tue, 2 May 2023 15:44:50 +0100
  • Authentication-results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none
  • Cc: <xen-devel@xxxxxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Julien Grall <julien@xxxxxxx>, Vincent Guittot <vincent.guittot@xxxxxxxxxx>, <stratos-dev@xxxxxxxxxxxxxxxxxxx>, Alex Bennée <alex.bennee@xxxxxxxxxx>, Mathieu Poirier <mathieu.poirier@xxxxxxxxxx>, Oleksandr Tyshchenko <olekstysh@xxxxxxxxx>, Erik Schilling <erik.schilling@xxxxxxxxxx>
  • Delivery-date: Tue, 02 May 2023 14:45:26 +0000
  • Ironport-data: A9a23:/l7eVKNUtbzLopTvrR0cl8FynXyQoLVcMsEvi/4bfWQNrUomgz0Hx zMaXzyHbPiJZWekf4twOYm/9EJTvJfUmoJiSgto+SlhQUwRpJueD7x1DKtS0wC6dZSfER09v 63yTvGacajYm1eF/k/F3oDJ9CU6jufQAOKnUoYoAwgpLSd8UiAtlBl/rOAwh49skLCRDhiE/ Nj/uKUzAnf8s9JPGj9SuvPrRC9H5qyo42tF5gZmP5ingXeF/5UrJMNHTU2OByOQrrl8RoaSW +vFxbelyWLVlz9F5gSNy+uTnuUiG9Y+DCDW4pZkc/HKbitq/0Te5p0TJvsEAXq7vh3S9zxHJ HehgrTrIeshFvWkdO3wyHC0GQkmVUFN0OevzXRSLaV/ZqAJGpfh66wGMa04AWEX0rdJW01J0 e4VESpTdzSlmdqZh5C7V9A506zPLOGzVG8eknRpzDWfBvc6W5HTBa7N4Le03h9p2JoIR6yHI ZNEN3w2Nk+ojx5nYz/7DLo3mvuogX/uNSVVsluPqYI84nTJzRw327/oWDbQUoXSG54JwBvC/ goq+UzSPVZKL9yc8AC//yuzp7TBgg3VdZg7QejQGvlC3wTImz175ActfUW6u/Siigi9RtdWM WQQ+ywnt69081akJvHtUhv9rHOasxo0X9tLD/Z8+AyLjK3O7G6xBGceSSVaQMc7r8JwTjsvv neLgtfoCDpHoLCTD3WH+d+8szK0MiUTMSkNeC4YUQwZy93ipogpiVTIVNkLOLWplNTpHiq1z z2UhC8mwrESltIQkaG6+1ndhHSrvJehZgcx6xWRVG+j6A50TIqkYYWy7h7c9/koBIOQUlmAs WVCg8+f9uEDF7mJlSqEWuJLF7asj96CNDDfmkJ+BJkJ+DGk+nrldodViBlzPkZqdN0PeT7tZ E7VtitV5ZlaJnzsarV4C6q4E8kwxLLsPcjkXPvTKNFJZ/BMmBSvpX80IxTKhia0zRZqyPtkU XuGTSqyJSckU4hg6Ci7fv1DyJsN2BgRgkHTWKmumnxLzoGiiG6ppaYtaQXeNbhgtvPb/2054 P4EaZLUlkw3vPnWJ3COrNVNdQ1iwW0TX8ieliBBSgKUzuOK8kkFAuSZ/74ucpcNc099xraRp SHVtqO1JTPCaZz7xeaiMCoLhEvHB8oXkJ7CFXVE0ayU83Yie52zy6wUaoE6e7IqnMQ6k64uH qdaIp/YXKkQItgixwnxkLGn9NAyHPhVrVvm09WZjMgXIMc7Gl2hFi7MdQrz7igeZheKWT8Fi +T4jGvzGMNTLzmO+e6KMJpDOXvt5ylC8A+zNmOUSuRulLLEqtk2cXSv1qVofKnh63zrn1On6 upfOj9AzcGlnmP/2IKhaXysx2txL9ZDIw==
  • Ironport-hdrordr: A9a23:TdL6VaPfSjkpUMBcTjejsMiBIKoaSvp037BK7S1MoNJuEvBw9v re+sjzsCWftN9/Yh4dcLy7VpVoBEmsl6KdgrNhWotKPjOW21dARbsKheffKn/bakjDH4Zmvp uIGJIObOEYY2IasS77ijPIbOrJwrO8gd6VbTG19QYdceloAZsQnzuQEmygYzRLrJEtP+tFKH KbjPA33waISDAsQemQIGIKZOTHr82jruObXfZXbyRXkzVnlFmTmcTHLyQ=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Thu, Mar 30, 2023 at 02:13:08PM +0530, Viresh Kumar wrote:
> diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
> index 10f37990be57..4879f136aab8 100644
> --- a/docs/man/xl.cfg.5.pod.in
> +++ b/docs/man/xl.cfg.5.pod.in
> @@ -1616,6 +1616,10 @@ properties in the Device Tree, the type field must be 
> set to "virtio,device".
>  Specifies the transport mechanism for the Virtio device, only "mmio" is
>  supported for now.
>  
> +=item B<forced_grant=BOOLEAN>
> +
> +Allows Xen Grant memory mapping to be done from Dom0.

I think this description is missing context. I'm not sure what it would
means "from dom0" without reading the patch. Also, it says "allows",
maybe this doesn't convey the meaning of "forced". How about something
like:

    Always use grant mapping, even when the backend is run in dom0.
    (grant are already used if the backend is in another domain.)

> +
>  =back
>  
>  =item B<tee="STRING">
> diff --git a/tools/libs/light/libxl_virtio.c b/tools/libs/light/libxl_virtio.c
> index faada49e184e..e1f15344ef97 100644
> --- a/tools/libs/light/libxl_virtio.c
> +++ b/tools/libs/light/libxl_virtio.c
> @@ -48,11 +48,13 @@ static int libxl__set_xenstore_virtio(libxl__gc *gc, 
> uint32_t domid,
>      flexarray_append_pair(back, "base", GCSPRINTF("%#"PRIx64, virtio->base));
>      flexarray_append_pair(back, "type", GCSPRINTF("%s", virtio->type));
>      flexarray_append_pair(back, "transport", GCSPRINTF("%s", transport));
> +    flexarray_append_pair(back, "forced_grant", GCSPRINTF("%u", 
> virtio->forced_grant));
>  
>      flexarray_append_pair(front, "irq", GCSPRINTF("%u", virtio->irq));
>      flexarray_append_pair(front, "base", GCSPRINTF("%#"PRIx64, 
> virtio->base));
>      flexarray_append_pair(front, "type", GCSPRINTF("%s", virtio->type));
>      flexarray_append_pair(front, "transport", GCSPRINTF("%s", transport));
> +    flexarray_append_pair(front, "forced_grant", GCSPRINTF("%u", 
> virtio->forced_grant));

This "forced_grant" feels weird to me in the protocol, I feel like this
use of grant or not could be handled by the backend. For example in
"blkif" protocol, there's plenty of "feature-*" which allows both
front-end and back-end to advertise which feature they can or want to
use.
But maybe the fact that the device tree needs to be modified to be able
to accommodate grant mapping means that libxl needs to ask the backend to
use grant or not, and the frontend needs to now if it needs to use
grant.

>  
>      return 0;
>  }
> @@ -104,6 +106,15 @@ static int libxl__virtio_from_xenstore(libxl__gc *gc, 
> const char *libxl_path,
>          }
>      }
>  
> +    tmp = NULL;
> +    rc = libxl__xs_read_checked(gc, XBT_NULL,
> +                             GCSPRINTF("%s/forced_grant", be_path), &tmp);
> +    if (rc) goto out;
> +
> +    if (tmp) {
> +        virtio->forced_grant = strtoul(tmp, NULL, 0);
> +    }
> +
>      tmp = NULL;
>      rc = libxl__xs_read_checked(gc, XBT_NULL,
>                               GCSPRINTF("%s/type", be_path), &tmp);
> diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
> index 1f6f47daf4e1..3e34da099785 100644
> --- a/tools/xl/xl_parse.c
> +++ b/tools/xl/xl_parse.c
> @@ -1215,6 +1215,8 @@ static int parse_virtio_config(libxl_device_virtio 
> *virtio, char *token)
>      } else if (MATCH_OPTION("transport", token, oparg)) {
>          rc = libxl_virtio_transport_from_string(oparg, &virtio->transport);
>          if (rc) return rc;
> +    } else if (MATCH_OPTION("forced_grant", token, oparg)) {
> +        virtio->forced_grant = strtoul(oparg, NULL, 0);

Maybe store only !!strtoul() ?
I don't think having values other that 0 or 1 is going to be good.

>      } else {
>          fprintf(stderr, "Unknown string \"%s\" in virtio spec\n", token);
>          return -1;

Thanks,

-- 
Anthony PERARD



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.