[Qemu-devel] Staging update (0.12 pending freeze)

[Qemu-devel] Staging update (0.12 pending freeze)

[Anthony Liguori]

I've got all of the patches I'm considering for 0.12 currently in 
staging.  I'm going to work through and test/commit these in a few 
chunks over the next few days before freezing the tree.

If you have a pending patch that you think should be in 0.12, please 
check to make sure it's there.  If you have a new patch you'd like to 
consider for 0.12, please indicate that in the subject with a [FOR 0.12] 
tag as I don't plan on doing another full pull of patches (since testing 
takes time).

http://repo.or.cz/w/qemu/aliguori-queue.git

Regards,

Anthony Liguori

[Qemu-devel] Re: Staging update (0.12 pending freeze)

[Jan Kiszka]

Anthony Liguori wrote:
> I've got all of the patches I'm considering for 0.12 currently in
> staging.  I'm going to work through and test/commit these in a few
> chunks over the next few days before freezing the tree.
> 
> If you have a pending patch that you think should be in 0.12, please
> check to make sure it's there.  If you have a new patch you'd like to
> consider for 0.12, please indicate that in the subject with a [FOR 0.12]
> tag as I don't plan on doing another full pull of patches (since testing
> takes time).
> 
> http://repo.or.cz/w/qemu/aliguori-queue.git
> 

I'm would like to see those two series included:
 - http://git.kiszka.org/?p=qemu.git;a=shortlog;h=refs/heads/queues/kvm
 - http://git.kiszka.org/?p=qemu.git;a=shortlog;h=refs/heads/queues/scsi

Both freshly rebased against staging (which doesn't build btw).

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

[Qemu-devel] Re: Staging update (0.12 pending freeze)

[Anthony Liguori]

Jan Kiszka wrote:
> Anthony Liguori wrote:
>   
>> I've got all of the patches I'm considering for 0.12 currently in
>> staging.  I'm going to work through and test/commit these in a few
>> chunks over the next few days before freezing the tree.
>>
>> If you have a pending patch that you think should be in 0.12, please
>> check to make sure it's there.  If you have a new patch you'd like to
>> consider for 0.12, please indicate that in the subject with a [FOR 0.12]
>> tag as I don't plan on doing another full pull of patches (since testing
>> takes time).
>>
>> http://repo.or.cz/w/qemu/aliguori-queue.git
>>
>>     
>
> I'm would like to see those two series included:
>  - http://git.kiszka.org/?p=qemu.git;a=shortlog;h=refs/heads/queues/kvm
>   

Got both of these.

>  - http://git.kiszka.org/?p=qemu.git;a=shortlog;h=refs/heads/queues/scsi
>   

I just got that.  Had a blip and missed a day of patches.

> Both freshly rebased against staging (which doesn't build btw).
>   

Nope, and it won't for a while.  Instead of fixing everything, I'm just 
focusing on small groups of patches at a time.

> Jan
>
>   

Thanks,

Regards,

Anthony Liguori

Re: [Qemu-devel] Re: Staging update (0.12 pending freeze)

[Luiz Capitulino]

On Wed, 02 Dec 2009 13:32:03 -0600
Anthony Liguori <anthony@codemonkey.ws> wrote:

> > Both freshly rebased against staging (which doesn't build btw).
> >   
> 
> Nope, and it won't for a while.  Instead of fixing everything, I'm just 
> focusing on small groups of patches at a time.

 Right, but people rebasing against it need to build it to be able
to fix conflicts and test things.

 So, here is a list of problems I had to fix/workaround to have staging
fully building on x86_64.

 I'm CC'ing Mark, Gerd and Eduardo because I believe they can help
fixing, but I'm unsure on what caused the problems (merge conflicts?).

- net:

net/dump.c: In function ‘net_dump_init’:
net/dump.c:119: error: ‘s’ may be used uninitialized in this function

- scsi-disk:

/home/lcapitulino/src/aliguori-queue/hw/scsi-disk.c: In function ‘scsi_handle_write_error’:
home/lcapitulino/src/aliguori-queue/hw/scsi-disk.c:176: error: ‘SCSIDiskReq’ has no member named ‘dev’
cc1: warnings being treated as errors
/home/lcapitulino/src/aliguori-queue/hw/scsi-disk.c:174: error: unused variable ‘s’

- monitor:

/home/lcapitulino/src/aliguori-queue/monitor.c: In function ‘eject_device’:
/home/lcapitulino/src/aliguori-queue/monitor.c:760: error: invalid storage class for function ‘do_eject’

 The last problem is a missing '}' in the second if.

Re: [Qemu-devel] Re: Staging update (0.12 pending freeze)

[Luiz Capitulino]

On Thu, 3 Dec 2009 12:23:45 -0200
Luiz Capitulino <lcapitulino@redhat.com> wrote:

> On Wed, 02 Dec 2009 13:32:03 -0600
> Anthony Liguori <anthony@codemonkey.ws> wrote:
> 
> > > Both freshly rebased against staging (which doesn't build btw).
> > >   
> > 
> > Nope, and it won't for a while.  Instead of fixing everything, I'm just 
> > focusing on small groups of patches at a time.
> 
>  Right, but people rebasing against it need to build it to be able
> to fix conflicts and test things.
> 
>  So, here is a list of problems I had to fix/workaround to have staging
> fully building on x86_64.

 With recent changes the -net one went away and we got a new one:

- virtio-rng:

/home/lcapitulino/src/aliguori-queue/hw/virtio-rng.c: In function ‘virtio_rng_save’:
/home/lcapitulino/src/aliguori-queue/hw/virtio-rng.c:147: error: implicit declaration of function ‘virtio_save’
/home/lcapitulino/src/aliguori-queue/hw/virtio-rng.c: In function ‘virtio_rng_load’:
/home/lcapitulino/src/aliguori-queue/hw/virtio-rng.c:157: error: implicit declaration of function ‘virtio_load’

 Added Ian to the CC list..

 Hm, this is stupid report being useful to anyone? :)

Re: [Qemu-devel] Re: Staging update (0.12 pending freeze)

[Anthony Liguori]

Luiz Capitulino wrote:
>>  Right, but people rebasing against it need to build it to be able
>> to fix conflicts and test things.
>>
>>  So, here is a list of problems I had to fix/workaround to have staging
>> fully building on x86_64.
>>     
>
>  With recent changes the -net one went away and we got a new one:
>
> - virtio-rng:
>
> /home/lcapitulino/src/aliguori-queue/hw/virtio-rng.c: In function ‘virtio_rng_save’:
> /home/lcapitulino/src/aliguori-queue/hw/virtio-rng.c:147: error: implicit declaration of function ‘virtio_save’
> /home/lcapitulino/src/aliguori-queue/hw/virtio-rng.c: In function ‘virtio_rng_load’:
> /home/lcapitulino/src/aliguori-queue/hw/virtio-rng.c:157: error: implicit declaration of function ‘virtio_load’
>
>  Added Ian to the CC list..
>
>  Hm, this is stupid report being useful to anyone? :)
>   
Just FYI, this happens all of the time in staging.  The difference this 
time around is that I usually fix all of these problems before pushing 
to staging.  There was just too many things in staging to do that this 
time around.

It's usually easy to resolve with some git magic.

Regards,

Anthony Liguori

Re: [Qemu-devel] Staging update (0.12 pending freeze)

[Luiz Capitulino]

On Wed, 02 Dec 2009 10:46:11 -0600
Anthony Liguori <anthony@codemonkey.ws> wrote:

> I've got all of the patches I'm considering for 0.12 currently in 
> staging.  I'm going to work through and test/commit these in a few 
> chunks over the next few days before freezing the tree.
> 
> If you have a pending patch that you think should be in 0.12, please 
> check to make sure it's there.  If you have a new patch you'd like to 
> consider for 0.12, please indicate that in the subject with a [FOR 0.12] 
> tag as I don't plan on doing another full pull of patches (since testing 
> takes time).

 My conversion series is not there:

http://lists.gnu.org/archive/html/qemu-devel/2009-11/msg01398.html

Re: [Qemu-devel] Staging update (0.12 pending freeze)

[Anthony Liguori]

Luiz Capitulino wrote:
> On Wed, 02 Dec 2009 10:46:11 -0600
> Anthony Liguori <anthony@codemonkey.ws> wrote:
>
>   
>> I've got all of the patches I'm considering for 0.12 currently in 
>> staging.  I'm going to work through and test/commit these in a few 
>> chunks over the next few days before freezing the tree.
>>
>> If you have a pending patch that you think should be in 0.12, please 
>> check to make sure it's there.  If you have a new patch you'd like to 
>> consider for 0.12, please indicate that in the subject with a [FOR 0.12] 
>> tag as I don't plan on doing another full pull of patches (since testing 
>> takes time).
>>     
>
>  My conversion series is not there:
>
> http://lists.gnu.org/archive/html/qemu-devel/2009-11/msg01398.html
>   
I'm not sure why they aren't there, but can you rebase that against 
staging?  Specifically, Jan's block migration info patches introduce new 
fields.

Regards,

Anthony Liguori

Re: [Qemu-devel] Staging update (0.12 pending freeze)

[Luiz Capitulino]

On Wed, 02 Dec 2009 13:54:20 -0600
Anthony Liguori <anthony@codemonkey.ws> wrote:

> Luiz Capitulino wrote:
> > On Wed, 02 Dec 2009 10:46:11 -0600
> > Anthony Liguori <anthony@codemonkey.ws> wrote:
> >
> >   
> >> I've got all of the patches I'm considering for 0.12 currently in 
> >> staging.  I'm going to work through and test/commit these in a few 
> >> chunks over the next few days before freezing the tree.
> >>
> >> If you have a pending patch that you think should be in 0.12, please 
> >> check to make sure it's there.  If you have a new patch you'd like to 
> >> consider for 0.12, please indicate that in the subject with a [FOR 0.12] 
> >> tag as I don't plan on doing another full pull of patches (since testing 
> >> takes time).
> >>     
> >
> >  My conversion series is not there:
> >
> > http://lists.gnu.org/archive/html/qemu-devel/2009-11/msg01398.html
> >   
> I'm not sure why they aren't there, but can you rebase that against 
> staging?  Specifically, Jan's block migration info patches introduce new 
> fields.

 Sure.

Re: [Qemu-devel] Staging update (0.12 pending freeze)

[Ian Molton]

Anthony Liguori wrote:
> I've got all of the patches I'm considering for 0.12 currently in
> staging.

> http://repo.or.cz/w/qemu/aliguori-queue.git

I see you have my rng and size patches in there, thanks for the quick
review!

Is it too late to get the timer based socket reconnect patch in and the
(two liner) patch to virtio-rng to use it? it'd make virtio-rng actually
useful in a production environment...

if not, let me know and I'll rebase and send an incremental patchset to you.

Cheers,

-Ian

Re: [Qemu-devel] Staging update (0.12 pending freeze)

[Anthony Liguori]

Ian Molton wrote:
> Anthony Liguori wrote:
>   
>> I've got all of the patches I'm considering for 0.12 currently in
>> staging.
>>     
>
>   
>> http://repo.or.cz/w/qemu/aliguori-queue.git
>>     
>
> I see you have my rng and size patches in there, thanks for the quick
> review!
>
> Is it too late to get the timer based socket reconnect patch in and the
> (two liner) patch to virtio-rng to use it? it'd make virtio-rng actually
> useful in a production environment...
>   

Actually, that patch would break a production environment.  You cannot 
sleep in qemu.  It will severely impact the guest.

> if not, let me know and I'll rebase and send an incremental patchset to you.
>   

Regards,

Anthony Liguori

Re: [Qemu-devel] Staging update (0.12 pending freeze)

[Ian Molton]

Anthony Liguori wrote:
> Ian Molton wrote:

> Actually, that patch would break a production environment.  You cannot
> sleep in qemu.  It will severely impact the guest.

I refer to the version posted today, which doesnt sleep, but uses a
timer instead. (or did I miss something and a callled function sleeps?
it didnt hang qemu here when I tested it...)

-Ian

Re: [Qemu-devel] Staging update (0.12 pending freeze)

[Anthony Liguori]

Ian Molton wrote:
> Anthony Liguori wrote:
>   
>> Ian Molton wrote:
>>     
>
>   
>> Actually, that patch would break a production environment.  You cannot
>> sleep in qemu.  It will severely impact the guest.
>>     
>
> I refer to the version posted today, which doesnt sleep, but uses a
> timer instead. (or did I miss something and a callled function sleeps?
> it didnt hang qemu here when I tested it...)
>   

Ah, if you don't post with a [PATCH] in the subject, I'm highly likely 
to miss the patch.  Please resubmit.

Regards,

Anthony Liguori

> -Ian
>   

[Qemu-devel] [PATCH] Socket reconnection take 2.

[Ian Molton]

Reposting as requested. hopefully t-brid doesnt whitespace-mangle it.

Anthony Liguori wrote:

> > sleep() in qemu is very, very wrong.  It will pause the guest's
> > execution and all sorts of badness can ensue.

Quite...

> > The right thing to do is set a timer and not generate data while
> > disconnected.

New patch attached, now with less crack...

> >  I still am not confident this is really a great thing to do.

What other option is there than to drop the ability to feed entropy to
the guest when the hosts egd link drops?

btw. Does anyone know how to get t-bird to inline patches?

-Ian



>From e9d4be9cd0ef9e34c65939d4604874035c45bf34 Mon Sep 17 00:00:00 2001
From: Ian Molton <ian.molton@collabora.co.uk>
Date: Tue, 1 Dec 2009 11:18:41 +0000
Subject: [PATCH 2/4] socket: Add a reconnect option.

	Add a reconnect option that allows sockets to reconnect (after a
specified delay) to the specified server. This makes the virtio-rng driver
useful in production environments where the EGD server may need to be
restarted.

Signed-off-by: Ian Molton <ian.molton@collabora.co.uk>
---
 qemu-char.c   |  177
++++++++++++++++++++++++++++++++++++++++++++-------------
 qemu-char.h   |    2 +
 qemu-config.c |    3 +
 vl.c          |    4 +
 4 files changed, 147 insertions(+), 39 deletions(-)

diff --git a/qemu-char.c b/qemu-char.c
index e202585..714c119 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -1870,8 +1870,12 @@ typedef struct {
     int max_size;
     int do_telnetopt;
     int do_nodelay;
+    int reconnect;
     int is_unix;
     int msgfd;
+    QemuOpts *opts;
+    CharDriverState *chr;
+    int (*setup)(QemuOpts *opts);
 } TCPCharDriver;

 static void tcp_chr_accept(void *opaque);
@@ -2011,6 +2015,69 @@ static ssize_t tcp_chr_recv(CharDriverState *chr,
char *buf, size_t len)
 }
 #endif

+struct reconnect_list {
+    TCPCharDriver *s;
+    uint64_t when;
+    struct reconnect_list *next;
+};
+
+static struct reconnect_list *rc_list;
+
+static int qemu_chr_sched_reconnect(TCPCharDriver *s)
+{
+    struct reconnect_list *new = qemu_malloc(sizeof(*new));
+    struct timeval tv;
+
+    if(!new)
+        return 1;
+
+    gettimeofday(&tv, NULL);
+    new->s = s;
+    new->when = (s->reconnect + tv.tv_sec) * 1000000 + tv.tv_usec;
+    new->next = rc_list;
+    rc_list = new;
+
+    return 0;
+}
+
+static int qemu_chr_connect_socket(TCPCharDriver *s);
+
+void qemu_chr_reconnect(void)
+{
+    struct reconnect_list *this = rc_list, *prev = NULL;
+    struct timeval tv;
+    uint64_t now;
+
+    if(!this)
+        return;
+
+    gettimeofday(&tv, NULL);
+    now = tv.tv_sec * 1000000 + tv.tv_usec;
+
+    while (this) {
+        if (this->when <= now) {
+            if(qemu_chr_connect_socket(this->s)) {
+                if(prev)
+                    prev->next = this->next;
+                else
+                    rc_list = NULL;
+                qemu_chr_event(this->s->chr, CHR_EVENT_RECONNECTED);
+                free(this);
+		if(prev)
+			this = prev;
+		else
+			this = NULL;
+            }
+            else {
+                this->when += this->s->reconnect * 1000000;
+            }
+        }
+        prev = this;
+	if(this)
+            this = this->next;
+    }
+}
+
 static void tcp_chr_read(void *opaque)
 {
     CharDriverState *chr = opaque;
@@ -2030,10 +2097,16 @@ static void tcp_chr_read(void *opaque)
         if (s->listen_fd >= 0) {
             qemu_set_fd_handler(s->listen_fd, tcp_chr_accept, NULL, chr);
         }
-        qemu_set_fd_handler(s->fd, NULL, NULL, NULL);
+        if (!s->reconnect)
+            qemu_set_fd_handler(s->fd, NULL, NULL, NULL);
         closesocket(s->fd);
         s->fd = -1;
-        qemu_chr_event(chr, CHR_EVENT_CLOSED);
+        if (!s->reconnect) {
+            qemu_chr_event(chr, CHR_EVENT_CLOSED);
+        } else if (qemu_chr_sched_reconnect(s)) {
+            printf("Unable to queue socket for reconnection.\n");
+            qemu_chr_event(chr, CHR_EVENT_CLOSED);
+        }
     } else if (size > 0) {
         if (s->do_telnetopt)
             tcp_chr_process_IAC_bytes(chr, s, buf, &size);
@@ -2137,7 +2210,6 @@ static CharDriverState
*qemu_chr_open_socket(QemuOpts *opts)
 {
     CharDriverState *chr = NULL;
     TCPCharDriver *s = NULL;
-    int fd = -1;
     int is_listen;
     int is_waitconnect;
     int do_nodelay;
@@ -2145,34 +2217,40 @@ static CharDriverState
*qemu_chr_open_socket(QemuOpts *opts)
     int is_telnet;

     is_listen      = qemu_opt_get_bool(opts, "server", 0);
+    is_unix        = qemu_opt_get(opts, "path") != NULL;
+
     is_waitconnect = qemu_opt_get_bool(opts, "wait", 1);
     is_telnet      = qemu_opt_get_bool(opts, "telnet", 0);
     do_nodelay     = !qemu_opt_get_bool(opts, "delay", 1);
-    is_unix        = qemu_opt_get(opts, "path") != NULL;
-    if (!is_listen)
+
+    if (!is_listen) {
         is_waitconnect = 0;
+    } else {
+        if (is_telnet)
+            s->do_telnetopt = 1;
+    }
+

-    chr = qemu_mallocz(sizeof(CharDriverState));
     s = qemu_mallocz(sizeof(TCPCharDriver));
+    chr = qemu_mallocz(sizeof(CharDriverState));
+    s->opts = opts;
+
+    if (!is_listen && !is_telnet)
+        s->reconnect = qemu_opt_get_number(opts, "reconnect", 0);

     if (is_unix) {
         if (is_listen) {
-            fd = unix_listen_opts(opts);
+            s->setup = unix_listen_opts;
         } else {
-            fd = unix_connect_opts(opts);
+            s->setup = unix_connect_opts;
         }
     } else {
         if (is_listen) {
-            fd = inet_listen_opts(opts, 0);
+            s->setup = inet_listen_opts;
         } else {
-            fd = inet_connect_opts(opts);
+            s->setup = inet_connect_opts;
         }
     }
-    if (fd < 0)
-        goto fail;
-
-    if (!is_waitconnect)
-        socket_set_nonblock(fd);

     s->connected = 0;
     s->fd = -1;
@@ -2186,19 +2264,6 @@ static CharDriverState
*qemu_chr_open_socket(QemuOpts *opts)
     chr->chr_close = tcp_chr_close;
     chr->get_msgfd = tcp_get_msgfd;

-    if (is_listen) {
-        s->listen_fd = fd;
-        qemu_set_fd_handler(s->listen_fd, tcp_chr_accept, NULL, chr);
-        if (is_telnet)
-            s->do_telnetopt = 1;
-
-    } else {
-        s->connected = 1;
-        s->fd = fd;
-        socket_set_nodelay(fd);
-        tcp_chr_connect(chr);
-    }
-
     /* for "info chardev" monitor command */
     chr->filename = qemu_malloc(256);
     if (is_unix) {
@@ -2215,22 +2280,56 @@ static CharDriverState
*qemu_chr_open_socket(QemuOpts *opts)
                  qemu_opt_get_bool(opts, "server", 0) ? ",server" : "");
     }

-    if (is_listen && is_waitconnect) {
-        printf("QEMU waiting for connection on: %s\n",
-               chr->filename);
-        tcp_chr_accept(chr);
-        socket_set_nonblock(s->listen_fd);
-    }
-    return chr;
+    s->chr = chr;
+
+    if(qemu_chr_connect_socket(s))
+        return chr;

- fail:
-    if (fd >= 0)
-        closesocket(fd);
-    qemu_free(s);
     qemu_free(chr);
+    qemu_free(s);
+
     return NULL;
 }

+
+static int qemu_chr_connect_socket(TCPCharDriver *s)
+{
+    QemuOpts *opts = s->opts;
+    int is_listen;
+    int fd;
+    int is_waitconnect;
+    int do_nodelay;
+
+    is_waitconnect = qemu_opt_get_bool(opts, "wait", 1);
+    is_listen      = qemu_opt_get_bool(opts, "server", 0);
+    do_nodelay     = !qemu_opt_get_bool(opts, "delay", 1);
+
+
+    fd = s->setup(s->opts);
+    if (fd < 0)
+        return 0;
+
+    if (!is_waitconnect)
+        socket_set_nonblock(fd);
+
+    if (is_listen) {
+        s->listen_fd = fd;
+        qemu_set_fd_handler(s->listen_fd, tcp_chr_accept, NULL, s->chr);
+        if (is_waitconnect) {
+            printf("QEMU waiting for connection on: %s\n",
+                   s->chr->filename);
+            tcp_chr_accept(s->chr);
+            socket_set_nonblock(s->listen_fd);
+        }
+    } else {
+        s->fd = fd;
+        socket_set_nodelay(fd);
+        tcp_chr_connect(s->chr);
+    }
+
+    return 1;
+}
+
 static QemuOpts *qemu_chr_parse_compat(const char *label, const char
*filename)
 {
     char host[65], port[33], width[8], height[8];
diff --git a/qemu-char.h b/qemu-char.h
index 9957db1..dc954e2 100644
--- a/qemu-char.h
+++ b/qemu-char.h
@@ -14,6 +14,7 @@
 #define CHR_EVENT_MUX_IN  3 /* mux-focus was set to this terminal */
 #define CHR_EVENT_MUX_OUT 4 /* mux-focus will move on */
 #define CHR_EVENT_CLOSED  5 /* connection closed */
+#define CHR_EVENT_RECONNECTED  6 /* reconnect event */


 #define CHR_IOCTL_SERIAL_SET_PARAMS   1
@@ -73,6 +74,7 @@ CharDriverState *qemu_chr_open_opts(QemuOpts *opts,
                                     void (*init)(struct CharDriverState
*s));
 CharDriverState *qemu_chr_open(const char *label, const char *filename,
void (*init)(struct CharDriverState *s));
 void qemu_chr_close(CharDriverState *chr);
+void qemu_chr_reconnect(void);
 void qemu_chr_printf(CharDriverState *s, const char *fmt, ...);
 int qemu_chr_write(CharDriverState *s, const uint8_t *buf, int len);
 void qemu_chr_send_event(CharDriverState *s, int event);
diff --git a/qemu-config.c b/qemu-config.c
index 590fc05..ff8b06e 100644
--- a/qemu-config.c
+++ b/qemu-config.c
@@ -140,6 +140,9 @@ QemuOptsList qemu_chardev_opts = {
         },{
             .name = "signal",
             .type = QEMU_OPT_BOOL,
+        },{
+            .name = "reconnect",
+            .type = QEMU_OPT_NUMBER,
         },
         { /* end if list */ }
     },
diff --git a/vl.c b/vl.c
index 44763af..5876c3e 100644
--- a/vl.c
+++ b/vl.c
@@ -3795,6 +3795,10 @@ void main_loop_wait(int timeout)

     host_main_loop_wait(&timeout);

+    /* Reconnect any disconnected sockets, if necessary */
+
+    qemu_chr_reconnect();
+
     /* poll any events */
     /* XXX: separate device handlers from system ones */
     nfds = -1;
-- 1.6.5

[Qemu-devel] Re: [PATCH] Socket reconnection take 2.

[Michael S. Tsirkin]

On Wed, Dec 02, 2009 at 08:13:52PM +0000, Ian Molton wrote:
> btw. Does anyone know how to get t-bird to inline patches?

Read this:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/email-clients.txt;hb=HEAD

Re: [Qemu-devel] Staging update (0.12 pending freeze)

[Gerd Hoffmann]

On 12/02/09 17:46, Anthony Liguori wrote:

> If you have a pending patch that you think should be in 0.12, please
> check to make sure it's there.

A clear 'must have':

   http://patchwork.ozlabs.org/patch/39291/
   Add a new machine type for qemu 0.12

On top of that, to reduce irq sharing (nice to have):

   http://patchwork.ozlabs.org/patch/39294/
   virtio: enable msi-x for console+balloon

This bugfix ('must have' IMHO):

   http://patchwork.ozlabs.org/patch/39311/
   make chardevs specified in config file work

Also useful (nice to have):

   http://patchwork.ozlabs.org/patch/39202/
   http://patchwork.ozlabs.org/patch/39201/
   add command line option to set global defaults for properties

Finally the 'default devices' patch series ('must have' IMHO):

   http://patchwork.ozlabs.org/patch/39180/ (patch 1/10)

Without that one using -device and -readconfig becomes much harder.

cheers,
   Gerd

Re: [Qemu-devel] Staging update (0.12 pending freeze)

[Alexander Graf]

Gerd Hoffmann wrote:
> On 12/02/09 17:46, Anthony Liguori wrote:
>
>> If you have a pending patch that you think should be in 0.12, please
>> check to make sure it's there.
>
> A clear 'must have':
>
>   http://patchwork.ozlabs.org/patch/39291/
>   Add a new machine type for qemu 0.12
>
> On top of that, to reduce irq sharing (nice to have):
>
>   http://patchwork.ozlabs.org/patch/39294/
>   virtio: enable msi-x for console+balloon
>
> This bugfix ('must have' IMHO):
>
>   http://patchwork.ozlabs.org/patch/39311/
>   make chardevs specified in config file work
>
> Also useful (nice to have):
>
>   http://patchwork.ozlabs.org/patch/39202/
>   http://patchwork.ozlabs.org/patch/39201/
>   add command line option to set global defaults for properties
>
> Finally the 'default devices' patch series ('must have' IMHO):
>
>   http://patchwork.ozlabs.org/patch/39180/ (patch 1/10)
>
> Without that one using -device and -readconfig becomes much harder.

