Re: xenstored: EACCESS error accessing control/feature-balloon 1

[zithro <slack@xxxxxxxxx>]

Hi,

[ snipped for brevity, report summary:
XAPI daemon in domU tries to write to a non-existent xenstore node in a 
non-XAPI dom0 ]
On 12 Apr 2023 18:41, Yann Dirson wrote:
> Is there anything besides XAPI using this node, or the other data
> published by xe-daemon?
On my vanilla Xen (ie. non-XAPI), I have no node about "balloon"-ing in 
xenstore (either dom0 or domU nodes, but I'm not using ballooning in both).
> Maybe the original issue is just that there is no reason to have
> xe-guest-utilities installed in this setup?
That's what I thought as I'm not using XAPI, so maybe the problem should 
only be addressed to the truenas team ? I posted on their forum but got 
no answer.
I killed the 'xe-daemon' in both setups without loss of functionality.

My wild guess is that 'xe-daemon', 'xe-update-guest-attrs' and all 
'xenstore* commands' are leftovers from when Xen was working as a dom0 
under FreeBSD (why would a *domU* have them ?).

But Julien Grall went further by reacting to a suggestion by Yann Dirson 
(no snip here so you have the full patch details) :
On 12 Apr 2023 22:04, Julien Grall wrote:
>  From a brief look, this is very similar to the patch below that was 
> sent 3 years ago. I bet no-one ever tested the driver against libxl.
> commit 30a970906038
> Author: Vitaly Kuznetsov <vkuznets@xxxxxxxxxx>
> Date:   Tue Sep 4 13:39:29 2018 +0200
>
>      libxl: create control/sysrq xenstore node
>
>      'xl sysrq' command doesn't work with modern Linux guests with the 
> following
>      message in guest's log:
>
>       xen:manage: sysrq_handler: Error -13 writing sysrq in control/sysrq
>
>      xenstore trace confirms:
>
>       IN 0x24bd9a0 20180904 04:36:32 WRITE (control/sysrq )
>       OUT 0x24bd9a0 20180904 04:36:32 ERROR (EACCES )
>
>      The problem seems to be in the fact that we don't pre-create 
> control/sysrq
>      xenstore node and libxl_send_sysrq() doing libxl__xs_printf() 
> creates it as
>      read-only. As we want to allow guests to clean 'control/sysrq' 
> after the
>      requested action is performed, we need to make this node writable.
>
>      Signed-off-by: Vitaly Kuznetsov <vkuznets@xxxxxxxxxx>
>      Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>
>
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index 60676304e9b5..dcfde7787e2c 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -695,6 +695,9 @@ retry_transaction:
>                           GCSPRINTF("%s/control/feature-s4", dom_path),
>                           rwperm, ARRAY_SIZE(rwperm));
>       }
> +    libxl__xs_mknod(gc, t,
> +                    GCSPRINTF("%s/control/sysrq", dom_path),
> +                    rwperm, ARRAY_SIZE(rwperm));
>       libxl__xs_mknod(gc, t,
>                       GCSPRINTF("%s/device/suspend/event-channel", 
> dom_path),
>                       rwperm, ARRAY_SIZE(rwperm));
>
> > I suspect the best (/least bad) thing to do here is formally introduce
> > feature-ballon as a permitted node, and have the toolstack initialise it
> > to "" like we do with all other nodes, after which TrueNAS ought to be
> > able to set it successfully and not touch it a second time.
> +1. This would match how libxl already deal "feature-s3" & co.
So, I will file a bug against truenas anyways, but are you going to 
alter the xenstore/toolstack ?
In that case it may be good to tell them at the same time.

Thanks all,

Kind regards,

zithro/Cyril