Xen devel - May 2011 - Upstream QEMU not working with Xen unstable, lacks option definitions

Hi,

I compiled Anthony''s QEMU [0]:

./configure --target-list=i386-softmmu --enable-xen
--extra-cflags=-I${X}/dist/install/usr/include
--extra-ldflags=-L${X}/dist/install/usr/lib

However, this newly generated qemu does not support Xen-specific
options such as -domain-name, -vcpus, etc, which makes it unfeasible
to be used as device_model.

How to solve this problem? Did I miss anything with `configure`?

[0]: git://xenbits.xensource.com/people/aperard/qemu-dm.git

-- 
Best regards
Wei Liu
Twitter: @iliuw
Site: http://liuw.name

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, 2011-05-05 at 09:38 +0100, Wei Liu wrote:
> Hi,
> 
> I compiled Anthony''s QEMU [0]:
> 
> ./configure --target-list=i386-softmmu --enable-xen
> --extra-cflags=-I${X}/dist/install/usr/include
> --extra-ldflags=-L${X}/dist/install/usr/lib
> 
> However, this newly generated qemu does not support Xen-specific
> options such as -domain-name, -vcpus, etc, which makes it unfeasible
> to be used as device_model.
> 
> How to solve this problem? Did I miss anything with `configure`?
> 
> [0]: git://xenbits.xensource.com/people/aperard/qemu-dm.git
Please check the recently updated
http://wiki.xen.org/xenwiki/QEMUUpstream -- you need to tell xl (using
the "device_model_version" option) that you are using the new qemu,
then
the toolstack will use the correct options for the upstream qemu.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, May 5, 2011 at 4:47 PM, Ian Campbell <Ian.Campbell@citrix.com>
wrote:
>> [0]: git://xenbits.xensource.com/people/aperard/qemu-dm.git
>
> Please check the recently updated
> http://wiki.xen.org/xenwiki/QEMUUpstream -- you need to tell xl (using
> the "device_model_version" option) that you are using the new
qemu, then
> the toolstack will use the correct options for the upstream qemu.
>
> Ian.
>
>
Thanks, that works, though xl is not stable enough.

xl seems to use different format for configuration, and the page
http://wiki.xen.org/xenwiki/PythonInXlConfig is not available. Any
other resources for writing a xl config file?


-- 
Best regards
Wei Liu
Twitter: @iliuw
Site: http://liuw.name

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, 2011-05-05 at 11:06 +0100, Wei Liu wrote:
> On Thu, May 5, 2011 at 4:47 PM, Ian Campbell
<Ian.Campbell@citrix.com> wrote:
> >> [0]: git://xenbits.xensource.com/people/aperard/qemu-dm.git
> >
> > Please check the recently updated
> > http://wiki.xen.org/xenwiki/QEMUUpstream -- you need to tell xl (using
> > the "device_model_version" option) that you are using the
new qemu, then
> > the toolstack will use the correct options for the upstream qemu.
> >
> > Ian.
> >
> >
> 
> Thanks, that works, though xl is not stable enough.
How so? Please file bugs on the mailing list.
> xl seems to use different format for configuration, and the page
> http://wiki.xen.org/xenwiki/PythonInXlConfig is not available. Any
> other resources for writing a xl config file?
xl configuration files are intended to be compatible with xm ones, with
a few caveats as described at
http://wiki.xen.org/xenwiki/MigrationGuideToXen4.1+

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, 5 May 2011, Wei Liu wrote:
> On Thu, May 5, 2011 at 4:47 PM, Ian Campbell
<Ian.Campbell@citrix.com> wrote:
> >> [0]: git://xenbits.xensource.com/people/aperard/qemu-dm.git
> >
> > Please check the recently updated
> > http://wiki.xen.org/xenwiki/QEMUUpstream -- you need to tell xl (using
> > the "device_model_version" option) that you are using the
new qemu, then
> > the toolstack will use the correct options for the upstream qemu.
> >
> > Ian.
> >
> >
> 
> Thanks, that works, though xl is not stable enough.
> 
> xl seems to use different format for configuration, and the page
> http://wiki.xen.org/xenwiki/PythonInXlConfig is not available. Any
> other resources for writing a xl config file?
The file format should be the same except the embedded python that is
not supported. So you should remove lines like these from the config
file:

