Re: [PATCH 20/29] tools: add 9pfs device to xenstore-stubdom

[Jason Andryuk <jandryuk@xxxxxxxxx>]

On Wed, Nov 1, 2023 at 8:23 AM Juergen Gross <jgross@xxxxxxxx> wrote:
>
> Add a 9pfs device to Xenstore stubdom in order to allow it to do e.g.
> logging into a dom0 file.
>
> Use the following parameters for the new device:
>
> - tag = "xen"
> - type = "xenlogd"
> - path = "/var/lib/xen/xenstore"
>
> For now don't limit allowed file space or number of files.
>
> Add a new libxl function for adding it similar to the function for
> adding the console device.
>
> Signed-off-by: Juergen Gross <jgross@xxxxxxxx>

> diff --git a/tools/libs/light/libxl_9pfs.c b/tools/libs/light/libxl_9pfs.c
> index 0b9d84dce9..3297389493 100644
> --- a/tools/libs/light/libxl_9pfs.c
> +++ b/tools/libs/light/libxl_9pfs.c
> @@ -174,6 +174,35 @@ static void libxl__device_p9_add(libxl__egc *egc, 
> uint32_t domid,
>          aodev->callback(egc, aodev);
>  }
>
> +int libxl_p9_add_xenstore(libxl_ctx *ctx, uint32_t domid, uint32_t backend,
> +                          libxl_p9_type type, char *tag, char *path,
> +                          unsigned int max_space, unsigned int max_files,
> +                          unsigned int max_open_files, bool auto_delete,
> +                          const libxl_asyncop_how *ao_how)
> +{
> +    AO_CREATE(ctx, domid, ao_how);
> +    libxl__ao_device *aodev;
> +    libxl_device_p9 p9 = { .backend_domid = backend,
> +                           .tag = tag,
> +                           .path = path,
> +                           .security_model = "none",

While the xl.cfg man page states that only security_model="none" is
supported, it is possible to use other ones.    The value isn't
inspected and it is just passed through Xenstore to QEMU.  QEMU can
then operate however it operates.  I just tested mapped-xattr and it's
working from some quick testing.  So maybe libxl_p9_add_xenstore()
should take security_model as an argument, and then
init-xenstore-domain can pass in "none"?

Everything else looks good, so either way:
Reviewed-by: Jason Andryuk <jandryuk@xxxxxxxxx>