[PATCH 0/3] Mini-OS: preparations for 9pfs in xenstore-stubdom

[PATCH 0/3] Mini-OS: preparations for 9pfs in xenstore-stubdom

[Juergen Gross]

This small patch series is doing some preparations for being able to
use 9pfs in Xenstore-stubdom.

Juergen Gross (3):
  Mini-OS: make xenstore_buf externally visible
  Mini-OS: don't crash if no shutdown node is available
  Mini-OS: fix 9pfs stat receive format

 9pfront.c        |  9 +++++----
 include/xenbus.h |  2 ++
 shutdown.c       | 12 ++++--------
 xenbus.c         |  2 +-
 4 files changed, 12 insertions(+), 13 deletions(-)

-- 
2.35.3

[PATCH 1/3] Mini-OS: make xenstore_buf externally visible

[Juergen Gross]

For support of the 9pfs frontend in Xenstore-stubdom xenstore_buf
needs to be externally visible.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 include/xenbus.h | 2 ++
 xenbus.c         | 2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/xenbus.h b/include/xenbus.h
index c0fc0ac5..542ee456 100644
--- a/include/xenbus.h
+++ b/include/xenbus.h
@@ -8,12 +8,14 @@ typedef unsigned long xenbus_transaction_t;
 
 #ifdef CONFIG_XENBUS
 extern uint32_t xenbus_evtchn;
+extern struct xenstore_domain_interface *xenstore_buf;
 
 /* Initialize the XenBus system. */
 void init_xenbus(void);
 void get_xenbus(void *p);
 #else
 #define xenbus_evtchn ~0
