[Xen-devel] [PATCH 0/3] tools/xenstore

[Xen-devel] [PATCH 0/3] tools/xenstore

[Juergen Gross]

Some patches for Xenstore-stubdom which have been lying around in my
local tree for some time now.

Juergen Gross (3):
  xenstore: setup xenstore stubdom console interface properly
  xenstore: add console xenstore entries for xenstore stubdom
  xenstore: remove not applicable control commands in stubdom

 tools/helpers/init-xenstore-domain.c | 44 +++++++++++++++++++++++++++++++++++-
 tools/xenstore/xenstored_control.c   | 18 +++++++++++++++
 2 files changed, 61 insertions(+), 1 deletion(-)

-- 
2.16.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 1/3] xenstore: setup xenstore stubdom console interface properly

[Juergen Gross]

In order to be able to get access to the console of Xenstore stubdom
we need an appropriate granttab entry. So call xc_dom_gnttab_init()
when constructing the domain and preset some information needed
for that function in the dom structure.

We need to create the event channel for the console, too. Do that and
store all necessary data locally.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 tools/helpers/init-xenstore-domain.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/tools/helpers/init-xenstore-domain.c b/tools/helpers/init-xenstore-domain.c
index adb8408b63..a312bc38b8 100644
--- a/tools/helpers/init-xenstore-domain.c
+++ b/tools/helpers/init-xenstore-domain.c
@@ -24,6 +24,8 @@ static char *param;
 static char *name = "Xenstore";
 static int memory;
 static int maxmem;
+static xen_pfn_t console_mfn;
+static unsigned int console_evtchn;
 
 static struct option options[] = {
     { "kernel", 1, NULL, 'k' },
@@ -113,6 +115,7 @@ static int build(xc_interface *xch)
         fprintf(stderr, "xc_domain_setmaxmem failed\n");
         goto err;
     }
+    console_evtchn = xc_evtchn_alloc_unbound(xch, domid, 0);
     rv = xc_domain_set_memmap_limit(xch, domid, limit_kb);
     if ( rv )
     {
@@ -133,6 +136,9 @@ static int build(xc_interface *xch)
         snprintf(cmdline, 512, "--event %d --internal-db", rv);
 
     dom = xc_dom_allocate(xch, cmdline, NULL);
+    dom->container_type = XC_DOM_PV_CONTAINER;
+    dom->xenstore_domid = domid;
+    dom->console_evtchn = console_evtchn;
     rv = xc_dom_kernel_file(dom, kernel);
     if ( rv )
     {
@@ -186,6 +192,12 @@ static int build(xc_interface *xch)
         fprintf(stderr, "xc_dom_boot_image failed\n");
         goto err;
     }
+    rv = xc_dom_gnttab_init(dom);
+    if ( rv )
+    {
+        fprintf(stderr, "xc_dom_gnttab_init failed\n");
+        goto err;
+    }
 
     rv = xc_domain_set_virq_handler(xch, domid, VIRQ_DOM_EXC);
     if ( rv )
@@ -201,6 +213,7 @@ static int build(xc_interface *xch)
     }
 
     rv = 0;
+    console_mfn = xc_dom_p2m(dom, dom->console_pfn);
 
 err:
     if ( dom )
-- 
2.16.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 2/3] xenstore: add console xenstore entries for xenstore stubdom

[Juergen Gross]

In order to be able to connect to the console of Xenstore stubdom we
need to create the appropriate entries in Xenstore.

For the moment we don't support xenconsoled living in another domain
than dom0, as this information isn't available other then via
Xenstore which we are just setting up.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 tools/helpers/init-xenstore-domain.c | 31 ++++++++++++++++++++++++++++++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/tools/helpers/init-xenstore-domain.c b/tools/helpers/init-xenstore-domain.c
index a312bc38b8..a81a15a4de 100644
--- a/tools/helpers/init-xenstore-domain.c
+++ b/tools/helpers/init-xenstore-domain.c
@@ -12,6 +12,7 @@
 #include <xenstore.h>
 #include <xen/sys/xenbus_dev.h>
 #include <xen-xsm/flask/flask.h>
+#include <xen/io/xenbus.h>
 
 #include "init-dom-json.h"
 #include "_paths.h"