def vmid_check(var, val):
    val = int(val)
    if val <= 0:
        raise ValueError
    return val

# Define the ''vmid'' variable so that ''xm
create'' knows about it.
xm_vars.var(''vmid'',
            use="Virtual machine id. Integer greater than 0.",
            check=vmid_check)

# Check the defined variables have valid values..
xm_vars.check()

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Fri, May 6, 2011 at 3:54 PM, Ian Campbell <Ian.Campbell@eu.citrix.com>
wrote:
>
> Can you post your actual config file?
>
> I use both vnclisten = ''0.0.0.0'' and serial =
''pty'' in my config files
> and xl behaves as expected for me.
>
> Ian.
>
>
My first vnc config used with xm, which is taken from xen examples:

vfb = [ ''vnc=1,vnclisten=0.0.0.0,vncunused=1'']

Later I found out this is not for HVM. So I change to:

vnc=1
vnclisten=''0.0.0.0''

It solves the vnc problem.

As for serial, I use serial=''pty'', too. It works fine with
qemu-dm
from xen-tools. However, it is not working when I use upstream QEMU.
The upstream QEMU doesn''t write anything in
/local/domain/DOMID/serial/0/tty . If I manually write this entry, xl
console will work as expected.

Also I found that HVM creating process hangs from time to time. Log reads

(XEN) HVM12: HVM Loader
(XEN) HVM12: Detected Xen v4.2-unstable
(XEN) HVM12: Xenbus rings @0xfeffc000, event channel 2

I can not reproduce this behavior. If I have further investigation, I
will report it on the list.

-- 
Best regards
Wei Liu
Twitter: @iliuw
Site: http://liuw.name

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Fri, 2011-05-06 at 09:20 +0100, Wei Liu wrote:
> On Fri, May 6, 2011 at 3:54 PM, Ian Campbell
<Ian.Campbell@eu.citrix.com> wrote:
> >
> > Can you post your actual config file?
> >
> > I use both vnclisten = ''0.0.0.0'' and serial =
''pty'' in my config files
> > and xl behaves as expected for me.
> >
> > Ian.
> >
> >
> 
> My first vnc config used with xm, which is taken from xen examples:
> 
> vfb = [ ''vnc=1,vnclisten=0.0.0.0,vncunused=1'']
> 
> Later I found out this is not for HVM. So I change to:
> 
> vnc=1
> vnclisten=''0.0.0.0''
> 
> It solves the vnc problem.
Great.
> 
> As for serial, I use serial=''pty'', too. It works fine
with qemu-dm
> from xen-tools. However, it is not working when I use upstream QEMU.
> The upstream QEMU doesn''t write anything in
> /local/domain/DOMID/serial/0/tty . If I manually write this entry, xl
> console will work as expected.
Oh, yes, I use the following local patch and had forgotten about it, not
sure how upstreamable it is, perhaps we might need to get libxl to query
this via QMP and write the result itself or something.

Ian.

diff --git a/hw/xen.h b/hw/xen.h
index adc32f7..b46a02c 100644
--- a/hw/xen.h
+++ b/hw/xen.h
@@ -9,6 +9,7 @@
 #include <inttypes.h>
 
 #include "qemu-common.h"
+#include "qemu-option.h"
 
 /* xen-machine.c */
 enum xen_mode {
@@ -57,4 +58,6 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size);
 #  define HVM_MAX_VCPUS 32
 #endif
 
+void xenstore_store_serial_port_info(CharDriverState *chr, QemuOpts *opts);
+
 #endif /* QEMU_HW_XEN_H */
diff --git a/qemu-char.c b/qemu-char.c
index 03858d4..0870cc8 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -31,6 +31,7 @@
 #include "hw/usb.h"
 #include "hw/baum.h"
 #include "hw/msmouse.h"
+#include "hw/xen.h"
 #include "qemu-objects.h"
 
 #include <unistd.h>
@@ -1007,6 +1008,8 @@ static CharDriverState *qemu_chr_open_pty(QemuOpts *opts)
 
     s->timer = qemu_new_timer_ms(rt_clock, pty_chr_timer, chr);
 
+    xenstore_store_serial_port_info(chr, opts);
+
     return chr;
 }
 