+#define xenstore_buf NULL
 
 static inline void init_xenbus(void)
 {
diff --git a/xenbus.c b/xenbus.c
index 923e8181..8bfd5bd4 100644
--- a/xenbus.c
+++ b/xenbus.c
@@ -44,7 +44,7 @@
 #define DEBUG(_f, _a...)    ((void)0)
 #endif
 
-static struct xenstore_domain_interface *xenstore_buf;
+struct xenstore_domain_interface *xenstore_buf;
 static DECLARE_WAIT_QUEUE_HEAD(xb_waitq);
 DECLARE_WAIT_QUEUE_HEAD(xenbus_watch_queue);
 static __DECLARE_SEMAPHORE_GENERIC(xb_write_sem, 1);
-- 
2.35.3

Re: [PATCH 1/3] Mini-OS: make xenstore_buf externally visible

[Jason Andryuk]

On Wed, Nov 1, 2023 at 6:13 AM Juergen Gross <jgross@suse.com> wrote:
>
> For support of the 9pfs frontend in Xenstore-stubdom xenstore_buf
> needs to be externally visible.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>

xenstore_buf will be used by the xen.git patch "[PATCH 24/29]
tools/xenstored: map stubdom interface".

Reviewed-by: Jason Andryuk <jandryuk@gmail.com>

Thanks,
Jason

[PATCH 2/3] Mini-OS: don't crash if no shutdown node is available

[Juergen Gross]

It might be perfectly fine not to have a control/shutdown Xenstore
node. If this is the case, don't crash, but just terminate the
shutdown thread after issuing a message that shutdown isn't available.

In fini_shutdown() clearing the watch can result in an error now, in
case the early exit above was taken. Just ignore this error now.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 shutdown.c | 12 ++++--------
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/shutdown.c b/shutdown.c
index bb2c6f11..ded6b64d 100644
--- a/shutdown.c
+++ b/shutdown.c
@@ -75,7 +75,9 @@ static void shutdown_thread(void *p)
         xenbus_wait_for_watch(&events);
         if ((err = xenbus_read(XBT_NIL, path, &shutdown))) {
             free(err);
-            do_exit();
+            free(xenbus_unwatch_path_token(XBT_NIL, path, token));
+            printk("Shutdown Xenstore node not available.\n");
+            return;
         }
 
         if (end_shutdown_thread)
@@ -117,15 +119,9 @@ void init_shutdown(void)
 
 void fini_shutdown(void)
 {
-    char *err;
-
     end_shutdown_thread = 1;
     xenbus_release_wait_for_watch(&events);
-    err = xenbus_unwatch_path_token(XBT_NIL, path, token);
-    if (err) {
-        free(err);
-        do_exit();
-    }
+    free(xenbus_unwatch_path_token(XBT_NIL, path, token));
 }
 #endif
 
-- 
2.35.3

Re: [PATCH 2/3] Mini-OS: don't crash if no shutdown node is available

[Jason Andryuk]

On Wed, Nov 1, 2023 at 5:06 AM Juergen Gross <jgross@suse.com> wrote:
>
> It might be perfectly fine not to have a control/shutdown Xenstore
> node. If this is the case, don't crash, but just terminate the
> shutdown thread after issuing a message that shutdown isn't available.
>
> In fini_shutdown() clearing the watch can result in an error now, in
> case the early exit above was taken. Just ignore this error now.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>

Reviewed-by: Jason Andryuk <jandryuk@gmail.com>

Re: [PATCH 2/3] Mini-OS: don't crash if no shutdown node is available

[Andrew Cooper]

On 01/11/2023 9:00 am, Juergen Gross wrote:
> It might be perfectly fine not to have a control/shutdown Xenstore
> node. If this is the case, don't crash, but just terminate the
> shutdown thread after issuing a message that shutdown isn't available.
>
> In fini_shutdown() clearing the watch can result in an error now, in
> case the early exit above was taken. Just ignore this error now.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>

Which cases might we not have a control/shutdown node?

I'm all for coping better with its absence, but it's not a piece of the
Xen ABI which is optional.

And on that front, not crashing is good, but why remove the watch?  What
if it comes into existence later?  Is there any problem with just
leaving the watch outstanding?

~Andrew

Re: [PATCH 2/3] Mini-OS: don't crash if no shutdown node is available

[Juergen Gross]

[-- Attachment #1.1.1: Type: text/plain, Size: 1092 bytes --]

On 01.11.23 17:38, Andrew Cooper wrote:
> On 01/11/2023 9:00 am, Juergen Gross wrote:
>> It might be perfectly fine not to have a control/shutdown Xenstore
>> node. If this is the case, don't crash, but just terminate the
>> shutdown thread after issuing a message that shutdown isn't available.
>>
>> In fini_shutdown() clearing the watch can result in an error now, in
>> case the early exit above was taken. Just ignore this error now.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
> 
> Which cases might we not have a control/shutdown node?

Xenstore-stubdom. It should _never_ shutdown, and it isn't really under
control of Xen tools (other than being created).

> I'm all for coping better with its absence, but it's not a piece of the
> Xen ABI which is optional.

I'd like to differ here. See reasoning above.

> And on that front, not crashing is good, but why remove the watch?  What
> if it comes into existence later?  Is there any problem with just
> leaving the watch outstanding?

A needless waste of memory in Xenstore-stubdom.


Juergen

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3149 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [PATCH 2/3] Mini-OS: don't crash if no shutdown node is available

[Andrew Cooper]

On 01/11/2023 4:42 pm, Juergen Gross wrote:
> On 01.11.23 17:38, Andrew Cooper wrote:
>> On 01/11/2023 9:00 am, Juergen Gross wrote:
>>> It might be perfectly fine not to have a control/shutdown Xenstore
>>> node. If this is the case, don't crash, but just terminate the
>>> shutdown thread after issuing a message that shutdown isn't available.
>>>
>>> In fini_shutdown() clearing the watch can result in an error now, in
>>> case the early exit above was taken. Just ignore this error now.
>>>
>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>
>> Which cases might we not have a control/shutdown node?
>
> Xenstore-stubdom. It should _never_ shutdown, and it isn't really under
> control of Xen tools (other than being created).
>
>> I'm all for coping better with its absence, but it's not a piece of the
>> Xen ABI which is optional.
>
> I'd like to differ here. See reasoning above.

If we're going to permit this configuration, then I think it needs an
extension to xenstore-paths to make it officially optional.

And I think it's reasonable to support, but I wouldn't go as far as
saying "never".  If you've cleaved the global xenstored in
twain/trine/etc, then individual parts of it can shut down normally.

~Andrew

Re: [PATCH 2/3] Mini-OS: don't crash if no shutdown node is available

[Juergen Gross]

[-- Attachment #1.1.1: Type: text/plain, Size: 1998 bytes --]

On 01.11.23 17:57, Andrew Cooper wrote:
> On 01/11/2023 4:42 pm, Juergen Gross wrote:
>> On 01.11.23 17:38, Andrew Cooper wrote:
>>> On 01/11/2023 9:00 am, Juergen Gross wrote:
>>>> It might be perfectly fine not to have a control/shutdown Xenstore
>>>> node. If this is the case, don't crash, but just terminate the
>>>> shutdown thread after issuing a message that shutdown isn't available.
>>>>
>>>> In fini_shutdown() clearing the watch can result in an error now, in
>>>> case the early exit above was taken. Just ignore this error now.
>>>>
>>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>>
>>> Which cases might we not have a control/shutdown node?
>>
>> Xenstore-stubdom. It should _never_ shutdown, and it isn't really under
>> control of Xen tools (other than being created).
>>
>>> I'm all for coping better with its absence, but it's not a piece of the
>>> Xen ABI which is optional.
>>
>> I'd like to differ here. See reasoning above.
> 
> If we're going to permit this configuration, then I think it needs an
> extension to xenstore-paths to make it officially optional.
> 
> And I think it's reasonable to support, but I wouldn't go as far as
> saying "never".  If you've cleaved the global xenstored in
> twain/trine/etc, then individual parts of it can shut down normally.

Xenstore-stubdom is a very special case. I don't think its shutdown node
can be under control of the normal Xen tools, as only the stubdom can know
whether it is able to react in any sensible way to it. It needs to take
specific measures to ensure that even its ABI-compliant reaction to a
shutdown request is visible to Xen tools (remember that this reaction is
a write to the shutdown node causing a watch event in dom0, which won't
work with Xenstore going down).

In the end there is no way the shutdown node can be present when starting
Xenstore-stubdom. There is no Xenstore at the time the node is probed in
today's Mini-OS boot sequence.


Juergen

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3149 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

[PATCH 3/3] Mini-OS: fix 9pfs stat receive format

[Juergen Gross]

The format string of the received data for the 9pfs stat command is
missing the initial 2 byte total length specifier. Add it.

Fixes: 2d1dfccd3aa3 ("Mini-OS: add read and write support to 9pfsfront")
Signed-off-by: Juergen Gross <jgross@suse.com>
---
 9pfront.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/9pfront.c b/9pfront.c
index 5da8a365..43c7409f 100644
--- a/9pfront.c
+++ b/9pfront.c
@@ -711,6 +711,7 @@ static int p9_create(struct dev_9pfs *dev, uint32_t fid, char *path,
 static int p9_stat(struct dev_9pfs *dev, uint32_t fid, struct p9_stat *stat)
 {
     struct req *req = get_free_req(dev);
+    uint16_t total;
     int ret;
 
     if ( !req )
@@ -719,10 +720,10 @@ static int p9_stat(struct dev_9pfs *dev, uint32_t fid, struct p9_stat *stat)
     memset(stat, 0, sizeof(*stat));
     req->cmd = P9_CMD_STAT;
     send_9p(dev, req, "U", fid);
-    rcv_9p(dev, req, "uuUQUUULSSSSSUUU", &stat->size, &stat->type, &stat->dev,
-           stat->qid, &stat->mode, &stat->atime, &stat->mtime, &stat->length,
-           &stat->name, &stat->uid, &stat->gid, &stat->muid, &stat->extension,
-           &stat->n_uid, &stat->n_gid, &stat->n_muid);
+    rcv_9p(dev, req, "uuuUQUUULSSSSSUUU", &total, &stat->size, &stat->type,
+           &stat->dev, stat->qid, &stat->mode, &stat->atime, &stat->mtime,
+           &stat->length, &stat->name, &stat->uid, &stat->gid, &stat->muid,
+           &stat->extension, &stat->n_uid, &stat->n_gid, &stat->n_muid);
 
     ret = req->result;
 
-- 
2.35.3

Re: [PATCH 3/3] Mini-OS: fix 9pfs stat receive format

[Jason Andryuk]

On Wed, Nov 1, 2023 at 5:14 AM Juergen Gross <jgross@suse.com> wrote:
>
> The format string of the received data for the 9pfs stat command is
> missing the initial 2 byte total length specifier. Add it.
>
> Fixes: 2d1dfccd3aa3 ("Mini-OS: add read and write support to 9pfsfront")
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
>  9pfront.c | 9 +++++----
>  1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/9pfront.c b/9pfront.c
> index 5da8a365..43c7409f 100644
> --- a/9pfront.c
> +++ b/9pfront.c
> @@ -711,6 +711,7 @@ static int p9_create(struct dev_9pfs *dev, uint32_t fid, char *path,
>  static int p9_stat(struct dev_9pfs *dev, uint32_t fid, struct p9_stat *stat)
>  {
>      struct req *req = get_free_req(dev);
> +    uint16_t total;
>      int ret;
>
>      if ( !req )
> @@ -719,10 +720,10 @@ static int p9_stat(struct dev_9pfs *dev, uint32_t fid, struct p9_stat *stat)
>      memset(stat, 0, sizeof(*stat));
>      req->cmd = P9_CMD_STAT;
>      send_9p(dev, req, "U", fid);
> -    rcv_9p(dev, req, "uuUQUUULSSSSSUUU", &stat->size, &stat->type, &stat->dev,
> -           stat->qid, &stat->mode, &stat->atime, &stat->mtime, &stat->length,
> -           &stat->name, &stat->uid, &stat->gid, &stat->muid, &stat->extension,
> -           &stat->n_uid, &stat->n_gid, &stat->n_muid);
> +    rcv_9p(dev, req, "uuuUQUUULSSSSSUUU", &total, &stat->size, &stat->type,
> +           &stat->dev, stat->qid, &stat->mode, &stat->atime, &stat->mtime,
> +           &stat->length, &stat->name, &stat->uid, &stat->gid, &stat->muid,
> +           &stat->extension, &stat->n_uid, &stat->n_gid, &stat->n_muid);

total is unused by the linux frontend end as well.  Looks like QEMU
hard codes the value as 0.

Reviewed-by: Jason Andryuk <jandryuk@gmail.com>

Thanks,
Jason