@@ -312,6 +313,15 @@ static void do_xs_write(struct xs_handle *xsh, char *path, char *val)
         fprintf(stderr, "writing %s to xenstore failed.\n", path);
 }
 
+static void do_xs_write_dir_node(struct xs_handle *xsh, char *dir, char *node,
+                                 char *val)
+{
+    char full_path[100];
+
+    snprintf(full_path, 100, "%s/%s", dir, node);
+    do_xs_write(xsh, full_path, val);
+}
+
 static void do_xs_write_dom(struct xs_handle *xsh, char *path, char *val)
 {
     char full_path[64];
@@ -325,7 +335,7 @@ int main(int argc, char** argv)
     int opt;
     xc_interface *xch;
     struct xs_handle *xsh;
-    char buf[16];
+    char buf[16], be_path[64], fe_path[64];
     int rv, fd;
     char *maxmem_str = NULL;
 
@@ -414,6 +424,25 @@ int main(int argc, char** argv)
     if (maxmem)
         snprintf(buf, 16, "%d", maxmem * 1024);
     do_xs_write_dom(xsh, "memory/static-max", buf);
+    snprintf(be_path, 64, "/local/domain/0/backend/console/%d/0", domid);
+    snprintf(fe_path, 64, "/local/domain/%d/console", domid);
+    snprintf(buf, 16, "%d", domid);
+    do_xs_write_dir_node(xsh, be_path, "frontend-id", buf);
+    do_xs_write_dir_node(xsh, be_path, "frontend", fe_path);
+    do_xs_write_dir_node(xsh, be_path, "online", "1");
+    snprintf(buf, 16, "%d", XenbusStateInitialising);
+    do_xs_write_dir_node(xsh, be_path, "state", buf);
+    do_xs_write_dir_node(xsh, be_path, "protocol", "vt100");
+    do_xs_write_dir_node(xsh, fe_path, "backend", be_path);
+    do_xs_write_dir_node(xsh, fe_path, "backend-id", "0");
+    do_xs_write_dir_node(xsh, fe_path, "limit", "1048576");
+    do_xs_write_dir_node(xsh, fe_path, "type", "xenconsoled");
+    do_xs_write_dir_node(xsh, fe_path, "output", "pty");
+    do_xs_write_dir_node(xsh, fe_path, "tty", "");
+    snprintf(buf, 16, "%d", console_evtchn);
+    do_xs_write_dir_node(xsh, fe_path, "port", buf);
+    snprintf(buf, 16, "%ld", console_mfn);
+    do_xs_write_dir_node(xsh, fe_path, "ring-ref", buf);
     xs_close(xsh);
 
     fd = creat(XEN_RUN_DIR "/xenstored.pid", 0666);
-- 
2.16.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 3/3] xenstore: remove not applicable control commands in stubdom

[Juergen Gross]

When run in a stubdom environment Xenstore can't select a logfile or
emit memory statistics to a specific file.

So remove or modify those control commands accordingly.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 tools/xenstore/xenstored_control.c | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/tools/xenstore/xenstored_control.c b/tools/xenstore/xenstored_control.c
index e4b8aa95ab..8d48ab4820 100644
--- a/tools/xenstore/xenstored_control.c
+++ b/tools/xenstore/xenstored_control.c
@@ -61,6 +61,19 @@ static int do_control_log(void *ctx, struct connection *conn,
 	return 0;
 }
 
+#ifdef __MINIOS__
+static int do_control_memreport(void *ctx, struct connection *conn,
+				char **vec, int num)
+{
+	if (num)
+		return EINVAL;
+
+	talloc_report_full(NULL, stdout);
+
+	send_ack(conn, XS_CONTROL);
+	return 0;
+}
+#else
 static int do_control_logfile(void *ctx, struct connection *conn,
 			      char **vec, int num)
 {
@@ -114,6 +127,7 @@ static int do_control_memreport(void *ctx, struct connection *conn,
 	send_ack(conn, XS_CONTROL);
 	return 0;
 }
+#endif
 
 static int do_control_print(void *ctx, struct connection *conn,
 			    char **vec, int num)
@@ -132,8 +146,12 @@ static int do_control_help(void *, struct connection *, char **, int);
 static struct cmd_s cmds[] = {
 	{ "check", do_control_check, "" },
 	{ "log", do_control_log, "on|off" },
+#ifdef __MINIOS__
+	{ "memreport", do_control_memreport, "" },
+#else
 	{ "logfile", do_control_logfile, "<file>" },
 	{ "memreport", do_control_memreport, "[<file>]" },
+#endif
 	{ "print", do_control_print, "<string>" },
 	{ "help", do_control_help, "" },
 };
-- 
2.16.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 0/3] tools/xenstore