diff --git a/xen-all.c b/xen-all.c
index 12258ef..a84b725 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -579,3 +579,85 @@ void destroy_hvm_domain(void)
         xc_interface_close(xc_handle);
     }
 }
+
+/*
+ * Create a store entry for a device (e.g., monitor, serial/parallel lines).
+ * The entry is <domain-path><storeString>/tty and the value is the
name
+ * of the pty associated with the device.
+ */
+static int store_dev_info(const char *id,
+			  CharDriverState *chr,
+			  const char *storeString,
+			  const char *storeVal)
+{
+#ifdef CONFIG_STUBDOM
+    fprintf(stderr, "can''t store dev %s name for domid %d in %s
from a stub domain\n", devName, xen_domid, storeString);
+    return ENOSYS;
+#else
+    xc_interface *xc_handle;
+    struct xs_handle *xs;
+    char *path, *newpath;
+
+    xs = xs_daemon_open();
+    if (xs == NULL) {
+        fprintf(stderr, "Could not contact XenStore\n");
+        return -1;
+    }
+
+    xc_handle = xc_interface_open(0,0,0);
+    if (xc_handle == NULL) {
+        fprintf(stderr, "xc_interface_open() error\n");
+        return -1;
+    }
+
+    path = xs_get_domain_path(xs, xen_domid);
+    if (path == NULL) {
+        fprintf(stderr, "xs_get_domain_path() error\n");
+        return -1;
+    }
+    newpath = realloc(path, (strlen(path) + strlen(storeString) +
+                             strlen("/tty") + 1));
+    if (newpath == NULL) {
+        free(path); /* realloc errors leave old block */
+        fprintf(stderr, "realloc error\n");
+        return -1;
+    }
+    path = newpath;
+
+    strcat(path, storeString);
+    strcat(path, "/tty");
+    if (!xs_write(xs, XBT_NULL, path, storeVal, strlen(storeVal))) {
+        fprintf(stderr, "xs_write for ''%s'' fail",
storeString);
+        return -1;
+    }
+
+    free(path);
+    xs_daemon_close(xs);
+    xc_interface_close(xc_handle);
+
+    return 0;
+#endif
+}
+
+void xenstore_store_serial_port_info(CharDriverState *chr, QemuOpts *opts) {
+    char path[16];
+    const char *id;
+    const char *backend;
+    const char *pty;
+    int i;
+
+    backend = qemu_opt_get(opts, "backend");
+    if (!backend || strcmp(backend, "pty") != 0) return;
+
+    id = qemu_opts_id(opts);
+    if (!id) return;
+
+    if (sscanf(id, "serial%d", &i) != 1)
+	    return;
+
+    pty = qemu_opt_get(opts, "path");
+    if (!pty) return;
+
+    snprintf(path, sizeof(path), "/serial/%d", i);
+    store_dev_info(id, chr, path, pty);
+}




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Fri, May 6, 2011 at 4:40 PM, Ian Campbell
<Ian.Campbell@eu.citrix.com> wrote:>
> Oh, yes, I use the following local patch and had forgotten about it, not
> sure how upstreamable it is, perhaps we might need to get libxl to query
> this via QMP and write the result itself or something.
>
> Ian.
Thanks for your patch.

I just find out that nographic=1 is not working, either. Seems that
lots of work has to be done here.

-- 
Best regards
Wei Liu
Twitter: @iliuw
Site: http://liuw.name

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Fri, 6 May 2011, Ian Campbell wrote:
> > As for serial, I use serial=''pty'', too. It works
fine with qemu-dm
> > from xen-tools. However, it is not working when I use upstream QEMU.
> > The upstream QEMU doesn''t write anything in
> > /local/domain/DOMID/serial/0/tty . If I manually write this entry, xl
> > console will work as expected.
> 
> Oh, yes, I use the following local patch and had forgotten about it, not
> sure how upstreamable it is, perhaps we might need to get libxl to query
> this via QMP and write the result itself or something.
> 
Yeah, the patch doesn''t look great but at least it is using xenstore
just to store informations and not as an RPC mechanism.
In any case at some point we''ll have to add QMP support to issue
commands to
Qemu (see PCI passthrough) and retrieving the device name by QMP would
certainly be preferred by the Qemu maintainers...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel