Re: [Qemu-devel] [PATCH v2 1/9] block: Add COR filter driver

2018-04-25 Thread Alberto Garcia
On Wed 25 Apr 2018 01:18:03 PM CEST, Max Reitz wrote:

>>> +#define PERM_PASSTHROUGH (BLK_PERM_CONSISTENT_READ \
>>> +  | BLK_PERM_WRITE \
>>> +  | BLK_PERM_RESIZE)
>>> +#define PERM_UNCHANGED (BLK_PERM_ALL & ~PERM_PASSTHROUGH)
>>> +
>>> +static void cor_child_perm(BlockDriverState *bs, BdrvChild *c,
>>> +   const BdrvChildRole *role,
>>> +   BlockReopenQueue *reopen_queue,
>>> +   uint64_t perm, uint64_t shared,
>>> +   uint64_t *nperm, uint64_t *nshared)
>>> +{
>>> +if (c == NULL) {
>>> +*nperm = (perm & PERM_PASSTHROUGH) | BLK_PERM_WRITE_UNCHANGED;
>>> +*nshared = (shared & PERM_PASSTHROUGH) | PERM_UNCHANGED;
>>> +return;
>>> +}
>>> +
>>> +*nperm = (perm & PERM_PASSTHROUGH) |
>>> + (c->perm & PERM_UNCHANGED);
>> 
>> I admit I'm not completely familiar with this, but don't you need to
>> add BLK_PERM_WRITE_UNCHANGED to *nperm ?
>
> As long as it's requested in when the child is attached (which it is
> in the "c == NULL" case), it should be part of c->perm then.
>
> (And since PERM_PASSTHROUGH does not contain WRITE_UNCHANGED, it is
> part of PERM_UNCHANGED.)

I see, thanks.

Reviewed-by: Alberto Garcia 

Berto



[Qemu-devel] [PATCH v12 21/21] migration: Stop sending whole pages through main channel

2018-04-25 Thread Juan Quintela
We have to flush() the QEMUFile because now we sent really few data
through that channel.

Signed-off-by: Juan Quintela 
---
 migration/ram.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/migration/ram.c b/migration/ram.c
index 23203756b7..f5cff2eb59 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -1634,20 +1634,12 @@ static int ram_multifd_page(RAMState *rs, 
PageSearchStatus *pss,
 bool last_stage)
 {
 int pages;
-uint8_t *p;
 RAMBlock *block = pss->block;
 ram_addr_t offset = pss->page << TARGET_PAGE_BITS;
 
-p = block->host + offset;
-
 pages = save_zero_page(rs, block, offset);
 if (pages == -1) {
-ram_counters.transferred +=
-save_page_header(rs, rs->f, block,
- offset | RAM_SAVE_FLAG_PAGE);
 multifd_queue_page(block, offset);
-qemu_put_buffer(rs->f, p, TARGET_PAGE_SIZE);
-ram_counters.transferred += TARGET_PAGE_SIZE;
 pages = 1;
 ram_counters.normal++;
 }
@@ -2869,6 +2861,7 @@ static int ram_save_setup(QEMUFile *f, void *opaque)
 
 multifd_send_sync_main();
 qemu_put_be64(f, RAM_SAVE_FLAG_EOS);
+qemu_fflush(f);
 
 return 0;
 }
@@ -2946,6 +2939,7 @@ static int ram_save_iterate(QEMUFile *f, void *opaque)
 multifd_send_sync_main();
 out:
 qemu_put_be64(f, RAM_SAVE_FLAG_EOS);
+qemu_fflush(f);
 ram_counters.transferred += 8;
 
 ret = qemu_file_get_error(f);
@@ -2999,6 +2993,7 @@ static int ram_save_complete(QEMUFile *f, void *opaque)
 
 multifd_send_sync_main();
 qemu_put_be64(f, RAM_SAVE_FLAG_EOS);
+qemu_fflush(f);
 
 return 0;
 }
-- 
2.17.0




[Qemu-devel] [PATCH v12 18/21] migration: Start sending messages

2018-04-25 Thread Juan Quintela
Signed-off-by: Juan Quintela 
---
 migration/ram.c | 30 --
 1 file changed, 24 insertions(+), 6 deletions(-)

diff --git a/migration/ram.c b/migration/ram.c
index 862ec53d32..9adbaa81f9 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -625,9 +625,6 @@ static int multifd_recv_unfill_packet(MultiFDRecvParams *p, 
Error **errp)
 RAMBlock *block;
 int i;
 
-/* ToDo: We can't use it until we haven't received a message */
-return 0;
-
 be32_to_cpus(>magic);
 if (packet->magic != MULTIFD_MAGIC) {
 error_setg(errp, "multifd: received packet "
@@ -851,6 +848,7 @@ static void *multifd_send_thread(void *opaque)
 {
 MultiFDSendParams *p = opaque;
 Error *local_err = NULL;
+int ret;
 
 trace_multifd_send_thread_start(p->id);
 
@@ -878,10 +876,18 @@ static void *multifd_send_thread(void *opaque)
 
 trace_multifd_send(p->id, seq, used, flags);
 
-/* ToDo: send packet here */
+ret = qio_channel_write_all(p->c, (void *)p->packet,
+p->packet_len, _err);
+if (ret != 0) {
+break;
+}
+
+ret = qio_channel_writev_all(p->c, p->pages->iov, used, 
_err);
+if (ret != 0) {
+break;
+}
 
 qemu_mutex_lock(>mutex);
-p->flags = 0;
 p->pending_job--;
 qemu_mutex_unlock(>mutex);
 
@@ -1091,7 +1097,14 @@ static void *multifd_recv_thread(void *opaque)
 uint32_t flags;
 qemu_mutex_unlock(>mutex);
 
-/* ToDo: recv packet here */
+ret = qio_channel_read_all_eof(p->c, (void *)p->packet,
+   p->packet_len, _err);
+if (ret == 0) {   /* EOF */
+break;
+}
+if (ret == -1) {   /* Error */
+break;
+}
 
 qemu_mutex_lock(>mutex);
 ret = multifd_recv_unfill_packet(p, _err);
@@ -1108,6 +1121,11 @@ static void *multifd_recv_thread(void *opaque)
 p->num_pages += used;
 qemu_mutex_unlock(>mutex);
 
+ret = qio_channel_readv_all(p->c, p->pages->iov, used, _err);
+if (ret != 0) {
+break;
+}
+
 if (flags & MULTIFD_FLAG_SYNC) {
 qemu_sem_post(_recv_state->sem_sync);
 qemu_sem_wait(>sem_sync);
-- 
2.17.0




[Qemu-devel] [PATCH v12 15/21] migration: Add block where to send/receive packets

2018-04-25 Thread Juan Quintela
Once there add tracepoints.

Signed-off-by: Juan Quintela 
---
 migration/ram.c| 49 +-
 migration/trace-events |  2 ++
 2 files changed, 46 insertions(+), 5 deletions(-)

diff --git a/migration/ram.c b/migration/ram.c
index 21b448c4ed..c4c185cc4c 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -455,6 +455,8 @@ typedef struct {
 bool running;
 /* should this thread finish */
 bool quit;
+/* thread has work to do */
+int pending_job;
 /* array of pages to sent */
 MultiFDPages_t *pages;
 /* packet allocated len */
@@ -489,6 +491,8 @@ typedef struct {
 bool running;
 /* should this thread finish */
 bool quit;
+/* thread has work to do */
+bool pending_job;
 /* array of pages to receive */
 MultiFDPages_t *pages;
 /* packet allocated len */
@@ -756,8 +760,28 @@ static void *multifd_send_thread(void *opaque)
 while (true) {
 qemu_sem_wait(>sem);
 qemu_mutex_lock(>mutex);
-multifd_send_fill_packet(p);
-if (p->quit) {
+
+if (p->pending_job) {
+uint32_t used = p->pages->used;
+uint32_t seq = p->seq;
+uint32_t flags = p->flags;
+
+multifd_send_fill_packet(p);
+p->flags = 0;
+p->num_packets++;
+p->num_pages += used;
+p->pages->used = 0;
+qemu_mutex_unlock(>mutex);
+
+trace_multifd_send(p->id, seq, used, flags);
+
+/* ToDo: send packet here */
+
+qemu_mutex_lock(>mutex);
+p->pending_job--;
+qemu_mutex_unlock(>mutex);
+continue;
+} else if (p->quit) {
 qemu_mutex_unlock(>mutex);
 break;
 }
@@ -823,6 +847,7 @@ int multifd_save_setup(void)
 qemu_mutex_init(>mutex);
 qemu_sem_init(>sem, 0);
 p->quit = false;
+p->pending_job = 0;
 p->id = i;
 multifd_pages_init(>pages, page_count);
 p->packet_len = sizeof(MultiFDPacket_t)
@@ -910,14 +935,27 @@ static void *multifd_recv_thread(void *opaque)
 while (true) {
 qemu_sem_wait(>sem);
 qemu_mutex_lock(>mutex);
-if (false)  {
-/* ToDo: Packet reception goes here */
+if (p->pending_job) {
+uint32_t used;
+uint32_t flags;
+qemu_mutex_unlock(>mutex);
 
+/* ToDo: recv packet here */
+
+qemu_mutex_lock(>mutex);
 ret = multifd_recv_unfill_packet(p, _err);
-qemu_mutex_unlock(>mutex);
 if (ret) {
+qemu_mutex_unlock(>mutex);
 break;
 }
+
+used = p->pages->used;
+flags = p->flags;
+trace_multifd_recv(p->id, p->seq, used, flags);
+p->pending_job = false;
+p->num_packets++;
+p->num_pages += used;
+qemu_mutex_unlock(>mutex);
 } else if (p->quit) {
 qemu_mutex_unlock(>mutex);
 break;
@@ -960,6 +998,7 @@ int multifd_load_setup(void)
 qemu_mutex_init(>mutex);
 qemu_sem_init(>sem, 0);
 p->quit = false;
+p->pending_job = false;
 p->id = i;
 multifd_pages_init(>pages, page_count);
 p->packet_len = sizeof(MultiFDPacket_t)
diff --git a/migration/trace-events b/migration/trace-events
index e480eb050e..9eee048287 100644
--- a/migration/trace-events
+++ b/migration/trace-events
@@ -81,6 +81,8 @@ multifd_send_thread_start(uint8_t id) "%d"
 multifd_send_thread_end(uint8_t id, uint32_t packets, uint32_t pages) "channel 
%d packets %d pages %d"
 multifd_recv_thread_start(uint8_t id) "%d"
 multifd_recv_thread_end(uint8_t id, uint32_t packets, uint32_t pages) "channel 
%d packets %d pages %d"
+multifd_send(uint8_t id, uint32_t seq, uint32_t used, uint32_t flags) "channel 
%d seq number %d pages %d flags 0x%x"
+multifd_recv(uint8_t id, uint32_t seq, uint32_t used, uint32_t flags) "channel 
%d seq number %d pages %d flags 0x%x"
 
 # migration/migration.c
 await_return_path_close_on_source_close(void) ""
-- 
2.17.0




[Qemu-devel] [PATCH v12 20/21] migration: Remove not needed semaphore and quit

2018-04-25 Thread Juan Quintela
We know quit closing the QIO.

Signed-off-by: Juan Quintela 
---
 migration/ram.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/migration/ram.c b/migration/ram.c
index 2734f91ded..23203756b7 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -488,14 +488,10 @@ typedef struct {
 QemuThread thread;
 /* communication channel */
 QIOChannel *c;
-/* sem where to wait for more work */
-QemuSemaphore sem;
 /* this mutex protects the following parameters */
 QemuMutex mutex;
 /* is this channel thread running */
 bool running;
-/* should this thread finish */
-bool quit;
 /* array of pages to receive */
 MultiFDPages_t *pages;
 /* packet allocated len */
@@ -1001,8 +997,8 @@ static void multifd_recv_terminate_threads(Error *err)
 MultiFDRecvParams *p = _recv_state->params[i];
 
 qemu_mutex_lock(>mutex);
-p->quit = true;
-qemu_sem_post(>sem);
+object_unref(OBJECT(p->c));
+p->c = NULL;
 qemu_mutex_unlock(>mutex);
 }
 }
@@ -1025,7 +1021,6 @@ int multifd_load_cleanup(Error **errp)
 object_unref(OBJECT(p->c));
 p->c = NULL;
 qemu_mutex_destroy(>mutex);
-qemu_sem_destroy(>sem);
 qemu_sem_destroy(>sem_sync);
 g_free(p->name);
 p->name = NULL;
@@ -1148,9 +1143,7 @@ int multifd_load_setup(void)
 MultiFDRecvParams *p = _recv_state->params[i];
 
 qemu_mutex_init(>mutex);
-qemu_sem_init(>sem, 0);
 qemu_sem_init(>sem_sync, 0);
-p->quit = false;
 p->id = i;
 multifd_pages_init(>pages, page_count);
 p->packet_len = sizeof(MultiFDPacket_t)
-- 
2.17.0




[Qemu-devel] [PATCH v12 13/21] migration: Calculate transferred ram correctly

2018-04-25 Thread Juan Quintela
On multifd we send data from more places that main channel.

Signed-off-by: Juan Quintela 
---
 migration/migration.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/migration/migration.c b/migration/migration.c
index 9b510a809a..75d30661e9 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -2246,12 +2246,19 @@ static void migration_update_counters(MigrationState *s,
 {
 uint64_t transferred, time_spent;
 double bandwidth;
+uint64_t now;
 
 if (current_time < s->iteration_start_time + BUFFER_DELAY) {
 return;
 }
 
-transferred = qemu_ftell(s->to_dst_file) - s->iteration_initial_bytes;
+if (migrate_use_multifd()) {
+now = ram_counters.normal * qemu_target_page_size()
++ qemu_ftell(s->to_dst_file);
+} else {
+now = qemu_ftell(s->to_dst_file);
+}
+transferred = now - s->iteration_initial_bytes;
 time_spent = current_time - s->iteration_start_time;
 bandwidth = (double)transferred / time_spent;
 s->threshold_size = bandwidth * s->parameters.downtime_limit;
@@ -2271,7 +2278,7 @@ static void migration_update_counters(MigrationState *s,
 qemu_file_reset_rate_limit(s->to_dst_file);
 
 s->iteration_start_time = current_time;
-s->iteration_initial_bytes = qemu_ftell(s->to_dst_file);
+s->iteration_initial_bytes = now;
 
 trace_migrate_transferred(transferred, time_spent,
   bandwidth, s->threshold_size);
-- 
2.17.0




[Qemu-devel] [PATCH v12 12/21] migration: Add multifd traces for start/end thread

2018-04-25 Thread Juan Quintela
We want to know how many pages/packets each channel has sent.  Add
counters for those.

Signed-off-by: Juan Quintela 
---
 migration/ram.c| 20 
 migration/trace-events |  4 
 2 files changed, 24 insertions(+)

diff --git a/migration/ram.c b/migration/ram.c
index 804c83ed89..0f1340b4e3 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -465,6 +465,10 @@ typedef struct {
 uint32_t flags;
 /* global number of generated multifd packets */
 uint32_t seq;
+/* packets sent through this channel */
+uint32_t num_packets;
+/* pages sent through this channel */
+uint32_t num_pages;
 }  MultiFDSendParams;
 
 typedef struct {
@@ -495,6 +499,10 @@ typedef struct {
 uint32_t flags;
 /* global number of generated multifd packets */
 uint32_t seq;
+/* packets sent through this channel */
+uint32_t num_packets;
+/* pages sent through this channel */
+uint32_t num_pages;
 } MultiFDRecvParams;
 
 static int multifd_send_initial_packet(MultiFDSendParams *p, Error **errp)
@@ -737,9 +745,13 @@ static void *multifd_send_thread(void *opaque)
 MultiFDSendParams *p = opaque;
 Error *local_err = NULL;
 
+trace_multifd_send_thread_start(p->id);
+
 if (multifd_send_initial_packet(p, _err) < 0) {
 goto out;
 }
+/* initial packet */
+p->num_packets = 1;
 
 while (true) {
 qemu_mutex_lock(>mutex);
@@ -761,6 +773,8 @@ out:
 p->running = false;
 qemu_mutex_unlock(>mutex);
 
+trace_multifd_send_thread_end(p->id, p->num_packets, p->num_pages);
+
 return NULL;
 }
 
@@ -888,6 +902,8 @@ static void *multifd_recv_thread(void *opaque)
 Error *local_err = NULL;
 int ret;
 
+trace_multifd_recv_thread_start(p->id);
+
 while (true) {
 qemu_mutex_lock(>mutex);
 if (false)  {
@@ -910,6 +926,8 @@ static void *multifd_recv_thread(void *opaque)
 p->running = false;
 qemu_mutex_unlock(>mutex);
 
+trace_multifd_recv_thread_end(p->id, p->num_packets, p->num_pages);
+
 return NULL;
 }
 
@@ -975,6 +993,8 @@ void multifd_recv_new_channel(QIOChannel *ioc)
 }
 p->c = ioc;
 object_ref(OBJECT(ioc));
+/* initial packet */
+p->num_packets = 1;
 
 p->running = true;
 qemu_thread_create(>thread, p->name, multifd_recv_thread, p,
diff --git a/migration/trace-events b/migration/trace-events
index a180d7b008..e480eb050e 100644
--- a/migration/trace-events
+++ b/migration/trace-events
@@ -77,6 +77,10 @@ ram_load_postcopy_loop(uint64_t addr, int flags) "@%" PRIx64 
" %x"
 ram_postcopy_send_discard_bitmap(void) ""
 ram_save_page(const char *rbname, uint64_t offset, void *host) "%s: offset: 
0x%" PRIx64 " host: %p"
 ram_save_queue_pages(const char *rbname, size_t start, size_t len) "%s: start: 
0x%zx len: 0x%zx"
+multifd_send_thread_start(uint8_t id) "%d"
+multifd_send_thread_end(uint8_t id, uint32_t packets, uint32_t pages) "channel 
%d packets %d pages %d"
+multifd_recv_thread_start(uint8_t id) "%d"
+multifd_recv_thread_end(uint8_t id, uint32_t packets, uint32_t pages) "channel 
%d packets %d pages %d"
 
 # migration/migration.c
 await_return_path_close_on_source_close(void) ""
-- 
2.17.0




[Qemu-devel] [PATCH v12 14/21] migration: Multifd channels always wait on the sem

2018-04-25 Thread Juan Quintela
Either for quit, sync or packet, we first wake them.

Signed-off-by: Juan Quintela 
---
 migration/ram.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/migration/ram.c b/migration/ram.c
index 0f1340b4e3..21b448c4ed 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -754,6 +754,7 @@ static void *multifd_send_thread(void *opaque)
 p->num_packets = 1;
 
 while (true) {
+qemu_sem_wait(>sem);
 qemu_mutex_lock(>mutex);
 multifd_send_fill_packet(p);
 if (p->quit) {
@@ -761,7 +762,9 @@ static void *multifd_send_thread(void *opaque)
 break;
 }
 qemu_mutex_unlock(>mutex);
-qemu_sem_wait(>sem);
+/* this is impossible */
+error_setg(_err, "multifd_send_thread: Unknown command");
+break;
 }
 
 out:
@@ -905,6 +908,7 @@ static void *multifd_recv_thread(void *opaque)
 trace_multifd_recv_thread_start(p->id);
 
 while (true) {
+qemu_sem_wait(>sem);
 qemu_mutex_lock(>mutex);
 if (false)  {
 /* ToDo: Packet reception goes here */
@@ -919,9 +923,14 @@ static void *multifd_recv_thread(void *opaque)
 break;
 }
 qemu_mutex_unlock(>mutex);
-qemu_sem_wait(>sem);
+/* this is impossible */
+error_setg(_err, "multifd_recv_thread: Unknown command");
+break;
 }
 
+if (local_err) {
+multifd_recv_terminate_threads(local_err);
+}
 qemu_mutex_lock(>mutex);
 p->running = false;
 qemu_mutex_unlock(>mutex);
-- 
2.17.0




[Qemu-devel] [PATCH v12 08/21] migration: Transmit initial package through the multifd channels

2018-04-25 Thread Juan Quintela
Signed-off-by: Juan Quintela 
Reviewed-by: Daniel P. Berrangé 

--

Be network agnostic.
Add error checking for all values.
---
 migration/ram.c | 101 +---
 1 file changed, 96 insertions(+), 5 deletions(-)

diff --git a/migration/ram.c b/migration/ram.c
index 5a87d74862..1aab392d8f 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -52,6 +52,8 @@
 #include "qemu/rcu_queue.h"
 #include "migration/colo.h"
 #include "migration/block.h"
+#include "sysemu/sysemu.h"
+#include "qemu/uuid.h"
 
 /***/
 /* ram save/restore */
@@ -400,6 +402,16 @@ static void compress_threads_save_setup(void)
 
 /* Multiple fd's */
 
+#define MULTIFD_MAGIC 0x11223344U
+#define MULTIFD_VERSION 1
+
+typedef struct {
+uint32_t magic;
+uint32_t version;
+unsigned char uuid[16]; /* QemuUUID */
+uint8_t id;
+} __attribute__((packed)) MultiFDInit_t;
+
 struct MultiFDSendParams {
 uint8_t id;
 char *name;
@@ -412,6 +424,65 @@ struct MultiFDSendParams {
 };
 typedef struct MultiFDSendParams MultiFDSendParams;
 
+static int multifd_send_initial_packet(MultiFDSendParams *p, Error **errp)
+{
+MultiFDInit_t msg;
+int ret;
+
+msg.magic = cpu_to_be32(MULTIFD_MAGIC);
+msg.version = cpu_to_be32(MULTIFD_VERSION);
+msg.id = p->id;
+memcpy(msg.uuid, _uuid.data, sizeof(msg.uuid));
+
+ret = qio_channel_write_all(p->c, (char *), sizeof(msg), errp);
+if (ret != 0) {
+return -1;
+}
+return 0;
+}
+
+static int multifd_recv_initial_packet(QIOChannel *c, Error **errp)
+{
+MultiFDInit_t msg;
+int ret;
+
+ret = qio_channel_read_all(c, (char *), sizeof(msg), errp);
+if (ret != 0) {
+return -1;
+}
+
+be32_to_cpus();
+be32_to_cpus();
+
+if (msg.magic != MULTIFD_MAGIC) {
+error_setg(errp, "multifd: received packet magic %d "
+   "expected %d", msg.magic, MULTIFD_MAGIC);
+return -1;
+}
+
+if (msg.version != MULTIFD_VERSION) {
+error_setg(errp, "multifd: received packet version %d "
+   "expected %d", msg.version, MULTIFD_VERSION);
+return -1;
+}
+
+if (memcmp(msg.uuid, _uuid, sizeof(qemu_uuid))) {
+char *uuid = qemu_uuid_unparse_strdup(_uuid);
+error_setg(errp, "multifd: received uuid '%s' and expected "
+   "uuid '%s' for channel %hhd", msg.uuid, uuid, msg.id);
+g_free(uuid);
+return -1;
+}
+
+if (msg.id > migrate_multifd_channels()) {
+error_setg(errp, "multifd: received channel version %d "
+   "expected %d", msg.version, MULTIFD_VERSION);
+return -1;
+}
+
+return msg.id;
+}
+
 struct {
 MultiFDSendParams *params;
 /* number of created threads */
@@ -474,6 +545,11 @@ int multifd_save_cleanup(Error **errp)
 static void *multifd_send_thread(void *opaque)
 {
 MultiFDSendParams *p = opaque;
+Error *local_err = NULL;
+
+if (multifd_send_initial_packet(p, _err) < 0) {
+goto out;
+}
 
 while (true) {
 qemu_mutex_lock(>mutex);
@@ -485,6 +561,11 @@ static void *multifd_send_thread(void *opaque)
 qemu_sem_wait(>sem);
 }
 
+out:
+if (local_err) {
+multifd_send_terminate_threads(local_err);
+}
+
 qemu_mutex_lock(>mutex);
 p->running = false;
 qemu_mutex_unlock(>mutex);
@@ -669,12 +750,22 @@ bool multifd_recv_all_channels_created(void)
 void multifd_recv_new_channel(QIOChannel *ioc)
 {
 MultiFDRecvParams *p;
-/* we need to invent channels id's until we transmit */
-/* we will remove this on a later patch */
-static int i;
+Error *local_err = NULL;
+int id;
 
-p = _recv_state->params[i];
-i++;
+id = multifd_recv_initial_packet(ioc, _err);
+if (id < 0) {
+multifd_recv_terminate_threads(local_err);
+return;
+}
+
+p = _recv_state->params[id];
+if (p->c != NULL) {
+error_setg(_err, "multifd: received id '%d' already setup'",
+   id);
+multifd_recv_terminate_threads(local_err);
+return;
+}
 p->c = ioc;
 object_ref(OBJECT(ioc));
 
-- 
2.17.0




[Qemu-devel] [PATCH v12 19/21] migration: Wait for blocking IO

2018-04-25 Thread Juan Quintela
We have three conditions here:
- channel fails -> error
- we have to quit: we close the channel and reads fails
- normal read that success, we are in bussiness

So forget the complications of waiting in a semaphore.

Signed-off-by: Juan Quintela 
---
 migration/ram.c | 81 ++---
 1 file changed, 29 insertions(+), 52 deletions(-)

diff --git a/migration/ram.c b/migration/ram.c
index 9adbaa81f9..2734f91ded 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -496,8 +496,6 @@ typedef struct {
 bool running;
 /* should this thread finish */
 bool quit;
-/* thread has work to do */
-bool pending_job;
 /* array of pages to receive */
 MultiFDPages_t *pages;
 /* packet allocated len */
@@ -1056,14 +1054,6 @@ static void multifd_recv_sync_main(void)
 for (i = 0; i < migrate_multifd_channels(); i++) {
 MultiFDRecvParams *p = _recv_state->params[i];
 
-trace_multifd_recv_sync_main_signal(p->id);
-qemu_mutex_lock(>mutex);
-p->pending_job = true;
-qemu_mutex_unlock(>mutex);
-}
-for (i = 0; i < migrate_multifd_channels(); i++) {
-MultiFDRecvParams *p = _recv_state->params[i];
-
 trace_multifd_recv_sync_main_wait(p->id);
 qemu_sem_wait(_recv_state->sem_sync);
 qemu_mutex_lock(>mutex);
@@ -1076,7 +1066,6 @@ static void multifd_recv_sync_main(void)
 MultiFDRecvParams *p = _recv_state->params[i];
 
 trace_multifd_recv_sync_main_signal(p->id);
-
 qemu_sem_post(>sem_sync);
 }
 trace_multifd_recv_sync_main(multifd_recv_state->seq);
@@ -1091,51 +1080,40 @@ static void *multifd_recv_thread(void *opaque)
 trace_multifd_recv_thread_start(p->id);
 
 while (true) {
+uint32_t used;
+uint32_t flags;
+
+ret = qio_channel_read_all_eof(p->c, (void *)p->packet,
+   p->packet_len, _err);
+if (ret == 0) {   /* EOF */
+break;
+}
+if (ret == -1) {   /* Error */
+break;
+}
+
 qemu_mutex_lock(>mutex);
-if (true || p->pending_job) {
-uint32_t used;
-uint32_t flags;
-qemu_mutex_unlock(>mutex);
-
-ret = qio_channel_read_all_eof(p->c, (void *)p->packet,
-   p->packet_len, _err);
-if (ret == 0) {   /* EOF */
-break;
-}
-if (ret == -1) {   /* Error */
-break;
-}
-
-qemu_mutex_lock(>mutex);
-ret = multifd_recv_unfill_packet(p, _err);
-if (ret) {
-qemu_mutex_unlock(>mutex);
-break;
-}
-
-used = p->pages->used;
-flags = p->flags;
-trace_multifd_recv(p->id, p->seq, used, flags);
-p->pending_job = false;
-p->num_packets++;
-p->num_pages += used;
+ret = multifd_recv_unfill_packet(p, _err);
+if (ret) {
 qemu_mutex_unlock(>mutex);
+break;
+}
 
-ret = qio_channel_readv_all(p->c, p->pages->iov, used, _err);
-if (ret != 0) {
-break;
-}
+used = p->pages->used;
+flags = p->flags;
+trace_multifd_recv(p->id, p->seq, used, flags);
+p->num_packets++;
+p->num_pages += used;
+qemu_mutex_unlock(>mutex);
 
-if (flags & MULTIFD_FLAG_SYNC) {
-qemu_sem_post(_recv_state->sem_sync);
-qemu_sem_wait(>sem_sync);
-}
-} else if (p->quit) {
-qemu_mutex_unlock(>mutex);
+ret = qio_channel_readv_all(p->c, p->pages->iov, used, _err);
+if (ret != 0) {
 break;
-} else {
-qemu_mutex_unlock(>mutex);
-/* sometimes there are spurious wakeups */
+}
+
+if (flags & MULTIFD_FLAG_SYNC) {
+qemu_sem_post(_recv_state->sem_sync);
+qemu_sem_wait(>sem_sync);
 }
 }
 
@@ -1173,7 +1151,6 @@ int multifd_load_setup(void)
 qemu_sem_init(>sem, 0);
 qemu_sem_init(>sem_sync, 0);
 p->quit = false;
-p->pending_job = false;
 p->id = i;
 multifd_pages_init(>pages, page_count);
 p->packet_len = sizeof(MultiFDPacket_t)
-- 
2.17.0




[Qemu-devel] [PATCH v12 11/21] migration: Create multifd packet

2018-04-25 Thread Juan Quintela
We still don't put anything there.

Signed-off-by: Juan Quintela 
---
 migration/ram.c | 137 +++-
 1 file changed, 136 insertions(+), 1 deletion(-)

diff --git a/migration/ram.c b/migration/ram.c
index b19300992e..804c83ed89 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -412,6 +412,17 @@ typedef struct {
 uint8_t id;
 } __attribute__((packed)) MultiFDInit_t;
 
+typedef struct {
+uint32_t magic;
+uint32_t version;
+uint32_t flags;
+uint32_t size;
+uint32_t used;
+uint32_t seq;
+char ramblock[256];
+uint64_t offset[];
+} __attribute__((packed)) MultiFDPacket_t;
+
 typedef struct {
 /* number of used pages */
 uint32_t used;
@@ -446,6 +457,14 @@ typedef struct {
 bool quit;
 /* array of pages to sent */
 MultiFDPages_t *pages;
+/* packet allocated len */
+uint32_t packet_len;
+/* pointer to the packet */
+MultiFDPacket_t *packet;
+/* multifd flags for each packet */
+uint32_t flags;
+/* global number of generated multifd packets */
+uint32_t seq;
 }  MultiFDSendParams;
 
 typedef struct {
@@ -468,6 +487,14 @@ typedef struct {
 bool quit;
 /* array of pages to receive */
 MultiFDPages_t *pages;
+/* packet allocated len */
+uint32_t packet_len;
+/* pointer to the packet */
+MultiFDPacket_t *packet;
+/* multifd flags for each packet */
+uint32_t flags;
+/* global number of generated multifd packets */
+uint32_t seq;
 } MultiFDRecvParams;
 
 static int multifd_send_initial_packet(MultiFDSendParams *p, Error **errp)
@@ -552,6 +579,91 @@ static void multifd_pages_clear(MultiFDPages_t *pages)
 g_free(pages);
 }
 
+static void multifd_send_fill_packet(MultiFDSendParams *p)
+{
+MultiFDPacket_t *packet = p->packet;
+int i;
+
+packet->magic = cpu_to_be32(MULTIFD_MAGIC);
+packet->version = cpu_to_be32(MULTIFD_VERSION);
+packet->flags = cpu_to_be32(p->flags);
+packet->size = cpu_to_be32(migrate_multifd_page_count());
+packet->used = cpu_to_be32(p->pages->used);
+packet->seq = cpu_to_be32(p->seq);
+
+if (p->pages->block) {
+strncpy(packet->ramblock, p->pages->block->idstr, 256);
+}
+
+for (i = 0; i < p->pages->used; i++) {
+packet->offset[i] = cpu_to_be64(p->pages->offset[i]);
+}
+}
+
+static int multifd_recv_unfill_packet(MultiFDRecvParams *p, Error **errp)
+{
+MultiFDPacket_t *packet = p->packet;
+RAMBlock *block;
+int i;
+
+/* ToDo: We can't use it until we haven't received a message */
+return 0;
+
+be32_to_cpus(>magic);
+if (packet->magic != MULTIFD_MAGIC) {
+error_setg(errp, "multifd: received packet "
+   "version %d and expected version %d",
+   packet->magic, MULTIFD_VERSION);
+return -1;
+}
+
+be32_to_cpus(>version);
+if (packet->version != MULTIFD_VERSION) {
+error_setg(errp, "multifd: received packet "
+   "version %d and expected version %d",
+   packet->version, MULTIFD_VERSION);
+return -1;
+}
+
+p->flags = be32_to_cpu(packet->flags);
+
+be32_to_cpus(>size);
+if (packet->size > migrate_multifd_page_count()) {
+error_setg(errp, "multifd: received packet "
+   "with size %d and expected maximum size %d",
+   packet->size, migrate_multifd_page_count()) ;
+return -1;
+}
+
+p->pages->used = be32_to_cpu(packet->used);
+if (p->pages->used > packet->size) {
+error_setg(errp, "multifd: received packet "
+   "with size %d and expected maximum size %d",
+   p->pages->used, packet->size) ;
+return -1;
+}
+
+p->seq = be32_to_cpu(packet->seq);
+
+if (p->pages->used) {
+block = qemu_ram_block_by_name(packet->ramblock);
+if (!block) {
+error_setg(errp, "multifd: unknown ram block %s",
+   packet->ramblock);
+return -1;
+}
+}
+
+for (i = 0; i < p->pages->used; i++) {
+ram_addr_t offset = be64_to_cpu(packet->offset[i]);
+
+p->pages->iov[i].iov_base = block->host + offset;
+p->pages->iov[i].iov_len = TARGET_PAGE_SIZE;
+}
+
+return 0;
+}
+
 struct {
 MultiFDSendParams *params;
 /* number of created threads */
@@ -607,6 +719,9 @@ int multifd_save_cleanup(Error **errp)
 p->name = NULL;
 multifd_pages_clear(p->pages);
 p->pages = NULL;
+p->packet_len = 0;
+g_free(p->packet);
+p->packet = NULL;
 }
 g_free(multifd_send_state->params);
 multifd_send_state->params = NULL;
@@ -628,6 +743,7 @@ static void *multifd_send_thread(void *opaque)
 
 while (true) {
 qemu_mutex_lock(>mutex);
+multifd_send_fill_packet(p);
 if (p->quit) {
 qemu_mutex_unlock(>mutex);
 break;
@@ -692,6 

[Qemu-devel] [PATCH v12 07/21] migration: Delay start of migration main routines

2018-04-25 Thread Juan Quintela
We need to make sure that we have started all the multifd threads.

Signed-off-by: Juan Quintela 
Reviewed-by: Daniel P. Berrangé 
---
 migration/migration.c | 4 ++--
 migration/migration.h | 1 +
 migration/ram.c   | 3 +++
 migration/socket.c| 4 
 4 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/migration/migration.c b/migration/migration.c
index 98f85e982c..9b510a809a 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -447,7 +447,7 @@ static void migration_incoming_setup(QEMUFile *f)
 qemu_file_set_blocking(f, false);
 }
 
-static void migration_incoming_process(void)
+void migration_incoming_process(void)
 {
 Coroutine *co = qemu_coroutine_create(process_incoming_migration_co, NULL);
 qemu_coroutine_enter(co);
@@ -465,7 +465,7 @@ void migration_ioc_process_incoming(QIOChannel *ioc)
 
 if (!mis->from_src_file) {
 QEMUFile *f = qemu_fopen_channel_input(ioc);
-migration_fd_process_incoming(f);
+migration_incoming_setup(f);
 return;
 }
 multifd_recv_new_channel(ioc);
diff --git a/migration/migration.h b/migration/migration.h
index 4774ee305f..e20f680bac 100644
--- a/migration/migration.h
+++ b/migration/migration.h
@@ -188,6 +188,7 @@ void migrate_set_state(int *state, int old_state, int 
new_state);
 
 void migration_fd_process_incoming(QEMUFile *f);
 void migration_ioc_process_incoming(QIOChannel *ioc);
+void migration_incoming_process(void);
 
 bool  migration_has_all_channels(void);
 
diff --git a/migration/ram.c b/migration/ram.c
index 54b1f8e836..5a87d74862 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -682,6 +682,9 @@ void multifd_recv_new_channel(QIOChannel *ioc)
 qemu_thread_create(>thread, p->name, multifd_recv_thread, p,
QEMU_THREAD_JOINABLE);
 atomic_inc(_recv_state->count);
+if (multifd_recv_state->count == migrate_multifd_channels()) {
+migration_incoming_process();
+}
 }
 
 /**
diff --git a/migration/socket.c b/migration/socket.c
index 893a04f4cc..d4a2c1e916 100644
--- a/migration/socket.c
+++ b/migration/socket.c
@@ -171,6 +171,10 @@ static void 
socket_accept_incoming_migration(QIONetListener *listener,
 qio_net_listener_disconnect(listener);
 
 object_unref(OBJECT(listener));
+
+if (!migrate_use_multifd()) {
+migration_incoming_process();
+}
 }
 }
 
-- 
2.17.0




[Qemu-devel] [PATCH v12 04/21] migration: Be sure all recv channels are created

2018-04-25 Thread Juan Quintela
We need them before we start migration.

Signed-off-by: Juan Quintela 
Reviewed-by: Daniel P. Berrangé 
---
 migration/migration.c |  6 +-
 migration/ram.c   | 11 +++
 migration/ram.h   |  1 +
 3 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/migration/migration.c b/migration/migration.c
index 604722cec9..98f85e982c 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -479,7 +479,11 @@ void migration_ioc_process_incoming(QIOChannel *ioc)
  */
 bool migration_has_all_channels(void)
 {
-return true;
+bool all_channels;
+
+all_channels = multifd_recv_all_channels_created();
+
+return all_channels;
 }
 
 /*
diff --git a/migration/ram.c b/migration/ram.c
index c0ad6d8e9f..3a01472835 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -636,6 +636,17 @@ int multifd_load_setup(void)
 return 0;
 }
 
+bool multifd_recv_all_channels_created(void)
+{
+int thread_count = migrate_multifd_channels();
+
+if (!migrate_use_multifd()) {
+return true;
+}
+
+return thread_count == atomic_read(_recv_state->count);
+}
+
 void multifd_recv_new_channel(QIOChannel *ioc)
 {
 /* nothing to do yet */
diff --git a/migration/ram.h b/migration/ram.h
index 06dbddc2a2..3f4b7daee8 100644
--- a/migration/ram.h
+++ b/migration/ram.h
@@ -45,6 +45,7 @@ int multifd_save_setup(void);
 int multifd_save_cleanup(Error **errp);
 int multifd_load_setup(void);
 int multifd_load_cleanup(Error **errp);
+bool multifd_recv_all_channels_created(void);
 void multifd_recv_new_channel(QIOChannel *ioc);
 
 uint64_t ram_pagesize_summary(void);
-- 
2.17.0




[Qemu-devel] [PATCH v12 16/21] migration: Synchronize multifd threads with main thread

2018-04-25 Thread Juan Quintela
We synchronize all threads each RAM_SAVE_FLAG_EOS.  Bitmap
synchronizations don't happen inside a  ram section, so we are safe
about two channels trying to overwrite the same memory.

Signed-off-by: Juan Quintela 
---
 migration/ram.c| 118 +
 migration/trace-events |   6 +++
 2 files changed, 113 insertions(+), 11 deletions(-)

diff --git a/migration/ram.c b/migration/ram.c
index c4c185cc4c..398cb0af3b 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -405,6 +405,8 @@ static void compress_threads_save_setup(void)
 #define MULTIFD_MAGIC 0x11223344U
 #define MULTIFD_VERSION 1
 
+#define MULTIFD_FLAG_SYNC (1 << 0)
+
 typedef struct {
 uint32_t magic;
 uint32_t version;
@@ -471,6 +473,8 @@ typedef struct {
 uint32_t num_packets;
 /* pages sent through this channel */
 uint32_t num_pages;
+/* syncs main thread and channels */
+QemuSemaphore sem_sync;
 }  MultiFDSendParams;
 
 typedef struct {
@@ -507,6 +511,8 @@ typedef struct {
 uint32_t num_packets;
 /* pages sent through this channel */
 uint32_t num_pages;
+/* syncs main thread and channels */
+QemuSemaphore sem_sync;
 } MultiFDRecvParams;
 
 static int multifd_send_initial_packet(MultiFDSendParams *p, Error **errp)
@@ -682,6 +688,10 @@ struct {
 int count;
 /* array of pages to sent */
 MultiFDPages_t *pages;
+/* syncs main thread and channels */
+QemuSemaphore sem_sync;
+/* global number of generated multifd packets */
+uint32_t seq;
 } *multifd_send_state;
 
 static void multifd_send_terminate_threads(Error *err)
@@ -727,6 +737,7 @@ int multifd_save_cleanup(Error **errp)
 p->c = NULL;
 qemu_mutex_destroy(>mutex);
 qemu_sem_destroy(>sem);
+qemu_sem_destroy(>sem_sync);
 g_free(p->name);
 p->name = NULL;
 multifd_pages_clear(p->pages);
@@ -735,6 +746,7 @@ int multifd_save_cleanup(Error **errp)
 g_free(p->packet);
 p->packet = NULL;
 }
+qemu_sem_destroy(_send_state->sem_sync);
 g_free(multifd_send_state->params);
 multifd_send_state->params = NULL;
 multifd_pages_clear(multifd_send_state->pages);
@@ -744,6 +756,33 @@ int multifd_save_cleanup(Error **errp)
 return ret;
 }
 
+static void multifd_send_sync_main(void)
+{
+int i;
+
+if (!migrate_use_multifd()) {
+return;
+}
+for (i = 0; i < migrate_multifd_channels(); i++) {
+MultiFDSendParams *p = _send_state->params[i];
+
+trace_multifd_send_sync_main_signal(p->id);
+
+qemu_mutex_lock(>mutex);
+p->flags |= MULTIFD_FLAG_SYNC;
+p->pending_job++;
+qemu_mutex_unlock(>mutex);
+qemu_sem_post(>sem);
+}
+for (i = 0; i < migrate_multifd_channels(); i++) {
+MultiFDSendParams *p = _send_state->params[i];
+
+trace_multifd_send_sync_main_wait(p->id);
+qemu_sem_wait(_send_state->sem_sync);
+}
+trace_multifd_send_sync_main(multifd_send_state->seq);
+}
+
 static void *multifd_send_thread(void *opaque)
 {
 MultiFDSendParams *p = opaque;
@@ -778,17 +817,20 @@ static void *multifd_send_thread(void *opaque)
 /* ToDo: send packet here */
 
 qemu_mutex_lock(>mutex);
+p->flags = 0;
 p->pending_job--;
 qemu_mutex_unlock(>mutex);
-continue;
+
+if (flags & MULTIFD_FLAG_SYNC) {
+qemu_sem_post(_send_state->sem_sync);
+}
 } else if (p->quit) {
 qemu_mutex_unlock(>mutex);
 break;
+} else {
+qemu_mutex_unlock(>mutex);
+/* sometimes there are spurious wakeups */
 }
-qemu_mutex_unlock(>mutex);
-/* this is impossible */
-error_setg(_err, "multifd_send_thread: Unknown command");
-break;
 }
 
 out:
@@ -840,12 +882,14 @@ int multifd_save_setup(void)
 multifd_send_state->params = g_new0(MultiFDSendParams, thread_count);
 atomic_set(_send_state->count, 0);
 multifd_pages_init(_send_state->pages, page_count);
+qemu_sem_init(_send_state->sem_sync, 0);
 
 for (i = 0; i < thread_count; i++) {
 MultiFDSendParams *p = _send_state->params[i];
 
 qemu_mutex_init(>mutex);
 qemu_sem_init(>sem, 0);
+qemu_sem_init(>sem_sync, 0);
 p->quit = false;
 p->pending_job = 0;
 p->id = i;
@@ -863,6 +907,10 @@ struct {
 MultiFDRecvParams *params;
 /* number of created threads */
 int count;
+/* syncs main thread and channels */
+QemuSemaphore sem_sync;
+/* global number of generated multifd packets */
+uint32_t seq;
 } *multifd_recv_state;
 
 static void multifd_recv_terminate_threads(Error *err)
@@ -908,6 +956,7 @@ int multifd_load_cleanup(Error **errp)
 p->c = NULL;
 qemu_mutex_destroy(>mutex);
 qemu_sem_destroy(>sem);
+qemu_sem_destroy(>sem_sync);
 

[Qemu-devel] [PATCH v12 10/21] migration: Create multipage support

2018-04-25 Thread Juan Quintela
We only create/destry the page list here.  We will use it later.

Signed-off-by: Juan Quintela 
---
 migration/ram.c | 56 +
 1 file changed, 56 insertions(+)

diff --git a/migration/ram.c b/migration/ram.c
index ffefa73099..b19300992e 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -412,6 +412,20 @@ typedef struct {
 uint8_t id;
 } __attribute__((packed)) MultiFDInit_t;
 
+typedef struct {
+/* number of used pages */
+uint32_t used;
+/* number of allocated pages */
+uint32_t allocated;
+/* global number of generated multifd packets */
+uint32_t seq;
+/* offset of each page */
+ram_addr_t *offset;
+/* pointer to each page */
+struct iovec *iov;
+RAMBlock *block;
+} MultiFDPages_t;
+
 typedef struct {
 /* this fields are not changed once the thread is created */
 /* channel number */
@@ -430,6 +444,8 @@ typedef struct {
 bool running;
 /* should this thread finish */
 bool quit;
+/* array of pages to sent */
+MultiFDPages_t *pages;
 }  MultiFDSendParams;
 
 typedef struct {
@@ -450,6 +466,8 @@ typedef struct {
 bool running;
 /* should this thread finish */
 bool quit;
+/* array of pages to receive */
+MultiFDPages_t *pages;
 } MultiFDRecvParams;
 
 static int multifd_send_initial_packet(MultiFDSendParams *p, Error **errp)
@@ -511,10 +529,35 @@ static int multifd_recv_initial_packet(QIOChannel *c, 
Error **errp)
 return msg.id;
 }
 
+static void multifd_pages_init(MultiFDPages_t **ppages, size_t size)
+{
+MultiFDPages_t *pages = g_new0(MultiFDPages_t, 1);
+
+pages->allocated = size;
+pages->iov = g_new0(struct iovec, size);
+pages->offset = g_new0(ram_addr_t, size);
+*ppages = pages;
+}
+
+static void multifd_pages_clear(MultiFDPages_t *pages)
+{
+pages->used = 0;
+pages->allocated = 0;
+pages->seq = 0;
+pages->block = NULL;
+g_free(pages->iov);
+pages->iov = NULL;
+g_free(pages->offset);
+pages->offset = NULL;
+g_free(pages);
+}
+
 struct {
 MultiFDSendParams *params;
 /* number of created threads */
 int count;
+/* array of pages to sent */
+MultiFDPages_t *pages;
 } *multifd_send_state;
 
 static void multifd_send_terminate_threads(Error *err)
@@ -562,9 +605,13 @@ int multifd_save_cleanup(Error **errp)
 qemu_sem_destroy(>sem);
 g_free(p->name);
 p->name = NULL;
+multifd_pages_clear(p->pages);
+p->pages = NULL;
 }
 g_free(multifd_send_state->params);
 multifd_send_state->params = NULL;
+multifd_pages_clear(multifd_send_state->pages);
+multifd_send_state->pages = NULL;
 g_free(multifd_send_state);
 multifd_send_state = NULL;
 return ret;
@@ -625,6 +672,7 @@ static void multifd_new_send_channel_async(QIOTask *task, 
gpointer opaque)
 int multifd_save_setup(void)
 {
 int thread_count;
+uint32_t page_count = migrate_multifd_page_count();
 uint8_t i;
 
 if (!migrate_use_multifd()) {
@@ -634,6 +682,8 @@ int multifd_save_setup(void)
 multifd_send_state = g_malloc0(sizeof(*multifd_send_state));
 multifd_send_state->params = g_new0(MultiFDSendParams, thread_count);
 atomic_set(_send_state->count, 0);
+multifd_pages_init(_send_state->pages, page_count);
+
 for (i = 0; i < thread_count; i++) {
 MultiFDSendParams *p = _send_state->params[i];
 
@@ -641,6 +691,7 @@ int multifd_save_setup(void)
 qemu_sem_init(>sem, 0);
 p->quit = false;
 p->id = i;
+multifd_pages_init(>pages, page_count);
 p->name = g_strdup_printf("multifdsend_%d", i);
 socket_send_channel_create(multifd_new_send_channel_async, p);
 }
@@ -698,6 +749,8 @@ int multifd_load_cleanup(Error **errp)
 qemu_sem_destroy(>sem);
 g_free(p->name);
 p->name = NULL;
+multifd_pages_clear(p->pages);
+p->pages = NULL;
 }
 g_free(multifd_recv_state->params);
 multifd_recv_state->params = NULL;
@@ -731,6 +784,7 @@ static void *multifd_recv_thread(void *opaque)
 int multifd_load_setup(void)
 {
 int thread_count;
+uint32_t page_count = migrate_multifd_page_count();
 uint8_t i;
 
 if (!migrate_use_multifd()) {
@@ -740,6 +794,7 @@ int multifd_load_setup(void)
 multifd_recv_state = g_malloc0(sizeof(*multifd_recv_state));
 multifd_recv_state->params = g_new0(MultiFDRecvParams, thread_count);
 atomic_set(_recv_state->count, 0);
+
 for (i = 0; i < thread_count; i++) {
 MultiFDRecvParams *p = _recv_state->params[i];
 
@@ -747,6 +802,7 @@ int multifd_load_setup(void)
 qemu_sem_init(>sem, 0);
 p->quit = false;
 p->id = i;
+multifd_pages_init(>pages, page_count);
 p->name = g_strdup_printf("multifdrecv_%d", i);
 }
 return 0;
-- 
2.17.0




[Qemu-devel] [PATCH v12 06/21] migration: Create multifd channels

2018-04-25 Thread Juan Quintela
In both sides.  We still don't transmit anything through them.

Signed-off-by: Juan Quintela 
Reviewed-by: Daniel P. Berrangé 
---
 migration/ram.c | 52 +++--
 1 file changed, 42 insertions(+), 10 deletions(-)

diff --git a/migration/ram.c b/migration/ram.c
index 3a01472835..54b1f8e836 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -404,6 +404,7 @@ struct MultiFDSendParams {
 uint8_t id;
 char *name;
 QemuThread thread;
+QIOChannel *c;
 QemuSemaphore sem;
 QemuMutex mutex;
 bool running;
@@ -456,6 +457,8 @@ int multifd_save_cleanup(Error **errp)
 if (p->running) {
 qemu_thread_join(>thread);
 }
+socket_send_channel_destroy(p->c);
+p->c = NULL;
 qemu_mutex_destroy(>mutex);
 qemu_sem_destroy(>sem);
 g_free(p->name);
@@ -489,6 +492,27 @@ static void *multifd_send_thread(void *opaque)
 return NULL;
 }
 
+static void multifd_new_send_channel_async(QIOTask *task, gpointer opaque)
+{
+MultiFDSendParams *p = opaque;
+QIOChannel *sioc = QIO_CHANNEL(qio_task_get_source(task));
+Error *local_err = NULL;
+
+if (qio_task_propagate_error(task, _err)) {
+if (multifd_save_cleanup(_err) != 0) {
+migrate_set_error(migrate_get_current(), local_err);
+}
+} else {
+p->c = QIO_CHANNEL(sioc);
+qio_channel_set_delay(p->c, false);
+p->running = true;
+qemu_thread_create(>thread, p->name, multifd_send_thread, p,
+   QEMU_THREAD_JOINABLE);
+
+atomic_inc(_send_state->count);
+}
+}
+
 int multifd_save_setup(void)
 {
 int thread_count;
@@ -509,11 +533,7 @@ int multifd_save_setup(void)
 p->quit = false;
 p->id = i;
 p->name = g_strdup_printf("multifdsend_%d", i);
-p->running = true;
-qemu_thread_create(>thread, p->name, multifd_send_thread, p,
-   QEMU_THREAD_JOINABLE);
-
-atomic_inc(_send_state->count);
+socket_send_channel_create(multifd_new_send_channel_async, p);
 }
 return 0;
 }
@@ -522,6 +542,7 @@ struct MultiFDRecvParams {
 uint8_t id;
 char *name;
 QemuThread thread;
+QIOChannel *c;
 QemuSemaphore sem;
 QemuMutex mutex;
 bool running;
@@ -574,6 +595,8 @@ int multifd_load_cleanup(Error **errp)
 if (p->running) {
 qemu_thread_join(>thread);
 }
+object_unref(OBJECT(p->c));
+p->c = NULL;
 qemu_mutex_destroy(>mutex);
 qemu_sem_destroy(>sem);
 g_free(p->name);
@@ -628,10 +651,6 @@ int multifd_load_setup(void)
 p->quit = false;
 p->id = i;
 p->name = g_strdup_printf("multifdrecv_%d", i);
-p->running = true;
-qemu_thread_create(>thread, p->name, multifd_recv_thread, p,
-   QEMU_THREAD_JOINABLE);
-atomic_inc(_recv_state->count);
 }
 return 0;
 }
@@ -649,7 +668,20 @@ bool multifd_recv_all_channels_created(void)
 
 void multifd_recv_new_channel(QIOChannel *ioc)
 {
-/* nothing to do yet */
+MultiFDRecvParams *p;
+/* we need to invent channels id's until we transmit */
+/* we will remove this on a later patch */
+static int i;
+
+p = _recv_state->params[i];
+i++;
+p->c = ioc;
+object_ref(OBJECT(ioc));
+
+p->running = true;
+qemu_thread_create(>thread, p->name, multifd_recv_thread, p,
+   QEMU_THREAD_JOINABLE);
+atomic_inc(_recv_state->count);
 }
 
 /**
-- 
2.17.0




[Qemu-devel] [PATCH v12 02/21] migration: Introduce multifd_recv_new_channel()

2018-04-25 Thread Juan Quintela
Signed-off-by: Juan Quintela 
Reviewed-by: Daniel P. Berrangé 
---
 migration/migration.c | 3 ++-
 migration/ram.c   | 6 ++
 migration/ram.h   | 2 ++
 3 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/migration/migration.c b/migration/migration.c
index 7eca65d1f0..604722cec9 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -466,8 +466,9 @@ void migration_ioc_process_incoming(QIOChannel *ioc)
 if (!mis->from_src_file) {
 QEMUFile *f = qemu_fopen_channel_input(ioc);
 migration_fd_process_incoming(f);
+return;
 }
-/* We still only have a single channel.  Nothing to do here yet */
+multifd_recv_new_channel(ioc);
 }
 
 /**
diff --git a/migration/ram.c b/migration/ram.c
index 2ae560ea80..c3c330b0e0 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -36,6 +36,7 @@
 #include "xbzrle.h"
 #include "ram.h"
 #include "migration.h"
+#include "socket.h"
 #include "migration/register.h"
 #include "migration/misc.h"
 #include "qemu-file.h"
@@ -619,6 +620,11 @@ int multifd_load_setup(void)
 return 0;
 }
 
+void multifd_recv_new_channel(QIOChannel *ioc)
+{
+/* nothing to do yet */
+}
+
 /**
  * save_page_header: write page header to wire
  *
diff --git a/migration/ram.h b/migration/ram.h
index 5030be110a..06dbddc2a2 100644
--- a/migration/ram.h
+++ b/migration/ram.h
@@ -32,6 +32,7 @@
 #include "qemu-common.h"
 #include "qapi/qapi-types-migration.h"
 #include "exec/cpu-common.h"
+#include "io/channel.h"
 
 extern MigrationStats ram_counters;
 extern XBZRLECacheStats xbzrle_counters;
@@ -44,6 +45,7 @@ int multifd_save_setup(void);
 int multifd_save_cleanup(Error **errp);
 int multifd_load_setup(void);
 int multifd_load_cleanup(Error **errp);
+void multifd_recv_new_channel(QIOChannel *ioc);
 
 uint64_t ram_pagesize_summary(void);
 int ram_save_queue_pages(const char *rbname, ram_addr_t start, ram_addr_t len);
-- 
2.17.0




[Qemu-devel] [PATCH v12 09/21] migration: Define MultifdRecvParams sooner

2018-04-25 Thread Juan Quintela
Once there, we don't need the struct names anywhere, just the
typedefs.  And now also document all fields.

Signed-off-by: Juan Quintela 
---
 migration/ram.c | 46 +++---
 1 file changed, 31 insertions(+), 15 deletions(-)

diff --git a/migration/ram.c b/migration/ram.c
index 1aab392d8f..ffefa73099 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -412,17 +412,45 @@ typedef struct {
 uint8_t id;
 } __attribute__((packed)) MultiFDInit_t;
 
-struct MultiFDSendParams {
+typedef struct {
+/* this fields are not changed once the thread is created */
+/* channel number */
 uint8_t id;
+/* channel thread name */
 char *name;
+/* channel thread id */
 QemuThread thread;
+/* communication channel */
 QIOChannel *c;
+/* sem where to wait for more work */
 QemuSemaphore sem;
+/* this mutex protects the following parameters */
 QemuMutex mutex;
+/* is this channel thread running */
 bool running;
+/* should this thread finish */
 bool quit;
-};
-typedef struct MultiFDSendParams MultiFDSendParams;
+}  MultiFDSendParams;
+
+typedef struct {
+/* this fields are not changed once the thread is created */
+/* channel number */
+uint8_t id;
+/* channel thread name */
+char *name;
+/* channel thread id */
+QemuThread thread;
+/* communication channel */
+QIOChannel *c;
+/* sem where to wait for more work */
+QemuSemaphore sem;
+/* this mutex protects the following parameters */
+QemuMutex mutex;
+/* is this channel thread running */
+bool running;
+/* should this thread finish */
+bool quit;
+} MultiFDRecvParams;
 
 static int multifd_send_initial_packet(MultiFDSendParams *p, Error **errp)
 {
@@ -619,18 +647,6 @@ int multifd_save_setup(void)
 return 0;
 }
 
-struct MultiFDRecvParams {
-uint8_t id;
-char *name;
-QemuThread thread;
-QIOChannel *c;
-QemuSemaphore sem;
-QemuMutex mutex;
-bool running;
-bool quit;
-};
-typedef struct MultiFDRecvParams MultiFDRecvParams;
-
 struct {
 MultiFDRecvParams *params;
 /* number of created threads */
-- 
2.17.0




[Qemu-devel] [PATCH v12 03/21] migration: terminate_* can be called for other threads

2018-04-25 Thread Juan Quintela
Once there, make  count field to always be accessed with atomic
operations.  To make blocking operations, we need to know that the
thread is running, so create a bool to indicate that.

Signed-off-by: Juan Quintela 
Reviewed-by: Daniel P. Berrangé 

--

Once here, s/terminate_multifd_*-threads/multifd_*_terminate_threads/
This is consistente with every other function
---
 migration/ram.c | 44 ++--
 1 file changed, 30 insertions(+), 14 deletions(-)

diff --git a/migration/ram.c b/migration/ram.c
index c3c330b0e0..c0ad6d8e9f 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -406,6 +406,7 @@ struct MultiFDSendParams {
 QemuThread thread;
 QemuSemaphore sem;
 QemuMutex mutex;
+bool running;
 bool quit;
 };
 typedef struct MultiFDSendParams MultiFDSendParams;
@@ -416,7 +417,7 @@ struct {
 int count;
 } *multifd_send_state;
 
-static void terminate_multifd_send_threads(Error *err)
+static void multifd_send_terminate_threads(Error *err)
 {
 int i;
 
@@ -430,7 +431,7 @@ static void terminate_multifd_send_threads(Error *err)
 }
 }
 
-for (i = 0; i < multifd_send_state->count; i++) {
+for (i = 0; i < migrate_multifd_channels(); i++) {
 MultiFDSendParams *p = _send_state->params[i];
 
 qemu_mutex_lock(>mutex);
@@ -448,11 +449,13 @@ int multifd_save_cleanup(Error **errp)
 if (!migrate_use_multifd()) {
 return 0;
 }
-terminate_multifd_send_threads(NULL);
-for (i = 0; i < multifd_send_state->count; i++) {
+multifd_send_terminate_threads(NULL);
+for (i = 0; i < migrate_multifd_channels(); i++) {
 MultiFDSendParams *p = _send_state->params[i];
 
-qemu_thread_join(>thread);
+if (p->running) {
+qemu_thread_join(>thread);
+}
 qemu_mutex_destroy(>mutex);
 qemu_sem_destroy(>sem);
 g_free(p->name);
@@ -479,6 +482,10 @@ static void *multifd_send_thread(void *opaque)
 qemu_sem_wait(>sem);
 }
 
+qemu_mutex_lock(>mutex);
+p->running = false;
+qemu_mutex_unlock(>mutex);
+
 return NULL;
 }
 
@@ -493,7 +500,7 @@ int multifd_save_setup(void)
 thread_count = migrate_multifd_channels();
 multifd_send_state = g_malloc0(sizeof(*multifd_send_state));
 multifd_send_state->params = g_new0(MultiFDSendParams, thread_count);
-multifd_send_state->count = 0;
+atomic_set(_send_state->count, 0);
 for (i = 0; i < thread_count; i++) {
 MultiFDSendParams *p = _send_state->params[i];
 
@@ -502,10 +509,11 @@ int multifd_save_setup(void)
 p->quit = false;
 p->id = i;
 p->name = g_strdup_printf("multifdsend_%d", i);
+p->running = true;
 qemu_thread_create(>thread, p->name, multifd_send_thread, p,
QEMU_THREAD_JOINABLE);
 
-multifd_send_state->count++;
+atomic_inc(_send_state->count);
 }
 return 0;
 }
@@ -516,6 +524,7 @@ struct MultiFDRecvParams {
 QemuThread thread;
 QemuSemaphore sem;
 QemuMutex mutex;
+bool running;
 bool quit;
 };
 typedef struct MultiFDRecvParams MultiFDRecvParams;
@@ -526,7 +535,7 @@ struct {
 int count;
 } *multifd_recv_state;
 
-static void terminate_multifd_recv_threads(Error *err)
+static void multifd_recv_terminate_threads(Error *err)
 {
 int i;
 
@@ -540,7 +549,7 @@ static void terminate_multifd_recv_threads(Error *err)
 }
 }
 
-for (i = 0; i < multifd_recv_state->count; i++) {
+for (i = 0; i < migrate_multifd_channels(); i++) {
 MultiFDRecvParams *p = _recv_state->params[i];
 
 qemu_mutex_lock(>mutex);
@@ -558,11 +567,13 @@ int multifd_load_cleanup(Error **errp)
 if (!migrate_use_multifd()) {
 return 0;
 }
-terminate_multifd_recv_threads(NULL);
-for (i = 0; i < multifd_recv_state->count; i++) {
+multifd_recv_terminate_threads(NULL);
+for (i = 0; i < migrate_multifd_channels(); i++) {
 MultiFDRecvParams *p = _recv_state->params[i];
 
-qemu_thread_join(>thread);
+if (p->running) {
+qemu_thread_join(>thread);
+}
 qemu_mutex_destroy(>mutex);
 qemu_sem_destroy(>sem);
 g_free(p->name);
@@ -590,6 +601,10 @@ static void *multifd_recv_thread(void *opaque)
 qemu_sem_wait(>sem);
 }
 
+qemu_mutex_lock(>mutex);
+p->running = false;
+qemu_mutex_unlock(>mutex);
+
 return NULL;
 }
 
@@ -604,7 +619,7 @@ int multifd_load_setup(void)
 thread_count = migrate_multifd_channels();
 multifd_recv_state = g_malloc0(sizeof(*multifd_recv_state));
 multifd_recv_state->params = g_new0(MultiFDRecvParams, thread_count);
-multifd_recv_state->count = 0;
+atomic_set(_recv_state->count, 0);
 for (i = 0; i < thread_count; i++) {
 MultiFDRecvParams *p = _recv_state->params[i];
 
@@ -613,9 +628,10 @@ int multifd_load_setup(void)
 p->quit = 

[Qemu-devel] [RFC v2 2/2] pmem: device flush over VIRTIO

2018-04-25 Thread Pankaj Gupta
This patch adds functionality to perform 
flush from guest to hosy over VIRTIO 
when 'ND_REGION_VIRTIO'flag is set on 
nd_negion. Flag is set by 'virtio-pmem'
driver.

Signed-off-by: Pankaj Gupta 
---
 drivers/nvdimm/region_devs.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/nvdimm/region_devs.c b/drivers/nvdimm/region_devs.c
index a612be6..6c6454e 100644
--- a/drivers/nvdimm/region_devs.c
+++ b/drivers/nvdimm/region_devs.c
@@ -20,6 +20,7 @@
 #include 
 #include "nd-core.h"
 #include "nd.h"
+#include 
 
 /*
  * For readq() and writeq() on 32-bit builds, the hi-lo, lo-hi order is
@@ -1074,6 +1075,12 @@ void nvdimm_flush(struct nd_region *nd_region)
struct nd_region_data *ndrd = dev_get_drvdata(_region->dev);
int i, idx;
 
+   /* call PV device flush */
+   if (test_bit(ND_REGION_VIRTIO, _region->flags)) {
+   virtio_pmem_flush(_region->dev);
+   return;
+   }
+
/*
 * Try to encourage some diversity in flush hint addresses
 * across cpus assuming a limited number of flush hints.
-- 
2.9.3




[Qemu-devel] [PATCH v12 00/21] Multifd

2018-04-25 Thread Juan Quintela

Hi


[v12]

Big news, it is not RFC anymore, it works reliabely for me.

Changes:
- Locknig changed completely (several times)
- We now send  all pages through the channels.  In a 2GB guest with 1 disk and 
a network card, the amount of data send for RAM was 80KB.
- This is not optimized yet, but it shouws clear improvements over precopy.  
testing over localhost networking I can guet:
  - 2 VCPUs guest
  - 2GB RAM
  - runn stress --vm 4 --vm 500GB (i.e. dirtying 2GB or RAM each second)

  - Total time: precopy ~50seconds, multifd  around 11seconds
  - Bandwidth usage is around 273MB/s vs 71MB/s on the same hardware

This is very preleminary testing, will send more numbers when I got them.  But 
looks promissing.

Things that will be improved later:
- Initial synchronization is too slow (around 1s)
- We synchronize all threads after each RAM section, we can move to only
  synchronize them after we have done a bitmap syncrhronization
- We can improve bitmap walking (but that is independent of multifd)

Please review.

Later, Juan.


[v11]

Changes on top of previous sumbimission:
- Now on top of migration-tests/v6 that I sent on Wednesday
- Rebased to latest upstream
- Everything that is sent through the network should be converted correctly
  (famous last words)
- Still on RFC (sometimes it ends some packets at the end), just to
  show how things are going on.  Problems are only on the last patch.

- Redo some locking (again) Now the problem is being able te send the
  synchronization through the multifd channels.  I end the migration
  _before_ all the channels have recevied all the packets.

- Trying to get a flags argument into each packet, to be able to synchronze
  through the network, not from the "main" incoming corroutine.

- Related to the network-safe fields, now everything is in its own
  routine, it should be easier to understand/review.  Once there, I
  check that all values are inside range.

So, please comment.

Thanks, Juan.


[v10]
Lots of changes from previous versions:
a - everything is sent now through the multifd channels, nothing is sent 
through main channel
b - locking is band new, I was getting into a hole with the previous approach, 
right now, there is a single way to
do locking (both source and destination)
   main thread : sets a ->sync variable for each thread and wakeps it
   multifd threads: clean the variable and signal (sem) back to main thread

using this for either:
- all threads have started
- we need to synchronize after each round through memory
- all threads have finished

c - I have to use a qio watcher for a thread to wait for ready data to read

d - lots of cleanups

e - to make things easier, I have included the missing tests stuff on
this round of patches, because they build on top of them

f - lots of traces, it is now much easier to follow what is happening

Now, why it is an RFC:

- in the last patch, there is still race between the whatcher, the
  ->quit of the threads and the last synchronization.  Techinically they
  are done in oder, but in practice, they are hanging sometimes.

- I *know* I can optimize the synchronization of the threads sending
  the "we start a new round" through the multifd channels, have to add a flag 
here.

- Not having a thread on the incoming side  is a mess, I can't block waiting 
for things to happen :-(

- When doing the synchronization, I need to optimize the sending of the "not 
finished packet" of pages, working on that.

please, take a look and review.

Thanks, Juan.

[v9]

This series is on top of my migration test series just sent, only reject should 
be on the test system, though.

On v9 series for you:
- qobject_unref() as requested by dan

  Yes he was right, I had a reference leak for _non_ multifd, I
  *thought* he mean for multifd, and that took a while to understand
  (and then find when/where).

- multifd page count: it is dropped for good
- uuid handling: we use the default qemu uuid of ...
- uuid handling: using and struct and sending the struct
  * idea is to add a size field and add more parameter after that
  * anyone has a good idea how to "ouptut" info
migrate_capabilities/parameters json into a string and how to read it back?
- changed how we test that all threads/channels are already created.
  Should be more robust.
- Add tests multifd.  Still not ported on top of migration-tests series sent 
early
  waiting for review on the ideas there.
- Rebase and remove al the integrated patches (back at 12)

Please, review.

Later, Juan.

[v8]
Things NOT done yet:

- drop x-multifd-page-count?  We can use performance to set a default value
- paolo suggestion of not having a control channel
  needs iyet more cleanups to be able to have more than one ramstate, trying it.
- still not performance done, but it has been very stable

On v8:
- use connect_async
- rename multifd-group to multifd-page-count (danp suggestion)
- rename multifd-threads to multifd-channels (danp 

[Qemu-devel] [PATCH v12 05/21] migration: Export functions to create send channels

2018-04-25 Thread Juan Quintela
Signed-off-by: Juan Quintela 
Reviewed-by: Daniel P. Berrangé 
---
 migration/socket.c | 28 +++-
 migration/socket.h |  7 +++
 2 files changed, 34 insertions(+), 1 deletion(-)

diff --git a/migration/socket.c b/migration/socket.c
index edf33c70cf..893a04f4cc 100644
--- a/migration/socket.c
+++ b/migration/socket.c
@@ -29,6 +29,28 @@
 #include "trace.h"
 
 
+struct SocketOutgoingArgs {
+SocketAddress *saddr;
+} outgoing_args;
+
+void socket_send_channel_create(QIOTaskFunc f, void *data)
+{
+QIOChannelSocket *sioc = qio_channel_socket_new();
+qio_channel_socket_connect_async(sioc, outgoing_args.saddr,
+ f, data, NULL, NULL);
+}
+
+int socket_send_channel_destroy(QIOChannel *send)
+{
+/* Remove channel */
+object_unref(OBJECT(send));
+if (outgoing_args.saddr) {
+qapi_free_SocketAddress(outgoing_args.saddr);
+outgoing_args.saddr = NULL;
+}
+return 0;
+}
+
 static SocketAddress *tcp_build_address(const char *host_port, Error **errp)
 {
 SocketAddress *saddr;
@@ -96,6 +118,11 @@ static void socket_start_outgoing_migration(MigrationState 
*s,
 struct SocketConnectData *data = g_new0(struct SocketConnectData, 1);
 
 data->s = s;
+
+/* in case previous migration leaked it */
+qapi_free_SocketAddress(outgoing_args.saddr);
+outgoing_args.saddr = saddr;
+
 if (saddr->type == SOCKET_ADDRESS_TYPE_INET) {
 data->hostname = g_strdup(saddr->u.inet.host);
 }
@@ -107,7 +134,6 @@ static void socket_start_outgoing_migration(MigrationState 
*s,
  data,
  socket_connect_data_free,
  NULL);
-qapi_free_SocketAddress(saddr);
 }
 
 void tcp_start_outgoing_migration(MigrationState *s,
diff --git a/migration/socket.h b/migration/socket.h
index 6b91e9db38..528c3b0202 100644
--- a/migration/socket.h
+++ b/migration/socket.h
@@ -16,6 +16,13 @@
 
 #ifndef QEMU_MIGRATION_SOCKET_H
 #define QEMU_MIGRATION_SOCKET_H
+
+#include "io/channel.h"
+#include "io/task.h"
+
+void socket_send_channel_create(QIOTaskFunc f, void *data);
+int socket_send_channel_destroy(QIOChannel *send);
+
 void tcp_start_incoming_migration(const char *host_port, Error **errp);
 
 void tcp_start_outgoing_migration(MigrationState *s, const char *host_port,
-- 
2.17.0




[Qemu-devel] [RFC v2] qemu: Add virtio pmem device

2018-04-25 Thread Pankaj Gupta
This patch adds virtio-pmem Qemu device.

This device presents memory address range 
information to guest which is backed by file 
backend type. It acts like persistent memory 
device for KVM guest. Guest can perform read 
and persistent write operations on this memory 
range with the help of DAX capable filesystem.

Persistent guest writes are assured with the 
help of virtio based flushing interface. When 
guest userspace space performs fsync on file 
fd on pmem device, a flush command is send to 
Qemu over VIRTIO and host side flush/sync is 
done on backing image file.

This PV device code is dependent and tested 
with 'David Hildenbrand's ' patchset[1] to 
map non-PCDIMM devices to guest address space.
There is still upstream discussion on using 
among PCI bar vs memory device, will update 
as per concensus.

[1] https://marc.info/?l=qemu-devel=152450249319168=2

Signed-off-by: Pankaj Gupta 
---
 hw/virtio/Makefile.objs |   3 +
 hw/virtio/virtio-pci.c  |  44 +++
 hw/virtio/virtio-pci.h  |  14 ++
 hw/virtio/virtio-pmem.c | 197 
 include/hw/pci/pci.h|   1 +
 include/hw/virtio/virtio-pmem.h |  44 +++
 include/standard-headers/linux/virtio_ids.h |   1 +
 qapi/misc.json  |  26 +++-
 8 files changed, 329 insertions(+), 1 deletion(-)
 create mode 100644 hw/virtio/virtio-pmem.c
 create mode 100644 include/hw/virtio/virtio-pmem.h

diff --git a/hw/virtio/Makefile.objs b/hw/virtio/Makefile.objs
index 765d363c1f..d329dbb1a1 100644
--- a/hw/virtio/Makefile.objs
+++ b/hw/virtio/Makefile.objs
@@ -6,6 +6,9 @@ common-obj-y += virtio-mmio.o
 
 obj-y += virtio.o virtio-balloon.o 
 obj-$(CONFIG_LINUX) += vhost.o vhost-backend.o vhost-user.o
+ifeq ($(CONFIG_MEM_HOTPLUG),y)
+obj-$(CONFIG_LINUX) += virtio-pmem.o
+endif
 obj-$(CONFIG_VHOST_VSOCK) += vhost-vsock.o
 obj-y += virtio-crypto.o
 obj-$(CONFIG_VIRTIO_PCI) += virtio-crypto-pci.o
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index 1e8ab7bbc5..e15a3a5a2e 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -2501,6 +2501,49 @@ static const TypeInfo virtio_rng_pci_info = {
 .class_init= virtio_rng_pci_class_init,
 };
 
+/* virtio-pmem-pci */
+
+static void virtio_pmem_pci_realize(VirtIOPCIProxy *vpci_dev, Error **errp)
+{
+VirtIOPMEMPCI *vpmem = VIRTIO_PMEM_PCI(vpci_dev);
+DeviceState *vdev = DEVICE(>vdev);
+
+qdev_set_parent_bus(vdev, BUS(_dev->bus));
+object_property_set_bool(OBJECT(vdev), true, "realized", errp);
+}
+
+static void virtio_pmem_pci_class_init(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+VirtioPCIClass *k = VIRTIO_PCI_CLASS(klass);
+PCIDeviceClass *pcidev_k = PCI_DEVICE_CLASS(klass);
+k->realize = virtio_pmem_pci_realize;
+set_bit(DEVICE_CATEGORY_MISC, dc->categories);
+pcidev_k->vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET;
+pcidev_k->device_id = PCI_DEVICE_ID_VIRTIO_PMEM;
+pcidev_k->revision = VIRTIO_PCI_ABI_VERSION;
+pcidev_k->class_id = PCI_CLASS_OTHERS;
+}
+
+static void virtio_pmem_pci_instance_init(Object *obj)
+{
+VirtIOPMEMPCI *dev = VIRTIO_PMEM_PCI(obj);
+
+virtio_instance_init_common(obj, >vdev, sizeof(dev->vdev),
+TYPE_VIRTIO_PMEM);
+object_property_add_alias(obj, "memdev", OBJECT(>vdev), "memdev",
+  _abort);
+}
+
+static const TypeInfo virtio_pmem_pci_info = {
+.name  = TYPE_VIRTIO_PMEM_PCI,
+.parent= TYPE_VIRTIO_PCI,
+.instance_size = sizeof(VirtIOPMEMPCI),
+.instance_init = virtio_pmem_pci_instance_init,
+.class_init= virtio_pmem_pci_class_init,
+};
+
+
 /* virtio-input-pci */
 
 static Property virtio_input_pci_properties[] = {
@@ -2693,6 +2736,7 @@ static void virtio_pci_register_types(void)
 type_register_static(_balloon_pci_info);
 type_register_static(_serial_pci_info);
 type_register_static(_net_pci_info);
+type_register_static(_pmem_pci_info);
 #ifdef CONFIG_VHOST_SCSI
 type_register_static(_scsi_pci_info);
 #endif
diff --git a/hw/virtio/virtio-pci.h b/hw/virtio/virtio-pci.h
index 813082b0d7..fe74fcad3f 100644
--- a/hw/virtio/virtio-pci.h
+++ b/hw/virtio/virtio-pci.h
@@ -19,6 +19,7 @@
 #include "hw/virtio/virtio-blk.h"
 #include "hw/virtio/virtio-net.h"
 #include "hw/virtio/virtio-rng.h"
+#include "hw/virtio/virtio-pmem.h"
 #include "hw/virtio/virtio-serial.h"
 #include "hw/virtio/virtio-scsi.h"
 #include "hw/virtio/virtio-balloon.h"
@@ -57,6 +58,7 @@ typedef struct VirtIOInputHostPCI VirtIOInputHostPCI;
 typedef struct VirtIOGPUPCI VirtIOGPUPCI;
 typedef struct VHostVSockPCI VHostVSockPCI;
 typedef struct VirtIOCryptoPCI VirtIOCryptoPCI;
+typedef struct VirtIOPMEMPCI VirtIOPMEMPCI;
 
 /* virtio-pci-bus */
 
@@ -274,6 +276,18 @@ struct VirtIOBlkPCI {
 VirtIOBlock vdev;
 };
 
+/*
+ * 

[Qemu-devel] [RFC v2 0/2] kvm "fake DAX" device flushing

2018-04-25 Thread Pankaj Gupta
This is RFC V2 for 'fake DAX' flushing interface sharing
for review. This patchset has two main parts:

- Guest virtio-pmem driver
  Guest driver reads persistent memory range from paravirt 
  device and registers with 'nvdimm_bus'. 'nvdimm/pmem' 
  driver uses this information to allocate persistent 
  memory range. Also, we have implemented guest side of 
  VIRTIO flushing interface.

- Qemu virtio-pmem device
  It exposes a persistent memory range to KVM guest which 
  at host side is file backed memory and works as persistent 
  memory device. In addition to this it provides virtio 
  device handling of flushing interface. KVM guest performs
  Qemu side asynchronous sync using this interface.

Changes from previous RFC[1]:

- Reuse existing 'pmem' code for registering persistent 
  memory and other operations instead of creating an entirely 
  new block driver.
- Use VIRTIO driver to register memory information with 
  nvdimm_bus and create region_type accordingly. 
- Call VIRTIO flush from existing pmem driver.

Details of project idea for 'fake DAX' flushing interface is 
shared [2] & [3].

Pankaj Gupta (2):
   Add virtio-pmem guest driver
   pmem: device flush over VIRTIO

[1] https://marc.info/?l=linux-mm=150782346802290=2
[2] https://www.spinics.net/lists/kvm/msg149761.html
[3] https://www.spinics.net/lists/kvm/msg153095.html  

 drivers/nvdimm/region_devs.c |7 ++
 drivers/virtio/Kconfig   |   12 +++
 drivers/virtio/Makefile  |1 
 drivers/virtio/virtio_pmem.c |  118 +++
 include/linux/libnvdimm.h|4 +
 include/uapi/linux/virtio_ids.h  |1 
 include/uapi/linux/virtio_pmem.h |   58 +++
 7 files changed, 201 insertions(+)



[Qemu-devel] [PATCH v12 01/21] migration: Set error state in case of error

2018-04-25 Thread Juan Quintela
Signed-off-by: Juan Quintela 
---
 migration/ram.c | 24 ++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/migration/ram.c b/migration/ram.c
index 0e90efa092..2ae560ea80 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -415,10 +415,20 @@ struct {
 int count;
 } *multifd_send_state;
 
-static void terminate_multifd_send_threads(Error *errp)
+static void terminate_multifd_send_threads(Error *err)
 {
 int i;
 
+if (err) {
+MigrationState *s = migrate_get_current();
+migrate_set_error(s, err);
+if (s->state == MIGRATION_STATUS_SETUP ||
+s->state == MIGRATION_STATUS_ACTIVE) {
+migrate_set_state(>state, s->state,
+  MIGRATION_STATUS_FAILED);
+}
+}
+
 for (i = 0; i < multifd_send_state->count; i++) {
 MultiFDSendParams *p = _send_state->params[i];
 
@@ -515,10 +525,20 @@ struct {
 int count;
 } *multifd_recv_state;
 
-static void terminate_multifd_recv_threads(Error *errp)
+static void terminate_multifd_recv_threads(Error *err)
 {
 int i;
 
+if (err) {
+MigrationState *s = migrate_get_current();
+migrate_set_error(s, err);
+if (s->state == MIGRATION_STATUS_SETUP ||
+s->state == MIGRATION_STATUS_ACTIVE) {
+migrate_set_state(>state, s->state,
+  MIGRATION_STATUS_FAILED);
+}
+}
+
 for (i = 0; i < multifd_recv_state->count; i++) {
 MultiFDRecvParams *p = _recv_state->params[i];
 
-- 
2.17.0




[Qemu-devel] [RFC v2 1/2] virtio: add pmem driver

2018-04-25 Thread Pankaj Gupta
This patch adds virtio-pmem driver for KVM 
guest. 

Guest reads the persistent memory range 
information from Qemu over VIRTIO and registers 
it on nvdimm_bus. It also creates a nd_region 
object with the persistent memory range 
information so that existing 'nvdimm/pmem' 
driver can reserve this into system memory map. 
This way 'virtio-pmem' driver uses existing 
functionality of pmem driver to register persistent 
memory compatible for DAX capable filesystems.

This also provides function to perform guest flush 
over VIRTIO from 'pmem' driver when userspace 
performs flush on DAX memory range.

Signed-off-by: Pankaj Gupta 
---
 drivers/virtio/Kconfig   |  12 
 drivers/virtio/Makefile  |   1 +
 drivers/virtio/virtio_pmem.c | 118 +++
 include/linux/libnvdimm.h|   4 ++
 include/uapi/linux/virtio_ids.h  |   1 +
 include/uapi/linux/virtio_pmem.h |  58 +++
 6 files changed, 194 insertions(+)
 create mode 100644 drivers/virtio/virtio_pmem.c
 create mode 100644 include/uapi/linux/virtio_pmem.h

diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index 3589764..879335d 100644
--- a/drivers/virtio/Kconfig
+++ b/drivers/virtio/Kconfig
@@ -42,6 +42,18 @@ config VIRTIO_PCI_LEGACY
 
  If unsure, say Y.
 
+config VIRTIO_PMEM
+   tristate "Virtio pmem driver"
+   depends on VIRTIO
+   help
+This driver adds persistent memory range to nd_region and registers
+with nvdimm bus. NVDIMM 'pmem' driver later allocates a persistent
+memory range on the memory information added by this driver. In 
addition
+to this, 'virtio-pmem' driver also provides a paravirt flushing 
interface
+from guest to host.
+
+If unsure, say M.
+
 config VIRTIO_BALLOON
tristate "Virtio balloon driver"
depends on VIRTIO
diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile
index 3a2b5c5..cbe91c6 100644
--- a/drivers/virtio/Makefile
+++ b/drivers/virtio/Makefile
@@ -6,3 +6,4 @@ virtio_pci-y := virtio_pci_modern.o virtio_pci_common.o
 virtio_pci-$(CONFIG_VIRTIO_PCI_LEGACY) += virtio_pci_legacy.o
 obj-$(CONFIG_VIRTIO_BALLOON) += virtio_balloon.o
 obj-$(CONFIG_VIRTIO_INPUT) += virtio_input.o
+obj-$(CONFIG_VIRTIO_PMEM) += virtio_pmem.o
diff --git a/drivers/virtio/virtio_pmem.c b/drivers/virtio/virtio_pmem.c
new file mode 100644
index 000..0906d2d
--- /dev/null
+++ b/drivers/virtio/virtio_pmem.c
@@ -0,0 +1,118 @@
+/* Virtio pmem Driver
+ *
+ * Discovers persitent memory range information
+ * from host and provides a virtio based flushing
+ * interface.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int init_vq(struct virtio_pmem *vpmem)
+{
+   struct virtqueue *vq;
+
+   /* single vq */
+   vpmem->req_vq = vq = virtio_find_single_vq(vpmem->vdev,
+   NULL, "flush_queue");
+
+   if (IS_ERR(vq))
+   return PTR_ERR(vq);
+
+   return 0;
+};
+
+static int virtio_pmem_probe(struct virtio_device *vdev)
+{
+   int err = 0;
+   struct resource res;
+   struct virtio_pmem *vpmem;
+   struct nvdimm_bus *nvdimm_bus;
+   struct nd_region_desc ndr_desc;
+   int nid = dev_to_node(>dev);
+   static struct nvdimm_bus_descriptor nd_desc;
+
+   if (!vdev->config->get) {
+   dev_err(>dev, "%s failure: config disabled\n",
+   __func__);
+   return -EINVAL;
+   }
+
+   vdev->priv = vpmem = devm_kzalloc(>dev, sizeof(*vpmem),
+   GFP_KERNEL);
+   if (!vpmem) {
+   err = -ENOMEM;
+   goto out;
+   }
+
+   vpmem->vdev = vdev;
+   err = init_vq(vpmem);
+   if (err)
+   goto out;
+
+   virtio_cread(vpmem->vdev, struct virtio_pmem_config,
+   start, >start);
+   virtio_cread(vpmem->vdev, struct virtio_pmem_config,
+   size, >size);
+
+   res.start = vpmem->start;
+   res.end   = vpmem->start + vpmem->size-1;
+
+   memset(_desc, 0, sizeof(nd_desc));
+   nd_desc.provider_name = "virtio-pmem";
+   nd_desc.module = THIS_MODULE;
+   nvdimm_bus = nvdimm_bus_register(>dev, _desc);
+
+   if (!nvdimm_bus)
+   goto out_nd;
+   dev_set_drvdata(>dev, nvdimm_bus);
+
+   memset(_desc, 0, sizeof(ndr_desc));
+   ndr_desc.res = 
+   ndr_desc.numa_node = nid;
+   set_bit(ND_REGION_PAGEMAP, _desc.flags);
+   set_bit(ND_REGION_VIRTIO, _desc.flags);
+
+   if (!nvdimm_pmem_region_create(nvdimm_bus, _desc))
+   goto out_nd;
+
+   virtio_device_ready(vdev);
+   return 0;
+
+out_nd:
+   nvdimm_bus_unregister(nvdimm_bus);
+out:
+   dev_err(>dev, "failed to register virtio pmem memory\n");
+   vdev->config->del_vqs(vdev);
+   return err;
+}
+
+static 

[Qemu-devel] [PATCH v8 7/8] migration: Add multifd test

2018-04-25 Thread Juan Quintela
We set the x-multifd-page-count and x-multifd-channels.

Signed-off-by: Juan Quintela 
Reviewed-by: Dr. David Alan Gilbert 
---
 tests/migration-test.c | 48 ++
 1 file changed, 48 insertions(+)

diff --git a/tests/migration-test.c b/tests/migration-test.c
index 309ae4793e..873bb58200 100644
--- a/tests/migration-test.c
+++ b/tests/migration-test.c
@@ -742,6 +742,53 @@ static void test_precopy_tcp(void)
 g_free(uri);
 }
 
+static void test_multifd_tcp(void)
+{
+char *uri;
+QTestState *from, *to;
+
+test_migrate_start(, , "tcp:127.0.0.1:0", false);
+
+/* We want to pick a speed slow enough that the test completes
+ * quickly, but that it doesn't complete precopy even on a slow
+ * machine, so also set the downtime.
+ */
+/* 1 ms should make it not converge*/
+migrate_set_parameter(from, "downtime-limit", "1");
+/* 1GB/s */
+migrate_set_parameter(from, "max-bandwidth", "10");
+
+migrate_set_parameter(from, "x-multifd-channels", "4");
+migrate_set_parameter(to, "x-multifd-channels", "4");
+
+migrate_set_parameter(from, "x-multifd-page-count", "64");
+migrate_set_parameter(to, "x-multifd-page-count", "64");
+
+migrate_set_capability(from, "x-multifd", "true");
+migrate_set_capability(to, "x-multifd", "true");
+/* Wait for the first serial output from the source */
+wait_for_serial("src_serial");
+
+uri = migrate_get_socket_address(to, "socket-address");
+
+migrate(from, uri);
+
+wait_for_migration_pass(from);
+
+/* 300ms it should converge */
+migrate_set_parameter(from, "downtime-limit", "300");
+
+if (!got_stop) {
+qtest_qmp_eventwait(from, "STOP");
+}
+qtest_qmp_eventwait(to, "RESUME");
+
+wait_for_serial("dest_serial");
+wait_for_migration_complete(from);
+
+test_migrate_end(from, to, true);
+}
+
 int main(int argc, char **argv)
 {
 char template[] = "/tmp/migration-test-XX";
@@ -767,6 +814,7 @@ int main(int argc, char **argv)
 qtest_add_func("/migration/precopy/unix", test_precopy_unix);
 qtest_add_func("/migration/precopy/tcp", test_precopy_tcp);
 qtest_add_func("/migration/xbzrle/unix", test_xbzrle_unix);
+qtest_add_func("/migration/multifd/tcp", test_multifd_tcp);
 
 ret = g_test_run();
 
-- 
2.17.0




[Qemu-devel] [PATCH v8 2/8] tests: Add migration precopy test

2018-04-25 Thread Juan Quintela
Signed-off-by: Juan Quintela 
Reviewed-by: Dr. David Alan Gilbert 
Reviewed-by: Peter Xu 
---
 tests/migration-test.c | 44 --
 1 file changed, 42 insertions(+), 2 deletions(-)

diff --git a/tests/migration-test.c b/tests/migration-test.c
index 422bf1afdf..834cdf50f2 100644
--- a/tests/migration-test.c
+++ b/tests/migration-test.c
@@ -524,7 +524,7 @@ static void test_deprecated(void)
 qtest_quit(from);
 }
 
-static void test_migrate(void)
+static void test_postcopy(void)
 {
 char *uri = g_strdup_printf("unix:%s/migsocket", tmpfs);
 QTestState *from, *to;
@@ -595,6 +595,45 @@ static void test_baddest(void)
 test_migrate_end(from, to, false);
 }
 
+static void test_precopy_unix(void)
+{
+char *uri = g_strdup_printf("unix:%s/migsocket", tmpfs);
+QTestState *from, *to;
+
+test_migrate_start(, , uri, false);
+
+/* We want to pick a speed slow enough that the test completes
+ * quickly, but that it doesn't complete precopy even on a slow
+ * machine, so also set the downtime.
+ */
+/* 1 ms should make it not converge*/
+migrate_set_parameter(from, "downtime-limit", "1");
+/* 1GB/s */
+migrate_set_parameter(from, "max-bandwidth", "10");
+
+/* Wait for the first serial output from the source */
+wait_for_serial("src_serial");
+
+migrate(from, uri);
+
+wait_for_migration_pass(from);
+
+/* 300 ms should converge */
+migrate_set_parameter(from, "downtime-limit", "300");
+
+if (!got_stop) {
+qtest_qmp_eventwait(from, "STOP");
+}
+
+qtest_qmp_eventwait(to, "RESUME");
+
+wait_for_serial("dest_serial");
+wait_for_migration_complete(from);
+
+test_migrate_end(from, to, true);
+g_free(uri);
+}
+
 int main(int argc, char **argv)
 {
 char template[] = "/tmp/migration-test-XX";
@@ -614,9 +653,10 @@ int main(int argc, char **argv)
 
 module_call_init(MODULE_INIT_QOM);
 
-qtest_add_func("/migration/postcopy/unix", test_migrate);
+qtest_add_func("/migration/postcopy/unix", test_postcopy);
 qtest_add_func("/migration/deprecated", test_deprecated);
 qtest_add_func("/migration/bad_dest", test_baddest);
+qtest_add_func("/migration/precopy/unix", test_precopy_unix);
 
 ret = g_test_run();
 
-- 
2.17.0




[Qemu-devel] [PATCH v8 5/8] tests: Migration ppc now inlines its program

2018-04-25 Thread Juan Quintela
No need to write it to a file.  Just need a proper firmware O:-)

Signed-off-by: Juan Quintela 
CC: Laurent Vivier 
---
 tests/migration-test.c | 41 +
 1 file changed, 5 insertions(+), 36 deletions(-)

diff --git a/tests/migration-test.c b/tests/migration-test.c
index fd885ba909..4a94d3d598 100644
--- a/tests/migration-test.c
+++ b/tests/migration-test.c
@@ -19,9 +19,6 @@
 #include "qemu/sockets.h"
 #include "chardev/char.h"
 #include "sysemu/sysemu.h"
-#include "hw/nvram/chrp_nvram.h"
-
-#define MIN_NVRAM_SIZE 8192 /* from spapr_nvram.c */
 
 const unsigned start_address = 1024 * 1024;
 const unsigned end_address = 100 * 1024 * 1024;
@@ -90,36 +87,6 @@ static void init_bootfile_x86(const char *bootpath)
 fclose(bootfile);
 }
 
-static void init_bootfile_ppc(const char *bootpath)
-{
-FILE *bootfile;
-char buf[MIN_NVRAM_SIZE];
-ChrpNvramPartHdr *header = (ChrpNvramPartHdr *)buf;
-
-memset(buf, 0, MIN_NVRAM_SIZE);
-
-/* Create a "common" partition in nvram to store boot-command property */
-
-header->signature = CHRP_NVPART_SYSTEM;
-memcpy(header->name, "common", 6);
-chrp_nvram_finish_partition(header, MIN_NVRAM_SIZE);
-
-/* FW_MAX_SIZE is 4MB, but slof.bin is only 900KB,
- * so let's modify memory between 1MB and 100MB
- * to do like PC bootsector
- */
-
-sprintf(buf + 16,
-"boot-command=hex .\" _\" begin %x %x do i c@ 1 + i c! 1000 +loop "
-".\" B\" 0 until", end_address, start_address);
-
-/* Write partition to the NVRAM file */
-
-bootfile = fopen(bootpath, "wb");
-g_assert_cmpint(fwrite(buf, MIN_NVRAM_SIZE, 1, bootfile), ==, 1);
-fclose(bootfile);
-}
-
 /*
  * Wait for some output in the serial output file,
  * we get an 'A' followed by an endless string of 'B's
@@ -410,12 +377,14 @@ static void test_migrate_start(QTestState **from, 
QTestState **to,
 if (access("/sys/module/kvm_hv", F_OK)) {
 accel = "tcg";
 }
-init_bootfile_ppc(bootpath);
 cmd_src = g_strdup_printf("-machine accel=%s -m 256M"
   " -name source,debug-threads=on"
   " -serial file:%s/src_serial"
-  " -drive file=%s,if=pflash,format=raw",
-  accel, tmpfs, bootpath);
+  " -prom-env '"
+  "boot-command=hex .\" _\" begin %x %x "
+  "do i c@ 1 + i c! 1000 +loop .\" B\" 0 "
+  "until'",  accel, tmpfs, end_address,
+  start_address);
 cmd_dst = g_strdup_printf("-machine accel=%s -m 256M"
   " -name target,debug-threads=on"
   " -serial file:%s/dest_serial"
-- 
2.17.0




[Qemu-devel] [PATCH v8 8/8] [RFH] tests: Add migration compress threads tests

2018-04-25 Thread Juan Quintela
Yeap, it is still not working. trying to learn how to debug threads
for guests running from the testt hardness.

For some reason, compression is not working at the moment, test is
disabled until I found why.

Signed-off-by: Juan Quintela 
---
 tests/migration-test.c | 52 ++
 1 file changed, 52 insertions(+)

diff --git a/tests/migration-test.c b/tests/migration-test.c
index 873bb58200..cf6cec11ef 100644
--- a/tests/migration-test.c
+++ b/tests/migration-test.c
@@ -789,6 +789,55 @@ static void test_multifd_tcp(void)
 test_migrate_end(from, to, true);
 }
 
+static void test_compress(const char *uri)
+{
+QTestState *from, *to;
+
+test_migrate_start(, , uri, false);
+
+/* We want to pick a speed slow enough that the test completes
+ * quickly, but that it doesn't complete precopy even on a slow
+ * machine, so also set the downtime.
+ */
+/* 1 ms should make it not converge*/
+migrate_set_parameter(from, "downtime-limit", "1");
+/* 1GB/s */
+migrate_set_parameter(from, "max-bandwidth", "10");
+
+migrate_set_parameter(from, "compress-threads", "4");
+migrate_set_parameter(to, "decompress-threads", "3");
+
+migrate_set_capability(from, "compress", "true");
+migrate_set_capability(to, "compress", "true");
+/* Wait for the first serial output from the source */
+wait_for_serial("src_serial");
+
+migrate(from, uri);
+
+wait_for_migration_pass(from);
+
+/* 300ms it should converge */
+migrate_set_parameter(from, "downtime-limit", "300");
+
+if (!got_stop) {
+qtest_qmp_eventwait(from, "STOP");
+}
+qtest_qmp_eventwait(to, "RESUME");
+
+wait_for_serial("dest_serial");
+wait_for_migration_complete(from);
+
+test_migrate_end(from, to, true);
+}
+
+static void test_compress_unix(void)
+{
+char *uri = g_strdup_printf("unix:%s/migsocket", tmpfs);
+
+test_compress(uri);
+g_free(uri);
+}
+
 int main(int argc, char **argv)
 {
 char template[] = "/tmp/migration-test-XX";
@@ -815,6 +864,9 @@ int main(int argc, char **argv)
 qtest_add_func("/migration/precopy/tcp", test_precopy_tcp);
 qtest_add_func("/migration/xbzrle/unix", test_xbzrle_unix);
 qtest_add_func("/migration/multifd/tcp", test_multifd_tcp);
+if (0) {
+qtest_add_func("/migration/compress/unix", test_compress_unix);
+}
 
 ret = g_test_run();
 
-- 
2.17.0




[Qemu-devel] [PATCH v8 4/8] migration: Create socket-address parameter

2018-04-25 Thread Juan Quintela
It will be used to store the uri parameters. We want this only for
tcp, so we don't set it for other uris.  We need it to know what port
is migration running.

Signed-off-by: Juan Quintela 

--

This used to be uri parameter, but it has so many troubles to
reproduce that it don't just make sense.

This used to be a port parameter.  I was asked to move to
SocketAddress, done.
I also merged the setting of the migration tcp port in this one
because now I need to free the address, and this makes it easier.
This used to be x-socket-address with a single direction, now it is a
list of addresses.
---
 hmp.c | 14 ++
 migration/migration.c | 25 +
 migration/migration.h |  1 +
 migration/socket.c| 11 +++
 qapi/migration.json   | 13 +++--
 qapi/sockets.json | 13 +
 6 files changed, 75 insertions(+), 2 deletions(-)

diff --git a/hmp.c b/hmp.c
index a25c7bd9a8..caf94345c9 100644
--- a/hmp.c
+++ b/hmp.c
@@ -355,6 +355,20 @@ void hmp_info_migrate_parameters(Monitor *mon, const QDict 
*qdict)
 monitor_printf(mon, "%s: %" PRIu64 "\n",
 MigrationParameter_str(MIGRATION_PARAMETER_XBZRLE_CACHE_SIZE),
 params->xbzrle_cache_size);
+if (params->has_socket_address) {
+SocketAddressList *addr;
+
+monitor_printf(mon, "%s: [\n",
+MigrationParameter_str(MIGRATION_PARAMETER_SOCKET_ADDRESS));
+
+for (addr = params->socket_address; addr; addr = addr->next) {
+char *s = SocketAddress_to_str("", addr->value,
+   false, false);
+monitor_printf(mon, "\t%s\n", s);
+}
+
+monitor_printf(mon, "]\n");
+}
 }
 
 qapi_free_MigrationParameters(params);
diff --git a/migration/migration.c b/migration/migration.c
index 52a5092add..7eca65d1f0 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -31,6 +31,8 @@
 #include "migration/vmstate.h"
 #include "block/block.h"
 #include "qapi/error.h"
+#include "qapi/clone-visitor.h"
+#include "qapi/qapi-visit-sockets.h"
 #include "qapi/qapi-commands-migration.h"
 #include "qapi/qapi-events-migration.h"
 #include "qapi/qmp/qerror.h"
@@ -277,6 +279,21 @@ int migrate_send_rp_req_pages(MigrationIncomingState *mis, 
const char *rbname,
 return migrate_send_rp_message(mis, msg_type, msglen, bufc);
 }
 
+void migrate_set_address(SocketAddress *address)
+{
+MigrationState *s = migrate_get_current();
+SocketAddressList *addrs;
+
+addrs = g_new0(SocketAddressList, 1);
+addrs->next = s->parameters.socket_address;
+s->parameters.socket_address = addrs;
+
+if (!s->parameters.has_socket_address) {
+s->parameters.has_socket_address = true;
+}
+addrs->value = QAPI_CLONE(SocketAddress, address);
+}
+
 void qemu_start_incoming_migration(const char *uri, Error **errp)
 {
 const char *p;
@@ -556,6 +573,11 @@ MigrationParameters *qmp_query_migrate_parameters(Error 
**errp)
 params->x_multifd_page_count = s->parameters.x_multifd_page_count;
 params->has_xbzrle_cache_size = true;
 params->xbzrle_cache_size = s->parameters.xbzrle_cache_size;
+if (s->parameters.socket_address) {
+params->has_socket_address = true;
+params->socket_address =
+QAPI_CLONE(SocketAddressList, s->parameters.socket_address);
+}
 
 return params;
 }
@@ -2563,6 +2585,9 @@ static void migration_instance_finalize(Object *obj)
 qemu_mutex_destroy(>error_mutex);
 g_free(params->tls_hostname);
 g_free(params->tls_creds);
+if (params->socket_address) {
+qapi_free_SocketAddressList(params->socket_address);
+}
 qemu_sem_destroy(>pause_sem);
 error_free(ms->error);
 }
diff --git a/migration/migration.h b/migration/migration.h
index 8d2f320c48..4774ee305f 100644
--- a/migration/migration.h
+++ b/migration/migration.h
@@ -241,5 +241,6 @@ int migrate_send_rp_req_pages(MigrationIncomingState *mis, 
const char* rbname,
 
 void dirty_bitmap_mig_before_vm_start(void);
 void init_dirty_bitmap_incoming_migration(void);
+void migrate_set_address(SocketAddress *address);
 
 #endif
diff --git a/migration/socket.c b/migration/socket.c
index 122d8ccfbe..edf33c70cf 100644
--- a/migration/socket.c
+++ b/migration/socket.c
@@ -15,6 +15,7 @@
  */
 
 #include "qemu/osdep.h"
+#include "qemu/cutils.h"
 
 #include "qemu-common.h"
 #include "qemu/error-report.h"
@@ -152,6 +153,7 @@ static void socket_start_incoming_migration(SocketAddress 
*saddr,
 Error **errp)
 {
 QIONetListener *listener = qio_net_listener_new();
+int i;
 
 qio_net_listener_set_name(listener, "migration-socket-listener");
 
@@ -163,6 +165,15 @@ static void socket_start_incoming_migration(SocketAddress 
*saddr,
 qio_net_listener_set_client_func(listener,
  

[Qemu-devel] [PATCH v8 6/8] tests: Add basic migration precopy tcp test

2018-04-25 Thread Juan Quintela
Not sharing code from precopy/unix because we have to read back the
tcp parameter.

Signed-off-by: Juan Quintela 
Reviewed-by: Dr. David Alan Gilbert 
Reviewed-by: Peter Xu 
---
 tests/migration-test.c | 83 --
 1 file changed, 80 insertions(+), 3 deletions(-)

diff --git a/tests/migration-test.c b/tests/migration-test.c
index 4a94d3d598..309ae4793e 100644
--- a/tests/migration-test.c
+++ b/tests/migration-test.c
@@ -19,6 +19,9 @@
 #include "qemu/sockets.h"
 #include "chardev/char.h"
 #include "sysemu/sysemu.h"
+#include "qapi/qapi-visit-sockets.h"
+#include "qapi/qobject-input-visitor.h"
+#include "qapi/qobject-output-visitor.h"
 
 const unsigned start_address = 1024 * 1024;
 const unsigned end_address = 100 * 1024 * 1024;
@@ -277,8 +280,32 @@ static void cleanup(const char *filename)
 g_free(path);
 }
 
-static void migrate_check_parameter(QTestState *who, const char *parameter,
-const char *value)
+static char *migrate_get_socket_address(QTestState *who, const char *parameter)
+{
+QDict *rsp, *rsp_return;
+char *result;
+Error *local_err = NULL;
+SocketAddressList *addrs;
+Visitor *iv = NULL;
+QObject *object;
+
+rsp = wait_command(who, "{ 'execute': 'query-migrate-parameters' }");
+rsp_return = qdict_get_qdict(rsp, "return");
+object = qdict_get(rsp_return, parameter);
+
+iv = qobject_input_visitor_new(object);
+visit_type_SocketAddressList(iv, NULL, , _err);
+
+/* we are only using a single address */
+result = g_strdup_printf("%s", SocketAddress_to_str("", addrs->value,
+false, false));
+
+qapi_free_SocketAddressList(addrs);
+QDECREF(rsp);
+return result;
+}
+
+static char *migrate_get_parameter(QTestState *who, const char *parameter)
 {
 QDict *rsp, *rsp_return;
 char *result;
@@ -287,9 +314,18 @@ static void migrate_check_parameter(QTestState *who, const 
char *parameter,
 rsp_return = qdict_get_qdict(rsp, "return");
 result = g_strdup_printf("%" PRId64,
  qdict_get_try_int(rsp_return,  parameter, -1));
+QDECREF(rsp);
+return result;
+}
+
+static void migrate_check_parameter(QTestState *who, const char *parameter,
+const char *value)
+{
+char *result;
+
+result = migrate_get_parameter(who, parameter);
 g_assert_cmpstr(result, ==, value);
 g_free(result);
-QDECREF(rsp);
 }
 
 static void migrate_set_parameter(QTestState *who, const char *parameter,
@@ -666,6 +702,46 @@ static void test_xbzrle_unix(void)
 g_free(uri);
 }
 
+static void test_precopy_tcp(void)
+{
+char *uri;
+QTestState *from, *to;
+
+test_migrate_start(, , "tcp:127.0.0.1:0", false);
+
+/* We want to pick a speed slow enough that the test completes
+ * quickly, but that it doesn't complete precopy even on a slow
+ * machine, so also set the downtime.
+ */
+/* 1 ms should make it not converge*/
+migrate_set_parameter(from, "downtime-limit", "1");
+/* 1GB/s */
+migrate_set_parameter(from, "max-bandwidth", "10");
+
+/* Wait for the first serial output from the source */
+wait_for_serial("src_serial");
+
+uri = migrate_get_socket_address(to, "socket-address");
+
+migrate(from, uri);
+
+wait_for_migration_pass(from);
+
+/* 300ms should converge */
+migrate_set_parameter(from, "downtime-limit", "300");
+
+if (!got_stop) {
+qtest_qmp_eventwait(from, "STOP");
+}
+qtest_qmp_eventwait(to, "RESUME");
+
+wait_for_serial("dest_serial");
+wait_for_migration_complete(from);
+
+test_migrate_end(from, to, true);
+g_free(uri);
+}
+
 int main(int argc, char **argv)
 {
 char template[] = "/tmp/migration-test-XX";
@@ -689,6 +765,7 @@ int main(int argc, char **argv)
 qtest_add_func("/migration/deprecated", test_deprecated);
 qtest_add_func("/migration/bad_dest", test_baddest);
 qtest_add_func("/migration/precopy/unix", test_precopy_unix);
+qtest_add_func("/migration/precopy/tcp", test_precopy_tcp);
 qtest_add_func("/migration/xbzrle/unix", test_xbzrle_unix);
 
 ret = g_test_run();
-- 
2.17.0




[Qemu-devel] [PATCH v8 3/8] tests: Add migration xbzrle test

2018-04-25 Thread Juan Quintela
Signed-off-by: Juan Quintela 
Reviewed-by: Peter Xu 
---
 tests/migration-test.c | 64 ++
 1 file changed, 64 insertions(+)

diff --git a/tests/migration-test.c b/tests/migration-test.c
index 834cdf50f2..fd885ba909 100644
--- a/tests/migration-test.c
+++ b/tests/migration-test.c
@@ -512,6 +512,20 @@ static void deprecated_set_speed(QTestState *who, const 
char *value)
 migrate_check_parameter(who, "max-bandwidth", value);
 }
 
+static void deprecated_set_cache_size(QTestState *who, const char *value)
+{
+QDict *rsp;
+gchar *cmd;
+
+cmd = g_strdup_printf("{ 'execute': 'migrate-set-cache-size',"
+  "'arguments': { 'value': %s } }", value);
+rsp = qtest_qmp(who, cmd);
+g_free(cmd);
+g_assert(qdict_haskey(rsp, "return"));
+QDECREF(rsp);
+migrate_check_parameter(who, "xbzrle-cache-size", value);
+}
+
 static void test_deprecated(void)
 {
 QTestState *from;
@@ -520,6 +534,7 @@ static void test_deprecated(void)
 
 deprecated_set_downtime(from, 0.12345);
 deprecated_set_speed(from, "12345");
+deprecated_set_cache_size(from, "4096");
 
 qtest_quit(from);
 }
@@ -634,6 +649,54 @@ static void test_precopy_unix(void)
 g_free(uri);
 }
 
+static void test_xbzrle(const char *uri)
+{
+QTestState *from, *to;
+
+test_migrate_start(, , uri, false);
+
+/* We want to pick a speed slow enough that the test completes
+ * quickly, but that it doesn't complete precopy even on a slow
+ * machine, so also set the downtime.
+ */
+/* 1 ms should make it not converge*/
+migrate_set_parameter(from, "downtime-limit", "1");
+/* 1GB/s */
+migrate_set_parameter(from, "max-bandwidth", "10");
+
+migrate_set_parameter(from, "xbzrle-cache-size", "33554432");
+
+migrate_set_capability(from, "xbzrle", "true");
+migrate_set_capability(to, "xbzrle", "true");
+/* Wait for the first serial output from the source */
+wait_for_serial("src_serial");
+
+migrate(from, uri);
+
+wait_for_migration_pass(from);
+
+/* 300ms should converge */
+migrate_set_parameter(from, "downtime-limit", "300");
+
+if (!got_stop) {
+qtest_qmp_eventwait(from, "STOP");
+}
+qtest_qmp_eventwait(to, "RESUME");
+
+wait_for_serial("dest_serial");
+wait_for_migration_complete(from);
+
+test_migrate_end(from, to, true);
+}
+
+static void test_xbzrle_unix(void)
+{
+char *uri = g_strdup_printf("unix:%s/migsocket", tmpfs);
+
+test_xbzrle(uri);
+g_free(uri);
+}
+
 int main(int argc, char **argv)
 {
 char template[] = "/tmp/migration-test-XX";
@@ -657,6 +720,7 @@ int main(int argc, char **argv)
 qtest_add_func("/migration/deprecated", test_deprecated);
 qtest_add_func("/migration/bad_dest", test_baddest);
 qtest_add_func("/migration/precopy/unix", test_precopy_unix);
+qtest_add_func("/migration/xbzrle/unix", test_xbzrle_unix);
 
 ret = g_test_run();
 
-- 
2.17.0




[Qemu-devel] [PATCH v8 1/8] qemu-sockets: Export SocketAddress_to_str

2018-04-25 Thread Juan Quintela
Migration code needs that function in hmp.c (so we need to export it),
and it needs it on tests/migration-test.c, so we need to move it to a
place where it is compiled into the test framework.

Signed-off-by: Juan Quintela 
---
 chardev/char-socket.c  | 29 -
 include/qemu/sockets.h |  3 +++
 util/qemu-sockets.c| 29 +
 3 files changed, 32 insertions(+), 29 deletions(-)

diff --git a/chardev/char-socket.c b/chardev/char-socket.c
index 159e69c3b1..3bbf3a37a0 100644
--- a/chardev/char-socket.c
+++ b/chardev/char-socket.c
@@ -382,35 +382,6 @@ static void tcp_chr_free_connection(Chardev *chr)
 s->connected = 0;
 }
 
-static char *SocketAddress_to_str(const char *prefix, SocketAddress *addr,
-  bool is_listen, bool is_telnet)
-{
-switch (addr->type) {
-case SOCKET_ADDRESS_TYPE_INET:
-return g_strdup_printf("%s%s:%s:%s%s", prefix,
-   is_telnet ? "telnet" : "tcp",
-   addr->u.inet.host,
-   addr->u.inet.port,
-   is_listen ? ",server" : "");
-break;
-case SOCKET_ADDRESS_TYPE_UNIX:
-return g_strdup_printf("%sunix:%s%s", prefix,
-   addr->u.q_unix.path,
-   is_listen ? ",server" : "");
-break;
-case SOCKET_ADDRESS_TYPE_FD:
-return g_strdup_printf("%sfd:%s%s", prefix, addr->u.fd.str,
-   is_listen ? ",server" : "");
-break;
-case SOCKET_ADDRESS_TYPE_VSOCK:
-return g_strdup_printf("%svsock:%s:%s", prefix,
-   addr->u.vsock.cid,
-   addr->u.vsock.port);
-default:
-abort();
-}
-}
-
 static void update_disconnected_filename(SocketChardev *s)
 {
 Chardev *chr = CHARDEV(s);
diff --git a/include/qemu/sockets.h b/include/qemu/sockets.h
index 8140fea685..efea0ea850 100644
--- a/include/qemu/sockets.h
+++ b/include/qemu/sockets.h
@@ -110,4 +110,7 @@ SocketAddress *socket_remote_address(int fd, Error **errp);
  */
 SocketAddress *socket_address_flatten(SocketAddressLegacy *addr);
 
+char *SocketAddress_to_str(const char *prefix, SocketAddress *addr,
+   bool is_listen, bool is_telnet);
+
 #endif /* QEMU_SOCKETS_H */
diff --git a/util/qemu-sockets.c b/util/qemu-sockets.c
index 8bd8bb64eb..09f04bf76b 100644
--- a/util/qemu-sockets.c
+++ b/util/qemu-sockets.c
@@ -1333,3 +1333,32 @@ SocketAddress 
*socket_address_flatten(SocketAddressLegacy *addr_legacy)
 
 return addr;
 }
+
+char *SocketAddress_to_str(const char *prefix, SocketAddress *addr,
+  bool is_listen, bool is_telnet)
+{
+switch (addr->type) {
+case SOCKET_ADDRESS_TYPE_INET:
+return g_strdup_printf("%s%s:%s:%s%s", prefix,
+   is_telnet ? "telnet" : "tcp",
+   addr->u.inet.host,
+   addr->u.inet.port,
+   is_listen ? ",server" : "");
+break;
+case SOCKET_ADDRESS_TYPE_UNIX:
+return g_strdup_printf("%sunix:%s%s", prefix,
+   addr->u.q_unix.path,
+   is_listen ? ",server" : "");
+break;
+case SOCKET_ADDRESS_TYPE_FD:
+return g_strdup_printf("%sfd:%s%s", prefix, addr->u.fd.str,
+   is_listen ? ",server" : "");
+break;
+case SOCKET_ADDRESS_TYPE_VSOCK:
+return g_strdup_printf("%svsock:%s:%s", prefix,
+   addr->u.vsock.cid,
+   addr->u.vsock.port);
+default:
+abort();
+}
+}
-- 
2.17.0




[Qemu-devel] [PATCH v8 0/8] Add make check tests for Migration

2018-04-25 Thread Juan Quintela

Hi

v8:
- just rebase to make things continue to wonk


New in the other v7:
- SocketAddress is now a list (a.k.a make happy danp)
- Rebase on top of upstream
  network listener is *interesting*
- *HACK* to make SocketAddress list in common
  see patch: create-socket-paramenter

Please review, Juan.

CC: berra...@redhat.com

[v7]
This is v6, it differest from the patches that I sent with previous
multifd post:
- Rename x-tcp-port to x-socket-address
  This is more *complicated* that it looks as:

  * it is a pointer, so I need to use QAPI_CLONE() to make info
migrate work

  * this is an union of structs.  In QAPI. So, a dict of strings.  The
only way that I was able to make things work is parsing the qdict
to a SocketAddress and then output a SocketAddress as an str.  It
needs to be an easier way, for sure.

  * Cleanups here andthere.

Please, review, Juan.

[v5]
- Several patches moved to pull request
- merge info_migrate and migration_tests
  only missing bit is tcp_port, needed for tcp tests
- Rename tcp-port to x-tcp-port
  We will get better naming from David at some point, and we will use that bit
- ppc: use inline code as suggested by lvivier

Please, review.

It is based on my previous pull request

Based-on: 20180129120932.12874-1-quint...@redhat.com

[v4]
- rebase on top on v4 info_migrate patches
- Tune sleeps to make patches fast
- Create a deprecated test for deprecated commands (i.e. make peterxu happy)
- create migrate_start_postcopy function
- fix naming/sizes between power and x86
- cleanup comments to match code

[v3]

- No more tests for deprecated parameters. Now I only use
  migrate_set_parameter.  If there is a deprecated command for that,
  we tests it there.
- free "result" string, always good to return memory (Peter found it)
- use the new tcp_port parameter from info migrate.  So we are
  handling well the tcp case.
- lots of code movement around to make everything consistent.
- Several patches already integrated upstream.

[v2]
- to make review easier, I started renaming postcopy-test.c to migration-test.c
- Did cleanups/refactoring there
- Don't use global-qtest anymore
- check that the parameters that we sent got really set
- RFH: comrpress threads tests is not working for some weird reason.  Using the 
same code on command line works.
  still investigating why.

ToDoo:

- tcp: after discussions with dave, we ended in conclusion that we
  need to use the 0 port and let the system gives us a free one

  But  that means that we need to be able to get that port back somehow.
  "info migrate" woring on destination side?

- compression threads.  There is some weird interaction with the test
  hardness and every migration thread get waiting in a different
  semaphore.  Investigating if it is a race/bug/whateverr

- deprecated commands: There was a suggestion to make
  migrate_set_parameter look at the parameter name and test old/new
  depending on something.  Not sure what to do here.

- testing commands: Is there a way to launch qemu and just sent
  qmp/hmp commands without having to really run anything else?

[v1]
- add test for precopy for unix/tcp
  exec and fd to came, don't know how to test rdma without hardware
- add tests using deprecated interfaces
- add test for xbzrle
  Note to myself, there is no way to set the cache size with 
migraton_set_parameters
- Add test for compress threads
  disabled on the series, right now it appears that compression is not working 
at all
- Move postcopy to use new results
  Idea is to move it on top of migration-test.c, but first I want some reviews 
on basic idea

Juan Quintela (8):
  qemu-sockets: Export SocketAddress_to_str
  tests: Add migration precopy test
  tests: Add migration xbzrle test
  migration: Create socket-address parameter
  tests: Migration ppc now inlines its program
  tests: Add basic migration precopy tcp test
  migration: Add multifd test
  [RFH] tests: Add migration compress threads tests

 chardev/char-socket.c  |  29 
 hmp.c  |  14 ++
 include/qemu/sockets.h |   3 +
 migration/migration.c  |  25 
 migration/migration.h  |   1 +
 migration/socket.c |  11 ++
 qapi/migration.json|  13 +-
 qapi/sockets.json  |  13 ++
 tests/migration-test.c | 332 -
 util/qemu-sockets.c|  29 
 10 files changed, 398 insertions(+), 72 deletions(-)

-- 
2.17.0




Re: [Qemu-devel] [PATCH v2 1/9] block: Add COR filter driver

2018-04-25 Thread Max Reitz
On 2018-04-24 17:08, Alberto Garcia wrote:
> On Sat 21 Apr 2018 03:29:21 PM CEST, Max Reitz wrote:
>> This adds a simple copy-on-read filter driver.  It relies on the already
>> existing COR functionality in the central block layer code, which may be
>> moved here once we no longer need it there.
>>
>> Signed-off-by: Max Reitz 
> 
> 
>> +#define PERM_PASSTHROUGH (BLK_PERM_CONSISTENT_READ \
>> +  | BLK_PERM_WRITE \
>> +  | BLK_PERM_RESIZE)
>> +#define PERM_UNCHANGED (BLK_PERM_ALL & ~PERM_PASSTHROUGH)
>> +
>> +static void cor_child_perm(BlockDriverState *bs, BdrvChild *c,
>> +   const BdrvChildRole *role,
>> +   BlockReopenQueue *reopen_queue,
>> +   uint64_t perm, uint64_t shared,
>> +   uint64_t *nperm, uint64_t *nshared)
>> +{
>> +if (c == NULL) {
>> +*nperm = (perm & PERM_PASSTHROUGH) | BLK_PERM_WRITE_UNCHANGED;
>> +*nshared = (shared & PERM_PASSTHROUGH) | PERM_UNCHANGED;
>> +return;
>> +}
>> +
>> +*nperm = (perm & PERM_PASSTHROUGH) |
>> + (c->perm & PERM_UNCHANGED);
> 
> I admit I'm not completely familiar with this, but don't you need to add
> BLK_PERM_WRITE_UNCHANGED to *nperm ?

As long as it's requested in when the child is attached (which it is in
the "c == NULL" case), it should be part of c->perm then.

(And since PERM_PASSTHROUGH does not contain WRITE_UNCHANGED, it is part
of PERM_UNCHANGED.)

Max

>> +*nshared = (shared & PERM_PASSTHROUGH) |
>> +   (c->shared_perm & PERM_UNCHANGED);
>> +}
> 
> Berto
> 




signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [PATCH] block: Merge .bdrv_co_writev{, _flags} in drivers

2018-04-25 Thread Kevin Wolf
Am 25.04.2018 um 10:06 hat Daniel P. Berrangé geschrieben:
> On Tue, Apr 24, 2018 at 05:01:57PM -0500, Eric Blake wrote:
> > We have too many driver callback interfaces; simplify the mess
> > somewhat by merging the flags parameter of .bdrv_co_writev_flags()
> > into .bdrv_co_writev_flags().  Note that as long as a driver doesn't
> 
> Typo - this should be just  .bdrv_co_writev

Thanks, fixed up the typo and applied to block-next.

Kevin



Re: [Qemu-devel] [PATCH] hw/pci-host/q35: Replace hardcoded value with macro

2018-04-25 Thread no-reply
Hi,

This series seems to have some coding style problems. See output below for
more information:

Type: series
Message-id: 1524648037-5010-1-git-send-email-whois.zihan.y...@gmail.com
Subject: [Qemu-devel] [PATCH] hw/pci-host/q35: Replace hardcoded value with 
macro

=== TEST SCRIPT BEGIN ===
#!/bin/bash

BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0

git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram

commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
failed=1
echo
fi
n=$((n+1))
done

exit $failed
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag]   
patchew/1524648037-5010-1-git-send-email-whois.zihan.y...@gmail.com -> 
patchew/1524648037-5010-1-git-send-email-whois.zihan.y...@gmail.com
Switched to a new branch 'test'
361db0df59 hw/pci-host/q35: Replace hardcoded value with macro

=== OUTPUT BEGIN ===
Checking PATCH 1/1: hw/pci-host/q35: Replace hardcoded value with macro...
ERROR: line over 90 characters
#22: FILE: hw/pci-host/q35.c:538:
+ mch->pci_address_space, 
MCH_HOST_BRIDGE_SMRAM_C_BASE, MCH_HOST_BRIDGE_SMRAM_C_SIZE);

WARNING: line over 80 characters
#23: FILE: hw/pci-host/q35.c:539:
+memory_region_add_subregion_overlap(mch->system_memory, 
MCH_HOST_BRIDGE_SMRAM_C_BASE,

ERROR: line over 90 characters
#29: FILE: hw/pci-host/q35.c:544:
+ mch->ram_memory, MCH_HOST_BRIDGE_SMRAM_C_BASE, 
MCH_HOST_BRIDGE_SMRAM_C_SIZE);

WARNING: line over 80 characters
#38: FILE: hw/pci-host/q35.c:553:
+ mch->ram_memory, MCH_HOST_BRIDGE_SMRAM_C_BASE, 
0x2);

ERROR: line over 90 characters
#41: FILE: hw/pci-host/q35.c:555:
+memory_region_add_subregion(>smram, MCH_HOST_BRIDGE_SMRAM_C_BASE, 
>low_smram);

ERROR: line over 90 characters
#44: FILE: hw/pci-host/q35.c:557:
+ mch->ram_memory, MCH_HOST_BRIDGE_SMRAM_C_BASE, 
MCH_HOST_BRIDGE_SMRAM_C_SIZE);

total: 4 errors, 2 warnings, 30 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

=== OUTPUT END ===

Test command exited with code: 1


---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [Qemu-devel] [PATCH v2 0/6] block: byte-based AIO read/write

2018-04-25 Thread Kevin Wolf
Am 24.04.2018 um 21:25 hat Eric Blake geschrieben:
> While we would prefer that block drivers use coroutines instead
> of aio callbacks, it is a fairly easy exercise to prove that
> all existing drivers with aio callbacks are merely scaling
> from bytes into sectors and back to bytes.  So, even though I
> am not set up to completely run (or even compile-test) this
> full series, it seems pretty straightforward to change the
> signature to quit playing games with pointless scaling.
> 
> Incorporate Kevin's review on v1, which amounted to pretty much
> rewriting the series to be saner (the block layer now defaults
> to alignment of 1, so drivers that still need 512 for keeping the
> patch conservative have to override that; and improve the code
> in io.c to put byte-based access before sector-based fallbacks).

Thanks, applied to the block-next branch.

Kevin



Re: [Qemu-devel] [Qemu-block] [PATCH v2 4/6] rbd: Switch to byte-based callbacks

2018-04-25 Thread Kevin Wolf
Am 24.04.2018 um 21:53 hat Jason Dillaman geschrieben:
> On Tue, Apr 24, 2018 at 3:25 PM, Eric Blake  wrote:
> > We are gradually moving away from sector-based interfaces, towards
> > byte-based.  Make the change for the last few sector-based callbacks
> > in the rbd driver.
> >
> > Note that the driver was already using byte-based calls for
> > performing actual I/O, so this just gets rid of a round trip
> > of scaling; however, as I don't know if RBD is tolerant of
> > non-sector AIO operations, I went with the conservate approach
> > of adding .bdrv_refresh_limits to override the block layer
> > defaults back to the pre-patch value of 512.
> >
> > Signed-off-by: Eric Blake 
> >
> > ---
> > v2: override new block layer default alignment [Kevin]
> > ---
> >  block/rbd.c | 44 
> >  1 file changed, 24 insertions(+), 20 deletions(-)
> >
> > diff --git a/block/rbd.c b/block/rbd.c
> > index c9359d0ad84..638ecf8d986 100644
> > --- a/block/rbd.c
> > +++ b/block/rbd.c
> > @@ -231,6 +231,13 @@ done:
> >  }
> >
> >
> > +static void qemu_rbd_refresh_limits(BlockDriverState *bs, Error **errp)
> > +{
> > +/* XXX Does RBD support AIO on less than 512-byte alignment? */
> 
> Yes, librbd internally supports 1-byte alignment for IO, but the
> optimal alignment/length would be object size * stripe count.

Would you like to post a follow-up patch to this series that removes the
.bdrv_refresh_limits implementation again with a commit message
explaining that RBD does support byte alignment?

Kevin



Re: [Qemu-devel] [PATCH v2 2/6] file-win32: Switch to byte-based callbacks

2018-04-25 Thread Kevin Wolf
Am 24.04.2018 um 21:25 hat Eric Blake geschrieben:
> We are gradually moving away from sector-based interfaces, towards
> byte-based.  Make the change for the last few sector-based callbacks
> in the file-win32 driver.
> 
> Note that the driver was already using byte-based calls for
> performing actual I/O, so this just gets rid of a round trip
> of scaling; however, as I don't know if Windows is tolerant of
> non-sector AIO operations, I went with the conservative approach
> of modifying .bdrv_refresh_limits to override the block layer
> defaults back to the pre-patch value of 512.
> 
> Signed-off-by: Eric Blake 
> ---
> Compile-tested via 'make docker-test-mingw@fedora', but I don't
> have a sane way to test whether it actually works.

Tried to test it, and the only result is that something was broken even
before your patch:

$ ./qemu-img.exe create -f raw /tmp/test.raw 128M
Formatting '/tmp/test.raw', fmt=raw size=134217728
$ ./qemu-io.exe -f raw -c 'read 0 4k' /tmp/test.raw
read failed: Input/output error

For some reason, doing the same with qcow2 works fine. qemu-iotests
for qcow2 starts hanging in 013. Maybe someone should look into this,
qemu-iotests was working fairly well with mingw builds some time ago.
Nothing that will hold up this series, though.

Kevin



Re: [Qemu-devel] Filtering files passing through MTP devices

2018-04-25 Thread Omer Katz
We're connecting USB drives that we want the guests to copy files from.
The user should only be allowed to copy certain files into the system.
The same thing goes for copying files to the USB drive. We only allow
certain files to be exported from the guest.

On Wed, Apr 25, 2018, 12:57 PM Daniel P. Berrangé 
wrote:

> On Mon, Apr 23, 2018 at 03:10:32PM +, Omer Katz wrote:
> > Hi everyone,
> >
> > We have a use case that requires us to only allow certain files to pass
> > through to the guest machine from USB storage devices.
> >
> > I was told on IRC that such a feature does not exist but the easiest way
> to
> > achieve our goal is to contribute a patch the the MTP device driver since
> > other drivers operate on a filesystem level instead of a file level which
> > is what we need.
>
> IMHO the easiest way to stop the guest accessing files is to simply not
> put them in the directory that you are exporting the guest in the first
> place. If you have a directory that has some files you don't want accessed
> and can't remove them, then perhaps create a second directory and use
> symlinks or hardlinks to pull in files from the original directory.
>
> > The plan is to pass the contents of each file to a program through stdin
> > and decide based on the exit code if the file should be allowed to pass
> > through to the guest or not.
>
> I can't say I like this idea. It is a really very inefficient and heavy
> solution.
>
> > Since this is the first time I'm contributing to QEMU I'd like some
> > guidance to where the filtering code should be.
> > https://github.com/qemu/qemu/blob/master/hw/usb/dev-mtp.c doesn't look
> that
> > complicated but I still need to understand it better to continue.
> > Furthermore, I need to know where to add such a command line option to
> > point QEMU to the filtering program.
> >
> > Would such a patch be accepted if all the requirements above are met?
>
> Can you explain the usage scenario you have in more details, rather than
> just the high level abstract.
>
>
> Regards,
> Daniel
> --
> |: https://berrange.com  -o-
> https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o-
> https://fstop138.berrange.com :|
> |: https://entangle-photo.org-o-
> https://www.instagram.com/dberrange :|
>


[Qemu-devel] [Bug 1766841] [NEW] QEMU 2.12 Running Problem in Windows 7 Installation

2018-04-25 Thread Justin
Public bug reported:

QEMU Version: 2.12 (Binary installer qemu-w64-setup-20180424.exe  from Stefan 
Weil's website so I am not sure I should report it to Weil by email or by this 
bug report system.)
Host System: Windows 7 64bit
Guest System: 9front 6350 (Codename“CONTENTS, MAINTAINED, STABLE”, Release 
2018/02/02)

QEMU Command:
qemu-system-x86_64 -usb -device usb-mouse -hda plan9.qcow2.img -cdrom 
9front-6350.iso -boot d

QEMU warning: 
(qemu-system-x86_64.exe:8844): GdkPixbuf-WARNING **: Cannot open pixbuf loader 
module file 'D:\qemu\lib\gdk-pixbuf-2.0\2.10.0\loaders.cache': No such file or 
directory

This likely means that your installation is broken.
Try running the command
  gdk-pixbuf-query-loaders > D:\qemu\lib\gdk-pixbuf-2.0\2.10.0\loaders.cache
to make things work again for the time being.

(qemu-system-x86_64.exe:8844): Gtk-WARNING **: Could not find the icon 
'window-minimize-symbolic-ltr'. The 'hicolor' theme was not found either, 
perhaps you need to install it.
You can get a copy from:
http://icon-theme.freedesktop.org/releases

** Affects: qemu
 Importance: Undecided
 Status: New


** Tags: installation windows

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1766841

Title:
  QEMU 2.12 Running Problem in Windows 7 Installation

Status in QEMU:
  New

Bug description:
  QEMU Version: 2.12 (Binary installer qemu-w64-setup-20180424.exe  from Stefan 
Weil's website so I am not sure I should report it to Weil by email or by this 
bug report system.)
  Host System: Windows 7 64bit
  Guest System: 9front 6350 (Codename“CONTENTS, MAINTAINED, STABLE”, Release 
2018/02/02)

  QEMU Command:
  qemu-system-x86_64 -usb -device usb-mouse -hda plan9.qcow2.img -cdrom 
9front-6350.iso -boot d

  QEMU warning: 
  (qemu-system-x86_64.exe:8844): GdkPixbuf-WARNING **: Cannot open pixbuf 
loader module file 'D:\qemu\lib\gdk-pixbuf-2.0\2.10.0\loaders.cache': No such 
file or directory

  This likely means that your installation is broken.
  Try running the command
gdk-pixbuf-query-loaders > D:\qemu\lib\gdk-pixbuf-2.0\2.10.0\loaders.cache
  to make things work again for the time being.

  (qemu-system-x86_64.exe:8844): Gtk-WARNING **: Could not find the icon 
'window-minimize-symbolic-ltr'. The 'hicolor' theme was not found either, 
perhaps you need to install it.
  You can get a copy from:
  http://icon-theme.freedesktop.org/releases

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1766841/+subscriptions



Re: [Qemu-devel] [PATCH v1] hw/s390x: Allow to configure the consoles with the "-serial" parameter

2018-04-25 Thread Thomas Huth
On 25.04.2018 11:50, David Hildenbrand wrote:
> On 25.04.2018 07:21, Thomas Huth wrote:
>> The consoles ("sclpconsole" and "sclplmconsole") can only be configured
>> with "-device" and "-chardev" so far. Other machines use the convenience
>> option "-serial" to configure the default consoles, even for virtual
>> consoles like spapr-vty on the pseries machine. So let's support this
>> option on s390x, too. This way we can easily enable the serial console
>> here again with "-nodefaults", for example:
>>
>> qemu-system-s390x -no-shutdown -nographic -nodefaults -serial mon:stdio
>>
>> ... which is way shorter than typing:
>>
>> qemu-system-s390x -no-shutdown -nographic -nodefaults \
>>   -chardev stdio,id=c1,mux=on -device sclpconsole,chardev=c1 \
>>   -mon chardev=c1
>>
>> The -serial parameter can also be used if you only want to see the QEMU
>> monitor on stdio without using -nodefaults, but not the console output.
>> That's something that is pretty impossible with the current code today:
>>
>> qemu-system-s390x -no-shutdown -nographic -serial none
>>
>> While we're at it, this patch also maps the second -serial option to the
>> "sclplmconsole", so that there is now an easy way to configure this second
>> console on s390x, too, for example:
>>
>> qemu-system-s390x -no-shutdown -nographic -serial null -serial mon:stdio
>>
>> Additionally, the new code is also smaller than the old one and we have
>> less s390x-specific code in vl.c :-)
>>
>> I've also checked that migration still works as expected by migrating
>> a guest with console output back and forth between a qemu-system-s390x
>> that has this patch and an instance without this patch.
>>
>> Signed-off-by: Thomas Huth 
>> ---
>>  RFC -> v1:
>>  - Improved the patch description (provided examples)
>>  - Moved the "init consoles" hunk in ccw_init to a later point in time
>>so that the output of "info qom-tree" shows the same order of devices
>>in the "/machine/unattached" tree.
>>
>>  hw/s390x/event-facility.c | 14 +++
>>  hw/s390x/s390-virtio-ccw.c| 19 +--
>>  include/hw/boards.h   |  1 -
>>  include/hw/s390x/event-facility.h |  2 ++
>>  vl.c  | 50 
>> ---
>>  5 files changed, 33 insertions(+), 53 deletions(-)
>>
>> diff --git a/hw/s390x/event-facility.c b/hw/s390x/event-facility.c
>> index 9c24bc6..e6940a2 100644
>> --- a/hw/s390x/event-facility.c
>> +++ b/hw/s390x/event-facility.c
>> @@ -511,3 +511,17 @@ static void register_types(void)
>>  }
>>  
>>  type_init(register_types)
>> +
>> +BusState *sclp_get_event_facility_bus(void)
>> +{
>> +Object *busobj;
>> +SCLPEventsBus *sbus;
>> +
>> +busobj = object_resolve_path_type("", TYPE_SCLP_EVENTS_BUS, NULL);
>> +sbus = OBJECT_CHECK(SCLPEventsBus, busobj, TYPE_SCLP_EVENTS_BUS);
>> +if (!sbus) {
>> +return NULL;
>> +}
>> +
>> +return >qbus;
>> +}
>> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
>> index 435f7c9..62d909e 100644
>> --- a/hw/s390x/s390-virtio-ccw.c
>> +++ b/hw/s390x/s390-virtio-ccw.c
>> @@ -288,6 +288,15 @@ static void s390_create_virtio_net(BusState *bus, const 
>> char *name)
>>  }
>>  }
>>  
>> +static void s390_create_sclpconsole(const char *type, Chardev *chardev)
>> +{
>> +DeviceState *dev;
>> +
>> +dev = qdev_create(sclp_get_event_facility_bus(), type);
>> +qdev_prop_set_chr(dev, "chardev", chardev);
>> +qdev_init_nofail(dev);
>> +}
>> +
>>  static void ccw_init(MachineState *machine)
>>  {
>>  int ret;
>> @@ -346,6 +355,14 @@ static void ccw_init(MachineState *machine)
>>  /* Create VirtIO network adapters */
>>  s390_create_virtio_net(BUS(css_bus), "virtio-net-ccw");
>>  
>> +/* init consoles */
>> +if (serial_hds[0]) {
>> +s390_create_sclpconsole("sclpconsole", serial_hds[0]);
>> +}
>> +if (serial_hds[1]) {
>> +s390_create_sclpconsole("sclplmconsole", serial_hds[1]);
>> +}
> 
> What happens if more -serial are defined? An error? Silently ignored?

Silently ignored, since this is also what almost all other machines are
doing (look for serial_hds in hw/ and you'll see what I mean).

> (e.g. do we have to redefine MAX_SERIAL_PORTS on s390x or add checking
> code here?)

As all the other machines are also not redefining MAX_SERIAL_PORTS, I
think we should also not do this on s390x now, should we?

 Thomas



Re: [Qemu-devel] [PATCH V5] migration: add capability to bypass the shared memory

2018-04-25 Thread Lai Jiangshan
On Fri, Apr 20, 2018 at 12:38 AM, Dr. David Alan Gilbert
 wrote:

>> -static void ram_list_init_bitmaps(void)
>> +static void ram_list_init_bitmaps(RAMState *rs)
>>  {
>>  RAMBlock *block;
>>  unsigned long pages;
>> @@ -2151,9 +2152,17 @@ static void ram_list_init_bitmaps(void)
>>  /* Skip setting bitmap if there is no RAM */
>>  if (ram_bytes_total()) {
>>  QLIST_FOREACH_RCU(block, _list.blocks, next) {
>> +if (migrate_bypass_shared_memory() && 
>> qemu_ram_is_shared(block)) {
>> +continue;
>> +}
>>  pages = block->max_length >> TARGET_PAGE_BITS;
>>  block->bmap = bitmap_new(pages);
>>  bitmap_set(block->bmap, 0, pages);
>> +/*
>> + * Count the total number of pages used by ram blocks not
>> + * including any gaps due to alignment or unplugs.
>> + */
>> +rs->migration_dirty_pages += pages;
>>  if (migrate_postcopy_ram()) {
>>  block->unsentmap = bitmap_new(pages);
>>  bitmap_set(block->unsentmap, 0, pages);
>
> Can you please rework this to combine with Cédric Le Goater's
> 'discard non-migratable RAMBlocks' - it's quite similar to what you're
> trying to do but for a different reason;  If you look at the v2 from
> April 13, I think you can  just find somewhere to clear the
> RAM_MIGRATABLE flag.

Hello Dave:

It seems we need to add new qmp/hmp command to clear/add
RAM_MIGRATABLE flag which is overkill for such a simple feature.
Please point out if there is any simple way to do so.

And this kind of memory is not "un-MIGRATABLE", the user
just decided not to migrate it/them for one of the migrations.
But they are always MIGRATABLE regardless the user migrate
them or not. So clearing/setting the flag may
cause confusion in this case. What do you think?

Bypassing is an option for every migration. For the
same vm instance, the user might migrate it out
multiple times. He wants to bypass shared memory
in some migrations and do the normal migrations in
other times. So it is better that Bypassing is an option
or capability of migration instead of ramblock.

I don't insist on avoiding using RAM_MIGRATABLE.

Thanks,
Lai

>
> One thing I noticed; in my world I've got some code that checks if we
> ever do a RAM iteration, don't find any dirty blocks but then still have
> migration_dirty_pages being none-0; and with this patch I'm seeing that
> check trigger:
>
>ram_find_and_save_block: no page found, yet dirty_pages=480
>
> it doesn't seem to trigger without the patch.

Does initializing the migration_dirty_pages as you suggested help?

>
> Dave
>
>> @@ -2169,7 +2178,7 @@ static void ram_init_bitmaps(RAMState *rs)
>>  qemu_mutex_lock_ramlist();
>>  rcu_read_lock();
>>
>> -ram_list_init_bitmaps();
>> +ram_list_init_bitmaps(rs);
>>  memory_global_dirty_log_start();
>>  migration_bitmap_sync(rs);
>>
>> diff --git a/qapi/migration.json b/qapi/migration.json
>> index 9d0bf82cf4..45326480bd 100644
>> --- a/qapi/migration.json
>> +++ b/qapi/migration.json
>> @@ -357,13 +357,17 @@
>>  # @dirty-bitmaps: If enabled, QEMU will migrate named dirty bitmaps.
>>  # (since 2.12)
>>  #
>> +# @bypass-shared-memory: the shared memory region will be bypassed on 
>> migration.
>> +#  This feature allows the memory region to be reused by new qemu(s)
>> +#  or be migrated separately. (since 2.13)
>> +#
>>  # Since: 1.2
>>  ##
>>  { 'enum': 'MigrationCapability',
>>'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks',
>> 'compress', 'events', 'postcopy-ram', 'x-colo', 'release-ram',
>> 'block', 'return-path', 'pause-before-switchover', 'x-multifd',
>> -   'dirty-bitmaps' ] }
>> +   'dirty-bitmaps', 'bypass-shared-memory' ] }
>>
>>  ##
>>  # @MigrationCapabilityStatus:
>> --
>> 2.15.1 (Apple Git-101)
>>
> --
> Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK



Re: [Qemu-devel] QEMU monitor banner printed multiple times

2018-04-25 Thread Marc-André Lureau
Hi

On Wed, Apr 25, 2018 at 7:36 AM, Thomas Huth  wrote:
>  Hi,
>
> I just noticed that sometimes, the QEMU monitor banner is printed
> multiple times when you press "CTRL-a c" to enter the monitor:
>
> $ x86_64-softmmu/qemu-system-x86_64 -no-shutdown -nographic \
> -nodefaults - mon:stdio
> QEMU 2.12.0 monitor - type 'help' for more information
> QEMU 2.12.0 monitor - type 'help' for more information
> QEMU 2.12.0 monitor - type 'help' for more information
> QEMU 2.12.0 monitor - type 'help' for more information
> (qemu) q
> QEMU 2.12.0 monitor - type 'help' for more information
> (qemu)
> $
>
> That looks quite ugly. Anybody got an idea how to fix this?

virtio console creates many extra events.

It's not so trivial to fix given how mux works.

What seems easy and probably safe is the following change:

diff --git a/monitor.c b/monitor.c
index 39f8ee17ba..6f4646bf0c 100644
--- a/monitor.c
+++ b/monitor.c
@@ -4411,8 +4411,10 @@ static void monitor_event(void *opaque, int event)
 break;

 case CHR_EVENT_OPENED:
-monitor_printf(mon, "QEMU %s monitor - type 'help' for more "
-   "information\n", QEMU_VERSION);
+if (!mon->reset_seen) {
+monitor_printf(mon, "QEMU %s monitor - type 'help' for more "
+   "information\n", QEMU_VERSION);
+}


-- 
Marc-André Lureau



[Qemu-devel] [PATCH v2] linux-user: set minimum uname for RISC-V

2018-04-25 Thread Alex Bennée
As support for RISC-V was only merged into the mainline kernel at 4.15
it is unlikely that glibc will be happy with a reported kernel version
of 3.8.0. Indeed when I testing binaries created by the current Debian
Sid compiler the tests failed with:

  FATAL: kernel too old

Bump the version to the minimum a RISC-V glibc would expect:

  
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/riscv/configure.ac

Signed-off-by: Alex Bennée 
Reviewed-by: Palmer Dabbelt 
Reviewed-by: Richard Henderson 

---
v2
  - minor tweak to wording to make clearer and add link to glibc config
---
 linux-user/riscv/target_syscall.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/linux-user/riscv/target_syscall.h 
b/linux-user/riscv/target_syscall.h
index d4e109a27f..ee81d8bc88 100644
--- a/linux-user/riscv/target_syscall.h
+++ b/linux-user/riscv/target_syscall.h
@@ -45,7 +45,7 @@ struct target_pt_regs {
 #else
 #define UNAME_MACHINE "riscv64"
 #endif
-#define UNAME_MINIMUM_RELEASE "3.8.0"
+#define UNAME_MINIMUM_RELEASE "4.15.0"
 
 #define TARGET_MINSIGSTKSZ 2048
 #define TARGET_MLOCKALL_MCL_CURRENT 1
-- 
2.17.0




Re: [Qemu-devel] Filtering files passing through MTP devices

2018-04-25 Thread Daniel P . Berrangé
On Mon, Apr 23, 2018 at 03:10:32PM +, Omer Katz wrote:
> Hi everyone,
> 
> We have a use case that requires us to only allow certain files to pass
> through to the guest machine from USB storage devices.
> 
> I was told on IRC that such a feature does not exist but the easiest way to
> achieve our goal is to contribute a patch the the MTP device driver since
> other drivers operate on a filesystem level instead of a file level which
> is what we need.

IMHO the easiest way to stop the guest accessing files is to simply not
put them in the directory that you are exporting the guest in the first
place. If you have a directory that has some files you don't want accessed
and can't remove them, then perhaps create a second directory and use
symlinks or hardlinks to pull in files from the original directory.

> The plan is to pass the contents of each file to a program through stdin
> and decide based on the exit code if the file should be allowed to pass
> through to the guest or not.

I can't say I like this idea. It is a really very inefficient and heavy
solution.

> Since this is the first time I'm contributing to QEMU I'd like some
> guidance to where the filtering code should be.
> https://github.com/qemu/qemu/blob/master/hw/usb/dev-mtp.c doesn't look that
> complicated but I still need to understand it better to continue.
> Furthermore, I need to know where to add such a command line option to
> point QEMU to the filtering program.
> 
> Would such a patch be accepted if all the requirements above are met?

Can you explain the usage scenario you have in more details, rather than
just the high level abstract.


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|



[Qemu-devel] [PATCH v2] hw/pci-host/q35: Replace hardcoded value with macro

2018-04-25 Thread Zihan Yang
During smram region initialization some addresses are hardcoded,
replace them with macro to be more clear to readers.

Previous patch forgets about one value and exceeds the line
limit of 90 characters. The v2 breaks a few long lines

Signed-off-by: Zihan Yang 
---
 hw/pci-host/q35.c | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c
index a36a119..02f9576 100644
--- a/hw/pci-host/q35.c
+++ b/hw/pci-host/q35.c
@@ -535,13 +535,15 @@ static void mch_realize(PCIDevice *d, Error **errp)
 
 /* if *disabled* show SMRAM to all CPUs */
 memory_region_init_alias(>smram_region, OBJECT(mch), "smram-region",
- mch->pci_address_space, 0xa, 0x2);
-memory_region_add_subregion_overlap(mch->system_memory, 0xa,
+ mch->pci_address_space, 
MCH_HOST_BRIDGE_SMRAM_C_BASE,
+ MCH_HOST_BRIDGE_SMRAM_C_SIZE);
+memory_region_add_subregion_overlap(mch->system_memory, 
MCH_HOST_BRIDGE_SMRAM_C_BASE,
 >smram_region, 1);
 memory_region_set_enabled(>smram_region, true);
 
 memory_region_init_alias(>open_high_smram, OBJECT(mch), 
"smram-open-high",
- mch->ram_memory, 0xa, 0x2);
+ mch->ram_memory, MCH_HOST_BRIDGE_SMRAM_C_BASE,
+ MCH_HOST_BRIDGE_SMRAM_C_SIZE);
 memory_region_add_subregion_overlap(mch->system_memory, 0xfeda,
 >open_high_smram, 1);
 memory_region_set_enabled(>open_high_smram, false);
@@ -550,11 +552,14 @@ static void mch_realize(PCIDevice *d, Error **errp)
 memory_region_init(>smram, OBJECT(mch), "smram", 1ull << 32);
 memory_region_set_enabled(>smram, true);
 memory_region_init_alias(>low_smram, OBJECT(mch), "smram-low",
- mch->ram_memory, 0xa, 0x2);
+ mch->ram_memory, MCH_HOST_BRIDGE_SMRAM_C_BASE,
+ MCH_HOST_BRIDGE_SMRAM_C_SIZE);
 memory_region_set_enabled(>low_smram, true);
-memory_region_add_subregion(>smram, 0xa, >low_smram);
+memory_region_add_subregion(>smram, MCH_HOST_BRIDGE_SMRAM_C_BASE,
+>low_smram);
 memory_region_init_alias(>high_smram, OBJECT(mch), "smram-high",
- mch->ram_memory, 0xa, 0x2);
+ mch->ram_memory, MCH_HOST_BRIDGE_SMRAM_C_BASE,
+ MCH_HOST_BRIDGE_SMRAM_C_SIZE);
 memory_region_set_enabled(>high_smram, true);
 memory_region_add_subregion(>smram, 0xfeda, >high_smram);
 
-- 
2.7.4




Re: [Qemu-devel] [PATCH] migration: update docs

2018-04-25 Thread Balamuruhan S
On Fri, Apr 20, 2018 at 06:57:21PM +0100, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert" 
> 
> Update the migration docs:
> 
> Among other changes:
>   * Added a general list of advice for device authors
>   * Reordered the section on conditional state (subsections etc)
> into the order we prefer.
>   * Add a note about firmware
> 
> Signed-off-by: Dr. David Alan Gilbert 
> ---
>  docs/devel/migration.rst | 524 +++
>  1 file changed, 370 insertions(+), 154 deletions(-)
> 
> diff --git a/docs/devel/migration.rst b/docs/devel/migration.rst
> index e32b087f6e..5e2b2a2760 100644
> --- a/docs/devel/migration.rst
> +++ b/docs/devel/migration.rst
> @@ -28,11 +28,11 @@ the guest to be stopped.  Typically the time that the 
> guest is
>  unresponsive during live migration is the low hundred of milliseconds
>  (notice that this depends on a lot of things).
> 
> -Types of migration
> -==
> +Transports
> +==
> 
> -Now that we have talked about live migration, there are several ways
> -to do migration:
> +The migration stream is normally just a byte stream that can be passed
> +over any transport.
> 
>  - tcp migration: do the migration using tcp sockets
>  - unix migration: do the migration using unix sockets
> @@ -40,16 +40,16 @@ to do migration:
>  - fd migration: do the migration using an file descriptor that is
>passed to QEMU.  QEMU doesn't care how this file descriptor is opened.
> 
> -All these four migration protocols use the same infrastructure to
> +In addition support is included for migration using RDMA migration which
> +transports the page data using ``RDMA``, where the hardware takes care of
> +transporting the pages, and the load on the CPU is much lower.  While the
> +internals of RDMA migration are a bit different, this isn't really visible
> +outside the RAM migration code.
> +
> +All these migration protocols use the same infrastructure to
>  save/restore state devices.  This infrastructure is shared with the
>  savevm/loadvm functionality.
> 
> -State Live Migration
> -
> -
> -This is used for RAM and block devices.  It is not yet ported to vmstate.
> -
> -
>  Common infrastructure
>  =
> 
> @@ -57,60 +57,72 @@ The files, sockets or fd's that carry the migration 
> stream are abstracted by
>  the  ``QEMUFile`` type (see `migration/qemu-file.h`).  In most cases this
>  is connected to a subtype of ``QIOChannel`` (see `io/`).
> 
> +
>  Saving the state of one device
>  ==
> 
> -The state of a device is saved using intermediate buffers.  There are
> -some helper functions to assist this saving.
> -
> -There is a new concept that we have to explain here: device state
> -version.  When we migrate a device, we save/load the state as a series
> -of fields.  Some times, due to bugs or new functionality, we need to
> -change the state to store more/different information.  We use the
> -version to identify each time that we do a change.  Each version is
> -associated with a series of fields saved.  The `save_state` always saves
> -the state as the newer version.  But `load_state` sometimes is able to
> -load state from an older version.
> -
> -Legacy way
> ---
> -
> -This way is going to disappear as soon as all current users are ported to 
> VMSTATE.
> -
> -Each device has to register two functions, one to save the state and
> -another to load the state back.
> -
> -.. code:: c
> -
> -  int register_savevm(DeviceState *dev,
> -  const char *idstr,
> -  int instance_id,
> -  int version_id,
> -  SaveStateHandler *save_state,
> -  LoadStateHandler *load_state,
> -  void *opaque);
> -
> -  typedef void SaveStateHandler(QEMUFile *f, void *opaque);
> -  typedef int LoadStateHandler(QEMUFile *f, void *opaque, int version_id);
> -
> -The important functions for the device state format are the `save_state`
> -and `load_state`.  Notice that `load_state` receives a version_id
> -parameter to know what state format is receiving.  `save_state` doesn't
> -have a version_id parameter because it always uses the latest version.
> +For most devices, the state is saved in a single call to the migration
> +infrastrucutre; these are *non-iterative* devices.  The data for these
> +devices is sent at the end of precopy migration, when the CPUs are paused.
> +Where the data associated with the device is very large (e.g. RAM or large 
> tables)
> +see the iterative device section below.
> +
> +General advice for device developers
> +
> +
> +- The migration state saved should reflect the device being modelled rather
> +  than the way your implementation works.   That way if you change the 
> implementation
> +  later the migration stream will stay compatible.  That model 

Re: [Qemu-devel] [Qemu-ppc] [PATCH for-2.13 03/10] target/ppc: Remove unnecessary initialization of LPCR_UPRT

2018-04-25 Thread Cédric Le Goater
On 04/17/2018 09:17 AM, David Gibson wrote:
> In cpu_ppc_set_papr() the UPRT and GTSE bits of the LPCR are initialized
> based on on ppc64_radix_guest().  Which seems reasonable, except that
> ppc64_radix_guest() is based on spapr->patb_entry which is only set up
> in spapr_machine_reset, called much later than cpu_ppc_set_papr().
> 
> So the initialization here is pointless.  The base cpu initialization
> already sets a value that's good enough until the guest uses an hcall to
> configure it's preferred MMU mode.
> 
> Signed-off-by: David Gibson 
> ---
>  target/ppc/translate_init.c | 16 
>  1 file changed, 16 deletions(-)
> 
> diff --git a/target/ppc/translate_init.c b/target/ppc/translate_init.c
> index bb79d23b50..14f346f441 100644
> --- a/target/ppc/translate_init.c
> +++ b/target/ppc/translate_init.c
> @@ -8897,22 +8897,6 @@ void cpu_ppc_set_papr(PowerPCCPU *cpu, 
> PPCVirtualHypervisor *vhyp)
>  lpcr->default_value &= ~LPCR_RMLS;
>  lpcr->default_value |= 1ull << LPCR_RMLS_SHIFT;
>  
> -if (env->mmu_model == POWERPC_MMU_3_00) {
> -/* By default we choose legacy mode and switch to new hash or radix
> - * when a register process table hcall is made. So disable process
> - * tables and guest translation shootdown by default
> - *
> - * Hot-plugged CPUs inherit from the guest radix setting under
> - * KVM but not under TCG. Update the default LPCR to keep new
> - * CPUs in sync when radix is enabled.
> - */


This is breaking CPU hotplug under TCG. Should we reintroduce the same 
settings in spapr_cpu_reset() now ?

Thanks,

C. 


> -if (ppc64_radix_guest(cpu)) {
> -lpcr->default_value |= LPCR_UPRT | LPCR_GTSE;
> -} else {
> -lpcr->default_value &= ~(LPCR_UPRT | LPCR_GTSE);
> -}
> -}
> -
>  /* Only enable Power-saving mode Exit Cause exceptions on the boot
>   * CPU. The RTAS command start-cpu will enable them on secondaries.
>   */
> 




Re: [Qemu-devel] [PATCH v1] hw/s390x: Allow to configure the consoles with the "-serial" parameter

2018-04-25 Thread David Hildenbrand
On 25.04.2018 07:21, Thomas Huth wrote:
> The consoles ("sclpconsole" and "sclplmconsole") can only be configured
> with "-device" and "-chardev" so far. Other machines use the convenience
> option "-serial" to configure the default consoles, even for virtual
> consoles like spapr-vty on the pseries machine. So let's support this
> option on s390x, too. This way we can easily enable the serial console
> here again with "-nodefaults", for example:
> 
> qemu-system-s390x -no-shutdown -nographic -nodefaults -serial mon:stdio
> 
> ... which is way shorter than typing:
> 
> qemu-system-s390x -no-shutdown -nographic -nodefaults \
>   -chardev stdio,id=c1,mux=on -device sclpconsole,chardev=c1 \
>   -mon chardev=c1
> 
> The -serial parameter can also be used if you only want to see the QEMU
> monitor on stdio without using -nodefaults, but not the console output.
> That's something that is pretty impossible with the current code today:
> 
> qemu-system-s390x -no-shutdown -nographic -serial none
> 
> While we're at it, this patch also maps the second -serial option to the
> "sclplmconsole", so that there is now an easy way to configure this second
> console on s390x, too, for example:
> 
> qemu-system-s390x -no-shutdown -nographic -serial null -serial mon:stdio
> 
> Additionally, the new code is also smaller than the old one and we have
> less s390x-specific code in vl.c :-)
> 
> I've also checked that migration still works as expected by migrating
> a guest with console output back and forth between a qemu-system-s390x
> that has this patch and an instance without this patch.
> 
> Signed-off-by: Thomas Huth 
> ---
>  RFC -> v1:
>  - Improved the patch description (provided examples)
>  - Moved the "init consoles" hunk in ccw_init to a later point in time
>so that the output of "info qom-tree" shows the same order of devices
>in the "/machine/unattached" tree.
> 
>  hw/s390x/event-facility.c | 14 +++
>  hw/s390x/s390-virtio-ccw.c| 19 +--
>  include/hw/boards.h   |  1 -
>  include/hw/s390x/event-facility.h |  2 ++
>  vl.c  | 50 
> ---
>  5 files changed, 33 insertions(+), 53 deletions(-)
> 
> diff --git a/hw/s390x/event-facility.c b/hw/s390x/event-facility.c
> index 9c24bc6..e6940a2 100644
> --- a/hw/s390x/event-facility.c
> +++ b/hw/s390x/event-facility.c
> @@ -511,3 +511,17 @@ static void register_types(void)
>  }
>  
>  type_init(register_types)
> +
> +BusState *sclp_get_event_facility_bus(void)
> +{
> +Object *busobj;
> +SCLPEventsBus *sbus;
> +
> +busobj = object_resolve_path_type("", TYPE_SCLP_EVENTS_BUS, NULL);
> +sbus = OBJECT_CHECK(SCLPEventsBus, busobj, TYPE_SCLP_EVENTS_BUS);
> +if (!sbus) {
> +return NULL;
> +}
> +
> +return >qbus;
> +}
> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
> index 435f7c9..62d909e 100644
> --- a/hw/s390x/s390-virtio-ccw.c
> +++ b/hw/s390x/s390-virtio-ccw.c
> @@ -288,6 +288,15 @@ static void s390_create_virtio_net(BusState *bus, const 
> char *name)
>  }
>  }
>  
> +static void s390_create_sclpconsole(const char *type, Chardev *chardev)
> +{
> +DeviceState *dev;
> +
> +dev = qdev_create(sclp_get_event_facility_bus(), type);
> +qdev_prop_set_chr(dev, "chardev", chardev);
> +qdev_init_nofail(dev);
> +}
> +
>  static void ccw_init(MachineState *machine)
>  {
>  int ret;
> @@ -346,6 +355,14 @@ static void ccw_init(MachineState *machine)
>  /* Create VirtIO network adapters */
>  s390_create_virtio_net(BUS(css_bus), "virtio-net-ccw");
>  
> +/* init consoles */
> +if (serial_hds[0]) {
> +s390_create_sclpconsole("sclpconsole", serial_hds[0]);
> +}
> +if (serial_hds[1]) {
> +s390_create_sclpconsole("sclplmconsole", serial_hds[1]);
> +}

What happens if more -serial are defined? An error? Silently ignored?

(e.g. do we have to redefine MAX_SERIAL_PORTS on s390x or add checking
code here?)

> +
>  /* Register savevm handler for guest TOD clock */
>  register_savevm_live(NULL, "todclock", 0, 1, _gtod, NULL);
>  }
> @@ -470,10 +487,8 @@ static void ccw_machine_class_init(ObjectClass *oc, void 
> *data)
>  mc->block_default_type = IF_VIRTIO;
>  mc->no_cdrom = 1;
>  mc->no_floppy = 1;
> -mc->no_serial = 1;
>  mc->no_parallel = 1;
>  mc->no_sdcard = 1;
> -mc->use_sclp = 1;
>  mc->max_cpus = S390_MAX_CPUS;
>  mc->has_hotpluggable_cpus = true;
>  mc->get_hotplug_handler = s390_get_hotplug_handler;
> diff --git a/include/hw/boards.h b/include/hw/boards.h
> index a609239..5c5eee5 100644
> --- a/include/hw/boards.h
> +++ b/include/hw/boards.h
> @@ -180,7 +180,6 @@ struct MachineClass {
>  unsigned int no_serial:1,
>  no_parallel:1,
>  use_virtcon:1,
> -use_sclp:1,
>  no_floppy:1,
>  no_cdrom:1,
>  no_sdcard:1,
> diff --git 

[Qemu-devel] [PATCH] spapr: fix entry point for secondary CPUs

2018-04-25 Thread Cédric Le Goater
Secondary CPUs do not start at SPAPR_ENTRY_POINT but at an address
given by the guest OS.

Fixes commit c79128c14c20 ("spapr: Make a helper to set up cpu entry
point state")

Signed-off-by: Cédric Le Goater 
---
 hw/ppc/spapr_cpu_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/ppc/spapr_cpu_core.c b/hw/ppc/spapr_cpu_core.c
index 326b35d6ed23..f3e9b879b251 100644
--- a/hw/ppc/spapr_cpu_core.c
+++ b/hw/ppc/spapr_cpu_core.c
@@ -76,7 +76,7 @@ void spapr_cpu_set_entry_state(PowerPCCPU *cpu, target_ulong 
nip, target_ulong r
 PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu);
 CPUPPCState *env = >env;
 
-env->nip = SPAPR_ENTRY_POINT;
+env->nip = nip;
 env->gpr[3] = r3;
 CPU(cpu)->halted = 0;
 /* Enable Power-saving mode Exit Cause exceptions */
-- 
2.13.6




Re: [Qemu-devel] [PATCH v2] checkpatch.pl: add common glib defines to typelist

2018-04-25 Thread Markus Armbruster
Peter Xu  writes:

> Otherwise it can warn this:
>
>   ERROR: space prohibited between function name and open parenthesis '('
>
> When with things like this:
>
>   typedef gboolean (*it_tree_iterator)(ITValue start, ITValue end);
>
> CC: Paolo Bonzini 
> CC: Stefan Hajnoczi 
> CC: "Daniel P. Berrangé" 
> CC: Markus Armbruster 
> CC: Vladimir Sementsov-Ogievskiy 
> CC: Fam Zheng 
> Signed-off-by: Peter Xu 
> ---
> v2:
> - add more missing glib types [Markus]
> ---
>  scripts/checkpatch.pl | 27 +++
>  1 file changed, 27 insertions(+)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index d52207a3cc..4954150e87 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -266,6 +266,33 @@ our @typeList = (
>   qr{target_(?:u)?long},
>   qr{hwaddr},
>   qr{xml${Ident}},
> + # Glib definitions
> + qr{gchar},
> + qr{gshort},
> + qr{glong},
> + qr{gint},
> + qr{gboolean},
> + qr{guchar},
> + qr{gushort},
> + qr{gulong},
> + qr{guint},
> + qr{gfloat},
> + qr{gdouble},
> + qr{gpointer},
> + qr{gconstpointer},
> + qr{gint8},
> + qr{guint8},
> + qr{gint16},
> + qr{guint16},
> + qr{gint32},
> + qr{guint32},
> + qr{gint64},
> + qr{guint64},
> + qr{gsize},
> + qr{gssize},
> + qr{goffset},
> + qr{gintptr},
> + qr{guintptr},
>  );
>  
>  # This can be modified by sub possible.  Since it can be empty, be careful

We could quibble about order, but since this is unlikely to need
maintenance, let's just take it and move on.

Reviewed-by: Markus Armbruster 



[Qemu-devel] [PATCH] hw/pci-host/q35: Replace hardcoded value with macro

2018-04-25 Thread Zihan Yang
Currently part of mch_realize uses hardcoded value when initializing
smram regions. Use macro to be more clear to code readers

Signed-off-by: Zihan Yang 
---
 hw/pci-host/q35.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c
index a36a119..49e4be4 100644
--- a/hw/pci-host/q35.c
+++ b/hw/pci-host/q35.c
@@ -535,13 +535,13 @@ static void mch_realize(PCIDevice *d, Error **errp)
 
 /* if *disabled* show SMRAM to all CPUs */
 memory_region_init_alias(>smram_region, OBJECT(mch), "smram-region",
- mch->pci_address_space, 0xa, 0x2);
-memory_region_add_subregion_overlap(mch->system_memory, 0xa,
+ mch->pci_address_space, 
MCH_HOST_BRIDGE_SMRAM_C_BASE, MCH_HOST_BRIDGE_SMRAM_C_SIZE);
+memory_region_add_subregion_overlap(mch->system_memory, 
MCH_HOST_BRIDGE_SMRAM_C_BASE,
 >smram_region, 1);
 memory_region_set_enabled(>smram_region, true);
 
 memory_region_init_alias(>open_high_smram, OBJECT(mch), 
"smram-open-high",
- mch->ram_memory, 0xa, 0x2);
+ mch->ram_memory, MCH_HOST_BRIDGE_SMRAM_C_BASE, 
MCH_HOST_BRIDGE_SMRAM_C_SIZE);
 memory_region_add_subregion_overlap(mch->system_memory, 0xfeda,
 >open_high_smram, 1);
 memory_region_set_enabled(>open_high_smram, false);
@@ -550,11 +550,11 @@ static void mch_realize(PCIDevice *d, Error **errp)
 memory_region_init(>smram, OBJECT(mch), "smram", 1ull << 32);
 memory_region_set_enabled(>smram, true);
 memory_region_init_alias(>low_smram, OBJECT(mch), "smram-low",
- mch->ram_memory, 0xa, 0x2);
+ mch->ram_memory, MCH_HOST_BRIDGE_SMRAM_C_BASE, 
0x2);
 memory_region_set_enabled(>low_smram, true);
-memory_region_add_subregion(>smram, 0xa, >low_smram);
+memory_region_add_subregion(>smram, MCH_HOST_BRIDGE_SMRAM_C_BASE, 
>low_smram);
 memory_region_init_alias(>high_smram, OBJECT(mch), "smram-high",
- mch->ram_memory, 0xa, 0x2);
+ mch->ram_memory, MCH_HOST_BRIDGE_SMRAM_C_BASE, 
MCH_HOST_BRIDGE_SMRAM_C_SIZE);
 memory_region_set_enabled(>high_smram, true);
 memory_region_add_subregion(>smram, 0xfeda, >high_smram);
 
-- 
2.7.4




Re: [Qemu-devel] [PATCH 0/9] target/arm: Fixups for ARM_FEATURE_V8_FP16

2018-04-25 Thread Alex Bennée

Richard Henderson  writes:

> When running the gcc testsuite with current aarch64-linux-user,
> the testsuite detects the presence of the fp16 extension and
> enables lots of extra tests for builtins.
>
> Quite a few of these new tests fail because we missed implementing
> some instructions.  We really should go back and verify that nothing
> else is missing from this (rather large) extension.

Ouch. I thought I'd got them all from parsing the ASL. Obviously not.

> In addition, it tests some edge conditions on data that show flaws
> in the way we were performing integer<->fp conversion; particularly
> with respect to scaled conversion.
>
>
> r~
>
> PS: FWIW, this was written against my tgt-arm-sve-9 tree, since I
> was trying to test sve as generated by gcc.  I don't *think* there
> are any dependencies on any of the sve patches, but I didn't check.
>
> PPS: There are two more failures that might be qemu fp16 failures,
> but those are SIGSEGV.  This patch set cures all of the SIGILL and
> (subsequent) SIGABRT type failures within the testsuite.
>
>
> Richard Henderson (9):
>   target/arm: Implement vector shifted SCVF/UCVF for fp16
>   target/arm: Implement vector shifted FCVT for fp16
>   target/arm: Fix float16 to/from int16
>   target/arm: Clear SVE high bits for FMOV
>   target/arm: Implement FMOV (general) for fp16
>   target/arm: Implement FCVT (scalar,integer) for fp16
>   target/arm: Implement FCVT (scalar,fixed-point) for fp16
>   target/arm: Implement FP data-processing (2 source) for fp16
>   target/arm: Implement FP data-processing (3 source) for fp16
>
>  target/arm/helper.h|   6 +
>  target/arm/helper.c|  87 ++-
>  target/arm/translate-a64.c | 371 
> +
>  3 files changed, 399 insertions(+), 65 deletions(-)


--
Alex Bennée



Re: [Qemu-devel] [PATCH v3 36/46] tests/tcg/alpha: add Alpha specific tests

2018-04-25 Thread Alex Bennée

Richard Henderson  writes:

> On 04/24/2018 05:23 AM, Alex Bennée wrote:
>> These tests are a little strange as they use their own crt.o stub
>> instead of the system supplied one. We also disable the multiarch
>> testthread test as that requires a dynamically linked build.
>>
>> Signed-off-by: Alex Bennée 
>> ---
>>  tests/tcg/alpha/Makefile | 35 
>>  tests/tcg/alpha/Makefile.target  | 32 +
>>  tests/tcg/alpha/{crt.s => crt.S} |  0
>>  3 files changed, 32 insertions(+), 35 deletions(-)
>>  delete mode 100644 tests/tcg/alpha/Makefile
>>  create mode 100644 tests/tcg/alpha/Makefile.target
>>  rename tests/tcg/alpha/{crt.s => crt.S} (100%)
>
> Now that you have a cross-environment, you could simply drop the crt.o.
>
> There's nothing special in there at all; it was just someone's attempt to
> produce tests *without* a fill cross-environment.

Fair enough, I'll fix it up to be more normal.

--
Alex Bennée



Re: [Qemu-devel] [PATCH v3 03/46] configure: add support for --cross-cc-FOO

2018-04-25 Thread Alex Bennée

Richard Henderson  writes:

> On 04/24/2018 05:23 AM, Alex Bennée wrote:
>> @@ -675,10 +687,12 @@ case "$cpu" in
>>i386|i486|i586|i686|i86pc|BePC)
>>  cpu="i386"
>>  supported_cpu="yes"
>> +cross_cc_i386=gcc
>>;;
>>x86_64|amd64)
>>  cpu="x86_64"
>>  supported_cpu="yes"
>> +cross_cc_x86_64=gcc
>>;;
>>armv*b|armv*l|arm)
>>  cpu="arm"
>
> Isn't this hunk taken care of in the next patch, where you set these to $cc?
> And if not, surely bare "gcc" isn't correct...

Woops, I'll fix that.

>
> Otherwise,
> Reviewed-by: Richard Henderson 
>
>
> r~


--
Alex Bennée



[Qemu-devel] [PATCH v3 3/3] pc-bios/s390-ccw/net: Add support for .INS config files

2018-04-25 Thread Thomas Huth
The .INS config files can normally be found on CD-ROM ISO images,
so by supporting these files, it is now possible to boot directly
when the TFTP server is set up with the contents of such an CD-ROM
image.

Signed-off-by: Thomas Huth 
---
 pc-bios/s390-ccw/netmain.c | 100 ++---
 1 file changed, 95 insertions(+), 5 deletions(-)

diff --git a/pc-bios/s390-ccw/netmain.c b/pc-bios/s390-ccw/netmain.c
index 5f28ea0..c10b0ac 100644
--- a/pc-bios/s390-ccw/netmain.c
+++ b/pc-bios/s390-ccw/netmain.c
@@ -39,8 +39,12 @@
 
 extern char _start[];
 
+#define KERNEL_ADDR ((void *)0L)
+#define KERNEL_MAX_SIZE ((long)_start)
+
 char stack[PAGE_SIZE * 8] __attribute__((aligned(PAGE_SIZE)));
 IplParameterBlock iplb __attribute__((aligned(PAGE_SIZE)));
+static char cfgbuf[2048];
 
 static SubChannelId net_schid = { .one = 1 };
 static int ip_version = 4;
@@ -136,9 +140,15 @@ static int tftp_load(filename_ip_t *fnip, void *buffer, 
int len)
 rc = tftp(fnip, buffer, len, DEFAULT_TFTP_RETRIES, _err, 1, 1428,
   ip_version);
 
-if (rc > 0) {
-printf("  TFTP: Received %s (%d KBytes)\n", fnip->filename,
-   rc / 1024);
+if (rc < 0) {
+/* Make sure that error messages are put into a new line */
+printf("\n  ");
+}
+
+if (rc > 1024) {
+printf("  TFTP: Received %s (%d KBytes)\n", fnip->filename, rc / 1024);
+} else if (rc > 0) {
+printf("  TFTP: Received %s (%d Bytes)\n", fnip->filename, rc);
 } else if (rc == -1) {
 puts("unknown TFTP error");
 } else if (rc == -2) {
@@ -275,6 +285,83 @@ static void net_release(filename_ip_t *fn_ip)
 }
 }
 
+/**
+ * Load via information from a .INS file (which can be found on CD-ROMs
+ * for example)
+ */
+static int handle_ins_cfg(filename_ip_t *fn_ip, char *cfg, int cfgsize)
+{
+char *ptr;
+int rc = -1, llen;
+void *destaddr;
+char *insbuf = cfg;
+
+ptr = strchr(insbuf, '\n');
+if (!ptr) {
+puts("Does not seem to be a valid .INS file");
+return -1;
+}
+
+*ptr = 0;
+printf("\nParsing .INS file:\n %s\n", [2]);
+
+insbuf = ptr + 1;
+while (*insbuf && insbuf < cfg + cfgsize) {
+ptr = strchr(insbuf, '\n');
+if (ptr) {
+*ptr = 0;
+}
+llen = strlen(insbuf);
+if (!llen) {
+insbuf = ptr + 1;
+continue;
+}
+ptr = strchr(insbuf, ' ');
+if (!ptr) {
+puts("Missing space separator in .INS file");
+return -1;
+}
+*ptr = 0;
+strncpy((char *)fn_ip->filename, insbuf, sizeof(fn_ip->filename));
+destaddr = (char *)atol(ptr + 1);
+rc = tftp_load(fn_ip, destaddr, (long)_start - (long)destaddr);
+if (rc <= 0) {
+break;
+}
+insbuf += llen + 1;
+}
+
+return rc;
+}
+
+static int net_try_bootfile_load(filename_ip_t *fn_ip)
+{
+int rc;
+void *loadaddr = (void *)0x2000;  /* Load right after the low-core */
+
+rc = tftp_load(fn_ip, loadaddr, KERNEL_MAX_SIZE - (long)loadaddr);
+if (rc < 0) {
+return rc;
+} else if (rc < 8) {
+printf("'%s' is too small (%i bytes only).\n", fn_ip->filename, rc);
+return -1;
+}
+
+/* Check whether it is a configuration file instead of a kernel */
+if (rc < sizeof(cfgbuf) - 1) {
+memcpy(cfgbuf, loadaddr, rc);
+cfgbuf[rc] = 0;/* Make sure that it is NUL-terminated */
+if (!strncmp("* ", cfgbuf, 2)) {
+return handle_ins_cfg(fn_ip, cfgbuf, rc);
+}
+}
+
+/* Move kernel to right location */
+memmove(KERNEL_ADDR, loadaddr, rc);
+
+return rc;
+}
+
 void panic(const char *string)
 {
 sclp_print(string);
@@ -356,7 +443,7 @@ static void virtio_setup(void)
 void main(void)
 {
 filename_ip_t fn_ip;
-int rc;
+int rc, fnlen;
 
 sclp_setup();
 sclp_print("Network boot starting...\n");
@@ -368,7 +455,10 @@ void main(void)
 panic("Network initialization failed. Halting.\n");
 }
 
-rc = tftp_load(_ip, NULL, (long)_start);
+fnlen = strlen((char *)fn_ip.filename);
+if (fnlen > 0 && fn_ip.filename[fnlen - 1] != '/') {
+rc = net_try_bootfile_load(_ip);
+}
 
 net_release(_ip);
 
-- 
1.8.3.1




[Qemu-devel] [PATCH v3 1/3] pc-bios/s390-ccw/net: Split up net_load() into init, load and uninit parts

2018-04-25 Thread Thomas Huth
When we want to support pxelinux-style network booting later, we've got
to do several TFTP transfers - and we do not want to apply for a new IP
address via DHCP each time. So split up net_load into three parts:

1. net_init(), which initializes virtio-net, gets an IP address via DHCP
   and prints out the related information.

2. The tftp_load call is now moved directly into the main() function

3. A new net_release() function which should tear down the network stack
   before we are done in the firmware.

This will make it easier to extend the code in the next patches.

Signed-off-by: Thomas Huth 
---
 pc-bios/s390-ccw/netmain.c | 63 +++---
 1 file changed, 37 insertions(+), 26 deletions(-)

diff --git a/pc-bios/s390-ccw/netmain.c b/pc-bios/s390-ccw/netmain.c
index d86d46b..8fa9e6c 100644
--- a/pc-bios/s390-ccw/netmain.c
+++ b/pc-bios/s390-ccw/netmain.c
@@ -128,13 +128,13 @@ static void seed_rng(uint8_t mac[])
 srand(seed);
 }
 
-static int tftp_load(filename_ip_t *fnip, void *buffer, int len,
- unsigned int retries, int ip_vers)
+static int tftp_load(filename_ip_t *fnip, void *buffer, int len)
 {
 tftp_err_t tftp_err;
 int rc;
 
-rc = tftp(fnip, buffer, len, retries, _err, 1, 1428, ip_vers);
+rc = tftp(fnip, buffer, len, DEFAULT_TFTP_RETRIES, _err, 1, 1428,
+  ip_version);
 
 if (rc > 0) {
 printf("  TFTP: Received %s (%d KBytes)\n", fnip->filename,
@@ -199,20 +199,19 @@ static int tftp_load(filename_ip_t *fnip, void *buffer, 
int len,
 return rc;
 }
 
-static int net_load(char *buffer, int len)
+static int net_init(filename_ip_t *fn_ip)
 {
-filename_ip_t fn_ip;
 uint8_t mac[6];
 int rc;
 
-memset(_ip, 0, sizeof(filename_ip_t));
+memset(fn_ip, 0, sizeof(filename_ip_t));
 
 rc = virtio_net_init(mac);
 if (rc < 0) {
 puts("Could not initialize network device");
 return -101;
 }
-fn_ip.fd = rc;
+fn_ip->fd = rc;
 
 printf("  Using MAC address: %02x:%02x:%02x:%02x:%02x:%02x\n",
mac[0], mac[1], mac[2], mac[3], mac[4], mac[5]);
@@ -220,10 +219,10 @@ static int net_load(char *buffer, int len)
 set_mac_address(mac);/* init ethernet layer */
 seed_rng(mac);
 
-rc = dhcp(_ip, DEFAULT_BOOT_RETRIES);
+rc = dhcp(fn_ip, DEFAULT_BOOT_RETRIES);
 if (rc >= 0) {
 if (ip_version == 4) {
-set_ipv4_address(fn_ip.own_ip);
+set_ipv4_address(fn_ip->own_ip);
 }
 } else {
 puts("Could not get IP address");
@@ -232,18 +231,18 @@ static int net_load(char *buffer, int len)
 
 if (ip_version == 4) {
 printf("  Using IPv4 address: %d.%d.%d.%d\n",
-  (fn_ip.own_ip >> 24) & 0xFF, (fn_ip.own_ip >> 16) & 0xFF,
-  (fn_ip.own_ip >>  8) & 0xFF, fn_ip.own_ip & 0xFF);
+  (fn_ip->own_ip >> 24) & 0xFF, (fn_ip->own_ip >> 16) & 0xFF,
+  (fn_ip->own_ip >>  8) & 0xFF, fn_ip->own_ip & 0xFF);
 } else if (ip_version == 6) {
 char ip6_str[40];
-ipv6_to_str(fn_ip.own_ip6.addr, ip6_str);
+ipv6_to_str(fn_ip->own_ip6.addr, ip6_str);
 printf("  Using IPv6 address: %s\n", ip6_str);
 }
 
 if (rc == -2) {
 printf("ARP request to TFTP server (%d.%d.%d.%d) failed\n",
-   (fn_ip.server_ip >> 24) & 0xFF, (fn_ip.server_ip >> 16) & 0xFF,
-   (fn_ip.server_ip >>  8) & 0xFF, fn_ip.server_ip & 0xFF);
+   (fn_ip->server_ip >> 24) & 0xFF, (fn_ip->server_ip >> 16) & 
0xFF,
+   (fn_ip->server_ip >>  8) & 0xFF, fn_ip->server_ip & 0xFF);
 return -102;
 }
 if (rc == -4 || rc == -3) {
@@ -251,28 +250,31 @@ static int net_load(char *buffer, int len)
 return -107;
 }
 
+printf("  Using TFTP server: ");
 if (ip_version == 4) {
-printf("  Requesting file \"%s\" via TFTP from %d.%d.%d.%d\n",
-   fn_ip.filename,
-   (fn_ip.server_ip >> 24) & 0xFF, (fn_ip.server_ip >> 16) & 0xFF,
-   (fn_ip.server_ip >>  8) & 0xFF, fn_ip.server_ip & 0xFF);
+printf("%d.%d.%d.%d\n",
+   (fn_ip->server_ip >> 24) & 0xFF, (fn_ip->server_ip >> 16) & 
0xFF,
+   (fn_ip->server_ip >>  8) & 0xFF, fn_ip->server_ip & 0xFF);
 } else if (ip_version == 6) {
 char ip6_str[40];
-printf("  Requesting file \"%s\" via TFTP from ", fn_ip.filename);
-ipv6_to_str(fn_ip.server_ip6.addr, ip6_str);
+ipv6_to_str(fn_ip->server_ip6.addr, ip6_str);
 printf("%s\n", ip6_str);
 }
 
-/* Do the TFTP load and print error message if necessary */
-rc = tftp_load(_ip, buffer, len, DEFAULT_TFTP_RETRIES, ip_version);
-
-if (ip_version == 4) {
-dhcp_send_release(fn_ip.fd);
+if (strlen((char *)fn_ip->filename) > 0) {
+printf("  Bootfile name: '%s'\n", fn_ip->filename);
 }
 
 return rc;
 }
 
+static void 

Re: [Qemu-devel] [PATCH v3 16/46] tests/tcg: move i386 specific tests into subdir

2018-04-25 Thread Alex Bennée

Philippe Mathieu-Daudé  writes:

> On 04/24/2018 12:23 PM, Alex Bennée wrote:
>> These only need to be built for i386 guests. This includes a stub
>> tests/tcg/i386/Makfile.target which absorbs some of what was in
>> tests/tcg/Makefile.
>>
>> Signed-off-by: Alex Bennée 
>> Reviewed-by: Thomas Huth 
>> Reviewed-by: Philippe Mathieu-Daudé 
>> Tested-by: Philippe Mathieu-Daudé 
>> ---
>> v2
>>   - move VPATH and TESTs setup into i386/Makefile.target
>>   - set CFLAGS+=-m32 for cross building
>> ---
>>  tests/tcg/README|  39 
>>  tests/tcg/i386/Makefile.target  |  30 ++
>>  tests/tcg/i386/README   |  38 +++
>>  tests/tcg/{ => i386}/hello-i386.c   |   0
>>  tests/tcg/{ => i386}/pi_10.com  | Bin
>>  tests/tcg/{ => i386}/runcom.c   |   0
>>  tests/tcg/{ => i386}/test-i386-code16.S |   0
>>  tests/tcg/{ => i386}/test-i386-fprem.c  |   0
>>  tests/tcg/{ => i386}/test-i386-muldiv.h |   0
>>  tests/tcg/{ => i386}/test-i386-shift.h  |   0
>>  tests/tcg/{ => i386}/test-i386-ssse3.c  |   0
>>  tests/tcg/{ => i386}/test-i386-vm86.S   |   0
>>  tests/tcg/{ => i386}/test-i386.c|   0
>>  tests/tcg/{ => i386}/test-i386.h|   0
>>  14 files changed, 68 insertions(+), 39 deletions(-)
>>  create mode 100644 tests/tcg/i386/Makefile.target
>>  create mode 100644 tests/tcg/i386/README
>>  rename tests/tcg/{ => i386}/hello-i386.c (100%)
>>  rename tests/tcg/{ => i386}/pi_10.com (100%)
>>  rename tests/tcg/{ => i386}/runcom.c (100%)
>>  rename tests/tcg/{ => i386}/test-i386-code16.S (100%)
>>  rename tests/tcg/{ => i386}/test-i386-fprem.c (100%)
>>  rename tests/tcg/{ => i386}/test-i386-muldiv.h (100%)
>>  rename tests/tcg/{ => i386}/test-i386-shift.h (100%)
>>  rename tests/tcg/{ => i386}/test-i386-ssse3.c (100%)
>>  rename tests/tcg/{ => i386}/test-i386-vm86.S (100%)
>>  rename tests/tcg/{ => i386}/test-i386.c (100%)
>>  rename tests/tcg/{ => i386}/test-i386.h (100%)
>>
>> diff --git a/tests/tcg/README b/tests/tcg/README
>> index 0890044cf0..469504c4cb 100644
>> --- a/tests/tcg/README
>> +++ b/tests/tcg/README
>> @@ -3,45 +3,6 @@ regression testing. Tests are either multi-arch, meaning 
>> they can be
>>  built for all guest architectures that support linux-user executable,
>>  or they are architecture specific.
>>
>> -i386
>> -
>> -
>> -test-i386
>> --
>> -
>> -This program executes most of the 16 bit and 32 bit x86 instructions and
>> -generates a text output, for comparison with the output obtained with
>> -a real CPU or another emulator.
>> -
>> -The Linux system call modify_ldt() is used to create x86 selectors
>> -to test some 16 bit addressing and 32 bit with segmentation cases.
>> -
>> -The Linux system call vm86() is used to test vm86 emulation.
>> -
>> -Various exceptions are raised to test most of the x86 user space
>> -exception reporting.
>> -
>> -linux-test
>> ---
>> -
>> -This program tests various Linux system calls. It is used to verify
>> -that the system call parameters are correctly converted between target
>> -and host CPUs.
>> -
>> -test-i386-fprem
>> 
>> -
>> -runcom
>> ---
>> -
>> -test-mmap
>> --
>> -
>> -sha1
>> -
>> -
>> -hello-i386
>> ---
>>
>>
>>  ARM
>> diff --git a/tests/tcg/i386/Makefile.target b/tests/tcg/i386/Makefile.target
>> new file mode 100644
>> index 00..2f27b65e2d
>> --- /dev/null
>> +++ b/tests/tcg/i386/Makefile.target
>> @@ -0,0 +1,30 @@
>> +# i386 cross compile notes
>> +
>> +I386_SRC=$(SRC_PATH)/tests/tcg/i386
>> +
>> +# Set search path for all sources
>> +VPATH   += $(I386_SRC)
>> +
>> +I386_SRCS=$(notdir $(wildcard $(I386_SRC)/*.c))
>> +I386_TESTS=$(I386_SRCS:.c=)
>> +
>> +# Update TESTS
>> +TESTS+=$(I386_TESTS)
>> +
>> +ifneq ($(TARGET_NAME),x86_64)
>> +CFLAGS+=-m32
>> +endif
>> +
>> +#
>> +# hello-i386 is a barebones app
>> +#
>> +hello-i386: CFLAGS+=-ffreestanding
>> +hello-i386: LDFLAGS+=-nostdlib
>> +
>> +#
>> +# test-386 includes a couple of additional objects that need to be linked 
>> together
>> +#
>> +
>> +test-i386: test-i386.c test-i386-code16.S test-i386-vm86.S test-i386.h 
>> test-i386-shift.h test-i386-muldiv.h
>> +$(CC) $(CFLAGS) $(LDFLAGS) -o $@ \
>> +   $(> diff --git a/tests/tcg/i386/README b/tests/tcg/i386/README
>> new file mode 100644
>> index 00..7a0a47bf27
>> --- /dev/null
>> +++ b/tests/tcg/i386/README
>> @@ -0,0 +1,38 @@
>> +These are i386 specific guest programs
>> +
>> +test-i386
>> +-
>> +
>> +This program executes most of the 16 bit and 32 bit x86 instructions and
>> +generates a text output, for comparison with the output obtained with
>> +a real CPU or another emulator.
>> +
>> +The Linux system call modify_ldt() is used to create x86 selectors
>> 

[Qemu-devel] [PATCH v3 2/3] pc-bios/s390-ccw/net: Use diag308 to reset machine before jumping to the OS

2018-04-25 Thread Thomas Huth
The netboot firmware so far simply jumped directly into the OS kernel
after the download has been completed. This, however, bears the risk
that the virtio-net device still might be active in the background and
incoming packets are still placed into the buffers - which could destroy
memory of the now-running Linux kernel in case it did not take over the
device fast enough. Also the SCLP console is not put into a well-defined
state here. We should hand over the system in a clean state when jumping
into the kernel, so let's use the same mechanism as it's done in the
main s390-ccw firmware and reset the machine with diag308 into a clean
state before jumping into the OS kernel code. To be able to share the
code with the main s390-ccw firmware, the related functions are now
extracted from bootmap.c into a new file called jump2ipl.c.

Signed-off-by: Thomas Huth 
---
 pc-bios/s390-ccw/Makefile|  4 ++-
 pc-bios/s390-ccw/bootmap.c   | 63 +-
 pc-bios/s390-ccw/bootmap.h   |  4 ---
 pc-bios/s390-ccw/jump2ipl.c  | 81 
 pc-bios/s390-ccw/netboot.mak |  3 +-
 pc-bios/s390-ccw/netmain.c   | 11 +-
 pc-bios/s390-ccw/s390-ccw.h  |  4 +++
 7 files changed, 101 insertions(+), 69 deletions(-)
 create mode 100644 pc-bios/s390-ccw/jump2ipl.c

diff --git a/pc-bios/s390-ccw/Makefile b/pc-bios/s390-ccw/Makefile
index 1712c2d..439e3cc 100644
--- a/pc-bios/s390-ccw/Makefile
+++ b/pc-bios/s390-ccw/Makefile
@@ -9,7 +9,9 @@ $(call set-vpath, $(SRC_PATH)/pc-bios/s390-ccw)
 
 .PHONY : all clean build-all
 
-OBJECTS = start.o main.o bootmap.o sclp.o virtio.o virtio-scsi.o 
virtio-blkdev.o libc.o menu.o
+OBJECTS = start.o main.o bootmap.o jump2ipl.o sclp.o menu.o \
+ virtio.o virtio-scsi.o virtio-blkdev.o libc.o
+
 QEMU_CFLAGS := $(filter -W%, $(QEMU_CFLAGS))
 QEMU_CFLAGS += -ffreestanding -fno-delete-null-pointer-checks -msoft-float
 QEMU_CFLAGS += -march=z900 -fPIE -fno-strict-aliasing
diff --git a/pc-bios/s390-ccw/bootmap.c b/pc-bios/s390-ccw/bootmap.c
index 9287b7a..7e63e6b 100644
--- a/pc-bios/s390-ccw/bootmap.c
+++ b/pc-bios/s390-ccw/bootmap.c
@@ -29,14 +29,6 @@
 /* Scratch space */
 static uint8_t sec[MAX_SECTOR_SIZE*4] __attribute__((__aligned__(PAGE_SIZE)));
 
-typedef struct ResetInfo {
-uint32_t ipl_mask;
-uint32_t ipl_addr;
-uint32_t ipl_continue;
-} ResetInfo;
-
-static ResetInfo save;
-
 const uint8_t el_torito_magic[] = "EL TORITO SPECIFICATION"
   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0";
 
@@ -57,53 +49,6 @@ static inline bool is_iso_vd_valid(IsoVolDesc *vd)
vd->type <= VOL_DESC_TYPE_PARTITION;
 }
 
-static void jump_to_IPL_2(void)
-{
-ResetInfo *current = 0;
-
-void (*ipl)(void) = (void *) (uint64_t) current->ipl_continue;
-*current = save;
-ipl(); /* should not return */
-}
-
-static void jump_to_IPL_code(uint64_t address)
-{
-/* store the subsystem information _after_ the bootmap was loaded */
-write_subsystem_identification();
-
-/* prevent unknown IPL types in the guest */
-if (iplb.pbt == S390_IPL_TYPE_QEMU_SCSI) {
-iplb.pbt = S390_IPL_TYPE_CCW;
-set_iplb();
-}
-
-/*
- * The IPL PSW is at address 0. We also must not overwrite the
- * content of non-BIOS memory after we loaded the guest, so we
- * save the original content and restore it in jump_to_IPL_2.
- */
-ResetInfo *current = 0;
-
-save = *current;
-current->ipl_addr = (uint32_t) (uint64_t) _to_IPL_2;
-current->ipl_continue = address & 0x7fff;
-
-debug_print_int("set IPL addr to", current->ipl_continue);
-
-/* Ensure the guest output starts fresh */
-sclp_print("\n");
-
-/*
- * HACK ALERT.
- * We use the load normal reset to keep r15 unchanged. jump_to_IPL_2
- * can then use r15 as its stack pointer.
- */
-asm volatile("lghi 1,1\n\t"
- "diag 1,1,0x308\n\t"
- : : : "1", "memory");
-panic("\n! IPL returns !\n");
-}
-
 /***
  * IPL an ECKD DASD (CDL or LDL/CMS format)
  */
@@ -727,13 +672,7 @@ static void load_iso_bc_entry(IsoBcSection *load)
 (void *)((uint64_t)bswap16(s.load_segment)),
 blks_to_load);
 
-/* Trying to get PSW at zero address */
-if (*((uint64_t *)0) & IPL_PSW_MASK) {
-jump_to_IPL_code((*((uint64_t *)0)) & 0x7fff);
-}
-
-/* Try default linux start address */
-jump_to_IPL_code(KERN_IMAGE_START);
+jump_to_low_kernel();
 }
 
 static uint32_t find_iso_bc(void)
diff --git a/pc-bios/s390-ccw/bootmap.h b/pc-bios/s390-ccw/bootmap.h
index 07eb600..bef81ff 100644
--- a/pc-bios/s390-ccw/bootmap.h
+++ b/pc-bios/s390-ccw/bootmap.h
@@ -355,10 +355,6 @@ static inline uint32_t iso_733_to_u32(uint64_t x)
 #define ISO_SECTOR_SIZE 2048
 /* El Torito specifies boot image size in 512 byte blocks */
 #define 

[Qemu-devel] [PATCH v3 0/3] pc-bios/s390-ccw: Some few network boot improvements

2018-04-25 Thread Thomas Huth
Note: I've decided to removed the pxelinux.cfg patches from this series
for now, since full pxelinux support requires to parse some additional
DHCP options (see https://tools.ietf.org/html/rfc5071), and for this, the
SLOF libnet code needs to be changed first. So I guess I first have to
implement pxelinux.cfg support for PPC, too, which will likely take a
little bit longer...
Thus to keep this series short and reviewable, and to avoid that the other
patches bit-rot on my hard disk, I've now only included the patches that
are not related to pxelinux.cfg.

The first patch is just a minor code refactoring which should not have
any visible impact, but makes the following patches easier.

The second patch makes sure that we leave the machine in a sane state
before jumping into the Linux kernel - i.e. the netboot firmware now
resets the machine with diag308, too, just like the main s390-ccw
is doing it already.

Patch 3 adds support for loading kernels via .INS configuration files.
You can find these .INS config files on ISO images, so with this patch,
it should be possible to boot if the TFTP server is configured to use
the contents of such an ISO image.

Thomas Huth (3):
  pc-bios/s390-ccw/net: Split up net_load() into init, load and uninit
parts
  pc-bios/s390-ccw/net: Use diag308 to reset machine before jumping to
the OS
  pc-bios/s390-ccw/net: Add support for .INS config files

 pc-bios/s390-ccw/Makefile|   4 +-
 pc-bios/s390-ccw/bootmap.c   |  63 +---
 pc-bios/s390-ccw/bootmap.h   |   4 --
 pc-bios/s390-ccw/jump2ipl.c  |  81 +
 pc-bios/s390-ccw/netboot.mak |   3 +-
 pc-bios/s390-ccw/netmain.c   | 168 +++
 pc-bios/s390-ccw/s390-ccw.h  |   4 ++
 7 files changed, 230 insertions(+), 97 deletions(-)
 create mode 100644 pc-bios/s390-ccw/jump2ipl.c

-- 
1.8.3.1




Re: [Qemu-devel] [PATCH v3 21/46] tests/tcg/i386: fix test-i386-fprem

2018-04-25 Thread Alex Bennée

Thomas Huth  writes:

> On 24.04.2018 17:23, Alex Bennée wrote:
>> Remove dependencies on QEMU's source tree and build directly.
>>
>> Signed-off-by: Alex Bennée 
>> ---
>>  tests/tcg/i386/test-i386-fprem.c | 12 +---
>>  1 file changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/tests/tcg/i386/test-i386-fprem.c 
>> b/tests/tcg/i386/test-i386-fprem.c
>> index 1a71623204..66f5a9657d 100644
>> --- a/tests/tcg/i386/test-i386-fprem.c
>> +++ b/tests/tcg/i386/test-i386-fprem.c
>> @@ -23,7 +23,10 @@
>>   *  along with this program; if not, see .
>>   */
>>
>> -#include "qemu/osdep.h"
>> +#include 
>> +#include 
>> +
>> +#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
>>
>>  /*
>>   * Inspired by 's union ieee854_long_double, but with single
>> @@ -39,7 +42,7 @@ union float80u {
>>  unsigned int exponent:15;
>>  unsigned int negative:1;
>>  unsigned int empty:16;
>> -} QEMU_PACKED ieee;
>> +} __attribute__((packed)) ieee;
>>
>>  /* This is for NaNs in the IEEE 854 double-extended-precision format.  
>> */
>>  struct {
>> @@ -49,7 +52,7 @@ union float80u {
>>  unsigned int exponent:15;
>>  unsigned int negative:1;
>>  unsigned int empty:16;
>> -} QEMU_PACKED ieee_nan;
>> +} __attribute__((packed)) ieee_nan;
>>  };
>>
>>  #define IEEE854_LONG_DOUBLE_BIAS 0x3fff
>> @@ -229,6 +232,7 @@ static void test_fprem_cases(void)
>>  do_fprem_stack_underflow();
>>
>>  printf("= invalid operation =\n");
>> +do_fprem(q_nan.d, 1.0);
>>  do_fprem(s_nan.d, 1.0);
>>  do_fprem(1.0, 0.0);
>>  do_fprem(pos_inf.d, 1.0);
>> @@ -238,6 +242,8 @@ static void test_fprem_cases(void)
>>  do_fprem(pos_denorm.d, 1.0);
>>  do_fprem(1.0, pos_denorm.d);
>>
>> +do_fprem(smallest_positive_norm.d, smallest_positive_norm.d);
>
> How's that change related to the patch description? ... i.e. maybe you
> should mention these changes in the patch description, too?

Yeah I'll fix that up - they got added to stop the compiler bithing
about un-used things.

>
> Apart from that:
>
> Reviewed-by: Thomas Huth 


--
Alex Bennée



Re: [Qemu-devel] [PATCH v3 28/46] tests/tcg/aarch64: add Makefile.target

2018-04-25 Thread Alex Bennée

Philippe Mathieu-Daudé  writes:

> On 04/24/2018 12:23 PM, Alex Bennée wrote:
>> Nothing much here yet.
>>
>> Signed-off-by: Alex Bennée 
>> ---
>>  tests/tcg/aarch64/Makefile.target | 5 +
>>  1 file changed, 5 insertions(+)
>>  create mode 100644 tests/tcg/aarch64/Makefile.target
>>
>> diff --git a/tests/tcg/aarch64/Makefile.target 
>> b/tests/tcg/aarch64/Makefile.target
>> new file mode 100644
>> index 00..4ac8fbe73f
>> --- /dev/null
>> +++ b/tests/tcg/aarch64/Makefile.target
>> @@ -0,0 +1,5 @@
>> +# -*- Mode: makefile -*-
>> +#
>> +# AArch64 specific tweaks
>> +
>> +fcvt: LDFLAGS+=-lm
>>
>
> You missed tests/tcg/aarch64/Makefile.include with:
>
> DOCKER_IMAGE=debian-arm64-cross
> DOCKER_CROSS_COMPILER=aarch64-linux-gnueabi-gcc

Doh.. of course I was testing with my cross-compiler and forgot about
this ;-)



--
Alex Bennée



Re: [Qemu-devel] [PATCH v3 21/46] tests/tcg/i386: fix test-i386-fprem

2018-04-25 Thread Alex Bennée

Philippe Mathieu-Daudé  writes:

> On 04/24/2018 12:23 PM, Alex Bennée wrote:
>> Remove dependencies on QEMU's source tree and build directly.
>>
>> Signed-off-by: Alex Bennée 
>> ---
>>  tests/tcg/i386/test-i386-fprem.c | 12 +---
>>  1 file changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/tests/tcg/i386/test-i386-fprem.c 
>> b/tests/tcg/i386/test-i386-fprem.c
>> index 1a71623204..66f5a9657d 100644
>> --- a/tests/tcg/i386/test-i386-fprem.c
>> +++ b/tests/tcg/i386/test-i386-fprem.c
>> @@ -23,7 +23,10 @@
>>   *  along with this program; if not, see .
>>   */
>>
>> -#include "qemu/osdep.h"
>> +#include 
>> +#include 
>> +
>> +#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
>>
>>  /*
>>   * Inspired by 's union ieee854_long_double, but with single
>> @@ -39,7 +42,7 @@ union float80u {
>>  unsigned int exponent:15;
>>  unsigned int negative:1;
>>  unsigned int empty:16;
>> -} QEMU_PACKED ieee;
>> +} __attribute__((packed)) ieee;
>>
>>  /* This is for NaNs in the IEEE 854 double-extended-precision format.  
>> */
>>  struct {
>> @@ -49,7 +52,7 @@ union float80u {
>>  unsigned int exponent:15;
>>  unsigned int negative:1;
>>  unsigned int empty:16;
>> -} QEMU_PACKED ieee_nan;
>> +} __attribute__((packed)) ieee_nan;
>>  };
>>
>>  #define IEEE854_LONG_DOUBLE_BIAS 0x3fff
>> @@ -229,6 +232,7 @@ static void test_fprem_cases(void)
>>  do_fprem_stack_underflow();
>>
>>  printf("= invalid operation =\n");
>> +do_fprem(q_nan.d, 1.0);
>>  do_fprem(s_nan.d, 1.0);
>>  do_fprem(1.0, 0.0);
>>  do_fprem(pos_inf.d, 1.0);
>> @@ -238,6 +242,8 @@ static void test_fprem_cases(void)
>>  do_fprem(pos_denorm.d, 1.0);
>>  do_fprem(1.0, pos_denorm.d);
>>
>> +do_fprem(smallest_positive_norm.d, smallest_positive_norm.d);
>> +
>>  /* printf("= underflow =\n"); */
>>  /* TODO: Is there a case where FPREM raises underflow? */
>>  }
>>
>
> This test is disabled in tests/tcg/i386/Makefile.target and it would be
> nice to be able to run it without having to modify the Makefile, like
> running "make SLOW=1" or "SPEED=slow" like for iotests maybe?

Sounds like a good idea.

>
> This test is too verbose and I wonder if we should redirect stdout to
> /dev/null even for V=1.

I think the original intention was to compare against a reference.
Needless to say I think at the moment it's broken.

>
> Reviewed-by: Philippe Mathieu-Daudé 
> Enabled via tcg/i386/Makefile.target:
> Tested-by: Philippe Mathieu-Daudé 


--
Alex Bennée



Re: [Qemu-devel] [PATCH v3 23/46] tests/tcg/x86_64: add Makefile.target

2018-04-25 Thread Alex Bennée

Philippe Mathieu-Daudé  writes:

> On 04/24/2018 12:23 PM, Alex Bennée wrote:
>> The sources for x86_64 are shared in the i386 directory which will be
>> included thanks to TARGET_BASE_ARCH. However not all sources build so
>> we need to filter out the ones we can't build in the 64 bit world.
>>
>> Signed-off-by: Alex Bennée 
>> ---
>>  tests/tcg/i386/Makefile.target   |  2 +-
>>  tests/tcg/x86_64/Makefile.target | 15 +++
>>  2 files changed, 16 insertions(+), 1 deletion(-)
>>  create mode 100644 tests/tcg/x86_64/Makefile.target
>>
>> diff --git a/tests/tcg/i386/Makefile.target b/tests/tcg/i386/Makefile.target
>> index 80ccad3d7b..27086c3f2b 100644
>> --- a/tests/tcg/i386/Makefile.target
>> +++ b/tests/tcg/i386/Makefile.target
>> @@ -7,7 +7,7 @@ VPATH+= $(I386_SRC)
>>
>>  I386_SRCS=$(notdir $(wildcard $(I386_SRC)/*.c))
>>  I386_TESTS=$(I386_SRCS:.c=)
>> -
>> +I386_ONLY_TESTS=$(filter-out test-i386-ssse3, $(I386_TESTS))
>>  # Update TESTS
>>  TESTS+=$(I386_ONLY_TESTS)
>>
>> diff --git a/tests/tcg/x86_64/Makefile.target 
>> b/tests/tcg/x86_64/Makefile.target
>> new file mode 100644
>> index 00..74f170b9ed
>> --- /dev/null
>> +++ b/tests/tcg/x86_64/Makefile.target
>> @@ -0,0 +1,15 @@
>> +# -*- Mode: makefile -*-
>> +#
>> +# x86_64 tests - included from tests/tcg/Makefile.target
>> +#
>> +# Currently we only build test-x86_64 and test-i386-ssse3 from
>> +# $(SRC)/tests/tcg/i386/
>> +#
>> +
>> +X86_64_TESTS=$(filter-out $(I386_ONLY_TESTS), $(TESTS))
>> +X86_64_TESTS+=test-x86_64
>
> The linux-test is taking long... I canceled it after ~15min on a i7
> 2GHz. Maybe it also belongs to the "BROKEN TEST" series on x86_64?
> Currently it is only skipped if $(TARGET_NAME) == i386.

Hmm it runs pretty quickly for me:

time ./qemu-x86_64 ./tests/linux-test
0.02user 0.03system 0:00.08elapsed 72%CPU (0avgtext+0avgdata 7384maxresident)k
0inputs+0outputs (0major+1207minor)pagefaults 0swaps

I wonder if the failure mode you are seeing is the same as the others
which basically hang, which is why I added them to the broken test patch.

>
> Reviewed-by: Philippe Mathieu-Daudé 
>
>> +TESTS:=$(X86_64_TESTS)
>> +
>> +test-x86_64: LDFLAGS+=-lm -lc
>> +test-x86_64: test-i386.c test-i386.h test-i386-shift.h test-i386-muldiv.h
>> +$(CC) $(CFLAGS) $< -o $@ $(LDFLAGS)
>>
>
> $ make run-tcg-tests-x86_64-linux-user
>   RUN-TESTS for x86_64
>   TESTtest-mmap (default) on x86_64
>   TESTtest-mmap (8k pages) on x86_64
> ASAN:DEADLYSIGNAL
> =
> ==5717==ERROR: AddressSanitizer: SEGV on unknown address 0x7fcba47fc000
> (pc 0x7fcba8a3bf4d bp 0x7ffd19d74700 sp 0x7ffd19d73e88 T0)
> ==5717==The signal is caused by a WRITE memory access.
> #0 0x7fcba8a3bf4c  (/lib/x86_64-linux-gnu/libc.so.6+0x159f4c)
> #1 0x7fcbab33f891  (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x5c891)
> #2 0x55dd3ae4a7e0 in mmap_frag /source/qemu/linux-user/mmap.c:189
> #3 0x55dd3ae4bbce in target_mmap /source/qemu/linux-user/mmap.c:533
> #4 0x55dd3ae4b8cb in target_mmap /source/qemu/linux-user/mmap.c:501
> #5 0x55dd3ae3895c in do_syscall /source/qemu/linux-user/syscall.c:9448
> #6 0x55dd3adfaa57 in cpu_loop /source/qemu/linux-user/main.c:258
> #7 0x55dd3ae005f5 in main /source/qemu/linux-user/main.c:5147
> #8 0x7fcba8903a86 in __libc_start_main
> (/lib/x86_64-linux-gnu/libc.so.6+0x21a86)
> #9 0x55dd3ad34a89 in _start
> (/source/qemu/build/full/x86_64-linux-user/qemu-x86_64+0x350a89)
> AddressSanitizer can not provide additional info.
> SUMMARY: AddressSanitizer: SEGV (/lib/x86_64-linux-gnu/libc.so.6+0x159f4c)
> ==5717==ABORTING
> make[2]: ***
> [/home/phil/source/qemu/tests/tcg/multiarch/Makefile.target:27:
> run-test-mmap] Error 1
>
> Tested-by: Philippe Mathieu-Daudé 

This is only with ASAN enabled right?

--
Alex Bennée



Re: [Qemu-devel] [PATCH 5/9] target/arm: Implement FMOV (general) for fp16

2018-04-25 Thread Richard Henderson
On 04/24/2018 03:31 PM, Philippe Mathieu-Daudé wrote:
>> @@ -5431,10 +5446,15 @@ static void disas_fp_int_conv(DisasContext *s, 
>> uint32_t insn)
>>  case 0xa: /* 64 bit */
>>  case 0xd: /* 64 bit to top half of quad */
>>  break;
>> +case 0x6: /* 16-bit */
>> +if (arm_dc_feature(s, ARM_FEATURE_V8_FP16)) {
>> +break;
>> +}
>> +/* fallthru */
>>  default:
>>  /* all other sf/type/rmode combinations are invalid */
>>  unallocated_encoding(s);
>> -break;
>> +return;
> 
> Agreed with this change, however shouldn't this be in a separate patch?

Why?


r~



Re: [Qemu-devel] [PATCH v3 00/46] fix building of tests/tcg

2018-04-25 Thread Alex Bennée

Samuel Thibault  writes:

> Philippe Mathieu-Daudé, le mar. 24 avril 2018 22:25:18 -0300, a ecrit:
>> > This is starting to shape up pretty nicely. I was able to add a whole
>> > bunch of additional architectures thanks to cross compilers in Debian
>> > Sid which are there to support the Debian "ports". These may not be
>> > around for ever, most "ports" are on the way out, but they will be the
>> > last thing to drop out of the Sid repo. Maybe when Debian stops
>> > caring (and no other distro does) maybe we should to?
>>
>> I *think* working with Sid is not recommended as very unstable and not
>> reproducible. A reproducible way is to use the Debian Snapshot Archive
>> (http://snapshot.debian.org/) eventually using package specific version
>> and holding packages at this version.
>>
>> I found an example in the following post:
>> https://blog.sleeplessbeastie.eu/2017/07/17/how-to-install-packages-using-repository-snapshot/
>>
>> (I Cc'ed Debian experts who might have a better idea).
>
> That looks like the correct idea :)
> (basically what we use to make "releases" of the hurd port, as sid
> snapshots).

So how would this work in docker. Should I take for example the
sid-20180312 tag and then just munge sources.list to the appropriate
snapshot url?

That said I'm relatively sanguine about the stability of the toolchain
in sid. It would be the last thing to bitrot as once the toolchain is
dead the distro dies with it so it is the last thing to die and the
first thing to fix.

--
Alex Bennée



[Qemu-devel] [PATCH v2 2/2] ui: introduce vfio_display_reset

2018-04-25 Thread Tina Zhang
During guest OS reboot, guest framebuffer is invalid. It will cause
bugs, if the invalid guest framebuffer is still used by host.

This patch is to introduce vfio_display_reset which is invoked
during vfio display reset. This vfio_display_reset function is used
to release the invalid display resource, disable scanout mode and
replace the invalid surface with QemuConsole's DisplaySurafce.

This patch can fix the GPU hang issue caused by gd_egl_draw during
guest OS reboot.

Changes v1->v2:
 - Use dpy_gfx_update_full() to update screen after reset. (Gerd)
 - Remove dpy_gfx_switch_surface(). (Gerd)

Signed-off-by: Tina Zhang 
---
 hw/vfio/display.c | 10 ++
 hw/vfio/pci.c |  4 
 hw/vfio/pci.h |  1 +
 3 files changed, 15 insertions(+)

diff --git a/hw/vfio/display.c b/hw/vfio/display.c
index 7d727ce..dc4b1e9 100644
--- a/hw/vfio/display.c
+++ b/hw/vfio/display.c
@@ -198,6 +198,16 @@ static void vfio_display_dmabuf_exit(VFIODisplay *dpy)
 }
 
 /* -- */
+void vfio_display_reset(VFIOPCIDevice *vdev)
+{
+if (!vdev || !vdev->dpy || !vdev->dpy->con) {
+return;
+}
+
+dpy_gl_scanout_disable(vdev->dpy->con);
+vfio_display_dmabuf_exit(vdev->dpy);
+dpy_gfx_update_full(vdev->dpy->con);
+}
 
 static void vfio_display_region_update(void *opaque)
 {
diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index b9bc6cd..4947fe3 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -3103,6 +3103,10 @@ static void vfio_pci_reset(DeviceState *dev)
 
 vfio_pci_pre_reset(vdev);
 
+if (vdev->display != ON_OFF_AUTO_OFF) {
+vfio_display_reset(vdev);
+}
+
 if (vdev->resetfn && !vdev->resetfn(vdev)) {
 goto post_reset;
 }
diff --git a/hw/vfio/pci.h b/hw/vfio/pci.h
index 629c875..59ab775 100644
--- a/hw/vfio/pci.h
+++ b/hw/vfio/pci.h
@@ -176,6 +176,7 @@ int vfio_pci_igd_opregion_init(VFIOPCIDevice *vdev,
struct vfio_region_info *info,
Error **errp);
 
+void vfio_display_reset(VFIOPCIDevice *vdev);
 int vfio_display_probe(VFIOPCIDevice *vdev, Error **errp);
 void vfio_display_finalize(VFIOPCIDevice *vdev);
 
-- 
2.7.4




[Qemu-devel] [PATCH v2 0/2] Add vfio display reset handling

2018-04-25 Thread Tina Zhang
vfio display needs to release the invalid display resource and disable
the scanout mode during guest OS reboot, otherwise bugs come out.

Thanks hang.y...@intel.com for helping root cause the issue.

v1->v2:
 - remove dpy_gfx_switch_surface. (Gerd)
 - add dpy_gfx_update_full. (Gerd)

Tina Zhang (2):
  console: introduce dpy_gfx_update_full
  ui: introduce vfio_display_reset

 hw/vfio/display.c| 10 ++
 hw/vfio/pci.c|  4 
 hw/vfio/pci.h|  1 +
 include/ui/console.h |  1 +
 ui/console.c | 10 ++
 5 files changed, 26 insertions(+)

-- 
2.7.4




Re: [Qemu-devel] [PATCH] block: Merge .bdrv_co_writev{, _flags} in drivers

2018-04-25 Thread Daniel P . Berrangé
On Tue, Apr 24, 2018 at 05:01:57PM -0500, Eric Blake wrote:
> We have too many driver callback interfaces; simplify the mess
> somewhat by merging the flags parameter of .bdrv_co_writev_flags()
> into .bdrv_co_writev_flags().  Note that as long as a driver doesn't

Typo - this should be just  .bdrv_co_writev

> set .supported_write_flags, the flags argument will be 0 and behavior
> is identical.  Also note that the public function bdrv_co_writev()
> still lacks a flags argument; so the driver signature is thus
> intentionally slightly different.  But that's not the end of the
> world, nor the first time that the driver interface differs slightly
> from the public interface.
> 
> Ideally, we should be rewriting all of these drivers to use modern
> byte-based interfaces.  But that's a more invasive patch to write
> and audit, compared to the simplification done here.
> 
> Signed-off-by: Eric Blake 
> ---
> 
> Based-on: <20180424192506.149089-1-ebl...@redhat.com>
> ([PATCH v2 0/6] block: byte-based AIO read/write)
> 
>  include/block/block_int.h |  2 --
>  block/io.c| 13 -
>  block/gluster.c   |  4 +++-
>  block/iscsi.c |  8 
>  block/parallels.c |  4 +++-
>  block/qcow.c  |  6 --
>  block/qed.c   |  3 ++-
>  block/replication.c   |  4 +++-
>  block/sheepdog.c  |  4 +++-
>  block/ssh.c   |  4 +++-
>  block/vhdx.c  |  4 +++-
>  11 files changed, 32 insertions(+), 24 deletions(-)

Reviewed-by: Daniel P. Berrangé 


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|



[Qemu-devel] [PATCH v2 1/2] console: introduce dpy_gfx_update_full

2018-04-25 Thread Tina Zhang
dpy_gfx_update_full is used to do the whole display surface update.

This function is proposed by Gerd Hoffmann.

Signed-off-by: Tina Zhang 
---
 include/ui/console.h |  1 +
 ui/console.c | 10 ++
 2 files changed, 11 insertions(+)

diff --git a/include/ui/console.h b/include/ui/console.h
index 37a8d68..981b519 100644
--- a/include/ui/console.h
+++ b/include/ui/console.h
@@ -291,6 +291,7 @@ bool dpy_ui_info_supported(QemuConsole *con);
 int dpy_set_ui_info(QemuConsole *con, QemuUIInfo *info);
 
 void dpy_gfx_update(QemuConsole *con, int x, int y, int w, int h);
+void dpy_gfx_update_full(QemuConsole *con);
 void dpy_gfx_replace_surface(QemuConsole *con,
  DisplaySurface *surface);
 void dpy_text_cursor(QemuConsole *con, int x, int y);
diff --git a/ui/console.c b/ui/console.c
index 3fb2f4e..b02510c 100644
--- a/ui/console.c
+++ b/ui/console.c
@@ -1574,6 +1574,16 @@ void dpy_gfx_update(QemuConsole *con, int x, int y, int 
w, int h)
 }
 }
 
+void dpy_gfx_update_full(QemuConsole *con)
+{
+if (!con->surface) {
+return;
+}
+dpy_gfx_update(con, 0, 0,
+   surface_width(con->surface),
+   surface_height(con->surface));
+}
+
 void dpy_gfx_replace_surface(QemuConsole *con,
  DisplaySurface *surface)
 {
-- 
2.7.4




Re: [Qemu-devel] [PATCH] migration/fd: abort migration if receive POLLHUP event

2018-04-25 Thread Daniel P . Berrangé
On Wed, Apr 25, 2018 at 07:29:05AM +, wangxin (U) wrote:
> 
> > -Original Message-
> > From: Peter Xu [mailto:pet...@redhat.com]
> > Sent: Wednesday, April 25, 2018 11:32 AM
> > To: Daniel P. Berrangé 
> > Cc: Dr. David Alan Gilbert ; wangxin (U)
> > ; qemu-devel@nongnu.org;
> > quint...@redhat.com; Gonglei (Arei) 
> > Subject: Re: [PATCH] migration/fd: abort migration if receive POLLHUP event
> > 

> > Ah, wait.  I just noticed that Xin mentioned about the loop already -
> > it's an infinite loop of SIGHUP.  I suppose it means that we'll just
> > never go into fd_accept_incoming_migration() at all?
> 
> Yeah, that's what I want to fix.
> 
> > 
> > If so, I'm not sure whether we should just always watch on G_IO_HUP
> > (and possibly G_IO_ERR too) in qio_channel_create_watch():
> > 
> >   GSource *ret = klass->io_create_watch(ioc, condition | G_IO_HUP |
> > G_IO_ERR);
> > 
> > Otherwise I'm not sure the same loop will happen for other users of
> > qio_channel_add_watch().
> 
> In my scenario, it's clear the client quit immediately and we
> never got a POLLIN event, otherwise, 
> the watch should be unregistered when POLLIN event coming. 
> As Daniel said, normally G_IO_IN will be the first event, we
> need to find why POLLIN event never happened, I'll try it.

Yes, I have always been under the belief that you're guaranteed to get a
POLLIN event when the client closes the connection, in addition to the
POLLHUP event, but it sounds like that is not happening so I guess I'm
mistaken in that.

In this case, it should be sufficient to just add the G_IO_HUP|G_IO_ERR
events when creating the watch - probably no need to add extra code to
the fd_accept_incoming_migration() method.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|



Re: [Qemu-devel] [RFC][BROKEN] rbd: Allow configuration of authentication scheme

2018-04-25 Thread Kevin Wolf
Am 24.04.2018 um 20:26 hat Jeff Cody geschrieben:
> On Fri, Apr 20, 2018 at 04:39:02PM +0200, Markus Armbruster wrote:
> > >> Ways to avoid the troublesome auth-cephx: {}:
> > >> 
> > >> (A) Make auth-cephx a bool, rely on the other ways to provide the key
> > >> 
> > >> (B) Make auth-cephx a bool and add the @key-secret member next to it
> > >> 
> > >> Like @user, the member is meaningless with auth-none.
> > >> 
> > >> (C) Make auth-cephx.key-secret a mandatory StrOrNull
> > >> 
> > >> Should take care of "vanishes on flattening" problem, but dotted key
> > >> syntax is still screwed: since any value is a valid string, there's
> > >> none left for null.  My take would be that if you want to say
> > >> auth-cephx.key-secret: {}, you get to say it in JSON.
> > >> 
> > >> Aside: check_alternate() tries to catch such alternates, but we
> > >> failed to update it when we added first class null.  *sigh*
> > >> 
> > >> Which one do you hate least?
> > >
> > > What should happen with null when you stringify it? If we want to take
> > > the options QDict, stringify all entries and run them through the keyval
> > > visitor, I'm almost sure that null will be lost.
> > 
> > For the stringify idea to work, the keyval visitor needs to map the
> > string right back to the original value.
> > 
> > The keyval visitor currently requires the value to be null, not a
> > string.
> > 
> > Therefore, the stringify operation must leave null alone.  Not pretty,
> > but works.

Okay, I didn't know that the keyval visitor has any way to specify null.
It doesn't really matter what the exact representation is as long as we
can generate it. So sure, that's workable then.

> > You might ask why not change the keyval visitor instead so it expects ""
> > rather than null.  That's no good, because it makes StrOrNull ambiguous.
> > 
> > keyval.c can only create string scalars.  I think "use JSON if you want
> > to specify null" is still good enough.  We can make keyval.c more
> > expressive if we need to, but (1) I don't think we should block this
> > work on it, and (2) see "hairy" above.
> > 
> > > So (A) doesn't work unless we can specify what "other ways" are that are
> > > acceptable for libvirt,
> > 
> > Yes.
> > 
> > > and (C) probably doesn't play well with b. above
> > > (the qdict_stringify_entries() for handling mixed type QDicts).
> > 
> > I think it could be done, and tried to sketch how.
> > 
> > > Looks like only (B) is left as viable, so that's automatically the one I
> > > hate least of these. If we can fix the problems, I think I'd prefer (C),
> > > though.
> > 
> > I could accept (B), in particular since it mirrors existing @user.

I don't like (B) much because it adds additional rules which options
must, may or can be present depending on the presence or value of other
options. This kind of dependencies should be visible in the schema with
nested structs and unions, and checked for consistency by QAPI, rather
than being checked individually in .bdrv_open() implementations.

As for @user, you had sources to confirm that it is indeed irrelevant
for 'none', so I'd rather do the opposite thing and move it to
RbdAuthCephx.

> > I'm happy to help with exploring (C).
> > 
> > What's the next step?
> 
> My preference is (B).  Primarily because I don't like the idea of breaking
> dotted key syntax for null keys.  I'd rather see something more verbose like
> (B), that can still be navigated correctly both ways.

Yes, it's not perfect, but it doesn't make any functionality unavailable
because you can always using JSON, even on the command line. Dotted
syntax is nicer for manual use, but in this specific case I think null
will be the default, so there is no need to specify it explicitly
anyway - neither with dotted key syntax nor with JSON.

I prefer slightly unwieldy command line syntax to getting the internally
used data types wrong (= hard to use correctly).

> How about I put together a patch with (B) for an RFC v2?

How about doing the same with (C) and moving @user? :-)

Kevin



Re: [Qemu-devel] [PATCH 2/6] qapi: handle the riscv CpuInfoArch in query-cpus-fast

2018-04-25 Thread Cornelia Huck
On Wed, 25 Apr 2018 08:44:15 +0200
Markus Armbruster  wrote:

> Laszlo Ersek  writes:
> 
> > Commit 25fa194b7b11 added the @riscv enum constant to @CpuInfoArch (used
> > in both @CpuInfo and @CpuInfoFast -- the return types of the @query-cpus
> > and @query-cpus-fast commands, respectively), and assigned, in both return
> > structures, the @CpuInfoRISCV sub-structure to the new enum value.
> >
> > However, qmp_query_cpus_fast() would not populate either the @arch field
> > or the @CpuInfoRISCV sub-structure, when TARGET_RISCV was defined; only
> > qmp_query_cpus() would.
> >
> > In theory, there are two ways to fix this:
> >
> > (a) Fill in both the @arch field and the @CpuInfoRISCV sub-structure in
> > qmp_query_cpus_fast(), by copying the logic from qmp_query_cpus().
> >
> > (b) Assign @CpuInfoOther to the @riscv enum constant in @CpuInfoFast, and
> > populate only the @arch field in qmp_query_cpus_fast().
> >
> > Approach (b) seems more robust, because:
> >
> > - clearly there has never been an attempt to get actual RISV CPU state
> >   from qmp_query_cpus_fast(), so its lack of RISCV support is not actually
> >   a problem,
> >
> > - getting CPU state without interrupting KVM looks like an exceptional
> >   thing to do (only S390X does it currently).
> >
> > Cc: Bastian Koppelmann 
> > Cc: Eric Blake 
> > Cc: Laurent Vivier 
> > Cc: Markus Armbruster 
> > Cc: Michael Clark 
> > Cc: Palmer Dabbelt 
> > Cc: Paolo Bonzini 
> > Cc: Peter Crosthwaite 
> > Cc: Richard Henderson 
> > Cc: Riku Voipio 
> > Cc: Sagar Karandikar 
> > Cc: qemu-sta...@nongnu.org
> > Fixes: 25fa194b7b11901561532e435beb83d046899f7a
> > Signed-off-by: Laszlo Ersek 
> > ---
> >
> > Notes:
> > PATCHv1:
> > 
> > - new patch
> >
> >  qapi/misc.json | 2 +-
> >  cpus.c | 2 ++
> >  2 files changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/qapi/misc.json b/qapi/misc.json
> > index 5636f4a14997..104d013adba6 100644
> > --- a/qapi/misc.json
> > +++ b/qapi/misc.json
> > @@ -565,23 +565,23 @@
> >  { 'union': 'CpuInfoFast',
> >'base': {'cpu-index': 'int', 'qom-path': 'str',
> > 'thread-id': 'int', '*props': 'CpuInstanceProperties',
> > 'arch': 'CpuInfoArch' },
> >'discriminator': 'arch',
> >'data': { 'x86': 'CpuInfoOther',
> >  'sparc': 'CpuInfoOther',
> >  'ppc': 'CpuInfoOther',
> >  'mips': 'CpuInfoOther',
> >  'tricore': 'CpuInfoOther',
> >  's390': 'CpuInfoS390',
> > -'riscv': 'CpuInfoRISCV',
> > +'riscv': 'CpuInfoOther',
> >  'other': 'CpuInfoOther' } }  
> 
> Why do CpuInfoFast's variants match CpuInfo's for s390, but not the
> others?  Your commit message has an educated guess: "looks like an
> exceptional thing to do (only S390X does it currently)".  But why guess
> when we can ask authors of commit ce74ee3dea6?  Luiz and Victor, please
> advise.

I'm neither Luiz nor Viktor, but Laszlo's educated guess is correct. See
https://www.redhat.com/archives/libvir-list/2018-February/msg00121.html
for some background. So yes, s390x is exceptional in that it has state
in QEMU that is actually interesting for upper layers and can be
retrieved without performance penalty.

Might make sense to refer to the above.

> 
> >  ##
> >  # @query-cpus-fast:
> >  #
> >  # Returns information about all virtual CPUs. This command does not
> >  # incur a performance penalty and should be used in production
> >  # instead of query-cpus.
> >  #
> >  # Returns: list of @CpuInfoFast
> >  #
> > diff --git a/cpus.c b/cpus.c
> > index 1a9a2edee1f2..60563a6d54ec 100644
> > --- a/cpus.c
> > +++ b/cpus.c
> > @@ -2225,22 +2225,24 @@ CpuInfoFastList *qmp_query_cpus_fast(Error **errp)
> >  #elif defined(TARGET_SPARC)
> >  info->value->arch = CPU_INFO_ARCH_SPARC;
> >  #elif defined(TARGET_MIPS)
> >  info->value->arch = CPU_INFO_ARCH_MIPS;
> >  #elif defined(TARGET_TRICORE)
> >  info->value->arch = CPU_INFO_ARCH_TRICORE;
> >  #elif defined(TARGET_S390X)
> >  s390_cpu = S390_CPU(cpu);
> >  env = _cpu->env;
> >  info->value->arch = CPU_INFO_ARCH_S390;
> >  info->value->u.s390.cpu_state = env->cpu_state;
> > +#elif defined(TARGET_RISCV)
> > +info->value->arch = CPU_INFO_ARCH_RISCV;
> >  #else
> >  info->value->arch = CPU_INFO_ARCH_OTHER;
> >  #endif
> >  if (!cur_item) {
> >  head = cur_item = info;
> >  } else {
> >  cur_item->next = info;
> >  cur_item = info;
> >  }
> >  }  
> 




Re: [Qemu-devel] [PATCH 6/6] qapi: discriminate CpuInfo[Fast] on SysEmuTarget, not CpuInfoArch

2018-04-25 Thread Markus Armbruster
Laszlo Ersek  writes:

> Add a new field @target (of type @SysEmuTarget) to the outputs of the
> @query-cpus and @query-cpus-fast commands, which provides more information
> about the emulation target than the field @arch (of type @CpuInfoArch).
> Keep @arch for compatibility.
>
> Make @target the new discriminator for the @CpuInfo and @CpuInfoFast
> return structures. This lets us hoist @arch to @CpuInfoCommon, but it also
> requires some gymnastics in qmp_query_cpus() and qmp_query_cpus_fast().
>
> In particular, conditional compilation cannot be removed, because each
> pair of CPU base arch structures, such as X86CPU/CPUX86State,
> PowerPCCPU/CPUPPCState, SPARCCPU/CPUSPARCState, is only visible when
> building QEMU for a target that maps to that CPU base arch.
>
> Cc: Eric Blake 
> Cc: Markus Armbruster 
> Cc: Paolo Bonzini 
> Cc: Peter Crosthwaite 
> Cc: Richard Henderson 
> Signed-off-by: Laszlo Ersek 
> ---
>
> Notes:
> PATCHv1:
> 
> - new patch
>
>  qapi/misc.json | 118 ++---
>  cpus.c | 275 
> ++---
>  2 files changed, 291 insertions(+), 102 deletions(-)
>
> diff --git a/qapi/misc.json b/qapi/misc.json
> index d7b776a5af37..98c15880f9f0 100644
> --- a/qapi/misc.json
> +++ b/qapi/misc.json
> @@ -361,77 +361,105 @@
>  # Collects fields common to @CpuInfoBase and @CpuInfoFastBase; that is,
>  # fields that are shared by @query-cpus and @query-cpus-fast, and not
>  # specific to the target architecture.
>  #
>  # @qom-path: path to the CPU object in the QOM tree (since 2.4)
>  #
>  # @thread-id: ID of the underlying host thread
>  #
>  # @props: properties describing which node/socket/core/thread the
>  # virtual CPU belongs to, if supported by the board (since 2.10)
>  #
> +# @arch: base architecture of the cpu (since 2.6)
> +#
>  # Since: 2.13
>  ##
>  { 'struct' : 'CpuInfoCommon',
>'data'   : { 'qom-path'  : 'str',
> 'thread-id' : 'int',
> -   '*props': 'CpuInstanceProperties' } }
> +   '*props': 'CpuInstanceProperties',
> +   'arch'  : 'CpuInfoArch' } }
>  
>  ##
>  # @CpuInfoBase:
>  #
>  # Extends @CpuInfoCommon with fields that are specific to the @query-cpus
>  # command, but not specific to the target architecture.
>  #
>  # @CPU: the index of the virtual CPU
>  #
>  # @current: this only exists for backwards compatibility and should be 
> ignored
>  #
>  # @halted: true if the virtual CPU is in the halt state.  Halt usually refers
>  #  to a processor specific low power mode.
>  #
> -# @arch: architecture of the cpu, which determines which additional fields
> -#will be listed (since 2.6)
> +# @target: the QEMU system emulation target, which is more specific than
> +#  @arch and determines which additional fields will be listed
> +#
>  #
>  # Since: 2.13
>  #
>  # Notes: @halted is a transient state that changes frequently.  By the time 
> the
>  #data is sent to the client, the guest may no longer be halted.
> -#Moreover, @arch cannot be moved up to @CpuInfoCommon because
> +#Moreover, @target cannot be moved up to @CpuInfoCommon because
>  #that would prevent its use as the discriminator in @CpuInfo.
>  ##
>  { 'struct' : 'CpuInfoBase',
>'base'   : 'CpuInfoCommon',
>'data'   : { 'CPU' : 'int',
> 'current' : 'bool',
> 'halted'  : 'bool',
> -   'arch': 'CpuInfoArch' } }
> +   'target'  : 'SysEmuTarget' } }
>  
>  ##
>  # @CpuInfo:
>  #
>  # Information about a virtual CPU
>  #
>  # Since: 0.14.0
>  ##
> -{ 'union': 'CpuInfo',
> -  'base': 'CpuInfoBase',
> -  'discriminator': 'arch',
> -  'data': { 'x86': 'CpuInfoX86',
> -'sparc': 'CpuInfoSPARC',
> -'ppc': 'CpuInfoPPC',
> -'mips': 'CpuInfoMIPS',
> -'tricore': 'CpuInfoTricore',
> -'s390': 'CpuInfoS390',
> -'riscv': 'CpuInfoRISCV',
> -'other': 'CpuInfoOther' } }
> +{ 'union' : 'CpuInfo',
> +  'base'  : 'CpuInfoBase',
> +  'discriminator' : 'target',
> +  'data'  : { 'i386' : 'CpuInfoX86',
> +  'x86_64'   : 'CpuInfoX86',
> +  'sparc': 'CpuInfoSPARC',
> +  'sparc64'  : 'CpuInfoSPARC',
> +  'ppc'  : 'CpuInfoPPC',
> +  'ppcemb'   : 'CpuInfoPPC',
> +  'ppc64': 'CpuInfoPPC',
> +  'mips' : 'CpuInfoMIPS',
> +  'mipsel'   : 'CpuInfoMIPS',
> +  'mips64'   : 'CpuInfoMIPS',
> +  'mips64el' : 'CpuInfoMIPS',
> +  'tricore'  : 

Re: [Qemu-devel] [PATCH] migration/fd: abort migration if receive POLLHUP event

2018-04-25 Thread wangxin (U)

> -Original Message-
> From: Peter Xu [mailto:pet...@redhat.com]
> Sent: Wednesday, April 25, 2018 11:32 AM
> To: Daniel P. Berrangé 
> Cc: Dr. David Alan Gilbert ; wangxin (U)
> ; qemu-devel@nongnu.org;
> quint...@redhat.com; Gonglei (Arei) 
> Subject: Re: [PATCH] migration/fd: abort migration if receive POLLHUP event
> 
> On Wed, Apr 25, 2018 at 11:14:23AM +0800, Peter Xu wrote:
> > On Tue, Apr 24, 2018 at 07:24:05PM +0100, Daniel P. Berrangé wrote:
> > > On Tue, Apr 24, 2018 at 06:16:31PM +0100, Dr. David Alan Gilbert wrote:
> > > > * Wang Xin (wangxinxin.w...@huawei.com) wrote:
> > > > > If the fd socket peer closed shortly, ppoll may receive a POLLHUP
> > > > > event before the expected POLLIN event, and qemu will do nothing
> > > > > but goes into an infinite loop of the POLLHUP event.
> > > > >
> > > > > So, abort the migration if we receive a POLLHUP event.
> > > >
> > > > Hi Wang Xin,
> > > >   Can you explain how you manage to trigger this case; I've not hit it.

Hi David,

I haven't find a way of stable reproduction.
It happened when I try to use libvirt command to restore a VM from an remote 
image, and the net broken unexpectedly.

virsh restore --->   libvirtd
  run/   \ pass fd
Remote image <> libvirt_iohelper <--pipe--> qemu -migration

Here are some key log:
1) virsh resotre 
/opt/galax/mnt/hibernating/db898219-1cde-45bf-b46e-4e439aa2d573/db898219-1cde-45bf-b46e-4e439aa2d573.img
  --bypass-cache
2018-04-17T09:45:04.128979+08:00|info|libvirtd[4834]|[5098]|virDomainRestoreFlags[1140]|:
 enter virDomainRestoreFlags 
from=/opt/galax/mnt/hibernating/db898219-1cde-45bf-b46e-4e439aa2d573/db898219-1cde-45bf-b46e-4e439aa2d573.img,
 flags=3

2)some qemu log we catched:
2018-04-17T09:45:06.111682+08:00|info|qemu[1628]|[1628]|do_qmp_dispatch[109]|: 
qmp_cmd_name: migrate-incoming, arguments: {"uri": "fd:37"}
2018-04-17T09:45:06.111735+08:00|info|qemu[1628]|[1628]|monitor_qapi_event_emit[423]|:
 {"timestamp": {"seconds": 1523929506, "microseconds": 111706}, "event": 
"MIGRATION", "data": {"status": "setup"}}
2018-04-17T09:45:06.112353+08:00|info|qemu[1628]|[1628]|monitor_qapi_event_emit[423]|:
 {"timestamp": {"seconds": 1523929506, "microseconds": 112317}, "event": 
"MIGRATION", "data": {"status": "active"}}
... then nothing print

3) Remote storage broken, process libvirt_iohelper do error exit. The system 
key messages as below:
2018-04-17T09:45:04.298085+08:00|info|systemd-machined[-]|New machine 
qemu-1-i-023F.
2018-04-17T09:45:04.298547+08:00|info|systemd[-]|Started Virtual Machine 
qemu-1-i-023F.
2018-04-17T09:45:04.298918+08:00|info|systemd[-]|Starting Virtual Machine 
qemu-1-i-023F.
2018-04-17T09:45:06.188259+08:00|info|kernel[-]|[55369.414640]  connection6:0: 
detected conn error (1020)  //Remote storage broken, libvirt_iohelper do error 
exit
2018-04-17T09:45:06.198229+08:00|info|kernel[-]|[55369.423977]  connection7:0: 
detected conn error (1020)
2018-04-17T09:45:06.776992+08:00|warning|iscsid[-]|Kernel reported iSCSI 
connection 6:0 error (1020 - ISCSI_ERR_TCP_CONN_CLOSE: TCP connection closed) 
state (3)
2018-04-17T09:45:06.777200+08:00|warning|iscsid[-]|Kernel reported iSCSI 
connection 7:0 error (1020 - ISCSI_ERR_TCP_CONN_CLOSE: TCP connection closed) 
state (3)

4) Qemu ppoll() exit frequently because of POLLHUP event
(gdb) p ((GPollFD *)gpollfds->date)[8]
$117 = {fd = 37, events = 1, revents = 16}