[Jürgen Groß]

On 28.01.20 15:28, Juergen Gross wrote:
> Some patches for Xenstore-stubdom which have been lying around in my
> local tree for some time now.
> 
> Juergen Gross (3):
>    xenstore: setup xenstore stubdom console interface properly
>    xenstore: add console xenstore entries for xenstore stubdom
>    xenstore: remove not applicable control commands in stubdom
> 
>   tools/helpers/init-xenstore-domain.c | 44 +++++++++++++++++++++++++++++++++++-
>   tools/xenstore/xenstored_control.c   | 18 +++++++++++++++
>   2 files changed, 61 insertions(+), 1 deletion(-)
> 

Ping?


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 1/3] xenstore: setup xenstore stubdom console interface properly

[Andrew Cooper]

On 28/01/2020 14:28, Juergen Gross wrote:
> In order to be able to get access to the console of Xenstore stubdom
> we need an appropriate granttab entry. So call xc_dom_gnttab_init()
> when constructing the domain and preset some information needed
> for that function in the dom structure.
>
> We need to create the event channel for the console, too. Do that and
> store all necessary data locally.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
>  tools/helpers/init-xenstore-domain.c | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
>
> diff --git a/tools/helpers/init-xenstore-domain.c b/tools/helpers/init-xenstore-domain.c
> index adb8408b63..a312bc38b8 100644
> --- a/tools/helpers/init-xenstore-domain.c
> +++ b/tools/helpers/init-xenstore-domain.c
> @@ -24,6 +24,8 @@ static char *param;
>  static char *name = "Xenstore";
>  static int memory;
>  static int maxmem;
> +static xen_pfn_t console_mfn;
> +static unsigned int console_evtchn;
>  
>  static struct option options[] = {
>      { "kernel", 1, NULL, 'k' },
> @@ -113,6 +115,7 @@ static int build(xc_interface *xch)
>          fprintf(stderr, "xc_domain_setmaxmem failed\n");
>          goto err;
>      }
> +    console_evtchn = xc_evtchn_alloc_unbound(xch, domid, 0);

Presumably some form of error checking?

Also, while it is probably fine for now, I think this does highlight a
future issue.  What happens when xenconsoled is also a stubdomain?

I suspect we have a looming chicken&egg problem, where the toolstack is
going to have to do some careful domid and plumbing to set up build both
stubdoms in tandem.

>      rv = xc_domain_set_memmap_limit(xch, domid, limit_kb);
>      if ( rv )
>      {
> @@ -133,6 +136,9 @@ static int build(xc_interface *xch)
>          snprintf(cmdline, 512, "--event %d --internal-db", rv);
>  
>      dom = xc_dom_allocate(xch, cmdline, NULL);

Any chance of some error handling, unlikely as it is to go wrong?

> +    dom->container_type = XC_DOM_PV_CONTAINER;
> +    dom->xenstore_domid = domid;
> +    dom->console_evtchn = console_evtchn;

and a newline here?

>      rv = xc_dom_kernel_file(dom, kernel);
>      if ( rv )
>      {
> @@ -186,6 +192,12 @@ static int build(xc_interface *xch)
>          fprintf(stderr, "xc_dom_boot_image failed\n");
>          goto err;
>      }
> +    rv = xc_dom_gnttab_init(dom);
> +    if ( rv )
> +    {
> +        fprintf(stderr, "xc_dom_gnttab_init failed\n");
> +        goto err;
> +    }
>  
>      rv = xc_domain_set_virq_handler(xch, domid, VIRQ_DOM_EXC);
>      if ( rv )
> @@ -201,6 +213,7 @@ static int build(xc_interface *xch)
>      }
>  
>      rv = 0;
> +    console_mfn = xc_dom_p2m(dom, dom->console_pfn);