Would you mind writing up a documentation on that whole -device stuff?
I'm having a hard time following your changes and every time you do a
patch you break my S390 series.

Alex

How to convert to -device & friends (was: [Qemu-devel] Staging update (0.12 pending freeze))

[Markus Armbruster]

Alexander Graf <agraf@suse.de> writes:

> Would you mind writing up a documentation on that whole -device stuff?
> I'm having a hard time following your changes and every time you do a
> patch you break my S390 series.

I've been writing a brief guide on how to use -device.  It's not yet in
the Wiki, so I append my last draft.

There's also my qdev status page[*], which I try to keepreasonably
up-to-date.

Hope this helps.

[*] http://www.linux-kvm.org/page/Qdev_status



=== Specifying Bus and Address on Bus ===

In qdev, each device has a parent bus.  Some devices provide one or
more buses for children.  You can specify a device's parent bus with
-device parameter bus.

A device typically has a device address on its parent bus.  For buses
where this address can be configured, devices provide a bus-specific
property.  These are

    bus     property name       value format
    PCI     addr                %x.%x (dev.fn, .fn optional)
    I2C     address             %u
    SCSI    scsi-id             %u

Example: device i440FX-pcihost is on the root bus, and provides a PCI
bus named pci.0.  To put a FOO device into its slot 4, use -device
FOO,bus=/i440FX-pcihost/pci.0,addr=4.  The abbreviated form bus=pci.0
also works as long as the bus name is unique.

Note: the USB device address can't be controlled at this time.

=== Block Devices ===

A QEMU block device (drive) has a host and a guest part.

In the general case, the guest device is connected to a controller
device.  For instance, the IDE controller provides two IDE buses, each
of which can have up to two ide-drive devices, and each ide-drive
device is a guest part, and is connected to a host part.

Except we sometimes lump controller, bus(es) and drive(s) all together
into a single device.  For instance, the ISA floppy controller is
connected to up to two host drives.

The old ways to define block devices define host and guest part
together.  Sometimes, they can even define a controller device in
addition to the block device.

The new way keeps the parts separate: you create the host part with
-drive, and guest device(s) with -device.

The various old ways to define drives all boil down to the common form

    -drive if=TYPE,index=IDX,bus=BUS,unit=UNIT,HOST-OPTS...

TYPE, BUS and UNIT identify the controller device, which of its buses
to use, and the drive's address on that bus.  Details depend on TYPE.
IDX is an alternative way to specify BUS and UNIT.

In the new way, this becomes something like

   -drive if=none,id=DRIVE-ID,HOST-OPTS...
   -device DEVNAME,drive=DRIVE-ID,DEV-OPTS...

The -device argument differs in detail for each kind of drive:

* if=ide

  -device ide-drive,drive=DRIVE-ID,bus=IDE-BUS,unit=UNIT

  where IDE-BUS identifies an IDE bus, normally either ide.0 or ide.1,
  and UNIT is either 0 or 1.

  Bug: new way does not work for ide.1 unit 0 (in old terms: index=2).
  Patch posted.

* if=scsi

  The old way implicitly creates SCSI controllers as needed.  The new
  way makes that explicit:

  -device lsi,id=ID

  As for all PCI devices, you can add bus=PCI-BUS,addr=DEVFN to
  control the PCI device address.

  The lsi device provides one SCSI bus, named ID.0.  Put a disk on it:

  -device scsi-disk,drive=DRIVE-ID,bus=ID.0,scsi-id=SCSI-ID

* if=floppy

  -device isa-fdc,driveA=DRIVE-ID,driveB=DRIVE-ID

  Omitting a drive parameter makes that drive empty.

  Except -device doesn't work for isa-fdc, because it is created by
  default.  It should be possible to manipulate the existing device
  with -set, but that doesn't yet work, either.  For now, you need to
  stick to the old ways for if=floppy.

* if=virtio

  -device virtio-blk-pci,drive=DRIVE-ID,class=C,vectors=V

  This lets you control PCI device class and MSI-X vectors.

  As for all PCI devices, you can add bus=PCI-BUS,addr=DEVFN to
  control the PCI device address.

* if=pflash, if=mtd, if=sd, if=xen are not yet available with -device

For USB devices, the old way is actually different:

    -usbdevice disk:format=FMT:FILENAME

Provides much less control than -drive's HOST-OPTS...  The new way
fixes that:

    -device "QEMU USB MSD",drive=DRIVE-ID

=== Character Devices ===

A QEMU character device has a host and a guest part.

The old ways to define character devices define host and guest part
together.

The new way keeps the parts separate: you create the host part with
-chardev, and the guest device with -device.

The various old ways to define a character device are all of the
general form

    -FOO FOO-OPTS...,LEGACY-CHARDEV

where FOO-OPTS... is specific to -FOO, and the host part
LEGACY-CHARDEV is the same everywhere.

In the new way, this becomes

    -chardev HOST-OPTS...,id=CHR-ID
    -device DEVNAME,chardev=CHR-ID,DEV-OPTS...

The appropriate DEVNAME depends on the machine type.  For type "pc":

* -serial becomes -device isa-serial,iobase=IOADDR,irq=IRQ,index=IDX

  This lets you control I/O ports and IRQs.

  Bug: the new way requires -serial none.  Patch posted.

* -parallel becomes -device isa-parallel,iobase=IOADDR,irq=IRQ,index=IDX

  This lets you control I/O ports and IRQs.

  Bug: the new way requires -parallel none.  Patch posted.

* -usbdevice serial:vendorid=VID,productid=PRID becomes
  -device "QEMU USB Serial",vendorid=VID,productid=PRID

* -usbdevice braille doesn't support LEGACY-CHARDEV syntax.  It always
  uses "braille".  With -device, this useful default is gone, so you
  have to use something like

  -device "QEMU USB Braille",chardev=braille,vendorid=VID,productid=PRID
  -chardev braille,id=braille

* -virtioconsole is still being worked on

LEGACY-CHARDEV translates to -chardev HOST-OPTS... as follows:

* null becomes -chardev null

* pty, msmouse, braille, stdio likewise

* vc:WIDTHxHEIGHT becomes -chardev vc,width=WIDTH,height=HEIGHT

* vc:<COLS>Cx<ROWS>C becomes -chardev vc,cols=<COLS>,rows=<ROWS>

* con: becomes -chardev console

* COM<NUM> becomes -chardev serial,path=<NUM>

* file:FNAME becomes -chardev file,path=FNAME

* pipe:FNAME becomes -chardev pipe,path=FNAME

* tcp:HOST:PORT,OPTS... becomes -chardev socket,host=HOST,port=PORT,OPTS...

* telnet:HOST:PORT,OPTS... becomes
  -chardev socket,host=HOST,port=PORT,OPTS...,telnet=on

* udp:HOST:PORT@LOCALADDR:LOCALPORT becomes
  -chardev udp,host=HOST,port=PORT,localaddr=LOCALADDR,localport=LOCALPORT

* unix:FNAME becomes -chardev socket,path=FNAME

* /dev/parportN becomes -chardev parport,file=/dev/parportN

* /dev/ppiN likewise

* Any other /dev/FNAME becomes -chardev tty,path=/dev/FNAME

* mon:LEGACY-CHARDEV is special: it multiplexes the monitor onto the
  character device defined by LEGACY-CHARDEV.  -chardev provides a
  more general multiplexing instead: you can connect up to four users
  to a single host part.  You need to pass mux=on to -chardev to
  enable switching the input focus.

QEMU uses LEGACY-CHARDEV syntax not just to set up guest devices, but
also in various other places such as -monitor or -net
user,guestfwd=...  You can use chardev:CHR-ID in place of
LEGACY-CHARDEV to refer to a host part defined with -chardev.

=== Network Devices ===

A QEMU network device (NIC) has a host and a guest part.

The old ways to define NICs define host and guest part together.  It
looks like this:

    -net nic,vlan=VLAN,macaddr=MACADDR,model=MODEL,name=ID,addr=STR,vectors=V

Except for USB it looks like this:

    -usbdevice net:vlan=VLAN,macaddr=MACADDR,name=ID,addr=STR,vectors=V

The new way keeps the parts separate: you create the host part with
-netdev, and the guest device with -device, like this:

    -netdev type=TYPE,id=NET-ID
    -device DEVNAME,netdev=NET-ID,mac=MACADDR,DEV-OPTS...

Unlike the old way, this creates just a network device, not a VLAN.
If you really want a VLAN, create it the usual way, then create the
guest device like this:

    -device DEVNAME,vlan=VLAN,mac=MACADDR,DEV-OPTS...

DEVNAME equals MODEL, except for virtio you have to name the virtio
device appropriate for the bus (virtio-net-pci for PCI), and for USB
NIC you have to use "QEMU USB Network Interface".

The old name=ID parameter becomes the usual id=ID with -device.

For PCI devices, you can add bus=PCI-BUS,addr=DEVFN to control the PCI
device address, as usual.  -net nic provides parameter addr for that,
it is silently ignored when the NIC is not a PCI device.

-net nic accepts vectors=V for all models, but it's silently ignored
except for virtio-net-pci (model=virtio).  With -device, only devices
that support it accept it.

Not all devices are available with -device at this time.  All PCI
devices and ne2k_isa are.  The USB NIC does not work, yet.  Patch
posted.

Some PCI devices aren't available with -net nic, e.g. i82558a.

Bug: -device does not work for first NIC.  Patch posted.

=== Graphics Devices ===

Host and guest part of graphics devices have always been separate.

The old way to define the guest graphics device is -vga VGA.

The new way is -device.  Map from -vga argument to -device:

    std         -device VGA
    cirrus      -device "Cirrus VGA"
    vmware      -device "QEMUware SVGA"
    xenfb       not yet available with -device

As for all PCI devices, you can add bus=PCI-BUS,addr=DEVFN to control
the PCI device address.

Actually, -device VGA supports properties bios-offset and bios-size,
but they aren't used with machine type "pc".

Bug: the new way requires -vga none.

Bug: the new way requires PCI; ISA VGA is not yet available with
-device.

Bug: the new way doesn't work for machine type "pc", because it
violates obscure device initialization ordering constraints.

=== Audio Devices ===

Host and guest part of audio devices have always been separate.

The old way to define guest audio devices is -soundhw C1,...

The new way is to define each guest audio device separately with
-device.

Map from -soundhw sound card name to -device:

    ac97        -device AC97
    cs4231a     -device cs4231a,iobase=IOADDR,irq=IRQ,dma=DMA
    es1370      -device ES1370
    gus         -device gus,iobase=IOADDR,irq=IRQ,dma=DMA,freq=F
    sb16        -device sb16,iobase=IOADDR,irq=IRQ,dma=DMA,dma16=DMA16,version=V
    adlib       not yet available with -device
    pcspk       not yet available with -device

For PCI devices, you can add bus=PCI-BUS,addr=DEVFN to control the PCI
device address, as usual.

=== USB Devices ===

The old way to define a virtual USB device is -usbdevice DRIVER:OPTS...

The new way is -device DEVNAME,DEV-OPTS...  Details depend on DRIVER:

* mouse           -device "QEMU USB Mouse"
* tablet          -device "QEMU USB Tablet"
* keyboard        -device "QEMU USB Keyboard"
* wacom-tablet    -device "QEMU PenPartner Tablet"
* host:...        See "Host Device Assignment"
* disk:...        See "Block Devices"
* serial:...      See "Character Devices"
* braille         See "Character Devices"
* net:...         See "Network Devices"
* bt:...          not yet available with -device

=== Watchdog Devices ===

Host and guest part of graphics devices have always been separate.

The old way to define a guest watchdog device is -watchdog DEVNAME.
The new way is -device DEVNAME.  For PCI devices, you can add
bus=PCI-BUS,addr=DEVFN to control the PCI device address, as usual.

=== Host Device Assignment ===

QEMU supports assigning host PCI devices (qemu-kvm only at this time)
and host USB devices.

The old way to assign a host PCI device is

    -pcidevice host=ADDR,dma=none,id=ID

The new way is

    -device pci-assign,host=ADDR,iommu=IOMMU,id=ID

The old dma=none becomes iommu=0 with -device.

The old way to assign a host USB device is

    -usbdevice host:auto:BUS.ADDR:VID:PRID

where any of BUS, ADDR, VID, PRID can be the wildcard *.

The new way is

    -device "USB Host Device",hostbus=BUS,hostaddr=ADDR,vendorid=VID,productid=PRID

where left out or zero BUS, ADDR, VID, PRID serve as wildcard.

[Qemu-devel] Re: How to convert to -device & friends (was: Staging update (0.12 pending freeze))

[Michael S. Tsirkin]

On Thu, Dec 03, 2009 at 02:49:44PM +0100, Markus Armbruster wrote:
> Alexander Graf <agraf@suse.de> writes:
> 
> > Would you mind writing up a documentation on that whole -device stuff?
> > I'm having a hard time following your changes and every time you do a
> > patch you break my S390 series.
> 
> I've been writing a brief guide on how to use -device.  It's not yet in
> the Wiki, so I append my last draft.
> 
> There's also my qdev status page[*], which I try to keepreasonably
> up-to-date.
> 
> Hope this helps.
> 
> [*] http://www.linux-kvm.org/page/Qdev_status
> 

Cool. Maybe this can be made into a manpage and put
into qemu sources proper?

-- 
MST

Re: [Qemu-devel] Staging update (0.12 pending freeze)

[Anthony Liguori]

Gerd Hoffmann wrote:
> On 12/02/09 17:46, Anthony Liguori wrote:
>
>> If you have a pending patch that you think should be in 0.12, please
>> check to make sure it's there.
>
> A clear 'must have':
>
>   http://patchwork.ozlabs.org/patch/39291/
>   Add a new machine type for qemu 0.12
>
> On top of that, to reduce irq sharing (nice to have):
>
>   http://patchwork.ozlabs.org/patch/39294/
>   virtio: enable msi-x for console+balloon
>
> This bugfix ('must have' IMHO):
>
>   http://patchwork.ozlabs.org/patch/39311/
>   make chardevs specified in config file work
>
> Also useful (nice to have):
>
>   http://patchwork.ozlabs.org/patch/39202/
>   http://patchwork.ozlabs.org/patch/39201/
>   add command line option to set global defaults for properties

Got all this, thanks.

> Finally the 'default devices' patch series ('must have' IMHO):
>
>   http://patchwork.ozlabs.org/patch/39180/ (patch 1/10)
>
> Without that one using -device and -readconfig becomes much harder.

This series doesn't get along with the QMP monitor support that's been 
added recently.  That's because there is now a set of monitor flags and 
-monitor takes more than a character device as an argument.

Honestly, I don't really like multiplexing the -monitor option to 
support qmp.  I think I would have a proper -qmp option at the top 
level.  That would integrate much more nicely too with this default 
devices series.  Luiz, what do you think?

Regards,

Anthony Liguori

Re: [Qemu-devel] Staging update (0.12 pending freeze)

[Luiz Capitulino]

On Thu, 03 Dec 2009 17:21:18 -0600
Anthony Liguori <anthony@codemonkey.ws> wrote:

> > Finally the 'default devices' patch series ('must have' IMHO):
> >
> >   http://patchwork.ozlabs.org/patch/39180/ (patch 1/10)
> >
> > Without that one using -device and -readconfig becomes much harder.
> 
> This series doesn't get along with the QMP monitor support that's been 
> added recently.  That's because there is now a set of monitor flags and 
> -monitor takes more than a character device as an argument.

 For QMP there is only one flag, which is 'control', like:

-monitor control,<device>

 Multiple Monitors work just fine, like:

-monitor stdio -monitor control,tcp:localhost:444,server

 I've even tested multiple QMP monitors iirc. :)

> Honestly, I don't really like multiplexing the -monitor option to 
> support qmp.  I think I would have a proper -qmp option at the top 
> level.  That would integrate much more nicely too with this default 
> devices series.  Luiz, what do you think?

 Multiplexing the monitor is really useful for testing and it doesn't
seem reasonable to me to drop this feature just because we can't
add a single flag to an existing command-line option.

Re: [Qemu-devel] Staging update (0.12 pending freeze)

[Anthony Liguori]

Luiz Capitulino wrote:
> On Thu, 03 Dec 2009 17:21:18 -0600
> Anthony Liguori <anthony@codemonkey.ws> wrote:
>
>   
>>> Finally the 'default devices' patch series ('must have' IMHO):
>>>
>>>   http://patchwork.ozlabs.org/patch/39180/ (patch 1/10)
>>>
>>> Without that one using -device and -readconfig becomes much harder.
>>>       
>> This series doesn't get along with the QMP monitor support that's been 
>> added recently.  That's because there is now a set of monitor flags and 
>> -monitor takes more than a character device as an argument.
>>     
>
>  For QMP there is only one flag, which is 'control', like:
>
> -monitor control,<device>
>
>  Multiple Monitors work just fine, like:
>
> -monitor stdio -monitor control,tcp:localhost:444,server
>
>  I've even tested multiple QMP monitors iirc. :)
>
>   
>> Honestly, I don't really like multiplexing the -monitor option to 
>> support qmp.  I think I would have a proper -qmp option at the top 
>> level.  That would integrate much more nicely too with this default 
>> devices series.  Luiz, what do you think?
>>     
>
>  Multiplexing the monitor is really useful for testing and it doesn't
> seem reasonable to me to drop this feature just because we can't
> add a single flag to an existing command-line option.
>   

Problem is, control is not a property of the character device. To 
express this in a consistent way with everything else, you would have to 
make this QemuOpts-like so it would look like

-monitor control,device=tcp:localhost:444,server

But so far, the monitor, serial, parallel, etc. devices don't take QemuOpts.

OTH, having:

-qmp tcp:localhost:444,server

Matches the other option types in a consistent manner. If you want to 
support muxing, just add a qmp: prefix to the mux device.

Regards,

Anthony Liguori

Re: [Qemu-devel] Staging update (0.12 pending freeze)

[Gerd Hoffmann]

On 12/04/09 01:04, Anthony Liguori wrote:
> Problem is, control is not a property of the character device. To
> express this in a consistent way with everything else, you would have to
> make this QemuOpts-like so it would look like
>
> -monitor control,device=tcp:localhost:444,server
>
> But so far, the monitor, serial, parallel, etc. devices don't take
> QemuOpts.
 >
> OTH, having:
>
> -qmp tcp:localhost:444,server

I think we should create a new option for monitor configuration, like this:

   -mon mode={control,readline},chardev=<name>,more-options-here

So you'll create a qmp monitor socket this way:

   -chardev socket,path=/tmp/qmpsock,id=qmp,server,nowait
   -mon mode=control,chardev=qmp

Then the -monitor switch will be legacy/convinience syntax for a 
readline monitor with auto-created chardev named 'monitor<nr>'.

If we need more options in the future they can be added easily.

cheers,
   Gerd

Re: [Qemu-devel] Staging update (0.12 pending freeze)

[Luiz Capitulino]

On Fri, 04 Dec 2009 12:17:51 +0100
Gerd Hoffmann <kraxel@redhat.com> wrote:

> On 12/04/09 01:04, Anthony Liguori wrote:
> > Problem is, control is not a property of the character device. To
> > express this in a consistent way with everything else, you would have to
> > make this QemuOpts-like so it would look like
> >
> > -monitor control,device=tcp:localhost:444,server
> >
> > But so far, the monitor, serial, parallel, etc. devices don't take
> > QemuOpts.
>  >
> > OTH, having:
> >
> > -qmp tcp:localhost:444,server
> 
> I think we should create a new option for monitor configuration, like this:
> 
>    -mon mode={control,readline},chardev=<name>,more-options-here
> 
> So you'll create a qmp monitor socket this way:
> 
>    -chardev socket,path=/tmp/qmpsock,id=qmp,server,nowait
>    -mon mode=control,chardev=qmp
> 
> Then the -monitor switch will be legacy/convinience syntax for a 
> readline monitor with auto-created chardev named 'monitor<nr>'.

 I like this.

 I believe it wouldn't be difficult for you to rebase your series
on top of staging with an incremental patch for QMP, right?

Re: [Qemu-devel] Staging update (0.12 pending freeze)

[Gerd Hoffmann]

On 12/04/09 12:48, Luiz Capitulino wrote:
>> I think we should create a new option for monitor configuration, like this:
>>
>>     -mon mode={control,readline},chardev=<name>,more-options-here
>>
>> So you'll create a qmp monitor socket this way:
>>
>>     -chardev socket,path=/tmp/qmpsock,id=qmp,server,nowait
>>     -mon mode=control,chardev=qmp
>>
>> Then the -monitor switch will be legacy/convinience syntax for a
>> readline monitor with auto-created chardev named 'monitor<nr>'.
>
>   I like this.
>
>   I believe it wouldn't be difficult for you to rebase your series
> on top of staging with an incremental patch for QMP, right?

Rebasing to a moving target is insane.  The qmp patches are committed 
already though, so this isn't a issue ;)

Right now I have some wip patches against current master:

    http://repo.or.cz/w/qemu/kraxel.git/shortlog/refs/heads/qmp  [1]

Not sure whenever I base this on the default series or the other way 
around.  Either way it will be a bit messy.

cheers,
   Gerd

[1] The friendly URLs are new, arn't they?

Re: [Qemu-devel] Staging update (0.12 pending freeze)

[Anthony Liguori]

Gerd Hoffmann wrote:
> On 12/04/09 01:04, Anthony Liguori wrote:
>> Problem is, control is not a property of the character device. To
>> express this in a consistent way with everything else, you would have to
>> make this QemuOpts-like so it would look like
>>
>> -monitor control,device=tcp:localhost:444,server
>>
>> But so far, the monitor, serial, parallel, etc. devices don't take
>> QemuOpts.
> >
>> OTH, having:
>>
>> -qmp tcp:localhost:444,server
>
> I think we should create a new option for monitor configuration, like 
> this:
>
>   -mon mode={control,readline},chardev=<name>,more-options-here
>
> So you'll create a qmp monitor socket this way:
>
>   -chardev socket,path=/tmp/qmpsock,id=qmp,server,nowait
>   -mon mode=control,chardev=qmp

Works for me.  Would be nice to have a -qmp convenience option too.

Regards,

Anthony Liguori

[Qemu-devel] Re: Staging update (0.12 pending freeze)

[Paolo Bonzini]

On 12/02/2009 05:46 PM, Anthony Liguori wrote:
> I've got all of the patches I'm considering for 0.12 currently in
> staging.  I'm going to work through and test/commit these in a few
> chunks over the next few days before freezing the tree.
>
> If you have a pending patch that you think should be in 0.12, please
> check to make sure it's there. If you have a new patch you'd like to
> consider for 0.12, please indicate that in the subject with a [FOR 0.12]
> tag as I don't plan on doing another full pull of patches (since testing
> takes time).

This one is missing:

http://permalink.gmane.org/gmane.comp.emulators.qemu/57388
[PATCH] Fix thinko in linuxboot.S

Paolo

Re: [Qemu-devel] Re: Staging update (0.12 pending freeze)

[Anthony Liguori]

Paolo Bonzini wrote:
> On 12/02/2009 05:46 PM, Anthony Liguori wrote:
>> I've got all of the patches I'm considering for 0.12 currently in
>> staging.  I'm going to work through and test/commit these in a few
>> chunks over the next few days before freezing the tree.
>>
>> If you have a pending patch that you think should be in 0.12, please
>> check to make sure it's there. If you have a new patch you'd like to
>> consider for 0.12, please indicate that in the subject with a [FOR 0.12]
>> tag as I don't plan on doing another full pull of patches (since testing
>> takes time).
>
> This one is missing:
>
> http://permalink.gmane.org/gmane.comp.emulators.qemu/57388
> [PATCH] Fix thinko in linuxboot.S

I clearly have an issue with my filters.  I'll try to figure this that 
out next week.

Thanks.

Regards,

Anthony Liguori
> Paolo
>
>
>

[Qemu-devel] Re: Staging update (0.12 pending freeze)

[Paolo Bonzini]

> This one is missing:
>
> http://permalink.gmane.org/gmane.comp.emulators.qemu/57388
> [PATCH] Fix thinko in linuxboot.S

Still unmerged, resending it rebased.

Paolo

[Qemu-devel] [FOR 0.12] [PATCH] virtio: Add memory statistics reporting to the balloon driver (V5)

[Adam Litke]

Anthony:  I ported this to your staging tree in case you want to consider it
for 0.12.0.  Thanks.  (The only substantive change is converting the new stats
fields to vmstate.)  Since the tree does not build I was unable to test the port
but will be happy to do so once able.

This iteration addresses all of the comments from the last round.  Thanks to
everyone for their careful reviews and helpful comments.  The most significant
change in this version is my use of the QObject API, so a concentrated review
in that area would be most appreciated.  I am hoping to target 0.12.0 with this
patch.  Please let me know if that remains a possibility.  Thanks.

Changes since V4:
 - Virtio spec updated: http://ozlabs.org/~rusty/virtio-spec/virtio-spec-0.8.2.pdf
 - Guest-side Linux implementation applied by Rusty
 - Start using the QObject infrastructure
 - All endian conversions done in the host
 - Report stats that reference a quantity of memory in bytes

Changes since V3:
 - Increase stat field size to 64 bits
 - Report all sizes in kb (not pages)
 - Drop anon_pages stat

Changes since V2:
 - Use a virtqueue for communication instead of the device config space

Changes since V1:
 - In the monitor, print all stats on one line with less abbreviated names
 - Coding style changes

When using ballooning to manage overcommitted memory on a host, a system for
guests to communicate their memory usage to the host can provide information
that will minimize the impact of ballooning on the guests.  The current method
employs a daemon running in each guest that communicates memory statistics to a
host daemon at a specified time interval.  The host daemon aggregates this
information and inflates and/or deflates balloons according to the level of
host memory pressure.  This approach is effective but overly complex since a
daemon must be installed inside each guest and coordinated to communicate with
the host.  A simpler approach is to collect memory statistics in the virtio
balloon driver and communicate them directly to the hypervisor.

This patch implements the qemu side of the communication channel.  I will post
the kernel driver modifications in-reply to this message.

Signed-off-by: Adam Litke <agl@us.ibm.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>
Cc: Avi Kivity <avi@redhat.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: qemu-devel@nongnu.org

diff --git a/balloon.h b/balloon.h
index 60b4a5d..23bbffe 100644
--- a/balloon.h
+++ b/balloon.h
@@ -16,12 +16,12 @@
 
 #include "cpu-defs.h"
 
-typedef ram_addr_t (QEMUBalloonEvent)(void *opaque, ram_addr_t target);
+typedef QObject *(QEMUBalloonEvent)(void *opaque, ram_addr_t target);
 
 void qemu_add_balloon_handler(QEMUBalloonEvent *func, void *opaque);
 
 void qemu_balloon(ram_addr_t target);
 
-ram_addr_t qemu_balloon_status(void);
+QObject *qemu_balloon_status(void);
 
 #endif
diff --git a/hw/virtio-balloon.c b/hw/virtio-balloon.c
index f461c32..1a59afe 100644
--- a/hw/virtio-balloon.c
+++ b/hw/virtio-balloon.c
@@ -19,6 +19,10 @@
 #include "balloon.h"
 #include "virtio-balloon.h"
 #include "kvm.h"
+#include "monitor.h"
+#include "qlist.h"
+#include "qint.h"
+#include "qstring.h"
 
 #if defined(__linux__)
 #include <sys/mman.h>
@@ -27,9 +31,13 @@
 typedef struct VirtIOBalloon
 {
     VirtIODevice vdev;
-    VirtQueue *ivq, *dvq;
+    VirtQueue *ivq, *dvq, *svq;
     uint32_t num_pages;
     uint32_t actual;
+    uint64_t stats[VIRTIO_BALLOON_S_NR];
+    VirtQueueElement stats_vq_elem;
+    size_t stats_vq_offset;
+    uint8_t stats_requested;
 } VirtIOBalloon;
 
 static void balloon_page(void *addr, int deflate)
@@ -41,6 +49,35 @@ static void balloon_page(void *addr, int deflate)
 #endif
 }
 
+static inline void reset_stats(VirtIOBalloon *dev)
+{
+    int i;
+    for (i = 0; i < VIRTIO_BALLOON_S_NR; dev->stats[i++] = -1);
+}
+
+static void stat_put(QList *list, const char *label, uint64_t val)
+{
+    if (val != -1) {
+        qlist_append(list, qstring_from_str(label));
+        qlist_append(list, qint_from_int(val));
+    }
+}
+
+static QObject *get_stats_qobject(VirtIOBalloon *dev)
+{
+    QList *list = qlist_new();
+    uint32_t actual = ram_size - (dev->actual << VIRTIO_BALLOON_PFN_SHIFT);
+
+    stat_put(list, "actual", (int)actual >> 20);
+    stat_put(list, "mem_swapped_in", dev->stats[VIRTIO_BALLOON_S_SWAP_IN]);
+    stat_put(list, "mem_swapped_out", dev->stats[VIRTIO_BALLOON_S_SWAP_OUT]);
+    stat_put(list, "major_page_faults", dev->stats[VIRTIO_BALLOON_S_MAJFLT]);
+    stat_put(list, "minor_page_faults", dev->stats[VIRTIO_BALLOON_S_MINFLT]);
+    stat_put(list, "free_mem", dev->stats[VIRTIO_BALLOON_S_MEMFREE]);
+    stat_put(list, "total_mem", dev->stats[VIRTIO_BALLOON_S_MEMTOT]);
+    return QOBJECT(list);
+}
+
 /* FIXME: once we do a virtio refactoring, this will get subsumed into common
  * code */
 static size_t memcpy_from_iovector(void *data, size_t offset, size_t size,
@@ -99,6 +136,36 @@ static void virtio_balloon_handle_output(VirtIODevice *vdev, VirtQueue *vq)
     }
 }
 
+static void virtio_balloon_receive_stats(VirtIODevice *vdev, VirtQueue *vq)
+{
+    VirtIOBalloon *s = to_virtio_balloon(vdev);
+    VirtQueueElement *elem = &s->stats_vq_elem;
+    VirtIOBalloonStat stat;
+    size_t offset = 0;
+
+    if (!virtqueue_pop(vq, elem))
+        return;
+
+    while (memcpy_from_iovector(&stat, offset, sizeof(stat), elem->out_sg,
+                                elem->out_num) == sizeof(stat)) {
+        uint16_t tag = tswap16(stat.tag);
+        uint64_t val = tswap64(stat.val);
+
+        offset += sizeof(stat);
+        if (tag < VIRTIO_BALLOON_S_NR)
+            s->stats[tag] = val;
+    }
+    s->stats_vq_offset = offset;
+
+    if (s->stats_requested) {
+        QObject *stats = get_stats_qobject(s);
+        monitor_print_balloon(cur_mon, stats);
+        qobject_decref(stats);
+        monitor_resume(cur_mon);
+        s->stats_requested = 0;
+    }
+}
+
 static void virtio_balloon_get_config(VirtIODevice *vdev, uint8_t *config_data)
 {
     VirtIOBalloon *dev = DO_UPCAST(VirtIOBalloon, vdev, vdev);
@@ -121,12 +188,22 @@ static void virtio_balloon_set_config(VirtIODevice *vdev,
 
 static uint32_t virtio_balloon_get_features(VirtIODevice *vdev)
 {
-    return 0;
+    return 1 << VIRTIO_BALLOON_F_STATS_VQ;
+}
+
+static void request_stats(VirtIOBalloon *vb)
+{
+    vb->stats_requested = 1;
+    reset_stats(vb);
+    monitor_suspend(cur_mon);
+    virtqueue_push(vb->svq, &vb->stats_vq_elem, vb->stats_vq_offset);
+    virtio_notify(&vb->vdev, vb->svq);
 }
 
-static ram_addr_t virtio_balloon_to_target(void *opaque, ram_addr_t target)
+static QObject *virtio_balloon_to_target(void *opaque, ram_addr_t target)
 {
     VirtIOBalloon *dev = opaque;
+    QObject *ret = NULL;
 
     if (target > ram_size)
         target = ram_size;
@@ -134,9 +211,15 @@ static ram_addr_t virtio_balloon_to_target(void *opaque, ram_addr_t target)
     if (target) {
         dev->num_pages = (ram_size - target) >> VIRTIO_BALLOON_PFN_SHIFT;
         virtio_notify_config(&dev->vdev);
+    } else if (dev->vdev.features & (1 << VIRTIO_BALLOON_F_STATS_VQ)) {
+        request_stats(dev);
+        ret = QOBJECT(qlist_new());
+    } else {
+        reset_stats(dev);
+        ret = get_stats_qobject(dev);
     }
 
-    return ram_size - (dev->actual << VIRTIO_BALLOON_PFN_SHIFT);
+    return ret;
 }
 
 static const VMStateDescription vmstate_virtio_balloon = {
@@ -148,6 +231,9 @@ static const VMStateDescription vmstate_virtio_balloon = {
         VMSTATE_VIRTIO(vdev, VirtIOBalloon),
         VMSTATE_UINT32(num_pages, VirtIOBalloon),
         VMSTATE_UINT32(actual, VirtIOBalloon),
+        VMSTATE_BUFFER(stats_vq_elem, VirtIOBalloon),
+        VMSTATE_BUFFER(stats_vq_offset, VirtIOBalloon),
+        VMSTATE_UINT8(stats_requested, VirtIOBalloon),
         VMSTATE_END_OF_LIST()
     }
 };
@@ -166,6 +252,7 @@ VirtIODevice *virtio_balloon_init(DeviceState *dev)
 
     s->ivq = virtio_add_queue(&s->vdev, 128, virtio_balloon_handle_output);
     s->dvq = virtio_add_queue(&s->vdev, 128, virtio_balloon_handle_output);
+    s->svq = virtio_add_queue(&s->vdev, 128, virtio_balloon_receive_stats);
 
     qemu_add_balloon_handler(virtio_balloon_to_target, s);
 
diff --git a/hw/virtio-balloon.h b/hw/virtio-balloon.h
index 9a0d119..e20cf6b 100644
--- a/hw/virtio-balloon.h
+++ b/hw/virtio-balloon.h
@@ -25,6 +25,7 @@
 
 /* The feature bitmap for virtio balloon */
 #define VIRTIO_BALLOON_F_MUST_TELL_HOST 0 /* Tell before reclaiming pages */
+#define VIRTIO_BALLOON_F_STATS_VQ 1       /* Memory stats virtqueue */
 
 /* Size of a PFN in the balloon interface. */
 #define VIRTIO_BALLOON_PFN_SHIFT 12
@@ -37,4 +38,18 @@ struct virtio_balloon_config
     uint32_t actual;
 };
 
+/* Memory Statistics */
+#define VIRTIO_BALLOON_S_SWAP_IN  0   /* Amount of memory swapped in */
+#define VIRTIO_BALLOON_S_SWAP_OUT 1   /* Amount of memory swapped out */
+#define VIRTIO_BALLOON_S_MAJFLT   2   /* Number of major faults */
+#define VIRTIO_BALLOON_S_MINFLT   3   /* Number of minor faults */
+#define VIRTIO_BALLOON_S_MEMFREE  4   /* Total amount of free memory */
+#define VIRTIO_BALLOON_S_MEMTOT   5   /* Total amount of memory */
+#define VIRTIO_BALLOON_S_NR       6
+
+typedef struct VirtIOBalloonStat {
+    uint16_t tag;
+    uint64_t val;
+} __attribute__((packed)) VirtIOBalloonStat;
+
 #endif
diff --git a/monitor.c b/monitor.c
index 18aa22b..3bb9e95 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1886,10 +1886,26 @@ static void do_balloon(Monitor *mon, const QDict *qdict, QObject **ret_data)
     qemu_balloon(target << 20);
 }
 
-static void monitor_print_balloon(Monitor *mon, const QObject *data)
+void monitor_print_balloon(Monitor *mon, const QObject *data)
 {
-    monitor_printf(mon, "balloon: actual=%d\n",
-                                     (int)qint_get_int(qobject_to_qint(data)));
+    QList *list = qobject_to_qlist(data);
+    QString *label;
+    QInt *val;
+
+    if (qlist_empty(list))
+        return;
+
+    label = qobject_to_qstring(qlist_pop(list));
+    val = qobject_to_qint(qlist_pop(list));
+    monitor_printf(mon, "balloon: actual=%d", (int)qint_get_int(val));
+
+    while (!qlist_empty(list)) {
+        label = qobject_to_qstring(qlist_pop(list));
+        val = qobject_to_qint(qlist_pop(list));
+        monitor_printf(mon, ",%s=%lu", qstring_get_str(label),
+                       (uint64_t)qint_get_int(val));
+    } 
+    monitor_printf(mon, "\n");
 }
 
 /**
@@ -1897,15 +1913,11 @@ static void monitor_print_balloon(Monitor *mon, const QObject *data)
  */
 static void do_info_balloon(Monitor *mon, QObject **ret_data)
 {
-    ram_addr_t actual;
-
-    actual = qemu_balloon_status();
     if (kvm_enabled() && !kvm_has_sync_mmu())
         qemu_error_new(QERR_KVM_MISSING_CAP, "synchronous MMU", "balloon");
-    else if (actual == 0)
+    *ret_data = qemu_balloon_status();
+    if (*ret_data == NULL)
         qemu_error_new(QERR_DEVICE_NOT_ACTIVE, "balloon");
-    else
-        *ret_data = QOBJECT(qint_from_int((int)(actual >> 20)));
 }
 
 static qemu_acl *find_acl(Monitor *mon, const char *name)
diff --git a/monitor.h b/monitor.h
index 851fd33..0b5b99d 100644
--- a/monitor.h
+++ b/monitor.h
@@ -33,6 +33,7 @@ void monitor_resume(Monitor *mon);
 void monitor_read_bdrv_key_start(Monitor *mon, BlockDriverState *bs,
                                  BlockDriverCompletionFunc *completion_cb,
                                  void *opaque);
+void monitor_print_balloon(Monitor *mon, const QObject *data);
 
 int monitor_get_fd(Monitor *mon, const char *fdname);
 
diff --git a/vl.c b/vl.c
index d6f196c..aab03e9 100644
--- a/vl.c
+++ b/vl.c
@@ -331,11 +331,11 @@ void qemu_balloon(ram_addr_t target)
         qemu_balloon_event(qemu_balloon_event_opaque, target);
 }
 
-ram_addr_t qemu_balloon_status(void)
+QObject *qemu_balloon_status(void)
 {
     if (qemu_balloon_event)
         return qemu_balloon_event(qemu_balloon_event_opaque, 0);
-    return 0;
+    return NULL;
 }
 
 /***********************************************************/


-- 
Thanks,
Adam

[Qemu-devel] [FOR 0.12] [PATCH] Updated: virtio: Add memory statistics reporting to the balloon driver (V5)

[Adam Litke]

Updated to fix a compile problem with my vmstate conversion...

This iteration addresses all of the comments from the last round.  Thanks to
everyone for their careful reviews and helpful comments.  The most significant
change in this version is my use of the QObject API, so a concentrated review
in that area would be most appreciated.  I am hoping to target 0.12.0 with this
patch.  Please let me know if that remains a possibility.  Thanks.

Changes since V4:
 - Virtio spec updated: http://ozlabs.org/~rusty/virtio-spec/virtio-spec-0.8.2.pdf
 - Guest-side Linux implementation applied by Rusty
 - Start using the QObject infrastructure
 - All endian conversions done in the host
 - Report stats that reference a quantity of memory in bytes

Changes since V3:
 - Increase stat field size to 64 bits
 - Report all sizes in kb (not pages)
 - Drop anon_pages stat

Changes since V2:
 - Use a virtqueue for communication instead of the device config space

Changes since V1:
 - In the monitor, print all stats on one line with less abbreviated names
 - Coding style changes

When using ballooning to manage overcommitted memory on a host, a system for
guests to communicate their memory usage to the host can provide information
that will minimize the impact of ballooning on the guests.  The current method
employs a daemon running in each guest that communicates memory statistics to a
host daemon at a specified time interval.  The host daemon aggregates this
information and inflates and/or deflates balloons according to the level of
host memory pressure.  This approach is effective but overly complex since a
daemon must be installed inside each guest and coordinated to communicate with
the host.  A simpler approach is to collect memory statistics in the virtio
balloon driver and communicate them directly to the hypervisor.

This patch implements the qemu side of the communication channel.  I will post
the kernel driver modifications in-reply to this message.

Signed-off-by: Adam Litke <agl@us.ibm.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>
Cc: Avi Kivity <avi@redhat.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: qemu-devel@nongnu.org

diff --git a/balloon.h b/balloon.h
index 60b4a5d..23bbffe 100644
--- a/balloon.h
+++ b/balloon.h
@@ -16,12 +16,12 @@
 
 #include "cpu-defs.h"
 
-typedef ram_addr_t (QEMUBalloonEvent)(void *opaque, ram_addr_t target);
+typedef QObject *(QEMUBalloonEvent)(void *opaque, ram_addr_t target);
 
 void qemu_add_balloon_handler(QEMUBalloonEvent *func, void *opaque);
 
 void qemu_balloon(ram_addr_t target);
 
-ram_addr_t qemu_balloon_status(void);
+QObject *qemu_balloon_status(void);
 
 #endif
diff --git a/hw/virtio-balloon.c b/hw/virtio-balloon.c
index f461c32..47da6ab 100644
--- a/hw/virtio-balloon.c
+++ b/hw/virtio-balloon.c
@@ -19,6 +19,10 @@
 #include "balloon.h"
 #include "virtio-balloon.h"
 #include "kvm.h"
+#include "monitor.h"
+#include "qlist.h"
+#include "qint.h"
+#include "qstring.h"
 
 #if defined(__linux__)
 #include <sys/mman.h>
@@ -27,9 +31,13 @@
 typedef struct VirtIOBalloon
 {
     VirtIODevice vdev;
-    VirtQueue *ivq, *dvq;
+    VirtQueue *ivq, *dvq, *svq;
     uint32_t num_pages;
     uint32_t actual;
+    uint64_t stats[VIRTIO_BALLOON_S_NR];
+    VirtQueueElement stats_vq_elem;
+    size_t stats_vq_offset;
+    uint8_t stats_requested;
 } VirtIOBalloon;
 
 static void balloon_page(void *addr, int deflate)
@@ -41,6 +49,35 @@ static void balloon_page(void *addr, int deflate)
 #endif
 }
 
+static inline void reset_stats(VirtIOBalloon *dev)
+{
+    int i;
+    for (i = 0; i < VIRTIO_BALLOON_S_NR; dev->stats[i++] = -1);
+}
+
+static void stat_put(QList *list, const char *label, uint64_t val)
+{
+    if (val != -1) {
+        qlist_append(list, qstring_from_str(label));
+        qlist_append(list, qint_from_int(val));
+    }
+}
+
+static QObject *get_stats_qobject(VirtIOBalloon *dev)
+{
+    QList *list = qlist_new();
+    uint32_t actual = ram_size - (dev->actual << VIRTIO_BALLOON_PFN_SHIFT);
+
+    stat_put(list, "actual", (int)actual >> 20);
+    stat_put(list, "mem_swapped_in", dev->stats[VIRTIO_BALLOON_S_SWAP_IN]);
+    stat_put(list, "mem_swapped_out", dev->stats[VIRTIO_BALLOON_S_SWAP_OUT]);
+    stat_put(list, "major_page_faults", dev->stats[VIRTIO_BALLOON_S_MAJFLT]);
+    stat_put(list, "minor_page_faults", dev->stats[VIRTIO_BALLOON_S_MINFLT]);
+    stat_put(list, "free_mem", dev->stats[VIRTIO_BALLOON_S_MEMFREE]);
+    stat_put(list, "total_mem", dev->stats[VIRTIO_BALLOON_S_MEMTOT]);
+    return QOBJECT(list);
+}
+
 /* FIXME: once we do a virtio refactoring, this will get subsumed into common
  * code */
 static size_t memcpy_from_iovector(void *data, size_t offset, size_t size,
@@ -99,6 +136,36 @@ static void virtio_balloon_handle_output(VirtIODevice *vdev, VirtQueue *vq)
     }
 }
 
+static void virtio_balloon_receive_stats(VirtIODevice *vdev, VirtQueue *vq)
+{
+    VirtIOBalloon *s = DO_UPCAST(VirtIOBalloon, vdev, vdev);
+    VirtQueueElement *elem = &s->stats_vq_elem;
+    VirtIOBalloonStat stat;
+    size_t offset = 0;
+
+    if (!virtqueue_pop(vq, elem))
+        return;
+
+    while (memcpy_from_iovector(&stat, offset, sizeof(stat), elem->out_sg,
+                                elem->out_num) == sizeof(stat)) {
+        uint16_t tag = tswap16(stat.tag);
+        uint64_t val = tswap64(stat.val);
+
+        offset += sizeof(stat);
+        if (tag < VIRTIO_BALLOON_S_NR)
+            s->stats[tag] = val;
+    }
+    s->stats_vq_offset = offset;
+
+    if (s->stats_requested) {
+        QObject *stats = get_stats_qobject(s);
+        monitor_print_balloon(cur_mon, stats);
+        qobject_decref(stats);
+        monitor_resume(cur_mon);
+        s->stats_requested = 0;
+    }
+}
+
 static void virtio_balloon_get_config(VirtIODevice *vdev, uint8_t *config_data)
 {
     VirtIOBalloon *dev = DO_UPCAST(VirtIOBalloon, vdev, vdev);
@@ -121,12 +188,22 @@ static void virtio_balloon_set_config(VirtIODevice *vdev,
 
 static uint32_t virtio_balloon_get_features(VirtIODevice *vdev)
 {
-    return 0;
+    return 1 << VIRTIO_BALLOON_F_STATS_VQ;
+}
+
+static void request_stats(VirtIOBalloon *vb)
+{
+    vb->stats_requested = 1;
+    reset_stats(vb);
+    monitor_suspend(cur_mon);
+    virtqueue_push(vb->svq, &vb->stats_vq_elem, vb->stats_vq_offset);
+    virtio_notify(&vb->vdev, vb->svq);
 }
 
-static ram_addr_t virtio_balloon_to_target(void *opaque, ram_addr_t target)
+static QObject *virtio_balloon_to_target(void *opaque, ram_addr_t target)
 {
     VirtIOBalloon *dev = opaque;
+    QObject *ret = NULL;
 
     if (target > ram_size)
         target = ram_size;
@@ -134,9 +211,15 @@ static ram_addr_t virtio_balloon_to_target(void *opaque, ram_addr_t target)
     if (target) {
         dev->num_pages = (ram_size - target) >> VIRTIO_BALLOON_PFN_SHIFT;
         virtio_notify_config(&dev->vdev);
+    } else if (dev->vdev.features & (1 << VIRTIO_BALLOON_F_STATS_VQ)) {
+        request_stats(dev);
+        ret = QOBJECT(qlist_new());
+    } else {
+        reset_stats(dev);
+        ret = get_stats_qobject(dev);
     }
 
-    return ram_size - (dev->actual << VIRTIO_BALLOON_PFN_SHIFT);
+    return ret;
 }
 
 static const VMStateDescription vmstate_virtio_balloon = {
@@ -148,6 +231,10 @@ static const VMStateDescription vmstate_virtio_balloon = {
         VMSTATE_VIRTIO(vdev, VirtIOBalloon),
         VMSTATE_UINT32(num_pages, VirtIOBalloon),
         VMSTATE_UINT32(actual, VirtIOBalloon),
+        VMSTATE_STRUCT(stats_vq_elem, VirtIOBalloon, 0, vmstate_virtio_balloon,
+                       VirtQueueElement),
+        VMSTATE_UINT64(stats_vq_offset, VirtIOBalloon),
+        VMSTATE_UINT8(stats_requested, VirtIOBalloon),
         VMSTATE_END_OF_LIST()
     }
 };
@@ -166,6 +253,7 @@ VirtIODevice *virtio_balloon_init(DeviceState *dev)
 
     s->ivq = virtio_add_queue(&s->vdev, 128, virtio_balloon_handle_output);
     s->dvq = virtio_add_queue(&s->vdev, 128, virtio_balloon_handle_output);
+    s->svq = virtio_add_queue(&s->vdev, 128, virtio_balloon_receive_stats);
 
     qemu_add_balloon_handler(virtio_balloon_to_target, s);
 
diff --git a/hw/virtio-balloon.h b/hw/virtio-balloon.h
index 9a0d119..e20cf6b 100644
--- a/hw/virtio-balloon.h
+++ b/hw/virtio-balloon.h
@@ -25,6 +25,7 @@
 
 /* The feature bitmap for virtio balloon */
 #define VIRTIO_BALLOON_F_MUST_TELL_HOST 0 /* Tell before reclaiming pages */
+#define VIRTIO_BALLOON_F_STATS_VQ 1       /* Memory stats virtqueue */
 
 /* Size of a PFN in the balloon interface. */
 #define VIRTIO_BALLOON_PFN_SHIFT 12
@@ -37,4 +38,18 @@ struct virtio_balloon_config
     uint32_t actual;
 };
 
+/* Memory Statistics */
+#define VIRTIO_BALLOON_S_SWAP_IN  0   /* Amount of memory swapped in */
+#define VIRTIO_BALLOON_S_SWAP_OUT 1   /* Amount of memory swapped out */
+#define VIRTIO_BALLOON_S_MAJFLT   2   /* Number of major faults */
+#define VIRTIO_BALLOON_S_MINFLT   3   /* Number of minor faults */
+#define VIRTIO_BALLOON_S_MEMFREE  4   /* Total amount of free memory */
+#define VIRTIO_BALLOON_S_MEMTOT   5   /* Total amount of memory */
+#define VIRTIO_BALLOON_S_NR       6
+
+typedef struct VirtIOBalloonStat {
+    uint16_t tag;
+    uint64_t val;
+} __attribute__((packed)) VirtIOBalloonStat;
+
 #endif
diff --git a/monitor.c b/monitor.c
index 18aa22b..3bb9e95 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1886,10 +1886,26 @@ static void do_balloon(Monitor *mon, const QDict *qdict, QObject **ret_data)
     qemu_balloon(target << 20);
 }
 
-static void monitor_print_balloon(Monitor *mon, const QObject *data)
+void monitor_print_balloon(Monitor *mon, const QObject *data)
 {
-    monitor_printf(mon, "balloon: actual=%d\n",
-                                     (int)qint_get_int(qobject_to_qint(data)));
+    QList *list = qobject_to_qlist(data);
+    QString *label;
+    QInt *val;
+
+    if (qlist_empty(list))
+        return;
+
+    label = qobject_to_qstring(qlist_pop(list));
+    val = qobject_to_qint(qlist_pop(list));
+    monitor_printf(mon, "balloon: actual=%d", (int)qint_get_int(val));
+
+    while (!qlist_empty(list)) {
+        label = qobject_to_qstring(qlist_pop(list));
+        val = qobject_to_qint(qlist_pop(list));
+        monitor_printf(mon, ",%s=%lu", qstring_get_str(label),
+                       (uint64_t)qint_get_int(val));
+    } 
+    monitor_printf(mon, "\n");
 }
 
 /**
@@ -1897,15 +1913,11 @@ static void monitor_print_balloon(Monitor *mon, const QObject *data)
  */
 static void do_info_balloon(Monitor *mon, QObject **ret_data)
 {
-    ram_addr_t actual;
-
-    actual = qemu_balloon_status();
     if (kvm_enabled() && !kvm_has_sync_mmu())
         qemu_error_new(QERR_KVM_MISSING_CAP, "synchronous MMU", "balloon");
-    else if (actual == 0)
+    *ret_data = qemu_balloon_status();
+    if (*ret_data == NULL)
         qemu_error_new(QERR_DEVICE_NOT_ACTIVE, "balloon");
-    else
-        *ret_data = QOBJECT(qint_from_int((int)(actual >> 20)));
 }
 
 static qemu_acl *find_acl(Monitor *mon, const char *name)
diff --git a/monitor.h b/monitor.h
index 851fd33..0b5b99d 100644
--- a/monitor.h
+++ b/monitor.h
@@ -33,6 +33,7 @@ void monitor_resume(Monitor *mon);
 void monitor_read_bdrv_key_start(Monitor *mon, BlockDriverState *bs,
                                  BlockDriverCompletionFunc *completion_cb,
                                  void *opaque);
+void monitor_print_balloon(Monitor *mon, const QObject *data);
 
 int monitor_get_fd(Monitor *mon, const char *fdname);
 
diff --git a/vl.c b/vl.c
index d6f196c..aab03e9 100644
--- a/vl.c
+++ b/vl.c
@@ -331,11 +331,11 @@ void qemu_balloon(ram_addr_t target)
         qemu_balloon_event(qemu_balloon_event_opaque, target);
 }
 
-ram_addr_t qemu_balloon_status(void)
+QObject *qemu_balloon_status(void)
 {
     if (qemu_balloon_event)
         return qemu_balloon_event(qemu_balloon_event_opaque, 0);
-    return 0;
+    return NULL;
 }
 
 /***********************************************************/


-- 
Thanks,
Adam

[Qemu-devel] [FOR 0.12] debugcon patch for staging

[H. Peter Anvin]

[-- Attachment #1: Type: text/plain, Size: 480 bytes --]

It would be nice if the -debugcon patch could be considered for 0.12; I
realize it is a trivial thing (unless you do mixed Qemu/Bochs
debugging!), but it also shouldn't affect anything else in any
significant way.

Here is the patch rebased against your staging tree.  The SCSI code in
your staging tree doesn't compile for me, so I can't verify it is
actually OK.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


[-- Attachment #2: 0001-debugcon-support-for-debugging-consoles-e.g.-Bochs.patch --]
[-- Type: text/x-patch, Size: 6767 bytes --]

>From e76a33ee6516e92f1e7223d590c6870c1ec689c9 Mon Sep 17 00:00:00 2001
From: H. Peter Anvin <hpa@zytor.com>
Date: Thu, 19 Nov 2009 17:31:19 -0800
Subject: [PATCH] debugcon: support for debugging consoles (e.g. Bochs port 0xe9)

Add generic support for debugging consoles (simple I/O ports which
when written to cause debugging output to be written to a target.)
The current implementation matches Bochs' port 0xe9, allowing the same
debugging code to be used for both Bochs and Qemu.

There is no vm state associated with the debugging port, simply
because it has none -- the entire interface is a single, stateless,
write-only port.

Most of the code was cribbed from the serial port driver.

Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
---
 Makefile.target |    2 +-
 hw/debugcon.c   |  107 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 qemu-options.hx |   11 ++++++
 vl.c            |   12 ++++++
 4 files changed, 131 insertions(+), 1 deletions(-)
 create mode 100644 hw/debugcon.c

diff --git a/Makefile.target b/Makefile.target
index 956ae25..0eedbb5 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -194,7 +194,7 @@ obj-i386-y += fdc.o mc146818rtc.o serial.o i8259.o i8254.o pcspk.o pc.o
 obj-i386-y += cirrus_vga.o apic.o ioapic.o parallel.o acpi.o piix_pci.o
 obj-i386-y += usb-uhci.o vmmouse.o vmport.o vmware_vga.o hpet.o
 obj-i386-y += device-hotplug.o pci-hotplug.o smbios.o wdt_ib700.o
-obj-i386-y += ne2000-isa.o
+obj-i386-y += ne2000-isa.o debugcon.o
 
 # shared objects
 obj-ppc-y = ppc.o ide/core.o ide/qdev.o ide/isa.o ide/pci.o ide/macio.o
diff --git a/hw/debugcon.c b/hw/debugcon.c
new file mode 100644
index 0000000..d549091
--- /dev/null
+++ b/hw/debugcon.c
@@ -0,0 +1,107 @@
+/*
+ * QEMU Bochs-style debug console ("port E9") emulation
+ *
+ * Copyright (c) 2003-2004 Fabrice Bellard
+ * Copyright (c) 2008 Citrix Systems, Inc.
+ * Copyright (c) Intel Corporation; author: H. Peter Anvin
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include "hw.h"
+#include "qemu-char.h"
+#include "isa.h"
+#include "pc.h"
+
+//#define DEBUG_DEBUGCON
+
+typedef struct DebugconState {
+    CharDriverState *chr;
+    uint32_t readback;
+} DebugconState;
+
+typedef struct ISADebugconState {
+    ISADevice dev;
+    uint32_t iobase;
+    DebugconState state;
+} ISADebugconState;
+
+static void debugcon_ioport_write(void *opaque, uint32_t addr, uint32_t val)
+{
+    DebugconState *s = opaque;
+    unsigned char ch = val;
+
+#ifdef DEBUG_DEBUGCON
+    printf("debugcon: write addr=0x%04x val=0x%02x\n", addr, val);
+#endif
+
+    qemu_chr_write(s->chr, &ch, 1);
+}
+
+
+static uint32_t debugcon_ioport_read(void *opaque, uint32_t addr)
+{
+    DebugconState *s = opaque;
+
+#ifdef DEBUG_DEBUGCON
+    printf("debugcon: read addr=0x%04x\n", addr, val);
+#endif
+
+    return s->readback;
+}
+
+static void debugcon_init_core(DebugconState *s)
+{
+    if (!s->chr) {
+        fprintf(stderr, "Can't create debugcon device, empty char device\n");
+        exit(1);
+    }
+
+    qemu_chr_add_handlers(s->chr, NULL, NULL, NULL, s);
+}
+
+static int debugcon_isa_initfn(ISADevice *dev)
+{
+    ISADebugconState *isa = DO_UPCAST(ISADebugconState, dev, dev);
+    DebugconState *s = &isa->state;
+
+    debugcon_init_core(s);
+    register_ioport_write(isa->iobase, 1, 1, debugcon_ioport_write, s);
+    register_ioport_read(isa->iobase, 1, 1, debugcon_ioport_read, s);
+    return 0;
+}
+
+static ISADeviceInfo debugcon_isa_info = {
+    .qdev.name  = "isa-debugcon",
+    .qdev.size  = sizeof(ISADebugconState),
+    .init       = debugcon_isa_initfn,
+    .qdev.props = (Property[]) {
+        DEFINE_PROP_HEX32("iobase", ISADebugconState, iobase, 0xe9),
+        DEFINE_PROP_CHR("chardev",  ISADebugconState, state.chr),
+        DEFINE_PROP_HEX32("readback", ISADebugconState, state.readback, 0xe9),
+        DEFINE_PROP_END_OF_LIST(),
+    },
+};
+
+static void debugcon_register_devices(void)
+{
+    isa_qdev_register(&debugcon_isa_info);
+}
+
+device_init(debugcon_register_devices)
diff --git a/qemu-options.hx b/qemu-options.hx
index c9c60b5..f4015c4 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1590,6 +1590,17 @@ non graphical mode.
 The option @var{control} enables the QEMU Monitor Protocol.
 ETEXI
 
+DEF("debugcon", HAS_ARG, QEMU_OPTION_debugcon, \
+    "-debugcon dev   redirect the debug console to char device 'dev'\n")
+STEXI
+@item -debugcon @var{dev}
+Redirect the debug console to host device @var{dev} (same devices as the
+serial port).  The debug console is an I/O port which is typically port
+0xe9; writing to that I/O port sends output to this device.
+The default device is @code{vc} in graphical mode and @code{stdio} in
+non graphical mode.
+ETEXI
+
 DEF("pidfile", HAS_ARG, QEMU_OPTION_pidfile, \
     "-pidfile file   write PID to 'file'\n")
 STEXI
diff --git a/vl.c b/vl.c
index d6f196c..9cba3f3 100644
--- a/vl.c
+++ b/vl.c
@@ -5199,6 +5199,18 @@ int main(int argc, char **argv, char **envp)
                 parallel_devices[parallel_device_index] = optarg;
                 parallel_device_index++;
                 break;
+            case QEMU_OPTION_debugcon:
+                if (!qemu_chr_open("debugcon", optarg, NULL)) {
+                    exit(1);
+                }
+                opts = qemu_opts_create(&qemu_device_opts, "debugcon", 1);
+                if (!opts) {
+                    fprintf(stderr, "qemu: already have a debugcon device\n");
+                    exit(1);
+                }
+                qemu_opt_set(opts, "driver", "isa-debugcon");
+                qemu_opt_set(opts, "chardev", "debugcon");
+                break;
 	    case QEMU_OPTION_loadvm:
 		loadvm = optarg;
 		break;
-- 
1.6.2.5

Re: [Qemu-devel] Staging update (0.12 pending freeze)

[Aurelien Jarno]

On Wed, Dec 02, 2009 at 10:46:11AM -0600, Anthony Liguori wrote:
> I've got all of the patches I'm considering for 0.12 currently in
> staging.  I'm going to work through and test/commit these in a few
> chunks over the next few days before freezing the tree.
> 

What are the plans on the OpenBIOS side? The version currently included
in QEMU is old compared to the SVN. Is it plan to sync a release of
OpenBIOS with QEMU?

-- 
Aurelien Jarno                          GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

Re: [Qemu-devel] Staging update (0.12 pending freeze)

[Blue Swirl]

On Thu, Dec 3, 2009 at 9:26 PM, Aurelien Jarno <aurelien@aurel32.net> wrote:
> On Wed, Dec 02, 2009 at 10:46:11AM -0600, Anthony Liguori wrote:
>> I've got all of the patches I'm considering for 0.12 currently in
>> staging.  I'm going to work through and test/commit these in a few
>> chunks over the next few days before freezing the tree.
>>
>
> What are the plans on the OpenBIOS side? The version currently included
> in QEMU is old compared to the SVN. Is it plan to sync a release of
> OpenBIOS with QEMU?

At least the images should be updated.

Re: [Qemu-devel] Staging update (0.12 pending freeze)

[Aurelien Jarno]

On Thu, Dec 03, 2009 at 10:03:18PM +0200, Blue Swirl wrote:
> On Thu, Dec 3, 2009 at 9:26 PM, Aurelien Jarno <aurelien@aurel32.net> wrote:
> > On Wed, Dec 02, 2009 at 10:46:11AM -0600, Anthony Liguori wrote:
> >> I've got all of the patches I'm considering for 0.12 currently in
> >> staging.  I'm going to work through and test/commit these in a few
> >> chunks over the next few days before freezing the tree.
> >>
> >
> > What are the plans on the OpenBIOS side? The version currently included
> > in QEMU is old compared to the SVN. Is it plan to sync a release of
> > OpenBIOS with QEMU?
> 
> At least the images should be updated.
> 

Now that version 0.12.0-rca has been tagged, we should probably do that
asap. Should I do it?

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

Re: [Qemu-devel] Staging update (0.12 pending freeze)

[Blue Swirl]

On Sat, Dec 5, 2009 at 8:05 PM, Aurelien Jarno <aurelien@aurel32.net> wrote:
> On Thu, Dec 03, 2009 at 10:03:18PM +0200, Blue Swirl wrote:
>> On Thu, Dec 3, 2009 at 9:26 PM, Aurelien Jarno <aurelien@aurel32.net> wrote:
>> > On Wed, Dec 02, 2009 at 10:46:11AM -0600, Anthony Liguori wrote:
>> >> I've got all of the patches I'm considering for 0.12 currently in
>> >> staging.  I'm going to work through and test/commit these in a few
>> >> chunks over the next few days before freezing the tree.
>> >>
>> >
>> > What are the plans on the OpenBIOS side? The version currently included
>> > in QEMU is old compared to the SVN. Is it plan to sync a release of
>> > OpenBIOS with QEMU?
>>
>> At least the images should be updated.
>>
>
> Now that version 0.12.0-rca has been tagged, we should probably do that
> asap. Should I do it?

Please do.

Re: [Qemu-devel] Staging update (0.12 pending freeze)

[Aurelien Jarno]

On Sat, Dec 05, 2009 at 08:07:13PM +0000, Blue Swirl wrote:
> On Sat, Dec 5, 2009 at 8:05 PM, Aurelien Jarno <aurelien@aurel32.net> wrote:
> > On Thu, Dec 03, 2009 at 10:03:18PM +0200, Blue Swirl wrote:
> >> On Thu, Dec 3, 2009 at 9:26 PM, Aurelien Jarno <aurelien@aurel32.net> wrote:
> >> > On Wed, Dec 02, 2009 at 10:46:11AM -0600, Anthony Liguori wrote:
> >> >> I've got all of the patches I'm considering for 0.12 currently in
> >> >> staging.  I'm going to work through and test/commit these in a few
> >> >> chunks over the next few days before freezing the tree.
> >> >>
> >> >
> >> > What are the plans on the OpenBIOS side? The version currently included
> >> > in QEMU is old compared to the SVN. Is it plan to sync a release of
> >> > OpenBIOS with QEMU?
> >>
> >> At least the images should be updated.
> >>
> >
> > Now that version 0.12.0-rca has been tagged, we should probably do that
> > asap. Should I do it?
> 
> Please do.
> 

I have seen you have been faster than me, thanks.

Anyway I am not able to fully build the powerpc images here,
openbios-unix fails to build with:

| libmodules.a(elf-loader.o): In function `elf_loader_init_program':
| /home/aurel32/openbios-devel/obj-ppc/../modules/elf-loader.c:77: undefined reference to `flush_icache_range'
| libmodules.a(xcoff-loader.o): In function `xcoff_loader_init_program':
| /home/aurel32/openbios-devel/obj-ppc/../modules/xcoff-loader.c:110: undefined reference to `flush_icache_range'
| libmodules.a(ofmem_common.o): In function `ofmem_translate':
| /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:680: undefined reference to `ofmem_arch_get_private'
| libmodules.a(ofmem_common.o): In function `ofmem_free':
| /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:129: undefined reference to `ofmem_arch_get_private'
| libmodules.a(ofmem_common.o): In function `split_trans':
| /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:505: undefined reference to `ofmem_arch_get_private'
| libmodules.a(ofmem_common.o): In function `ofmem_claim_virt_':
| /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:422: undefined reference to `ofmem_arch_get_private'
| libmodules.a(ofmem_common.o): In function `ofmem_update_translations':
| /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:256: undefined reference to `ofmem_arch_get_private'
| libmodules.a(ofmem_common.o):/home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:35: more undefined references to `ofmem_arch_get_private' follow
| libmodules.a(ofmem_common.o): In function `unmap_page_range':
| /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:609: undefined reference to `ofmem_arch_unmap_pages'
| libmodules.a(ofmem_common.o): In function `ofmem_map_page_range':
| /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:524: undefined reference to `ofmem_arch_get_private'
| /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:551: undefined reference to `ofmem_arch_unmap_pages'
| libmodules.a(ofmem_common.o): In function `ofmem_map':
| /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:647: undefined reference to `ofmem_arch_default_translation_mode'
| /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:654: undefined reference to `ofmem_arch_early_map_pages'
| libmodules.a(ofmem_common.o): In function `ofmem_claim':
| /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:456: undefined reference to `ofmem_arch_get_private'
| libmodules.a(ofmem_common.o): In function `get_ram_size':
| /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:35: undefined reference to `ofmem_arch_get_private'
| /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:35: undefined reference to `ofmem_arch_get_private'
| /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:35: undefined reference to `ofmem_arch_get_private'
| libmodules.a(ofmem_common.o): In function `ofmem_claim_virt':
| /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:448: undefined reference to `ofmem_arch_get_virt_top'
| libmodules.a(ofmem_common.o): In function `ofmem_malloc':
| /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:83: undefined reference to `ofmem_arch_get_private'
| /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:92: undefined reference to `ofmem_arch_get_malloc_base'
| /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:108: undefined reference to `ofmem_arch_get_heap_top'
| collect2: ld returned 1 exit status
| make[1]: *** [openbios-unix] Error 1
| make[1]: Leaving directory `/home/aurel32/openbios-devel/obj-ppc'

This is something that needs to be fixed before an OpenBIOS release,
though I don't know if its planned to release OpenBIOS in sync with QEMU.

-- 
Aurelien Jarno                          GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

Re: [Qemu-devel] Staging update (0.12 pending freeze)

[Blue Swirl]

[-- Attachment #1: Type: text/plain, Size: 5097 bytes --]

On Sun, Dec 6, 2009 at 11:59 AM, Aurelien Jarno <aurelien@aurel32.net> wrote:
> On Sat, Dec 05, 2009 at 08:07:13PM +0000, Blue Swirl wrote:
>> On Sat, Dec 5, 2009 at 8:05 PM, Aurelien Jarno <aurelien@aurel32.net> wrote:
>> > On Thu, Dec 03, 2009 at 10:03:18PM +0200, Blue Swirl wrote:
>> >> On Thu, Dec 3, 2009 at 9:26 PM, Aurelien Jarno <aurelien@aurel32.net> wrote:
>> >> > On Wed, Dec 02, 2009 at 10:46:11AM -0600, Anthony Liguori wrote:
>> >> >> I've got all of the patches I'm considering for 0.12 currently in
>> >> >> staging.  I'm going to work through and test/commit these in a few
>> >> >> chunks over the next few days before freezing the tree.
>> >> >>
>> >> >
>> >> > What are the plans on the OpenBIOS side? The version currently included
>> >> > in QEMU is old compared to the SVN. Is it plan to sync a release of
>> >> > OpenBIOS with QEMU?
>> >>
>> >> At least the images should be updated.
>> >>
>> >
>> > Now that version 0.12.0-rca has been tagged, we should probably do that
>> > asap. Should I do it?
>>
>> Please do.
>>
>
> I have seen you have been faster than me, thanks.
>
> Anyway I am not able to fully build the powerpc images here,
> openbios-unix fails to build with:
>
> | libmodules.a(elf-loader.o): In function `elf_loader_init_program':
> | /home/aurel32/openbios-devel/obj-ppc/../modules/elf-loader.c:77: undefined reference to `flush_icache_range'
> | libmodules.a(xcoff-loader.o): In function `xcoff_loader_init_program':
> | /home/aurel32/openbios-devel/obj-ppc/../modules/xcoff-loader.c:110: undefined reference to `flush_icache_range'
> | libmodules.a(ofmem_common.o): In function `ofmem_translate':
> | /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:680: undefined reference to `ofmem_arch_get_private'
> | libmodules.a(ofmem_common.o): In function `ofmem_free':
> | /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:129: undefined reference to `ofmem_arch_get_private'
> | libmodules.a(ofmem_common.o): In function `split_trans':
> | /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:505: undefined reference to `ofmem_arch_get_private'
> | libmodules.a(ofmem_common.o): In function `ofmem_claim_virt_':
> | /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:422: undefined reference to `ofmem_arch_get_private'
> | libmodules.a(ofmem_common.o): In function `ofmem_update_translations':
> | /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:256: undefined reference to `ofmem_arch_get_private'
> | libmodules.a(ofmem_common.o):/home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:35: more undefined references to `ofmem_arch_get_private' follow
> | libmodules.a(ofmem_common.o): In function `unmap_page_range':
> | /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:609: undefined reference to `ofmem_arch_unmap_pages'
> | libmodules.a(ofmem_common.o): In function `ofmem_map_page_range':
> | /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:524: undefined reference to `ofmem_arch_get_private'
> | /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:551: undefined reference to `ofmem_arch_unmap_pages'
> | libmodules.a(ofmem_common.o): In function `ofmem_map':
> | /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:647: undefined reference to `ofmem_arch_default_translation_mode'
> | /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:654: undefined reference to `ofmem_arch_early_map_pages'
> | libmodules.a(ofmem_common.o): In function `ofmem_claim':
> | /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:456: undefined reference to `ofmem_arch_get_private'
> | libmodules.a(ofmem_common.o): In function `get_ram_size':
> | /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:35: undefined reference to `ofmem_arch_get_private'
> | /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:35: undefined reference to `ofmem_arch_get_private'
> | /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:35: undefined reference to `ofmem_arch_get_private'
> | libmodules.a(ofmem_common.o): In function `ofmem_claim_virt':
> | /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:448: undefined reference to `ofmem_arch_get_virt_top'
> | libmodules.a(ofmem_common.o): In function `ofmem_malloc':
> | /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:83: undefined reference to `ofmem_arch_get_private'
> | /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:92: undefined reference to `ofmem_arch_get_malloc_base'
> | /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:108: undefined reference to `ofmem_arch_get_heap_top'
> | collect2: ld returned 1 exit status
> | make[1]: *** [openbios-unix] Error 1
> | make[1]: Leaving directory `/home/aurel32/openbios-devel/obj-ppc'
>
> This is something that needs to be fixed before an OpenBIOS release,
> though I don't know if its planned to release OpenBIOS in sync with QEMU.

Does this patch fix the problem?

[-- Attachment #2: 0001-Fix-openbios-unix-compile-on-PPC.patch --]
[-- Type: application/mbox, Size: 2250 bytes --]

Re: [Qemu-devel] Staging update (0.12 pending freeze)

[Aurelien Jarno]

On Sun, Dec 06, 2009 at 03:44:59PM +0000, Blue Swirl wrote:
> On Sun, Dec 6, 2009 at 11:59 AM, Aurelien Jarno <aurelien@aurel32.net> wrote:
> > On Sat, Dec 05, 2009 at 08:07:13PM +0000, Blue Swirl wrote:
> >> On Sat, Dec 5, 2009 at 8:05 PM, Aurelien Jarno <aurelien@aurel32.net> wrote:
> >> > On Thu, Dec 03, 2009 at 10:03:18PM +0200, Blue Swirl wrote:
> >> >> On Thu, Dec 3, 2009 at 9:26 PM, Aurelien Jarno <aurelien@aurel32.net> wrote:
> >> >> > On Wed, Dec 02, 2009 at 10:46:11AM -0600, Anthony Liguori wrote:
> >> >> >> I've got all of the patches I'm considering for 0.12 currently in
> >> >> >> staging.  I'm going to work through and test/commit these in a few
> >> >> >> chunks over the next few days before freezing the tree.
> >> >> >>
> >> >> >
> >> >> > What are the plans on the OpenBIOS side? The version currently included
> >> >> > in QEMU is old compared to the SVN. Is it plan to sync a release of
> >> >> > OpenBIOS with QEMU?
> >> >>
> >> >> At least the images should be updated.
> >> >>
> >> >
> >> > Now that version 0.12.0-rca has been tagged, we should probably do that
> >> > asap. Should I do it?
> >>
> >> Please do.
> >>
> >
> > I have seen you have been faster than me, thanks.
> >
> > Anyway I am not able to fully build the powerpc images here,
> > openbios-unix fails to build with:
> >
> > | libmodules.a(elf-loader.o): In function `elf_loader_init_program':
> > | /home/aurel32/openbios-devel/obj-ppc/../modules/elf-loader.c:77: undefined reference to `flush_icache_range'
> > | libmodules.a(xcoff-loader.o): In function `xcoff_loader_init_program':
> > | /home/aurel32/openbios-devel/obj-ppc/../modules/xcoff-loader.c:110: undefined reference to `flush_icache_range'
> > | libmodules.a(ofmem_common.o): In function `ofmem_translate':
> > | /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:680: undefined reference to `ofmem_arch_get_private'
> > | libmodules.a(ofmem_common.o): In function `ofmem_free':
> > | /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:129: undefined reference to `ofmem_arch_get_private'
> > | libmodules.a(ofmem_common.o): In function `split_trans':
> > | /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:505: undefined reference to `ofmem_arch_get_private'
> > | libmodules.a(ofmem_common.o): In function `ofmem_claim_virt_':
> > | /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:422: undefined reference to `ofmem_arch_get_private'
> > | libmodules.a(ofmem_common.o): In function `ofmem_update_translations':
> > | /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:256: undefined reference to `ofmem_arch_get_private'
> > | libmodules.a(ofmem_common.o):/home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:35: more undefined references to `ofmem_arch_get_private' follow
> > | libmodules.a(ofmem_common.o): In function `unmap_page_range':
> > | /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:609: undefined reference to `ofmem_arch_unmap_pages'
> > | libmodules.a(ofmem_common.o): In function `ofmem_map_page_range':
> > | /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:524: undefined reference to `ofmem_arch_get_private'
> > | /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:551: undefined reference to `ofmem_arch_unmap_pages'
> > | libmodules.a(ofmem_common.o): In function `ofmem_map':
> > | /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:647: undefined reference to `ofmem_arch_default_translation_mode'
> > | /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:654: undefined reference to `ofmem_arch_early_map_pages'
> > | libmodules.a(ofmem_common.o): In function `ofmem_claim':
> > | /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:456: undefined reference to `ofmem_arch_get_private'
> > | libmodules.a(ofmem_common.o): In function `get_ram_size':
> > | /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:35: undefined reference to `ofmem_arch_get_private'
> > | /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:35: undefined reference to `ofmem_arch_get_private'
> > | /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:35: undefined reference to `ofmem_arch_get_private'
> > | libmodules.a(ofmem_common.o): In function `ofmem_claim_virt':
> > | /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:448: undefined reference to `ofmem_arch_get_virt_top'
> > | libmodules.a(ofmem_common.o): In function `ofmem_malloc':
> > | /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:83: undefined reference to `ofmem_arch_get_private'
> > | /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:92: undefined reference to `ofmem_arch_get_malloc_base'
> > | /home/aurel32/openbios-devel/obj-ppc/../modules/ofmem_common.c:108: undefined reference to `ofmem_arch_get_heap_top'
> > | collect2: ld returned 1 exit status
> > | make[1]: *** [openbios-unix] Error 1
> > | make[1]: Leaving directory `/home/aurel32/openbios-devel/obj-ppc'
> >
> > This is something that needs to be fixed before an OpenBIOS release,
> > though I don't know if its planned to release OpenBIOS in sync with QEMU.
> 
> Does this patch fix the problem?

Not it's worse. With the CONFIG_OFMEM, openbios-qemu.elf doesn't build
anymore. With only the flush_icache_range, I see no change.

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

Re: [Qemu-devel] Staging update (0.12 pending freeze)

[Kevin Wolf]

Am 02.12.2009 17:46, schrieb Anthony Liguori:
> I've got all of the patches I'm considering for 0.12 currently in 
> staging.  I'm going to work through and test/commit these in a few 
> chunks over the next few days before freezing the tree.

You seem to have missed this one:

qemu-io: Fix memory leak
http://patchwork.ozlabs.org/patch/38738/

Kevin