> > > >
> > > > > Signed-off-by: Wang Xin 
> > > > >
> > > > > diff --git a/migration/fd.c b/migration/fd.c
> > > > > index cd06182..5932c87 100644
> > > > > --- a/migration/fd.c
> > > > > +++ b/migration/fd.c
> > > > > @@ -15,6 +15,7 @@
> > > > >   */
> > > > >
> > > > >  #include "qemu/osdep.h"
> > > > > +#include "qemu/error-report.h"
> > > > >  #include "channel.h"
> > > > >  #include "fd.h"
> > > > >  #include "monitor/monitor.h"
> > > > > @@ -46,6 +47,11 @@ static gboolean
> fd_accept_incoming_migration(QIOChannel *ioc,
> > > > >   GIOCondition
> condition,
> > > > >   gpointer
> opaque)
> > > > >  {
> > > > > +if (condition & G_IO_HUP) {
> > > > > +error_report("The migration peer closed, job abort");
> > > > > +exit(EXIT_FAILURE);
> > > > > +}
> > > > > +
> > > >
> > > > OK,  I wish we had a nicer way for failing;  especially for the
> > > > multifd/postcopy recovery worlds where one failed connection might not
> > > > be fatal; but I don't see how to do that here.

Any suggestion? Closing the fd is the normal way to handle G_IO_HUP event.

> > >
> > > This doesn't feel right to me.
> > >
> > > We have passed in a pre-opened FD to QEMU, and we registered a watch
> > > on it to detect when there is data from the src QEMU that is available
> > > to read.  Normally the src will have sent 

Re: [Qemu-devel] [PATCH 1/6] qapi: fill in CpuInfoFast.arch in query-cpus-fast

2018-04-25 Thread Cornelia Huck
On Tue, 24 Apr 2018 23:45:45 +0200
Laszlo Ersek  wrote:

> Commit ca230ff33f89 added added the @arch field to @CpuInfoFast, but it
> failed to set the new field in qmp_query_cpus_fast(), when TARGET_S390X
> was not defined. The updated @query-cpus-fast example in
> "qapi-schema.json" showed "arch":"x86" only because qmp_query_cpus_fast()
> calls g_malloc0() to allocate CpuInfoFast, and the CPU_INFO_ARCH_X86 enum
> constant is generated with value 0.
> 
> All @arch values other than @s390 implied the @CpuInfoOther sub-struct for
> @CpuInfoFast -- at the time of writing the patch --, thus no fields other
> than @arch needed to be set when TARGET_S390X was not defined. Set @arch
> now, by copying the corresponding assignments from qmp_query_cpus().

I agree with others that this looks a bit odd for riscv, and merging
patch 2 would be an option. But this is fine as well.

> 
> Cc: Eric Blake 
> Cc: Markus Armbruster 
> Cc: Paolo Bonzini 
> Cc: Peter Crosthwaite 
> Cc: Richard Henderson 
> Cc: qemu-sta...@nongnu.org
> Fixes: ca230ff33f89bf7102cbfbc2328716da6750aaed
> Signed-off-by: Laszlo Ersek 

Reviewed-by: Cornelia Huck 



Re: [Qemu-devel] [PATCH 2/2] ui: introduce vfio_display_reset

2018-04-25 Thread Zhang, Tina


> -Original Message-
> From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> Behalf Of Gerd Hoffmann
> Sent: Tuesday, April 24, 2018 4:16 PM
> To: Zhang, Tina 
> Cc: alex.william...@redhat.com; intel-gvt-...@lists.freedesktop.org; qemu-
> de...@nongnu.org; zhen...@linux.intel.com; Yuan, Hang
> 
> Subject: Re: [PATCH 2/2] ui: introduce vfio_display_reset
> 
>   Hi,
> 
> > After reviewing this patch-set again, I think we might not need the
> > proposed dpy_gfx_switch_surface() any more.  The reason I proposed it
> > was because I thought gfx.ds is changed to the surface related to
> > guest dma-buf framebuffer and we need to switch it with QemuConsole's
> > DisplaySurgface during reset.  But after reviewing the code,
> > vc->gfx.ds is always pointing to the valid QemuConsoles'
> > DisplaySurface. So we don’t need dpy_gfx_switch_surface() to take care
> > of it.
> 
> Good, this is what I expected.
> 
> > > Maybe you just need a full display update after disabling the gl
> > > scanout?
> > Do you still think updating full display is needed?
> 
> It certainly isn't required, gtk wouldn't access the dma-buf any more after
> scanout_disable().
> 
> Without display update the last guest display may remain visible until the 
> guest
> reloads the driver though.  With display update the gtk ui should show the
> (blank) DisplaySurface instead.  So it is more cosmetical.
Indeed. Thanks for the comments. I will send out the next version of this 
patch-set.
Thanks.

BR,
Tina
> 
> cheers,
>   Gerd
> 
> ___
> intel-gvt-dev mailing list
> intel-gvt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev


[Qemu-devel] [PATCH v3 1/1] migration: calculate expected_downtime with ram_bytes_remaining()

2018-04-25 Thread Balamuruhan S
expected_downtime value is not accurate with dirty_pages_rate * page_size,
using ram_bytes_remaining would yeild it correct. It will initially be a
gross over-estimate, but for for non-converging migrations it should
approach a reasonable estimate later on.

currently bandwidth and expected_downtime value are calculated in
migration_update_counters() during each iteration from
migration_thread(), where as remaining ram is calculated in
qmp_query_migrate() when we actually call "info migrate". Due to this
there is some difference in expected_downtime value being calculated.

with this patch bandwidth, expected_downtime and remaining ram are
calculated in migration_update_counters(), retrieve the same value during
"info migrate". By this approach we get almost close enough value.

Reported-by: Michael Roth 
Signed-off-by: Balamuruhan S 
---
 migration/migration.c | 11 ---
 migration/migration.h |  1 +
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/migration/migration.c b/migration/migration.c
index 52a5092add..5d721ee481 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -614,7 +614,7 @@ static void populate_ram_info(MigrationInfo *info, 
MigrationState *s)
 }
 
 if (s->state != MIGRATION_STATUS_COMPLETED) {
-info->ram->remaining = ram_bytes_remaining();
+info->ram->remaining = s->ram_bytes_remaining;
 info->ram->dirty_pages_rate = ram_counters.dirty_pages_rate;
 }
 }
@@ -2227,6 +2227,7 @@ static void migration_update_counters(MigrationState *s,
 transferred = qemu_ftell(s->to_dst_file) - s->iteration_initial_bytes;
 time_spent = current_time - s->iteration_start_time;
 bandwidth = (double)transferred / time_spent;
+s->ram_bytes_remaining = ram_bytes_remaining();
 s->threshold_size = bandwidth * s->parameters.downtime_limit;
 
 s->mbps = (((double) transferred * 8.0) /
@@ -2237,8 +2238,12 @@ static void migration_update_counters(MigrationState *s,
  * recalculate. 1 is a small enough number for our purposes
  */
 if (ram_counters.dirty_pages_rate && transferred > 1) {
-s->expected_downtime = ram_counters.dirty_pages_rate *
-qemu_target_page_size() / bandwidth;
+/*
+ * It will initially be a gross over-estimate, but for for
+ * non-converging migrations it should approach a reasonable estimate
+ * later on
+ */
+s->expected_downtime = s->ram_bytes_remaining / bandwidth;
 }
 
 qemu_file_reset_rate_limit(s->to_dst_file);
diff --git a/migration/migration.h b/migration/migration.h
index 8d2f320c48..8584f8e22e 100644
--- a/migration/migration.h
+++ b/migration/migration.h
@@ -128,6 +128,7 @@ struct MigrationState
 int64_t downtime_start;
 int64_t downtime;
 int64_t expected_downtime;
+int64_t ram_bytes_remaining;
 bool enabled_capabilities[MIGRATION_CAPABILITY__MAX];
 int64_t setup_time;
 /*
-- 
2.14.3




[Qemu-devel] [PATCH v3 0/1] migration: calculate expected_downtime with ram_bytes_remaining()

2018-04-25 Thread Balamuruhan S
V3:

* commit message to be updated with the changes done by the patch since
v1, review comment by David Gibson.

* Included Michael Roth as ``Reported-by:`` for bringing up the concern.

v2:

There is some difference in expected_downtime value due to following
reason,

1. bandwidth and expected_downtime value are calculated in
migration_update_counters() during each iteration from
migration_thread()

2. remaining ram is calculated in qmp_query_migrate() when we actually
call "info migrate"

This v2 patch where bandwidth, expected_downtime and remaining ram are
calculated in migration_update_counters(), retrieve the same value
during
"info migrate". By this approach we get almost close enough value,

(qemu) info migrate
globals:
store-global-state: on
only-migratable: off
send-configuration: on
send-section-footer: on
capabilities: xbzrle: off rdma-pin-all: off auto-converge: off
zero-blocks: off compress: off events: off postcopy-ram: off x-colo: off
release-ram: off block: off return-path: off pause-before-switchover:
off x-multifd: off dirty-bitmaps: off
Migration status: active
total time: 319737 milliseconds
expected downtime: 1054 milliseconds
setup: 16 milliseconds
transferred ram: 3669862 kbytes
throughput: 108.92 mbps
remaining ram: 14016 kbytes
total ram: 8388864 kbytes
duplicate: 2296276 pages
skipped: 0 pages
normal: 910639 pages
normal bytes: 3642556 kbytes
dirty sync count: 249
page size: 4 kbytes
dirty pages rate: 4626 pages

Calculation:
calculated value = (14016 * 8 ) / 108.92 = 1029.452809401 milliseconds
actual value = 1054 milliseconds

since v1:
use ram_bytes_remaining() instead of dirty_pages_rate * page_size to
calculate expected_downtime to be more accurate.

Regards,
Bala

Balamuruhan S (1):
  migration: calculate expected_downtime with ram_bytes_remaining()

 migration/migration.c | 11 ---
 migration/migration.h |  1 +
 2 files changed, 9 insertions(+), 3 deletions(-)

-- 
2.14.3




Re: [Qemu-devel] [PATCH 5/6] qapi: extract CpuInfoCommon to mitigate schema duplication

2018-04-25 Thread Markus Armbruster
Laszlo Ersek  writes:

> @CpuInfo and @CpuInfoFast duplicate the following four fields: @qom-path,
> @thread-id, @props and @arch. From these, extract the first three to a
> common structure called @CpuInfoCommon. (More on @arch later.)
>
> Introduce two new mid-layer structures, @CpuInfoBase and @CpuInfoFastBase,
> to soak up the union base struct fields on top of @CpuInfoCommon that are
> specific to @query-cpus and @query-cpus-fast, respectively. This is
> necessary because the base struct spec in union definitions does not let
> us mix named fields with a recursive base struct. (In other words, we
> couldn't directly use @CpuInfoCommon *plus* some other fields within
> @CpuInfo and @CpuInfoFast as base struct).

Yes, you can either specify a base type or inline common members.  If
"union's common members = base type plus additional inline members"
turns out to be desirable in more places, we can try to add the feature.
I'm not asking *you* to find out, let alone try :)

> @arch cannot be hoisted higher than to @CpuInfoBase and @CpuInfoFastBase
> because the union descriminator is only accepted from a direct base
> struct, not from an indirect one.

That's a bit of a blemish.  Again, I'm not asking you to do anything
about it.

> Cc: Eric Blake 
> Cc: Markus Armbruster 
> Signed-off-by: Laszlo Ersek 
> ---
>
> Notes:
> PATCHv1:
> 
> - new patch
>
>  qapi/misc.json  | 94 
> +
>  qapi/qapi-schema.json   |  2 +-
>  tests/test-x86-cpuid-compat.c   |  2 +-
>  tests/migration/guestperf/engine.py |  2 +-
>  4 files changed, 68 insertions(+), 32 deletions(-)
>
> diff --git a/qapi/misc.json b/qapi/misc.json
> index 460866cf542f..d7b776a5af37 100644
> --- a/qapi/misc.json
> +++ b/qapi/misc.json
> @@ -348,52 +348,81 @@
>  #
>  # @s390: since 2.12
>  #
>  # @riscv: since 2.12
>  #
>  # Since: 2.6
>  ##
>  { 'enum': 'CpuInfoArch',
>'data': ['x86', 'sparc', 'ppc', 'mips', 'tricore', 's390', 'riscv', 
> 'other' ] }
>  
>  ##
> -# @CpuInfo:
> +# @CpuInfoCommon:
>  #
> -# Information about a virtual CPU
> +# Collects fields common to @CpuInfoBase and @CpuInfoFastBase; that is,
> +# fields that are shared by @query-cpus and @query-cpus-fast, and not
> +# specific to the target architecture.
> +#
> +# @qom-path: path to the CPU object in the QOM tree (since 2.4)
> +#
> +# @thread-id: ID of the underlying host thread
> +#
> +# @props: properties describing which node/socket/core/thread the
> +# virtual CPU belongs to, if supported by the board (since 2.10)
> +#
> +# Since: 2.13
> +##
> +{ 'struct' : 'CpuInfoCommon',
> +  'data'   : { 'qom-path'  : 'str',
> +   'thread-id' : 'int',
> +   '*props': 'CpuInstanceProperties' } }
> +
> +##
> +# @CpuInfoBase:
> +#
> +# Extends @CpuInfoCommon with fields that are specific to the @query-cpus
> +# command, but not specific to the target architecture.
>  #
>  # @CPU: the index of the virtual CPU
>  #
>  # @current: this only exists for backwards compatibility and should be 
> ignored
>  #
>  # @halted: true if the virtual CPU is in the halt state.  Halt usually refers
>  #  to a processor specific low power mode.
>  #
> -# @qom_path: path to the CPU object in the QOM tree (since 2.4)
> -#
> -# @thread_id: ID of the underlying host thread
> -#
> -# @props: properties describing to which node/socket/core/thread
> -# virtual CPU belongs to, provided if supported by board (since 2.10)
> -#
>  # @arch: architecture of the cpu, which determines which additional fields
>  #will be listed (since 2.6)
>  #
> -# Since: 0.14.0
> +# Since: 2.13
>  #
>  # Notes: @halted is a transient state that changes frequently.  By the time 
> the
>  #data is sent to the client, the guest may no longer be halted.
> +#Moreover, @arch cannot be moved up to @CpuInfoCommon because
> +#that would prevent its use as the discriminator in @CpuInfo.
> +##
> +{ 'struct' : 'CpuInfoBase',
> +  'base'   : 'CpuInfoCommon',
> +  'data'   : { 'CPU' : 'int',
> +   'current' : 'bool',
> +   'halted'  : 'bool',
> +   'arch': 'CpuInfoArch' } }
> +
> +##
> +# @CpuInfo:
> +#
> +# Information about a virtual CPU
> +#
> +# Since: 0.14.0
>  ##
>  { 'union': 'CpuInfo',
> -  'base': {'CPU': 'int', 'current': 'bool', 'halted': 'bool',
> -   'qom_path': 'str', 'thread_id': 'int',
> -   '*props': 'CpuInstanceProperties', 'arch': 'CpuInfoArch' },
> +  'base': 'CpuInfoBase',
>'discriminator': 'arch',
>'data': { 'x86': 'CpuInfoX86',
>  'sparc': 'CpuInfoSPARC',
>  'ppc': 'CpuInfoPPC',
>  'mips': 'CpuInfoMIPS',
>  'tricore': 'CpuInfoTricore',
>  's390': 'CpuInfoS390',
>  'riscv': 'CpuInfoRISCV',
>  'other': 'CpuInfoOther' } }
>  
>  ##
> @@ -512,70 

Re: [Qemu-devel] [PATCH v3 00/46] fix building of tests/tcg

2018-04-25 Thread Samuel Thibault
Philippe Mathieu-Daudé, le mar. 24 avril 2018 22:25:18 -0300, a ecrit:
> > This is starting to shape up pretty nicely. I was able to add a whole
> > bunch of additional architectures thanks to cross compilers in Debian
> > Sid which are there to support the Debian "ports". These may not be
> > around for ever, most "ports" are on the way out, but they will be the
> > last thing to drop out of the Sid repo. Maybe when Debian stops
> > caring (and no other distro does) maybe we should to?
> 
> I *think* working with Sid is not recommended as very unstable and not
> reproducible. A reproducible way is to use the Debian Snapshot Archive
> (http://snapshot.debian.org/) eventually using package specific version
> and holding packages at this version.
> 
> I found an example in the following post:
> https://blog.sleeplessbeastie.eu/2017/07/17/how-to-install-packages-using-repository-snapshot/
> 
> (I Cc'ed Debian experts who might have a better idea).

That looks like the correct idea :)
(basically what we use to make "releases" of the hurd port, as sid
snapshots).

Samuel



[Qemu-devel] [PATCH v2] checkpatch.pl: add common glib defines to typelist

2018-04-25 Thread Peter Xu
Otherwise it can warn this:

  ERROR: space prohibited between function name and open parenthesis '('

When with things like this:

  typedef gboolean (*it_tree_iterator)(ITValue start, ITValue end);

CC: Paolo Bonzini 
CC: Stefan Hajnoczi 
CC: "Daniel P. Berrangé" 
CC: Markus Armbruster 
CC: Vladimir Sementsov-Ogievskiy 
CC: Fam Zheng 
Signed-off-by: Peter Xu 
---
v2:
- add more missing glib types [Markus]
---
 scripts/checkpatch.pl | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index d52207a3cc..4954150e87 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -266,6 +266,33 @@ our @typeList = (
qr{target_(?:u)?long},
qr{hwaddr},
qr{xml${Ident}},
+   # Glib definitions
+   qr{gchar},
+   qr{gshort},
+   qr{glong},
+   qr{gint},
+   qr{gboolean},
+   qr{guchar},
+   qr{gushort},
+   qr{gulong},
+   qr{guint},
+   qr{gfloat},
+   qr{gdouble},
+   qr{gpointer},
+   qr{gconstpointer},
+   qr{gint8},
+   qr{guint8},
+   qr{gint16},
+   qr{guint16},
+   qr{gint32},
+   qr{guint32},
+   qr{gint64},
+   qr{guint64},
+   qr{gsize},
+   qr{gssize},
+   qr{goffset},
+   qr{gintptr},
+   qr{guintptr},
 );
 
 # This can be modified by sub possible.  Since it can be empty, be careful
-- 
2.14.3




Re: [Qemu-devel] [PATCH 17/19] uninorth: create new uninorth device

2018-04-25 Thread Mark Cave-Ayland

On 25/04/18 07:34, David Gibson wrote:


On Wed, Apr 25, 2018 at 07:06:03AM +0100, Mark Cave-Ayland wrote:

On 06/04/18 06:33, Mark Cave-Ayland wrote:


On 25/03/18 22:11, Mark Cave-Ayland wrote:


Just to follow up on this, I spent a bit looking at what this
register is trying to do and from the Darwin source I can see that
in fact it is simply a hard-wired hardware register which should
return the revision of the UniNorth hardware.

So in fact the code in its current form is completely bogus which is
visible when trying to boot FreeBSD, which as the register is never
written to, returns a completely different random number each time.

David - are you okay to change DEVICE_NATIVE_ENDIAN to
DEVICE_BIG_ENDIAN and then apply this and the final patch to your
for-2.13 queue? I can then follow up with another patch later that
will implement this register (and also the matching PCI revision ID)
correctly.


Ping? I can see that more patches are being added to the for-2.13 branch
so I was just wondering if there is now anything else needed from me in
order to get the last 3 patches from this patchset queued?


Ping again? The reason for asking is because my next set of Mac branches are
all rebased on this patchset since they rely on this, plus the final two
patches in this series which remove the need for qdev_connect_gpio_out()
when wiring up macio devices.


Uh... sorry.  I completely missed this series.  And, apparently, your
earlier ping.  Can you resend, please.  Make sure you explicitly CC
me, I occasionally go through the lists but it's easy for me to miss
stuff there.


No it's okay - you've already got the majority of the patchset applied 
to ppc-for-2.13 (see 
https://lists.gnu.org/archive/html/qemu-devel/2018-03/msg04312.html) but 
it's the last 3 patches which are still missing, presumably because 
Philippe had some questions about them at 
https://lists.gnu.org/archive/html/qemu-devel/2018-03/msg06026.html and 
you queried the DEVICE_NATIVE_ENDIAN at 
https://lists.gnu.org/archive/html/qemu-devel/2018-03/msg05597.html.


If you're happy to consider patch 17 as just code movement and touch it 
up locally to use DEVICE_BIG_ENDIAN rather than have me resend, then 
does that allow the remaining patches 17-19 to be applied to ppc-for-2.13?


Once they are there I can send a follow-up patch which will completely 
remove the original implementation in patch 17 and replace it with a 
proper versioned register, updating the PCI config space to match 
accordingly.


In short: without the follow-up patch the code for the uninorth register 
both before and after patch 17 is wrong regardless of which endian is 
used, so that itself doesn't affect whether or not it can be applied.



ATB,

Mark.



Re: [Qemu-devel] [PATCH] checkpatch.pl: add common glib defines to typelist

2018-04-25 Thread Peter Xu
On Wed, Apr 25, 2018 at 08:08:45AM +0200, Markus Armbruster wrote:
> Peter Xu  writes:
> 
> > Otherwise it can warn this:
> >
> >   ERROR: space prohibited between function name and open parenthesis '('
> >
> > When with things like this:
> >
> >   typedef gboolean (*it_tree_iterator)(ITValue start, ITValue end);
> >
> > CC: Paolo Bonzini 
> > CC: Stefan Hajnoczi 
> > CC: "Daniel P. Berrangé" 
> > CC: Markus Armbruster 
> > CC: Vladimir Sementsov-Ogievskiy 
> > CC: Fam Zheng 
> > Signed-off-by: Peter Xu 
> > ---
> >  scripts/checkpatch.pl | 14 ++
> >  1 file changed, 14 insertions(+)
> >
> > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> > index d52207a3cc..6c25449cd3 100755
> > --- a/scripts/checkpatch.pl
> > +++ b/scripts/checkpatch.pl
> > @@ -266,6 +266,20 @@ our @typeList = (
> > qr{target_(?:u)?long},
> > qr{hwaddr},
> > qr{xml${Ident}},
> > +   # Glib definitions
> > +   qr{gchar},
> > +   qr{gshort},
> > +   qr{glong},
> > +   qr{gint},
> > +   qr{gboolean},
> > +   qr{guchar},
> > +   qr{gushort},
> > +   qr{gulong},
> > +   qr{guint},
> > +   qr{gfloat},
> > +   qr{gdouble},
> > +   qr{gpointer},
> > +   qr{gconstpointer},
> >  );
> >  
> >  # This can be modified by sub possible.  Since it can be empty, be careful
> 
> Personally, I'd kill these with fire, then salt the fields that bore
> them.
> 
> But as long as we have them in our code, checkpatch needs to cope.
> Let's list all types documented in
> .
> Missing:
> 
> gint8
> guint8
> gint16
> guint16
> gint32
> guint32
> gint64
> guint64
> gsize
> gssize
> goffset
> gintptr
> guintptr

I got the old list from the header file (glib/gtypes.h) directly, so I
should go for the document next time!  It's strange that I can hardly
find where is, e.g. gint8, defined.  Anyway, I'm posting a new one.

Thanks!

-- 
Peter Xu



Re: [Qemu-devel] [PATCH 4/6] qapi: change the type of TargetInfo.arch from string to enum SysEmuTarget

2018-04-25 Thread Markus Armbruster
Laszlo Ersek  writes:

> Now that we have @SysEmuTarget, it makes sense to restict
> @TargetInfo.@arch to valid sysemu targets at the schema level.
>
> Cc: "Daniel P. Berrange" 
> Cc: David Gibson 
> Cc: Eric Blake 
> Cc: Gerd Hoffmann 
> Cc: Kashyap Chamarthy 
> Cc: Markus Armbruster 
> Cc: Paolo Bonzini 
> Cc: Thomas Huth 
> Signed-off-by: Laszlo Ersek 
> ---
>
> Notes:
> PATCHv1:
> 
> - qmp_query_target(): pass (-1) as fallback value [Markus]
> - qmp_query_target(): catch lookup error with error_abort [Markus]
> 
> RFCv3:
> 
> - The patch is new in this version. [Markus]
>
>  qapi/misc.json |  6 --
>  arch_init.c| 10 +-
>  2 files changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/qapi/misc.json b/qapi/misc.json
> index 104d013adba6..460866cf542f 100644
> --- a/qapi/misc.json
> +++ b/qapi/misc.json
> @@ -1,18 +1,20 @@
>  # -*- Mode: Python -*-
>  #
>  
>  ##
>  # = Miscellanea
>  ##
>  
> +{ 'include': 'common.json' }
> +
>  ##
>  # @qmp_capabilities:
>  #
>  # Enable QMP capabilities.
>  #
>  # Arguments:
>  #
>  # @enable:   An optional list of QMPCapability values to enable.  The
>  #client must not enable any capability that is not
>  #mentioned in the QMP greeting message.  If the field is not
>  #provided, it means no QMP capabilities will be enabled.
> @@ -2441,28 +2443,28 @@
>  #  ]
>  #}
>  #
>  ##
>  { 'command': 'query-fdsets', 'returns': ['FdsetInfo'] }
>  
>  ##
>  # @TargetInfo:
>  #
>  # Information describing the QEMU target.
>  #
> -# @arch: the target architecture (eg "x86_64", "i386", etc)
> +# @arch: the target architecture
>  #
>  # Since: 1.2.0
>  ##
>  { 'struct': 'TargetInfo',
> -  'data': { 'arch': 'str' } }
> +  'data': { 'arch': 'SysEmuTarget' } }
>  
>  ##
>  # @query-target:
>  #
>  # Return information about the target for this QEMU
>  #
>  # Returns: TargetInfo
>  #
>  # Since: 1.2.0
>  ##
>  { 'command': 'query-target', 'returns': 'TargetInfo' }
> diff --git a/arch_init.c b/arch_init.c
> index 6ee07478bd11..ee3a57019000 100644
> --- a/arch_init.c
> +++ b/arch_init.c
> @@ -21,22 +21,23 @@
>   * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
>   * THE SOFTWARE.
>   */
>  #include "qemu/osdep.h"
>  #include "qemu-common.h"
>  #include "cpu.h"
>  #include "sysemu/sysemu.h"
>  #include "sysemu/arch_init.h"
>  #include "hw/pci/pci.h"
>  #include "hw/audio/soundhw.h"
>  #include "qapi/qapi-commands-misc.h"
> +#include "qapi/error.h"
>  #include "qemu/config-file.h"
>  #include "qemu/error-report.h"
>  #include "hw/acpi/acpi.h"
>  #include "qemu/help_option.h"
>  
>  #ifdef TARGET_SPARC
>  int graphic_width = 1024;
>  int graphic_height = 768;
>  int graphic_depth = 8;
>  #else
>  int graphic_width = 800;
> @@ -104,15 +105,22 @@ int xen_available(void)
>  return 1;
>  #else
>  return 0;
>  #endif
>  }
>  
>  
>  TargetInfo *qmp_query_target(Error **errp)
>  {
>  TargetInfo *info = g_malloc0(sizeof(*info));
>  
> -info->arch = g_strdup(TARGET_NAME);
> +/*
> + * The fallback enum value is irrelevant here (TARGET_NAME is a
> + * macro and can never be NULL), so simply pass (-1). Also, the
> + * lookup should never fail -- if it fails, then @SysEmuTarget needs
> + * extending. Catch that with "error_abort".
> + */
> +info->arch = qapi_enum_parse(_lookup, TARGET_NAME, -1,
> + _abort);
>  
>  return info;
>  }

Not sure the comment is carrying its weight; for me, the use of -1 and
_abort feels obvious enough.  But my feelings are subjective and
could be off.

Reviewed-by: Markus Armbruster 



Re: [Qemu-devel] [PATCH v3 3/4] qdev: Simplify the SysBusDeviceClass::init path

2018-04-25 Thread Yoni Bettan



On 04/20/2018 12:27 AM, Philippe Mathieu-Daudé wrote:

The SysBusDevice is the last DeviceClass::init user.

Instead of using
   SysBusDeviceClass::realize
-> DeviceClass::realize
-> DeviceClass::init
-> sysbus_device_init
   -> SysBusDeviceClass::init

Simplify the path by directly calling SysBusDeviceClass::init
in SysBusDeviceClass::realize:

   SysBusDeviceClass::realize
-> SysBusDeviceClass::init

Finally, remove the DeviceClass::init, there are no more users.

Signed-off-by: Philippe Mathieu-Daudé 
---
  include/hw/qdev-core.h |  2 --
  hw/core/qdev.c | 14 --
  hw/core/sysbus.c   | 15 ++-
  3 files changed, 10 insertions(+), 21 deletions(-)

diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
index 9453588160..6f60748043 100644
--- a/include/hw/qdev-core.h
+++ b/include/hw/qdev-core.h
@@ -29,7 +29,6 @@ typedef enum DeviceCategory {
  DEVICE_CATEGORY_MAX
  } DeviceCategory;
  
-typedef int (*qdev_initfn)(DeviceState *dev);

  typedef int (*qdev_event)(DeviceState *dev);
  typedef void (*DeviceRealize)(DeviceState *dev, Error **errp);
  typedef void (*DeviceUnrealize)(DeviceState *dev, Error **errp);
@@ -124,7 +123,6 @@ typedef struct DeviceClass {
  const struct VMStateDescription *vmsd;
  
  /* Private to qdev / bus.  */

-qdev_initfn init; /* TODO remove, once users are converted to realize */
  qdev_event exit; /* TODO remove, once users are converted to unrealize */
  const char *bus_type;
  } DeviceClass;
diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index f6f92473b8..4153b733c8 100644
--- a/hw/core/qdev.c
+++ b/hw/core/qdev.c
@@ -208,19 +208,6 @@ void device_listener_unregister(DeviceListener *listener)
  QTAILQ_REMOVE(_listeners, listener, link);
  }
  
-static void device_realize(DeviceState *dev, Error **errp)

-{
-DeviceClass *dc = DEVICE_GET_CLASS(dev);
-
-if (dc->init) {
-int rc = dc->init(dev);
-if (rc < 0) {
-error_setg(errp, "Device initialization failed.");
-return;
-}
-}
-}
-
  static void device_unrealize(DeviceState *dev, Error **errp)
  {
  DeviceClass *dc = DEVICE_GET_CLASS(dev);
@@ -1065,7 +1052,6 @@ static void device_class_init(ObjectClass *class, void 
*data)
  DeviceClass *dc = DEVICE_CLASS(class);
  
  class->unparent = device_unparent;

-dc->realize = device_realize;
  dc->unrealize = device_unrealize;
  
  /* by default all devices were considered as hotpluggable,

diff --git a/hw/core/sysbus.c b/hw/core/sysbus.c
index 5d0887f499..11f6d14b84 100644
--- a/hw/core/sysbus.c
+++ b/hw/core/sysbus.c
@@ -18,6 +18,7 @@
   */
  
  #include "qemu/osdep.h"

+#include "qapi/error.h"
  #include "hw/sysbus.h"
  #include "monitor/monitor.h"
  #include "exec/address-spaces.h"
@@ -200,15 +201,19 @@ void sysbus_init_ioports(SysBusDevice *dev, uint32_t 
ioport, uint32_t size)
  }
  }
  
-static int sysbus_device_init(DeviceState *dev)

+static void sysbus_realize(DeviceState *dev, Error **errp)
  {
  SysBusDevice *sd = SYS_BUS_DEVICE(dev);
  SysBusDeviceClass *sbc = SYS_BUS_DEVICE_GET_CLASS(sd);
  
-if (!sbc->init) {

-return 0;


Hello Philippe, is the purpose of this part to enable incremental 
conversion init->realize

to SysBusDevices ?!

Thanks,
Yoni

+/* TODO remove, once users are converted to realize */
+if (sbc->init) {
+int rc = sbc->init(sd);
+if (rc < 0) {
+error_setg(errp, "Device initialization failed.");
+return;
+}
  }
-return sbc->init(sd);
  }
  
  DeviceState *sysbus_create_varargs(const char *name,

@@ -324,7 +329,7 @@ MemoryRegion *sysbus_address_space(SysBusDevice *dev)
  static void sysbus_device_class_init(ObjectClass *klass, void *data)
  {
  DeviceClass *k = DEVICE_CLASS(klass);
-k->init = sysbus_device_init;
+k->realize = sysbus_realize;
  k->bus_type = TYPE_SYSTEM_BUS;
  /*
   * device_add plugs devices into a suitable bus.  For "real" buses,





Re: [Qemu-devel] [PATCH 2/6] qapi: handle the riscv CpuInfoArch in query-cpus-fast

2018-04-25 Thread Markus Armbruster
Laszlo Ersek  writes:

> Commit 25fa194b7b11 added the @riscv enum constant to @CpuInfoArch (used
> in both @CpuInfo and @CpuInfoFast -- the return types of the @query-cpus
> and @query-cpus-fast commands, respectively), and assigned, in both return
> structures, the @CpuInfoRISCV sub-structure to the new enum value.
>
> However, qmp_query_cpus_fast() would not populate either the @arch field
> or the @CpuInfoRISCV sub-structure, when TARGET_RISCV was defined; only
> qmp_query_cpus() would.
>
> In theory, there are two ways to fix this:
>
> (a) Fill in both the @arch field and the @CpuInfoRISCV sub-structure in
> qmp_query_cpus_fast(), by copying the logic from qmp_query_cpus().
>
> (b) Assign @CpuInfoOther to the @riscv enum constant in @CpuInfoFast, and
> populate only the @arch field in qmp_query_cpus_fast().
>
> Approach (b) seems more robust, because:
>
> - clearly there has never been an attempt to get actual RISV CPU state
>   from qmp_query_cpus_fast(), so its lack of RISCV support is not actually
>   a problem,
>
> - getting CPU state without interrupting KVM looks like an exceptional
>   thing to do (only S390X does it currently).
>
> Cc: Bastian Koppelmann 
> Cc: Eric Blake 
> Cc: Laurent Vivier 
> Cc: Markus Armbruster 
> Cc: Michael Clark 
> Cc: Palmer Dabbelt 
> Cc: Paolo Bonzini 
> Cc: Peter Crosthwaite 
> Cc: Richard Henderson 
> Cc: Riku Voipio 
> Cc: Sagar Karandikar 
> Cc: qemu-sta...@nongnu.org
> Fixes: 25fa194b7b11901561532e435beb83d046899f7a
> Signed-off-by: Laszlo Ersek 
> ---
>
> Notes:
> PATCHv1:
> 
> - new patch
>
>  qapi/misc.json | 2 +-
>  cpus.c | 2 ++
>  2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/qapi/misc.json b/qapi/misc.json
> index 5636f4a14997..104d013adba6 100644
> --- a/qapi/misc.json
> +++ b/qapi/misc.json
> @@ -565,23 +565,23 @@
>  { 'union': 'CpuInfoFast',
>'base': {'cpu-index': 'int', 'qom-path': 'str',
> 'thread-id': 'int', '*props': 'CpuInstanceProperties',
> 'arch': 'CpuInfoArch' },
>'discriminator': 'arch',
>'data': { 'x86': 'CpuInfoOther',
>  'sparc': 'CpuInfoOther',
>  'ppc': 'CpuInfoOther',
>  'mips': 'CpuInfoOther',
>  'tricore': 'CpuInfoOther',
>  's390': 'CpuInfoS390',
> -'riscv': 'CpuInfoRISCV',
> +'riscv': 'CpuInfoOther',
>  'other': 'CpuInfoOther' } }

Why do CpuInfoFast's variants match CpuInfo's for s390, but not the
others?  Your commit message has an educated guess: "looks like an
exceptional thing to do (only S390X does it currently)".  But why guess
when we can ask authors of commit ce74ee3dea6?  Luiz and Victor, please
advise.

>  ##
>  # @query-cpus-fast:
>  #
>  # Returns information about all virtual CPUs. This command does not
>  # incur a performance penalty and should be used in production
>  # instead of query-cpus.
>  #
>  # Returns: list of @CpuInfoFast
>  #
> diff --git a/cpus.c b/cpus.c
> index 1a9a2edee1f2..60563a6d54ec 100644
> --- a/cpus.c
> +++ b/cpus.c
> @@ -2225,22 +2225,24 @@ CpuInfoFastList *qmp_query_cpus_fast(Error **errp)
>  #elif defined(TARGET_SPARC)
>  info->value->arch = CPU_INFO_ARCH_SPARC;
>  #elif defined(TARGET_MIPS)
>  info->value->arch = CPU_INFO_ARCH_MIPS;
>  #elif defined(TARGET_TRICORE)
>  info->value->arch = CPU_INFO_ARCH_TRICORE;
>  #elif defined(TARGET_S390X)
>  s390_cpu = S390_CPU(cpu);
>  env = _cpu->env;
>  info->value->arch = CPU_INFO_ARCH_S390;
>  info->value->u.s390.cpu_state = env->cpu_state;
> +#elif defined(TARGET_RISCV)
> +info->value->arch = CPU_INFO_ARCH_RISCV;
>  #else
>  info->value->arch = CPU_INFO_ARCH_OTHER;
>  #endif
>  if (!cur_item) {
>  head = cur_item = info;
>  } else {
>  cur_item->next = info;
>  cur_item = info;
>  }
>  }



Re: [Qemu-devel] [PATCH 1/6] qapi: fill in CpuInfoFast.arch in query-cpus-fast

2018-04-25 Thread Markus Armbruster
Laszlo Ersek  writes:

> Commit ca230ff33f89 added added the @arch field to @CpuInfoFast, but it
> failed to set the new field in qmp_query_cpus_fast(), when TARGET_S390X
> was not defined. The updated @query-cpus-fast example in
> "qapi-schema.json" showed "arch":"x86" only because qmp_query_cpus_fast()
> calls g_malloc0() to allocate CpuInfoFast, and the CPU_INFO_ARCH_X86 enum
> constant is generated with value 0.
>
> All @arch values other than @s390 implied the @CpuInfoOther sub-struct for
> @CpuInfoFast -- at the time of writing the patch --, thus no fields other
> than @arch needed to be set when TARGET_S390X was not defined. Set @arch
> now, by copying the corresponding assignments from qmp_query_cpus().

Now I'm confused.

In the schema, @arch "riscv" implies CpuInfoRISCV:

{ 'union': 'CpuInfoFast',
  'base': {'cpu-index': 'int', 'qom-path': 'str',
   'thread-id': 'int', '*props': 'CpuInstanceProperties',
   'arch': 'CpuInfoArch' },
  'discriminator': 'arch',
  'data': { 'x86': 'CpuInfoOther',
'sparc': 'CpuInfoOther',
'ppc': 'CpuInfoOther',
'mips': 'CpuInfoOther',
'tricore': 'CpuInfoOther',
's390': 'CpuInfoS390',
'riscv': 'CpuInfoRISCV',
'other': 'CpuInfoOther' } }

In qmp_query_cpus_fast(), it can't imply anything, because can't occur.
That's a bug, and this patch fixes it.  Except it sets @arch to "other"
instead of "riscv" when defined(TARGET_RISCV).  Why?  Oh, I see, that
gets fixed in the next patch.  Please explain that in your commit
message, or squash the two patches.  The latter feels simpler, so that's
what I'd do.

>
> Cc: Eric Blake 
> Cc: Markus Armbruster 
> Cc: Paolo Bonzini 
> Cc: Peter Crosthwaite 
> Cc: Richard Henderson 
> Cc: qemu-sta...@nongnu.org
> Fixes: ca230ff33f89bf7102cbfbc2328716da6750aaed
> Signed-off-by: Laszlo Ersek 



Re: [Qemu-devel] [RFC for-2.13 0/7] spapr: Clean up pagesize handling

2018-04-25 Thread David Gibson
On Tue, Apr 24, 2018 at 05:35:59PM +0200, Andrea Bolognani wrote:
> On Fri, 2018-04-20 at 20:21 +1000, David Gibson wrote:
> > On Fri, Apr 20, 2018 at 11:31:10AM +0200, Andrea Bolognani wrote:
> > > I'll have to look into it to be sure, but I think it should be
> > > possible for libvirt to convert a generic
> > > 
> > >   
> > > 
> > >   
> > > 
> > > to a more specific
> > > 
> > >   
> > > 
> > >   
> > > 
> > >   
> > > 
> > > by figuring out the page size for the default hugepage mount,
> > > which actually sounds like a good idea regardless. Of course users
> > > user would still be able to provide the page size themselves in the
> > > first place.
> > 
> > Sounds like a good approach.
> 
> Unfortunately it seems like this is not going to be feasible, as
> POWER8 is apparently the only platform that enforces a strict
> relationship between host page size and guest page size: x86,
> aarch64 (and I have to assume POWER9 as well?) can reportedly all
> deal gracefully with guests migrating between hosts that have
> different hugepage mounts configured.

Yes, that's right.  As you guess POWER9 will also allow this.. at
least as long as the guest is in radix mode.  If the guest is in hash
mode (which includes but isn't limited to POWER8 compat mode guests)
then it will suffer from the same pagesize limitations as POWER8.

> I need to spend some more time digesting the rest of the
> information you provided, but as it stands right now I'm starting
> to think this might actually need to be its own, explicit opt-in
> knob at the libvirt level too after all :(

Poo.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature


Re: [Qemu-devel] [PATCH 17/19] uninorth: create new uninorth device

2018-04-25 Thread David Gibson
On Wed, Apr 25, 2018 at 07:06:03AM +0100, Mark Cave-Ayland wrote:
> On 06/04/18 06:33, Mark Cave-Ayland wrote:
> 
> > On 25/03/18 22:11, Mark Cave-Ayland wrote:
> > 
> > > Just to follow up on this, I spent a bit looking at what this
> > > register is trying to do and from the Darwin source I can see that
> > > in fact it is simply a hard-wired hardware register which should
> > > return the revision of the UniNorth hardware.
> > > 
> > > So in fact the code in its current form is completely bogus which is
> > > visible when trying to boot FreeBSD, which as the register is never
> > > written to, returns a completely different random number each time.
> > > 
> > > David - are you okay to change DEVICE_NATIVE_ENDIAN to
> > > DEVICE_BIG_ENDIAN and then apply this and the final patch to your
> > > for-2.13 queue? I can then follow up with another patch later that
> > > will implement this register (and also the matching PCI revision ID)
> > > correctly.
> > 
> > Ping? I can see that more patches are being added to the for-2.13 branch
> > so I was just wondering if there is now anything else needed from me in
> > order to get the last 3 patches from this patchset queued?
> 
> Ping again? The reason for asking is because my next set of Mac branches are
> all rebased on this patchset since they rely on this, plus the final two
> patches in this series which remove the need for qdev_connect_gpio_out()
> when wiring up macio devices.

Uh... sorry.  I completely missed this series.  And, apparently, your
earlier ping.  Can you resend, please.  Make sure you explicitly CC
me, I occasionally go through the lists but it's easy for me to miss
stuff there.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature


[Qemu-devel] [Bug 1755912] Re: qemu-system-x86_64 crashed with SIGABRT when using option -vga qxl

2018-04-25 Thread ChristianEhrhardt
The bug traces so far had no private information, so I opened up the
state to be visible to everyone.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1755912

Title:
  qemu-system-x86_64 crashed with SIGABRT when using option -vga qxl

Status in QEMU:
  New
Status in qemu package in Ubuntu:
  Confirmed

Bug description:
  When using qemu-system-x86_64 with the option -vga qxl, it crashes.
  The easiest way to crash it is by trying to change the guest's
  resolution. However, the system may randomly crash too, not happening
  only when changing resolution. Here is the terminal output of one of
  these random crashes:

  

  $ qemu-system-x86_64 -hda /dev/sdb -m 2048 -enable-kvm -cpu host -vga qxl 
-nodefaults -netdev user,id=hostnet0 -device 
virtio-net-pci,id=net0,netdev=hostnet0
  WARNING: Image format was not specified for '/dev/sdb' and probing guessed 
raw.
   Automatically detecting the format is dangerous for raw images, 
write operations on block 0 will be restricted.
   Specify the 'raw' format explicitly to remove the restrictions.

  (process:21313): Spice-WARNING **: 16:01:45.759: display-
  channel.c:2431:display_channel_validate_surface: canvas address is
  0x7f8eb948ab18 for 0 (and is NULL)

  
  (process:21313): Spice-WARNING **: 16:01:45.759: 
display-channel.c:2432:display_channel_validate_surface: failed on 0

  (process:21313): Spice-CRITICAL **: 16:01:45.759: 
display-channel.c:2035:display_channel_update: condition 
`display_channel_validate_surface(display, surface_id)' failed
  Abortado (imagem do núcleo gravada)

  

  I was running QEMU as a normal user which is on the groups kvm and
  disk. Initially I supposed the problem was because I was running QEMU
  as root, but as a normal user this happens too.

  I have tested with guests with different Ubuntu version: 18.04, 17.10
  and 16.04. It is happening with them all.

  ProblemType: Crash
  DistroRelease: Ubuntu 18.04
  Package: qemu-system-x86 1:2.11+dfsg-1ubuntu4
  ProcVersionSignature: Ubuntu 4.15.0-10.11-generic 4.15.3
  Uname: Linux 4.15.0-10-generic x86_64
  ApportVersion: 2.20.8-0ubuntu10
  Architecture: amd64
  CurrentDesktop: XFCE
  Date: Wed Mar 14 17:13:52 2018
  ExecutablePath: /usr/bin/qemu-system-x86_64
  InstallationDate: Installed on 2017-06-13 (273 days ago)
  InstallationMedia: Xubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412)
  KvmCmdLine: COMMAND STAT  EUID  RUID   PID  PPID %CPU COMMAND
  MachineType: LENOVO 80UG
  ProcCmdline: qemu-system-x86_64 -hda /dev/sdb -smp cpus=2 -m 512 -enable-kvm 
-cpu host -vga qxl -nodefaults -netdev user,id=hostnet0 -device 
virtio-net-pci,id=net0,netdev=hostnet0
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-10-generic.efi.signed 
root=UUID=6b4ae5c0-c78c-49a6-a1ba-029192618a7a ro quiet
  Signal: 6
  SourcePackage: qemu
  StacktraceTop:
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
  Title: qemu-system-x86_64 crashed with SIGABRT
  UpgradeStatus: Upgraded to bionic on 2017-10-20 (145 days ago)
  UserGroups: adm bluetooth cdrom dialout dip disk kvm libvirt lpadmin netdev 
plugdev sambashare sudo
  dmi.bios.date: 07/10/2017
  dmi.bios.vendor: LENOVO
  dmi.bios.version: 0XCN43WW
  dmi.board.asset.tag: NO Asset Tag
  dmi.board.name: Toronto 4A2
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0J40679 WIN
  dmi.chassis.asset.tag: NO Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Lenovo ideapad 310-14ISK
  dmi.modalias: 
dmi:bvnLENOVO:bvr0XCN43WW:bd07/10/2017:svnLENOVO:pn80UG:pvrLenovoideapad310-14ISK:rvnLENOVO:rnToronto4A2:rvrSDK0J40679WIN:cvnLENOVO:ct10:cvrLenovoideapad310-14ISK:
  dmi.product.family: IDEAPAD
  dmi.product.name: 80UG
  dmi.product.version: Lenovo ideapad 310-14ISK
  dmi.sys.vendor: LENOVO

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1755912/+subscriptions



[Qemu-devel] [Bug 1755912] Re: qemu-system-x86_64 crashed with SIGABRT when using option -vga qxl

2018-04-25 Thread ChristianEhrhardt
Thanks Leonardo, with that confirmed:
- not dependent on the guest distribution
- affecting latest upstream
- good logs on the crash

The videos are not needed but nice to proove your case (just as my pre-
analysis of the code path is nice but likely not useful to a developer
that regularly works on that code sections).

Overall this should really be ready for upstreams attention, I added a
Qemu task which will auto mirror this to the Mailing list.

** Also affects: qemu
   Importance: Undecided
   Status: New

** Changed in: qemu (Ubuntu)
   Status: Incomplete => Confirmed

** Information type changed from Private to Public

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1755912

Title:
  qemu-system-x86_64 crashed with SIGABRT when using option -vga qxl

Status in QEMU:
  New
Status in qemu package in Ubuntu:
  Confirmed

Bug description:
  When using qemu-system-x86_64 with the option -vga qxl, it crashes.
  The easiest way to crash it is by trying to change the guest's
  resolution. However, the system may randomly crash too, not happening
  only when changing resolution. Here is the terminal output of one of
  these random crashes:

  

  $ qemu-system-x86_64 -hda /dev/sdb -m 2048 -enable-kvm -cpu host -vga qxl 
-nodefaults -netdev user,id=hostnet0 -device 
virtio-net-pci,id=net0,netdev=hostnet0
  WARNING: Image format was not specified for '/dev/sdb' and probing guessed 
raw.
   Automatically detecting the format is dangerous for raw images, 
write operations on block 0 will be restricted.
   Specify the 'raw' format explicitly to remove the restrictions.

  (process:21313): Spice-WARNING **: 16:01:45.759: display-
  channel.c:2431:display_channel_validate_surface: canvas address is
  0x7f8eb948ab18 for 0 (and is NULL)

  
  (process:21313): Spice-WARNING **: 16:01:45.759: 
display-channel.c:2432:display_channel_validate_surface: failed on 0

  (process:21313): Spice-CRITICAL **: 16:01:45.759: 
display-channel.c:2035:display_channel_update: condition 
`display_channel_validate_surface(display, surface_id)' failed
  Abortado (imagem do núcleo gravada)

  

  I was running QEMU as a normal user which is on the groups kvm and
  disk. Initially I supposed the problem was because I was running QEMU
  as root, but as a normal user this happens too.

  I have tested with guests with different Ubuntu version: 18.04, 17.10
  and 16.04. It is happening with them all.

  ProblemType: Crash
  DistroRelease: Ubuntu 18.04
  Package: qemu-system-x86 1:2.11+dfsg-1ubuntu4
  ProcVersionSignature: Ubuntu 4.15.0-10.11-generic 4.15.3
  Uname: Linux 4.15.0-10-generic x86_64
  ApportVersion: 2.20.8-0ubuntu10
  Architecture: amd64
  CurrentDesktop: XFCE
  Date: Wed Mar 14 17:13:52 2018
  ExecutablePath: /usr/bin/qemu-system-x86_64
  InstallationDate: Installed on 2017-06-13 (273 days ago)
  InstallationMedia: Xubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412)
  KvmCmdLine: COMMAND STAT  EUID  RUID   PID  PPID %CPU COMMAND
  MachineType: LENOVO 80UG
  ProcCmdline: qemu-system-x86_64 -hda /dev/sdb -smp cpus=2 -m 512 -enable-kvm 
-cpu host -vga qxl -nodefaults -netdev user,id=hostnet0 -device 
virtio-net-pci,id=net0,netdev=hostnet0
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-10-generic.efi.signed 
root=UUID=6b4ae5c0-c78c-49a6-a1ba-029192618a7a ro quiet
  Signal: 6
  SourcePackage: qemu
  StacktraceTop:
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
   () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
  Title: qemu-system-x86_64 crashed with SIGABRT
  UpgradeStatus: Upgraded to bionic on 2017-10-20 (145 days ago)
  UserGroups: adm bluetooth cdrom dialout dip disk kvm libvirt lpadmin netdev 
plugdev sambashare sudo
  dmi.bios.date: 07/10/2017
  dmi.bios.vendor: LENOVO
  dmi.bios.version: 0XCN43WW
  dmi.board.asset.tag: NO Asset Tag
  dmi.board.name: Toronto 4A2
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0J40679 WIN
  dmi.chassis.asset.tag: NO Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Lenovo ideapad 310-14ISK
  dmi.modalias: 
dmi:bvnLENOVO:bvr0XCN43WW:bd07/10/2017:svnLENOVO:pn80UG:pvrLenovoideapad310-14ISK:rvnLENOVO:rnToronto4A2:rvrSDK0J40679WIN:cvnLENOVO:ct10:cvrLenovoideapad310-14ISK:
  dmi.product.family: IDEAPAD
  dmi.product.name: 80UG
  dmi.product.version: Lenovo ideapad 310-14ISK
  dmi.sys.vendor: LENOVO

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1755912/+subscriptions



Re: [Qemu-devel] [PATCH v4] loader: Fix misaligned member access

2018-04-25 Thread David Gibson
On Tue, Apr 24, 2018 at 07:21:03PM -0300, Philippe Mathieu-Daudé wrote:
> The libfdt does not guarantee than fdt_getprop() returns a pointer
> aligned to the property size.
> 
> Assuming the base of the fdt is aligned, a 32-bit property returns
> a 32-bit aligned pointer. This is however not guaranteed for 64-bit
> properties, where 64-bit loads might trigger unaligned access.
> 
> Fix the 64-bit access using the ldst (host) API, which uses a local
> copy on the stack, thus guaranteeing a safe aligned access.
> 
> This fixes the following ASan warning:
> 
>   $ qemu-system-mips64el -M boston -kernel vmlinux.gz.itb -nographic
>   hw/core/loader-fit.c:108:17: runtime error: load of misaligned address 
> 0x7f95cd7e4264 for type 'fdt64_t', which requires 8 byte alignment
>   0x7f95cd7e4264: note: pointer points here
> 00 00 00 3e ff ff ff ff  80 7d 2a c0 00 00 00 01  68 61 73 68 40 30 00 00 
>  00 00 00 03 00 00 00 14
> ^
> 
> Reported-by: AddressSanitizer
> Suggested-by: Peter Maydell 
> Signed-off-by: Philippe Mathieu-Daudé 

Reviewed-by: David Gibson 

I'll look at adding a hlper for this to libfdt, but no promises on timeframe.

> ---
> v4: do not change the 32-bit access, use ldq_he_p() for the 64-bit access
> v3: do not use memcpy(), incorrectly change ldl_he_p()
> v2: do not change the 32-bit access, use memcpy(), add comments (David Gibson)
> v1: use memcpy()
> 
>  hw/core/loader-fit.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/core/loader-fit.c b/hw/core/loader-fit.c
> index 0c4a7207f4..ed4140061b 100644
> --- a/hw/core/loader-fit.c
> +++ b/hw/core/loader-fit.c
> @@ -102,10 +102,17 @@ static int fit_image_addr(const void *itb, int img, 
> const char *name,
>  
>  switch (len) {
>  case 4:
> +/* Assuming the base of the fdt is aligned, then fdt_getprop()
> + * returns 32-bit aligned properties, so this load is guaranteed
> + * to be 32-bit aligned.
> + */
>  *addr = fdt32_to_cpu(*(fdt32_t *)prop);
>  return 0;
>  case 8:
> -*addr = fdt64_to_cpu(*(fdt64_t *)prop);
> +/* Since the property is not guaranteed to be 64-bit aligned,
> + * use ldq_he_p()'s stack to avoid an unaligned load.
> + */
> +*addr = fdt64_to_cpu(ldq_he_p(prop));
>  return 0;
>  default:
>  error_printf("invalid %s address length %d\n", name, len);

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature


Re: [Qemu-devel] [PATCH] checkpatch.pl: add common glib defines to typelist

2018-04-25 Thread Markus Armbruster
Peter Xu  writes:

> Otherwise it can warn this:
>
>   ERROR: space prohibited between function name and open parenthesis '('
>
> When with things like this:
>
>   typedef gboolean (*it_tree_iterator)(ITValue start, ITValue end);
>
> CC: Paolo Bonzini 
> CC: Stefan Hajnoczi 
> CC: "Daniel P. Berrangé" 
> CC: Markus Armbruster 
> CC: Vladimir Sementsov-Ogievskiy 
> CC: Fam Zheng 
> Signed-off-by: Peter Xu 
> ---
>  scripts/checkpatch.pl | 14 ++
>  1 file changed, 14 insertions(+)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index d52207a3cc..6c25449cd3 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -266,6 +266,20 @@ our @typeList = (
>   qr{target_(?:u)?long},
>   qr{hwaddr},
>   qr{xml${Ident}},
> + # Glib definitions
> + qr{gchar},
> + qr{gshort},
> + qr{glong},
> + qr{gint},
> + qr{gboolean},
> + qr{guchar},
> + qr{gushort},
> + qr{gulong},
> + qr{guint},
> + qr{gfloat},
> + qr{gdouble},
> + qr{gpointer},
> + qr{gconstpointer},
>  );
>  
>  # This can be modified by sub possible.  Since it can be empty, be careful

Personally, I'd kill these with fire, then salt the fields that bore
them.

But as long as we have them in our code, checkpatch needs to cope.
Let's list all types documented in
.
Missing:

gint8
guint8
gint16
guint16
gint32
guint32
gint64
guint64
gsize
gssize
goffset
gintptr
guintptr



Re: [Qemu-devel] [PATCH 17/19] uninorth: create new uninorth device

2018-04-25 Thread Mark Cave-Ayland

On 06/04/18 06:33, Mark Cave-Ayland wrote:


On 25/03/18 22:11, Mark Cave-Ayland wrote:

Just to follow up on this, I spent a bit looking at what this register 
is trying to do and from the Darwin source I can see that in fact it 
is simply a hard-wired hardware register which should return the 
revision of the UniNorth hardware.


So in fact the code in its current form is completely bogus which is 
visible when trying to boot FreeBSD, which as the register is never 
written to, returns a completely different random number each time.


David - are you okay to change DEVICE_NATIVE_ENDIAN to 
DEVICE_BIG_ENDIAN and then apply this and the final patch to your 
for-2.13 queue? I can then follow up with another patch later that 
will implement this register (and also the matching PCI revision ID) 
correctly.


Ping? I can see that more patches are being added to the for-2.13 branch 
so I was just wondering if there is now anything else needed from me in 
order to get the last 3 patches from this patchset queued?


Ping again? The reason for asking is because my next set of Mac branches 
are all rebased on this patchset since they rely on this, plus the final 
two patches in this series which remove the need for 
qdev_connect_gpio_out() when wiring up macio devices.



ATB,

Mark.



<    1   2   3   4