This doesn't appear to be used.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 2/3] xenstore: add console xenstore entries for xenstore stubdom

[Andrew Cooper]

On 28/01/2020 14:28, Juergen Gross wrote:
> In order to be able to connect to the console of Xenstore stubdom we
> need to create the appropriate entries in Xenstore.
>
> For the moment we don't support xenconsoled living in another domain
> than dom0, as this information isn't available other then via
> Xenstore which we are just setting up.

Ah - I see the observation here.

>
> Signed-off-by: Juergen Gross <jgross@suse.com>

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

> ---
>  tools/helpers/init-xenstore-domain.c | 31 ++++++++++++++++++++++++++++++-
>  1 file changed, 30 insertions(+), 1 deletion(-)
>
> diff --git a/tools/helpers/init-xenstore-domain.c b/tools/helpers/init-xenstore-domain.c
> index a312bc38b8..a81a15a4de 100644
> --- a/tools/helpers/init-xenstore-domain.c
> +++ b/tools/helpers/init-xenstore-domain.c
> @@ -12,6 +12,7 @@
>  #include <xenstore.h>
>  #include <xen/sys/xenbus_dev.h>
>  #include <xen-xsm/flask/flask.h>
> +#include <xen/io/xenbus.h>
>  
>  #include "init-dom-json.h"
>  #include "_paths.h"
> @@ -312,6 +313,15 @@ static void do_xs_write(struct xs_handle *xsh, char *path, char *val)
>          fprintf(stderr, "writing %s to xenstore failed.\n", path);
>  }
>  
> +static void do_xs_write_dir_node(struct xs_handle *xsh, char *dir, char *node,
> +                                 char *val)
> +{
> +    char full_path[100];
> +
> +    snprintf(full_path, 100, "%s/%s", dir, node);
> +    do_xs_write(xsh, full_path, val);
> +}
> +
>  static void do_xs_write_dom(struct xs_handle *xsh, char *path, char *val)
>  {
>      char full_path[64];
> @@ -325,7 +335,7 @@ int main(int argc, char** argv)
>      int opt;
>      xc_interface *xch;
>      struct xs_handle *xsh;
> -    char buf[16];
> +    char buf[16], be_path[64], fe_path[64];
>      int rv, fd;
>      char *maxmem_str = NULL;
>  
> @@ -414,6 +424,25 @@ int main(int argc, char** argv)
>      if (maxmem)
>          snprintf(buf, 16, "%d", maxmem * 1024);
>      do_xs_write_dom(xsh, "memory/static-max", buf);
> +    snprintf(be_path, 64, "/local/domain/0/backend/console/%d/0", domid);
> +    snprintf(fe_path, 64, "/local/domain/%d/console", domid);
> +    snprintf(buf, 16, "%d", domid);
> +    do_xs_write_dir_node(xsh, be_path, "frontend-id", buf);
> +    do_xs_write_dir_node(xsh, be_path, "frontend", fe_path);
> +    do_xs_write_dir_node(xsh, be_path, "online", "1");
> +    snprintf(buf, 16, "%d", XenbusStateInitialising);
> +    do_xs_write_dir_node(xsh, be_path, "state", buf);
> +    do_xs_write_dir_node(xsh, be_path, "protocol", "vt100");
> +    do_xs_write_dir_node(xsh, fe_path, "backend", be_path);
> +    do_xs_write_dir_node(xsh, fe_path, "backend-id", "0");
> +    do_xs_write_dir_node(xsh, fe_path, "limit", "1048576");
> +    do_xs_write_dir_node(xsh, fe_path, "type", "xenconsoled");
> +    do_xs_write_dir_node(xsh, fe_path, "output", "pty");
> +    do_xs_write_dir_node(xsh, fe_path, "tty", "");
> +    snprintf(buf, 16, "%d", console_evtchn);
> +    do_xs_write_dir_node(xsh, fe_path, "port", buf);
> +    snprintf(buf, 16, "%ld", console_mfn);
> +    do_xs_write_dir_node(xsh, fe_path, "ring-ref", buf);

Eww.  Why are pty/tty details in the protocol?  vt100, fine, but the
backend specifics about what it does with the data shouldn't matter to
the frontend.

I presume this is too engrained in legacy to fix?

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 3/3] xenstore: remove not applicable control commands in stubdom

[Andrew Cooper]

On 28/01/2020 14:28, Juergen Gross wrote:
> When run in a stubdom environment Xenstore can't select a logfile or
> emit memory statistics to a specific file.
>
> So remove or modify those control commands accordingly.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 1/3] xenstore: setup xenstore stubdom console interface properly

[Jürgen Groß]

On 11.02.20 21:18, Andrew Cooper wrote:
> On 28/01/2020 14:28, Juergen Gross wrote:
>> In order to be able to get access to the console of Xenstore stubdom
>> we need an appropriate granttab entry. So call xc_dom_gnttab_init()
>> when constructing the domain and preset some information needed
>> for that function in the dom structure.
>>
>> We need to create the event channel for the console, too. Do that and
>> store all necessary data locally.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>>   tools/helpers/init-xenstore-domain.c | 13 +++++++++++++
>>   1 file changed, 13 insertions(+)
>>
>> diff --git a/tools/helpers/init-xenstore-domain.c b/tools/helpers/init-xenstore-domain.c
>> index adb8408b63..a312bc38b8 100644
>> --- a/tools/helpers/init-xenstore-domain.c
>> +++ b/tools/helpers/init-xenstore-domain.c
>> @@ -24,6 +24,8 @@ static char *param;
>>   static char *name = "Xenstore";
>>   static int memory;
>>   static int maxmem;
>> +static xen_pfn_t console_mfn;
>> +static unsigned int console_evtchn;
>>   
>>   static struct option options[] = {
>>       { "kernel", 1, NULL, 'k' },
>> @@ -113,6 +115,7 @@ static int build(xc_interface *xch)
>>           fprintf(stderr, "xc_domain_setmaxmem failed\n");
>>           goto err;
>>       }
>> +    console_evtchn = xc_evtchn_alloc_unbound(xch, domid, 0);
> 
> Presumably some form of error checking?

Yes.

> 
> Also, while it is probably fine for now, I think this does highlight a
> future issue.  What happens when xenconsoled is also a stubdomain?
> 
> I suspect we have a looming chicken&egg problem, where the toolstack is
> going to have to do some careful domid and plumbing to set up build both
> stubdoms in tandem.

Hmm, I'd rather defer console setup in xenstore-stubdom then and do it
later via a XS_CONTROL message. This will even enable a restart of
console-stubdom.

> 
>>       rv = xc_domain_set_memmap_limit(xch, domid, limit_kb);
>>       if ( rv )
>>       {
>> @@ -133,6 +136,9 @@ static int build(xc_interface *xch)
>>           snprintf(cmdline, 512, "--event %d --internal-db", rv);
>>   
>>       dom = xc_dom_allocate(xch, cmdline, NULL);
> 
> Any chance of some error handling, unlikely as it is to go wrong?

Okay.

> 
>> +    dom->container_type = XC_DOM_PV_CONTAINER;
>> +    dom->xenstore_domid = domid;
>> +    dom->console_evtchn = console_evtchn;
> 
> and a newline here?

Okay.

> 
>>       rv = xc_dom_kernel_file(dom, kernel);
>>       if ( rv )
>>       {
>> @@ -186,6 +192,12 @@ static int build(xc_interface *xch)
>>           fprintf(stderr, "xc_dom_boot_image failed\n");
>>           goto err;
>>       }
>> +    rv = xc_dom_gnttab_init(dom);
>> +    if ( rv )
>> +    {
>> +        fprintf(stderr, "xc_dom_gnttab_init failed\n");
>> +        goto err;
>> +    }
>>   
>>       rv = xc_domain_set_virq_handler(xch, domid, VIRQ_DOM_EXC);
>>       if ( rv )
>> @@ -201,6 +213,7 @@ static int build(xc_interface *xch)
>>       }
>>   
>>       rv = 0;
>> +    console_mfn = xc_dom_p2m(dom, dom->console_pfn);
> 
> This doesn't appear to be used.

Oh, the usage is in patch 2. Probably I should move this addition to
that patch then.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 2/3] xenstore: add console xenstore entries for xenstore stubdom

[Jürgen Groß]

On 11.02.20 21:25, Andrew Cooper wrote:
> On 28/01/2020 14:28, Juergen Gross wrote:
>> In order to be able to connect to the console of Xenstore stubdom we
>> need to create the appropriate entries in Xenstore.
>>
>> For the moment we don't support xenconsoled living in another domain
>> than dom0, as this information isn't available other then via
>> Xenstore which we are just setting up.
> 
> Ah - I see the observation here.
> 
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
> 
> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
> 
>> ---
>>   tools/helpers/init-xenstore-domain.c | 31 ++++++++++++++++++++++++++++++-
>>   1 file changed, 30 insertions(+), 1 deletion(-)
>>
>> diff --git a/tools/helpers/init-xenstore-domain.c b/tools/helpers/init-xenstore-domain.c
>> index a312bc38b8..a81a15a4de 100644
>> --- a/tools/helpers/init-xenstore-domain.c
>> +++ b/tools/helpers/init-xenstore-domain.c
>> @@ -12,6 +12,7 @@
>>   #include <xenstore.h>
>>   #include <xen/sys/xenbus_dev.h>
>>   #include <xen-xsm/flask/flask.h>
>> +#include <xen/io/xenbus.h>
>>   
>>   #include "init-dom-json.h"
>>   #include "_paths.h"
>> @@ -312,6 +313,15 @@ static void do_xs_write(struct xs_handle *xsh, char *path, char *val)
>>           fprintf(stderr, "writing %s to xenstore failed.\n", path);
>>   }
>>   
>> +static void do_xs_write_dir_node(struct xs_handle *xsh, char *dir, char *node,
>> +                                 char *val)
>> +{
>> +    char full_path[100];
>> +
>> +    snprintf(full_path, 100, "%s/%s", dir, node);
>> +    do_xs_write(xsh, full_path, val);
>> +}
>> +
>>   static void do_xs_write_dom(struct xs_handle *xsh, char *path, char *val)
>>   {
>>       char full_path[64];
>> @@ -325,7 +335,7 @@ int main(int argc, char** argv)
>>       int opt;
>>       xc_interface *xch;
>>       struct xs_handle *xsh;
>> -    char buf[16];
>> +    char buf[16], be_path[64], fe_path[64];
>>       int rv, fd;
>>       char *maxmem_str = NULL;
>>   
>> @@ -414,6 +424,25 @@ int main(int argc, char** argv)
>>       if (maxmem)
>>           snprintf(buf, 16, "%d", maxmem * 1024);
>>       do_xs_write_dom(xsh, "memory/static-max", buf);
>> +    snprintf(be_path, 64, "/local/domain/0/backend/console/%d/0", domid);
>> +    snprintf(fe_path, 64, "/local/domain/%d/console", domid);
>> +    snprintf(buf, 16, "%d", domid);
>> +    do_xs_write_dir_node(xsh, be_path, "frontend-id", buf);
>> +    do_xs_write_dir_node(xsh, be_path, "frontend", fe_path);
>> +    do_xs_write_dir_node(xsh, be_path, "online", "1");
>> +    snprintf(buf, 16, "%d", XenbusStateInitialising);
>> +    do_xs_write_dir_node(xsh, be_path, "state", buf);
>> +    do_xs_write_dir_node(xsh, be_path, "protocol", "vt100");
>> +    do_xs_write_dir_node(xsh, fe_path, "backend", be_path);
>> +    do_xs_write_dir_node(xsh, fe_path, "backend-id", "0");
>> +    do_xs_write_dir_node(xsh, fe_path, "limit", "1048576");
>> +    do_xs_write_dir_node(xsh, fe_path, "type", "xenconsoled");
>> +    do_xs_write_dir_node(xsh, fe_path, "output", "pty");
>> +    do_xs_write_dir_node(xsh, fe_path, "tty", "");
>> +    snprintf(buf, 16, "%d", console_evtchn);
>> +    do_xs_write_dir_node(xsh, fe_path, "port", buf);
>> +    snprintf(buf, 16, "%ld", console_mfn);
>> +    do_xs_write_dir_node(xsh, fe_path, "ring-ref", buf);
> 
> Eww.  Why are pty/tty details in the protocol?  vt100, fine, but the
> backend specifics about what it does with the data shouldn't matter to
> the frontend.
> 
> I presume this is too engrained in legacy to fix?

I think cleaning this up is an orthogonal patch series.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel