[Qemu-devel] [PATCH v2] net/slirp: Tell the users when they are using deprecated options

[Thomas Huth]

We don't want to support the legacy -tftp, -bootp, -smb and
-net channel options forever. So let's start telling the users
that they are deprecated and what option should be used instead.

Signed-off-by: Thomas Huth 
---
 v2: Changed the texts to tell the users what options should be used instead.

 net/slirp.c | 3 +++
 os-posix.c  | 3 +++
 vl.c| 6 ++
 3 files changed, 12 insertions(+)

diff --git a/net/slirp.c b/net/slirp.c
index f505570..eac4fc2 100644
--- a/net/slirp.c
+++ b/net/slirp.c
@@ -784,6 +784,9 @@ int net_slirp_parse_legacy(QemuOptsList *opts_list, const 
char *optarg, int *ret
 return 0;
 }
 
+error_report("The '-net channel' option is deprecated. "
+ "Please use '-netdev user,guestfwd=...' instead.");
+
 /* handle legacy -net channel,port:chr */
 optarg += strlen("channel,");
 
diff --git a/os-posix.c b/os-posix.c
index e4da406..87e2a16 100644
--- a/os-posix.c
+++ b/os-posix.c
@@ -40,6 +40,7 @@
 #include "net/slirp.h"
 #include "qemu-options.h"
 #include "qemu/rcu.h"
+#include "qemu/error-report.h"
 
 #ifdef CONFIG_LINUX
 #include 
@@ -139,6 +140,8 @@ void os_parse_cmd_args(int index, const char *optarg)
 switch (index) {
 #ifdef CONFIG_SLIRP
 case QEMU_OPTION_smb:
+error_report("The -smb option is deprecated. "
+ "Please use '-netdev user,smb=...' instead.");
 if (net_slirp_smb(optarg) < 0)
 exit(1);
 break;
diff --git a/vl.c b/vl.c
index 5aaea77..71c4eee 100644
--- a/vl.c
+++ b/vl.c
@@ -3314,12 +3314,18 @@ int main(int argc, char **argv, char **envp)
 #endif
 #ifdef CONFIG_SLIRP
 case QEMU_OPTION_tftp:
+error_report("The -tftp option is deprecated. "
+ "Please use '-netdev user,tftp=...' instead.");
 legacy_tftp_prefix = optarg;
 break;
 case QEMU_OPTION_bootp:
+error_report("The -bootp option is deprecated. "
+ "Please use '-netdev user,bootfile=...' 
instead.");
 legacy_bootp_filename = optarg;
 break;
 case QEMU_OPTION_redir:
+error_report("The -redir option is deprecated. "
+ "Please use '-netdev user,hostfwd=...' instead.");
 if (net_slirp_redir(optarg) < 0)
 exit(1);
 break;
-- 
1.8.3.1

Re: [Qemu-devel] [PATCH 06/10] qemu-img: Prepare for locked images

[Markus Armbruster]

Kevin Wolf  writes:

> Am 12.01.2016 um 16:20 hat Markus Armbruster geschrieben:
>> Kevin Wolf  writes:
>> 
>> > Am 11.01.2016 um 16:49 hat Markus Armbruster geschrieben:
>> >> Eric Blake  writes:
>> >> 
>> >> > On 12/22/2015 09:46 AM, Kevin Wolf wrote:
>> >> >> This patch extends qemu-img for working with locked images. It prints a
>> >> >> helpful error message when trying to access a locked image read-write,
>> >> >> and adds a 'qemu-img force-unlock' command as well as a 'qemu-img check
>> >> >> -r all --force' option in order to override a lock left behind after a
>> >> >> qemu crash.
>> >> >> 
>> >> >> Signed-off-by: Kevin Wolf 
>> >> >> ---
>> >> >>  include/block/block.h |  1 +
>> >> >>  include/qapi/error.h  |  1 +
>> >> >>  qapi/common.json  |  3 +-
>> >> >>  qemu-img-cmds.hx  | 10 --
>> >> >>  qemu-img.c | 96
>> >> >> +++
>> >> >>  qemu-img.texi | 20 ++-
>> >> >>  6 files changed, 113 insertions(+), 18 deletions(-)
>> >> >> 
>> >> >
>> >> >> +++ b/include/qapi/error.h
>> >> >> @@ -102,6 +102,7 @@ typedef enum ErrorClass {
>> >> >>  ERROR_CLASS_DEVICE_NOT_ACTIVE = QAPI_ERROR_CLASS_DEVICENOTACTIVE,
>> >> >>  ERROR_CLASS_DEVICE_NOT_FOUND = QAPI_ERROR_CLASS_DEVICENOTFOUND,
>> >> >>  ERROR_CLASS_KVM_MISSING_CAP = QAPI_ERROR_CLASS_KVMMISSINGCAP,
>> >> >> +ERROR_CLASS_IMAGE_FILE_LOCKED = QAPI_ERROR_CLASS_IMAGEFILELOCKED,
>> >> >>  } ErrorClass;
>> >> >
>> >> > Wow - a new ErrorClass.  It's been a while since we could justify one of
>> >> > these, but I think you might have found a case.
>> >> 
>> >> Spell out the rationale for the new ErrorClass, please.
>> >
>> > Action to be taken for this error class: Decide whether the lock is a
>> > leftover from a previous qemu run that ended in an unclean shutdown. If
>> > so, retry with overriding the lock.
>> >
>> > Currently used by qemu-img when ordered to override a lock. libvirt
>> > will need to do the same.
>> 
>> Let's see whether I understand the intended use:
>> 
>> open image
>> if open fails with ImageFileLocked:
>> guess whether the lock is stale
>> if guessing not stale:
>> error out
>> open image with lock override
>> 
>> Correct?
>
> Yes. Where "guess" is more or less "check whether the management tool
> started qemu with this image, but didn't cleanly shut it down". This can
> guess wrong if, and only if, some other user used a different algorithm
> and forced an unlock even though the image didn't belong to them before
> the crash.
>
>> Obvious troublespots:
>> 
>> 1. If you guess wrong, you destroy the image.  No worse than before, so
>>okay, declare documentation problem.
>> 
>> 2. TOCTTOU open to open with lock override
>>[...]
>> 
>> 3. TOCTTOU within open (hypothetical, haven't read your code)
>>[...]
>
> Yes, these exist in theory. The question is what scenarios you want to
> protect against and whether improving the mechanism to cover these cases
> is worth the effort.
>
> The answer for what I wanted to protect is a manual action on an image
> that is already in use. The user isn't quick enough to manually let two
> processes open the same image at the same time, so I didn't consider
> that scenario relevant.
>
> But assuming that everyone (including the human user) follows the above
> protocol (force-unlock only what was yours before the crash), at least
> cases 1 and 2 don't happen anyway.

"Force-unlock only what you locked yourself" is easier to stipulate than
to adhere to when the tools can't give you a hint on who did the
locking.  This is particularly true when "you" is a human, with human
imperfect memory.

I understand that this locking can't provide complete protection, and
merely aims to catch certain common accidents.

However, to avoid a false sense of security, its limitations need to be
clearly documented.  This very much includes the rule "force-unlock only
what you locked yourself".  In my opinion, it should also include the
raciness.

Sometimes, solving a problem is easier than documenting it.

>> Let me try a different tack.  It may well be unworkable.
>> [...]
>
> It doesn't sound unworkable, but it might be overengineered if the goal
> is just to protect people against 'qemu-img snapshot' on running VMs.
>
>> Obviously, the management application will also need to be able to
>> override stale locks from opens by someone else, say a human user
>> bypassing the management application.
>
> That's not obvious. If another user messed it up, this other user can
> also clean it up. But yes, asking a higher level would work, too.
>
> Kevin

Re: [Qemu-devel] [PATCH v2 2/2] iotests: Test that negative throttle values are rejected

[Alberto Garcia]

On Wed 13 Jan 2016 01:52:30 AM CET, Fam Zheng  wrote:

> +echo === Catching nagative throttling values ===

s/nagative/negative/

(there are several of these in the patch)

You could also test the upper limits now.

Berto

[Qemu-devel] [PULL 1/6] migration: Export migrate_set_state()

[Amit Shah]

From: zhanghailiang 

Change the first parameter of migrate_set_state(), and export it.
We will use it in a later patch to update incoming state.

Signed-off-by: zhanghailiang 
Reviewed-by: Dr. David Alan Gilbert 

dgilbert: Updated comment as per Juan's review
Message-Id: <1450266458-3178-2-git-send-email-dgilb...@redhat.com>
Reviewed-by: Juan Quintela 
Reviewed-by: Amit Shah 
Signed-off-by: Amit Shah 
---
 include/migration/migration.h |  2 ++
 migration/migration.c | 36 +---
 2 files changed, 23 insertions(+), 15 deletions(-)

diff --git a/include/migration/migration.h b/include/migration/migration.h
index d9494b8..a64ca7c 100644
--- a/include/migration/migration.h
+++ b/include/migration/migration.h
@@ -169,6 +169,8 @@ struct MigrationState
 RAMBlock *last_req_rb;
 };
 
+void migrate_set_state(int *state, int old_state, int new_state);
+
 void process_incoming_migration(QEMUFile *f);
 
 void qemu_start_incoming_migration(const char *uri, Error **errp);
diff --git a/migration/migration.c b/migration/migration.c
index c842499..5db6227 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -787,9 +787,9 @@ void qmp_migrate_start_postcopy(Error **errp)
 
 /* shared migration helpers */
 
-static void migrate_set_state(MigrationState *s, int old_state, int new_state)
+void migrate_set_state(int *state, int old_state, int new_state)
 {
-if (atomic_cmpxchg(>state, old_state, new_state) == old_state) {
+if (atomic_cmpxchg(state, old_state, new_state) == old_state) {
 trace_migrate_set_state(new_state);
 migrate_generate_event(new_state);
 }
@@ -822,7 +822,7 @@ static void migrate_fd_cleanup(void *opaque)
(s->state != MIGRATION_STATUS_POSTCOPY_ACTIVE));
 
 if (s->state == MIGRATION_STATUS_CANCELLING) {
-migrate_set_state(s, MIGRATION_STATUS_CANCELLING,
+migrate_set_state(>state, MIGRATION_STATUS_CANCELLING,
   MIGRATION_STATUS_CANCELLED);
 }
 
@@ -833,7 +833,8 @@ void migrate_fd_error(MigrationState *s)
 {
 trace_migrate_fd_error();
 assert(s->file == NULL);
-migrate_set_state(s, MIGRATION_STATUS_SETUP, MIGRATION_STATUS_FAILED);
+migrate_set_state(>state, MIGRATION_STATUS_SETUP,
+  MIGRATION_STATUS_FAILED);
 notifier_list_notify(_state_notifiers, s);
 }
 
@@ -853,7 +854,7 @@ static void migrate_fd_cancel(MigrationState *s)
 if (!migration_is_setup_or_active(old_state)) {
 break;
 }
-migrate_set_state(s, old_state, MIGRATION_STATUS_CANCELLING);
+migrate_set_state(>state, old_state, MIGRATION_STATUS_CANCELLING);
 } while (s->state != MIGRATION_STATUS_CANCELLING);
 
 /*
@@ -927,7 +928,7 @@ MigrationState *migrate_init(const MigrationParams *params)
 s->migration_thread_running = false;
 s->last_req_rb = NULL;
 
-migrate_set_state(s, MIGRATION_STATUS_NONE, MIGRATION_STATUS_SETUP);
+migrate_set_state(>state, MIGRATION_STATUS_NONE, 
MIGRATION_STATUS_SETUP);
 
 QSIMPLEQ_INIT(>src_page_requests);
 
@@ -1026,7 +1027,8 @@ void qmp_migrate(const char *uri, bool has_blk, bool blk,
 } else {
 error_setg(errp, QERR_INVALID_PARAMETER_VALUE, "uri",
"a valid migration protocol");
-migrate_set_state(s, MIGRATION_STATUS_SETUP, MIGRATION_STATUS_FAILED);
+migrate_set_state(>state, MIGRATION_STATUS_SETUP,
+  MIGRATION_STATUS_FAILED);
 return;
 }
 
@@ -1405,7 +1407,7 @@ static int postcopy_start(MigrationState *ms, bool 
*old_vm_running)
 int ret;
 const QEMUSizedBuffer *qsb;
 int64_t time_at_stop = qemu_clock_get_ms(QEMU_CLOCK_REALTIME);
-migrate_set_state(ms, MIGRATION_STATUS_ACTIVE,
+migrate_set_state(>state, MIGRATION_STATUS_ACTIVE,
   MIGRATION_STATUS_POSTCOPY_ACTIVE);
 
 trace_postcopy_start();
@@ -1496,7 +1498,7 @@ static int postcopy_start(MigrationState *ms, bool 
*old_vm_running)
 ret = qemu_file_get_error(ms->file);
 if (ret) {
 error_report("postcopy_start: Migration stream errored");
-migrate_set_state(ms, MIGRATION_STATUS_POSTCOPY_ACTIVE,
+migrate_set_state(>state, MIGRATION_STATUS_POSTCOPY_ACTIVE,
   MIGRATION_STATUS_FAILED);
 }
 
@@ -1505,7 +1507,7 @@ static int postcopy_start(MigrationState *ms, bool 
*old_vm_running)
 fail_closefb:
 qemu_fclose(fb);
 fail:
-migrate_set_state(ms, MIGRATION_STATUS_POSTCOPY_ACTIVE,
+migrate_set_state(>state, MIGRATION_STATUS_POSTCOPY_ACTIVE,
   MIGRATION_STATUS_FAILED);
 qemu_mutex_unlock_iothread();
 return -1;
@@ -1574,11 +1576,13 @@ static void migration_completion(MigrationState *s, int 
current_active_state,
 goto fail;
 }
 
-

[Qemu-devel] [PULL 3/6] Postcopy: Send events/change state on incoming side

[Amit Shah]

From: "Dr. David Alan Gilbert" 

I missed the calls to send migration events on the destination side
as we enter postcopy.
Take care when adding them not to do it after state has been freed.

Signed-off-by: Dr. David Alan Gilbert 
Reviewed-by: zhanghailiang 
Reviewed-by: Juan Quintela 
Reviewed-by: Amit Shah 
Message-Id: <1450266458-3178-4-git-send-email-dgilb...@redhat.com>
Signed-off-by: Amit Shah 
---
 migration/savevm.c | 22 +++---
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/migration/savevm.c b/migration/savevm.c
index 0ad1b93..c469bad 100644
--- a/migration/savevm.c
+++ b/migration/savevm.c
@@ -1399,6 +1399,8 @@ static void *postcopy_ram_listen_thread(void *opaque)
 MigrationIncomingState *mis = migration_incoming_get_current();
 int load_res;
 
+migrate_set_state(>state, MIGRATION_STATUS_ACTIVE,
+   MIGRATION_STATUS_POSTCOPY_ACTIVE);
 qemu_sem_post(>listen_thread_sem);
 trace_postcopy_ram_listen_thread_start();
 
@@ -1415,6 +1417,8 @@ static void *postcopy_ram_listen_thread(void *opaque)
 if (load_res < 0) {
 error_report("%s: loadvm failed: %d", __func__, load_res);
 qemu_file_set_error(f, load_res);
+migrate_set_state(>state, MIGRATION_STATUS_POSTCOPY_ACTIVE,
+   MIGRATION_STATUS_FAILED);
 } else {
 /*
  * This looks good, but it's possible that the device loading in the
@@ -1424,13 +1428,6 @@ static void *postcopy_ram_listen_thread(void *opaque)
 qemu_event_wait(>main_thread_load_event);
 }
 postcopy_ram_incoming_cleanup(mis);
-/*
- * If everything has worked fine, then the main thread has waited
- * for us to start, and we're the last use of the mis.
- * (If something broke then qemu will have to exit anyway since it's
- * got a bad migration state).
- */
-migration_incoming_state_destroy();
 
 if (load_res < 0) {
 /*
@@ -1442,6 +1439,17 @@ static void *postcopy_ram_listen_thread(void *opaque)
 exit(EXIT_FAILURE);
 }
 
+migrate_set_state(>state, MIGRATION_STATUS_POSTCOPY_ACTIVE,
+   MIGRATION_STATUS_COMPLETED);
+/*
+ * If everything has worked fine, then the main thread has waited
+ * for us to start, and we're the last use of the mis.
+ * (If something broke then qemu will have to exit anyway since it's
+ * got a bad migration state).
+ */
+migration_incoming_state_destroy();
+
+
 return NULL;
 }
 
-- 
2.5.0

[Qemu-devel] [PULL 4/6] Migration: Emit event at start of pass

[Amit Shah]

From: "Dr. David Alan Gilbert" 

Emit an event each time we sync the dirty bitmap on the source;
this helps libvirt use postcopy by giving it a kick when it
might be a good idea to start the postcopy.

Signed-off-by: Dr. David Alan Gilbert 
Reviewed-by: Juan Quintela 
Reviewed-by: Eric Blake 
Reviewed-by: Amit Shah 
Message-Id: <1450266458-3178-5-git-send-email-dgilb...@redhat.com>
Signed-off-by: Amit Shah 
---
 docs/qmp-events.txt | 14 ++
 migration/ram.c |  4 
 qapi/event.json | 13 +
 3 files changed, 31 insertions(+)

diff --git a/docs/qmp-events.txt b/docs/qmp-events.txt
index d2f1ce4..52eb7e2 100644
--- a/docs/qmp-events.txt
+++ b/docs/qmp-events.txt
@@ -496,6 +496,20 @@ Example:
 {"timestamp": {"seconds": 1432121972, "microseconds": 744001},
  "event": "MIGRATION", "data": {"status": "completed"}}
 
+MIGRATION_PASS
+--
+
+Emitted from the source side of a migration at the start of each pass
+(when it syncs the dirty bitmap)
+
+Data: None.
+
+  - "pass": An incrementing count (starting at 1 on the first pass)
+
+Example:
+{"timestamp": {"seconds": 1449669631, "microseconds": 239225},
+ "event": "MIGRATION_PASS", "data": {"pass": 2}}
+
 STOP
 
 
diff --git a/migration/ram.c b/migration/ram.c
index 0490f00..102d1f2 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -27,6 +27,7 @@
  */
 #include 
 #include 
+#include "qapi-event.h"
 #include "qemu/bitops.h"
 #include "qemu/bitmap.h"
 #include "qemu/timer.h"
@@ -682,6 +683,9 @@ static void migration_bitmap_sync(void)
 num_dirty_pages_period = 0;
 }
 s->dirty_sync_count = bitmap_sync_count;
+if (migrate_use_events()) {
+qapi_event_send_migration_pass(bitmap_sync_count, NULL);
+}
 }
 
 /**
diff --git a/qapi/event.json b/qapi/event.json
index f0cef01..390fd45 100644
--- a/qapi/event.json
+++ b/qapi/event.json
@@ -255,6 +255,19 @@
   'data': {'status': 'MigrationStatus'}}
 
 ##
+# @MIGRATION_PASS
+#
+# Emitted from the source side of a migration at the start of each pass
+# (when it syncs the dirty bitmap)
+#
+# @pass: An incrementing count (starting at 1 on the first pass)
+#
+# Since: 2.6
+##
+{ 'event': 'MIGRATION_PASS',
+  'data': { 'pass': 'int' } }
+
+##
 # @ACPI_DEVICE_OST
 #
 # Emitted when guest executes ACPI _OST method.
-- 
2.5.0

[Qemu-devel] [PULL 0/6] migration fixes

[Amit Shah]

The following changes since commit 649a1bbaf95adb228f1030ab0618a932bc26aa8b:

  Merge remote-tracking branch 'remotes/kvaneesh/tags/for-upstream-signed' into 
staging (2016-01-12 17:37:22 +)

are available in the git repository at:

  https://git.kernel.org/pub/scm/virt/qemu/amit/migration.git 
tags/migration-for-2.6-1

for you to fetch changes up to c1bc66263c2360d5211ecd18191b0be65b3b54e5:

  multithread decompression: Avoid one copy (2016-01-13 16:03:01 +0530)


migration fixes for postcopy, xbzrle, multithread decompression



Dr. David Alan Gilbert (4):
  Postcopy: Send events/change state on incoming side
  Migration: Emit event at start of pass
  Use qemu_get_buffer_in_place for xbzrle data
  multithread decompression: Avoid one copy

zhanghailiang (2):
  migration: Export migrate_set_state()
  migration: Add state records for migration incoming

 docs/qmp-events.txt   | 14 
 include/migration/migration.h |  3 +++
 migration/migration.c | 52 ++-
 migration/ram.c   | 21 -
 migration/savevm.c| 22 --
 qapi/event.json   | 13 +++
 6 files changed, 87 insertions(+), 38 deletions(-)

-- 
2.5.0

[Qemu-devel] [PULL 6/6] multithread decompression: Avoid one copy

[Amit Shah]

From: "Dr. David Alan Gilbert" 

qemu_get_buffer does a copy, we can avoid the memcpy, and
we can then remove the extra buffer.

Signed-off-by: Dr. David Alan Gilbert 
Reviewed-by: Liang Li 
Reviewed-by: Juan Quintela 
Reviewed-by: Amit Shah 
Message-Id: <1450266458-3178-7-git-send-email-dgilb...@redhat.com>
Signed-off-by: Amit Shah 
---
 migration/ram.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/migration/ram.c b/migration/ram.c
index 994552c..2da3b51 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -286,7 +286,6 @@ static bool quit_comp_thread;
 static bool quit_decomp_thread;
 static DecompressParam *decomp_param;
 static QemuThread *decompress_threads;
-static uint8_t *compressed_data_buf;
 
 static int do_compress_ram_page(CompressParam *param);
 
@@ -2207,7 +2206,6 @@ void migrate_decompress_threads_create(void)
 thread_count = migrate_decompress_threads();
 decompress_threads = g_new0(QemuThread, thread_count);
 decomp_param = g_new0(DecompressParam, thread_count);
-compressed_data_buf = g_malloc0(compressBound(TARGET_PAGE_SIZE));
 quit_decomp_thread = false;
 for (i = 0; i < thread_count; i++) {
 qemu_mutex_init(_param[i].mutex);
@@ -2238,13 +2236,11 @@ void migrate_decompress_threads_join(void)
 }
 g_free(decompress_threads);
 g_free(decomp_param);
-g_free(compressed_data_buf);
 decompress_threads = NULL;
 decomp_param = NULL;
-compressed_data_buf = NULL;
 }
 
-static void decompress_data_with_multi_threads(uint8_t *compbuf,
+static void decompress_data_with_multi_threads(QEMUFile *f,
void *host, int len)
 {
 int idx, thread_count;
@@ -2253,7 +2249,7 @@ static void decompress_data_with_multi_threads(uint8_t 
*compbuf,
 while (true) {
 for (idx = 0; idx < thread_count; idx++) {
 if (!decomp_param[idx].start) {
-memcpy(decomp_param[idx].compbuf, compbuf, len);
+qemu_get_buffer(f, decomp_param[idx].compbuf, len);
 decomp_param[idx].des = host;
 decomp_param[idx].len = len;
 start_decompression(_param[idx]);
@@ -2498,8 +2494,7 @@ static int ram_load(QEMUFile *f, void *opaque, int 
version_id)
 ret = -EINVAL;
 break;
 }
-qemu_get_buffer(f, compressed_data_buf, len);
-decompress_data_with_multi_threads(compressed_data_buf, host, len);
+decompress_data_with_multi_threads(f, host, len);
 break;
 
 case RAM_SAVE_FLAG_XBZRLE:
-- 
2.5.0

Re: [Qemu-devel] [PATCH 1/1] blk: do not select PFLASH device for internal snapshot

[Markus Armbruster]

Kevin Wolf  writes:

> Am 12.01.2016 um 18:40 hat Markus Armbruster geschrieben:
>> Kevin Wolf  writes:
>> 
>> > Am 12.01.2016 um 17:35 hat Denis V. Lunev geschrieben:
>> >> On 01/12/2016 06:47 PM, Denis V. Lunev wrote:
>> >> >On 01/12/2016 06:20 PM, Kevin Wolf wrote:
>> >> >>Am 12.01.2016 um 15:59 hat Paolo Bonzini geschrieben:
>> >> >>>
>> >> >>>On 12/01/2016 15:16, Kevin Wolf wrote:
>> >> >Thus we should avoid selection of "pflash" drives for VM
>> >> >state saving.
>> >> >
>> >> >For now "pflash" is read-write raw image as it configured by libvirt.
>> >> >Thus there are no such images in the field and we could
>> >> >safely disable
>> >> >ability to save state to those images inside QEMU.
>> >> This is obviously broken. If you write to the pflash, then it needs to
>> >> be snapshotted in order to keep a consistent state.
>> >> 
>> >> If you want to avoid snapshotting the image, make it read-only and it
>> >> will be skipped even today.
>> >> >>>Sort of.  The point of having flash is to _not_ make it read-only, so
>> >> >>>that is not a solution.
>> >> >>>
>> >> >>>Flash is already being snapshotted as part of saving RAM state.  In
>> >> >>>fact, for this reason the device (at least the one used with OVMF; I
>> >> >>>haven't checked other pflash devices) can simply save it back to disk
>> >> >>>on the migration destination, without the need to use "migrate -b" or
>> >> >>>shared storage.
>> >> >>>[...]
>> >> >>>I don't like very much using IF_PFLASH this way, which is why I hadn't
>> >> >>>replied to the patch so far---I hadn't made up my mind about *what* to
>> >> >>>suggest instead, or whether to just accept it.  However, it does work.
>> >> >>>
>> >> >>>Perhaps a separate "I know what I am doing" skip-snapshot option?  Or
>> >> >>>a device callback saying "not snapshotting this is fine"?
>> >> >>Boy, is this ugly...
>> >> >>
>> >> >>What do you do with disk-only snapshots? The recovery only works as long
>> >> >>as you have VM state.
>> >> >>
>> >> >>Kevin
>> >> >actually I am in a bit of trouble :(
>> >> >
>> >> >I understand that this is ugly, but I would like to make working
>> >> >'virsh snapshot' for OVFM VMs. This is necessary for us to make
>> >> >a release.
>> >> >
>> >> >Currently libvirt guys generate XML in the following way:
>> >> >
>> >> >  
>> >> >hvm
>> >> >> >> >type='pflash'>/usr/share/OVMF/OVMF_CODE_new.fd
>> >> >/var/lib/libvirt/qemu/nvram/f20efi_VARS.fd
>> >> >  
>> >> >
>> >> >This results in:
>> >> >
>> >> >qemu -drive 
>> >> >file=/usr/share/OVMF/OVMF_CODE_new.fd,if=pflash,format=raw,unit=0,readonly=on
>> >> >\
>> >> > -drive 
>> >> > file=/var/lib/libvirt/qemu/nvram/f20efi_VARS.fd,if=pflash,format=raw,unit=1
>> >> >
>> >> >This obviously can not pass check in bdrv_all_can_snapshot()
>> >> >as 'pflash' is RW and raw, i.e. can not be snapshoted.
>> >> >
>> >> >They have discussed the switch to the following command line:
>> >> >
>> >> >qemu -drive 
>> >> >file=/usr/share/OVMF/OVMF_CODE_new.fd,if=pflash,format=raw,unit=0,readonly=on
>> >> >\
>> >> > -drive 
>> >> > file=/var/lib/libvirt/qemu/nvram/f20efi_VARS.fd.qcow2,if=pflash,format=qcow2,unit=1
>> >> >
>> >> >and say that in this case VM state could fall into PFLASH
>> >> >drive which is should not be big as the location of the
>> >> >file is different. This means that I am doomed here.
>> >> >
>> >> >Either we should force libvirt people to forget about their
>> >> >opinion that pflash should be small which I am unable to
>> >> >do or I should invent a way to ban VM state saving into
>> >> >pflash.
>> >> >
>> >> >OK. There are 2 options.
>> >> >
>> >> >1) Ban pflash as it was done.
>> >> >2) Add 'no-vmstate' flag to -drive (invented just now).
>> >> >
>> >> something like this:
>> >> 
>> >> diff --git a/block.c b/block.c
>> >> index 3e1877d..8900589 100644
>> >> --- a/block.c
>> >> +++ b/block.c
>> >> @@ -881,6 +881,11 @@ static QemuOptsList bdrv_runtime_opts = {
>> >>  .help = "Block driver to use for the node",
>> >>  },
>> >>  {
>> >> +.name = "novmstate",
>> >> +.type = QEMU_OPT_BOOL,
>> >> +.help = "Ignore for selecting to save VM state",
>> >> +},
>> >> +{
>> >>  .name = BDRV_OPT_CACHE_WB,
>> >>  .type = QEMU_OPT_BOOL,
>> >>  .help = "Enable writeback mode",
>> >> @@ -957,6 +962,7 @@ static int bdrv_open_common(BlockDriverState
>> >> *bs, BdrvChild *file,
>> >>  bs->request_alignment = 512;
>> >>  bs->zero_beyond_eof = true;
>> >>  bs->read_only = !(bs->open_flags & BDRV_O_RDWR);
>> >> +bs->disable_vmstate_save = qemu_opt_get_bool(opts, "novmstate", 
>> >> false);
>> >> 
>> >>  if (use_bdrv_whitelist && !bdrv_is_whitelisted(drv, bs->read_only)) {
>> >>  error_setg(errp,
>> >> diff --git a/block/snapshot.c b/block/snapshot.c
>> >> index 2d86b88..33cdd86 100644
>> >> --- 

Re: [Qemu-devel] [PATCH] hmp: avoid redundant null termination of buffer

[Wolfgang Bumiller]

On Tue, Jan 12, 2016 at 05:52:38PM +0100, Markus Armbruster wrote:
> Wolfgang Bumiller  writes:
> 
> >> On January 12, 2016 at 5:00 PM Markus Armbruster  wrote:
> >> Will you prepare a revised patch?
> >
> > Can do that tomorrow, but which option is the preferred one? If "%.*s" works
> > everywhere then changing index_from_key() and using "%.*s" would be the most
> > optimal I think.
> >
> > I don't want to bounce 5 more versions back and forth of something that's
> > supposed to be rather trivial.
> 
> Understandable.
> 
> If your patch works and is simple, I won't ask you to redo it using
> another method just because I might like that better.

Less simple (or at least longer) but gets rid of the static buffer,
shows the exact keyname in the error message and gets rid of the copying
of the word "less", too, by adding a length to index_from_key() as per
your suggestion. Seemed like the cleanest option.

Note that at the end of the loop (not visible in this patch's context
lines) 'keys' is reassigned to separator+1 or the loop ends if no
separator was there, which makes the `keys = "less"` assignment valid.
Though maybe adding an extra `const char *keyname` that becomes
`keyname = keys` at the beginning of the loop might be better? Not sure
which style you prefer, I can resend if you like.

===
>From 136dd5ac96fc21654a31aff7fa88b86570c8fc72 Mon Sep 17 00:00:00 2001
From: Wolfgang Bumiller 
Date: Wed, 13 Jan 2016 08:46:31 +0100
Subject: [PATCH] hmp: fix sendkey out of bounds write (CVE-2015-8619)

When processing 'sendkey' command, hmp_sendkey routine null
terminates the 'keyname_buf' array. This results in an OOB
write issue, if 'keyname_len' was to fall outside of
'keyname_buf' array.

Since the keyname's length is known the keyname_buf can be
removed altogether by adding a length parameter to
index_from_key() and using it for the error output as well.

Reported-by: Ling Liu 
Signed-off-by: Wolfgang Bumiller 
---
 hmp.c| 17 +++--
 include/ui/console.h |  2 +-
 ui/input-legacy.c|  5 +++--
 3 files changed, 11 insertions(+), 13 deletions(-)

diff --git a/hmp.c b/hmp.c
index c2b2c16..066ccf8 100644
--- a/hmp.c
+++ b/hmp.c
@@ -1742,21 +1742,18 @@ void hmp_sendkey(Monitor *mon, const QDict *qdict)
 int has_hold_time = qdict_haskey(qdict, "hold-time");
 int hold_time = qdict_get_try_int(qdict, "hold-time", -1);
 Error *err = NULL;
-char keyname_buf[16];
 char *separator;
 int keyname_len;
 
 while (1) {
 separator = strchr(keys, '-');
 keyname_len = separator ? separator - keys : strlen(keys);
-pstrcpy(keyname_buf, sizeof(keyname_buf), keys);
 
 /* Be compatible with old interface, convert user inputted "<" */
-if (!strncmp(keyname_buf, "<", 1) && keyname_len == 1) {
-pstrcpy(keyname_buf, sizeof(keyname_buf), "less");
+if (!strncmp(keys, "<", 1) && keyname_len == 1) {
+keys = "less";
 keyname_len = 4;
 }
-keyname_buf[keyname_len] = 0;
 
 keylist = g_malloc0(sizeof(*keylist));
 keylist->value = g_malloc0(sizeof(*keylist->value));
@@ -1769,16 +1766,16 @@ void hmp_sendkey(Monitor *mon, const QDict *qdict)
 }
 tmp = keylist;
 
-if (strstart(keyname_buf, "0x", NULL)) {
+if (strstart(keys, "0x", NULL)) {
 char *endp;
-int value = strtoul(keyname_buf, , 0);
-if (*endp != '\0') {
+int value = strtoul(keys, , 0);
+if (*endp != '\0' && *endp != '-') {
 goto err_out;
 }
 keylist->value->type = KEY_VALUE_KIND_NUMBER;
 keylist->value->u.number = value;
 } else {
-int idx = index_from_key(keyname_buf);
+int idx = index_from_key(keys, keyname_len);
 if (idx == Q_KEY_CODE__MAX) {
 goto err_out;
 }
@@ -1800,7 +1797,7 @@ out:
 return;
 
 err_out:
-monitor_printf(mon, "invalid parameter: %s\n", keyname_buf);
+monitor_printf(mon, "invalid parameter: %.*s\n", keyname_len, keys);
 goto out;
 }
 
diff --git a/include/ui/console.h b/include/ui/console.h
index adac36d..116bc2b 100644
--- a/include/ui/console.h
+++ b/include/ui/console.h
@@ -448,7 +448,7 @@ static inline int vnc_display_pw_expire(const char *id, 
time_t expires)
 void curses_display_init(DisplayState *ds, int full_screen);
 
 /* input.c */
-int index_from_key(const char *key);
+int index_from_key(const char *key, size_t key_length);
 
 /* gtk.c */
 void early_gtk_display_init(int opengl);
diff --git a/ui/input-legacy.c b/ui/input-legacy.c
index 35dfc27..3454055 100644
--- a/ui/input-legacy.c
+++ b/ui/input-legacy.c
@@ -57,12 +57,13 @@ struct QEMUPutLEDEntry {
 static QTAILQ_HEAD(, QEMUPutLEDEntry) led_handlers =
 QTAILQ_HEAD_INITIALIZER(led_handlers);
 

Re: [Qemu-devel] [PATCH] qemu-doc: Do not promote deprecated -smb and -redir options

[Jason Wang]

On 01/13/2016 04:21 PM, Thomas Huth wrote:
> Since -smb and -redir are deprecated options, we should not
> use them as examples in the documentation anymore.
>
> Signed-off-by: Thomas Huth 
> ---
>  qemu-doc.texi | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)

Applied to my -net.

Thanks

>
> diff --git a/qemu-doc.texi b/qemu-doc.texi
> index 7bc3882..2596503 100644
> --- a/qemu-doc.texi
> +++ b/qemu-doc.texi
> @@ -1237,9 +1237,9 @@ echo 100 100 > /proc/sys/net/ipv4/ping_group_range
>  When using the built-in TFTP server, the router is also the TFTP
>  server.
>  
> -When using the @option{-redir} option, TCP or UDP connections can be
> -redirected from the host to the guest. It allows for example to
> -redirect X11, telnet or SSH connections.
> +When using the @option{'-netdev user,hostfwd=...'} option, TCP or UDP
> +connections can be redirected from the host to the guest. It allows for
> +example to redirect X11, telnet or SSH connections.
>  
>  @subsection Connecting VLANs between QEMU instances
>  
> @@ -1889,7 +1889,8 @@ correctly instructs QEMU to shutdown at the appropriate 
> moment.
>  
>  @subsubsection Share a directory between Unix and Windows
>  
> -See @ref{sec_invocation} about the help of the option @option{-smb}.
> +See @ref{sec_invocation} about the help of the option
> +@option{'-netdev user,smb=...'}.
>  
>  @subsubsection Windows XP security problem
>  

Re: [Qemu-devel] [PATCH] ARM: Virt: Don't generate RTC ACPI node when using UEFI

[Laszlo Ersek]

On 01/12/16 16:24, Shannon Zhao wrote:
> When booting VM through UEFI, UEFI takes ownership of the RTC hardware.
> To DTB UEFI could call libfdt api to disable the RTC device node, but to
> ACPI it couldn't do that. Therefore, we don't generate the RTC ACPI
> device in QEMU when using UEFI.
> 
> Signed-off-by: Shannon Zhao 
> ---
>  hw/arm/virt-acpi-build.c | 13 +++--
>  hw/arm/virt.c|  5 -
>  include/hw/arm/virt-acpi-build.h |  1 +
>  3 files changed, 16 insertions(+), 3 deletions(-)
> 
> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> index 0caf5ce..cccec79 100644
> --- a/hw/arm/virt-acpi-build.c
> +++ b/hw/arm/virt-acpi-build.c
> @@ -575,8 +575,17 @@ build_dsdt(GArray *table_data, GArray *linker, 
> VirtGuestInfo *guest_info)
>  acpi_dsdt_add_cpus(scope, guest_info->smp_cpus);
>  acpi_dsdt_add_uart(scope, [VIRT_UART],
> (irqmap[VIRT_UART] + ARM_SPI_BASE));
> -acpi_dsdt_add_rtc(scope, [VIRT_RTC],
> -  (irqmap[VIRT_RTC] + ARM_SPI_BASE));
> +
> +/* When booting VM through UEFI, UEFI takes ownership of the RTC 
> hardware.
> + * To DTB UEFI could call libfdt api to disable the RTC device node, but 
> to
> + * ACPI it couldn't do that. Therefore, we don't generate the RTC ACPI
> + * device here when using UEFI.
> + */
> +if (guest_info->acpi_rtc) {
> +acpi_dsdt_add_rtc(scope, [VIRT_RTC],
> +  (irqmap[VIRT_RTC] + ARM_SPI_BASE));
> +}
> +
>  acpi_dsdt_add_flash(scope, [VIRT_FLASH]);
>  acpi_dsdt_add_virtio(scope, [VIRT_MMIO],
>  (irqmap[VIRT_MMIO] + ARM_SPI_BASE), 
> NUM_VIRTIO_TRANSPORTS);
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index fd52b76..de12037 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -1002,6 +1002,7 @@ static void machvirt_init(MachineState *machine)
>  VirtGuestInfoState *guest_info_state = g_malloc0(sizeof 
> *guest_info_state);
>  VirtGuestInfo *guest_info = _info_state->info;
>  char **cpustr;
> +bool firmware_loaded;
>  
>  if (!cpu_model) {
>  cpu_model = "cortex-a15";
> @@ -1124,12 +1125,14 @@ static void machvirt_init(MachineState *machine)
>  create_fw_cfg(vbi, _space_memory);
>  rom_set_fw(fw_cfg_find());
>  
> +firmware_loaded = bios_name || drive_get(IF_PFLASH, 0, 0);
>  guest_info->smp_cpus = smp_cpus;
>  guest_info->fw_cfg = fw_cfg_find();
>  guest_info->memmap = vbi->memmap;
>  guest_info->irqmap = vbi->irqmap;
>  guest_info->use_highmem = vms->highmem;
>  guest_info->gic_version = gic_version;
> +guest_info->acpi_rtc = !firmware_loaded;
>  guest_info_state->machine_done.notify = virt_guest_info_machine_done;
>  qemu_add_machine_init_done_notifier(_info_state->machine_done);
>  
> @@ -1141,7 +1144,7 @@ static void machvirt_init(MachineState *machine)
>  vbi->bootinfo.board_id = -1;
>  vbi->bootinfo.loader_start = vbi->memmap[VIRT_MEM].base;
>  vbi->bootinfo.get_dtb = machvirt_dtb;
> -vbi->bootinfo.firmware_loaded = bios_name || drive_get(IF_PFLASH, 0, 0);
> +vbi->bootinfo.firmware_loaded = firmware_loaded;
>  arm_load_kernel(ARM_CPU(first_cpu), >bootinfo);
>  
>  /*
> diff --git a/include/hw/arm/virt-acpi-build.h 
> b/include/hw/arm/virt-acpi-build.h
> index 744b666..6f412a4 100644
> --- a/include/hw/arm/virt-acpi-build.h
> +++ b/include/hw/arm/virt-acpi-build.h
> @@ -33,6 +33,7 @@ typedef struct VirtGuestInfo {
>  const int *irqmap;
>  bool use_highmem;
>  int gic_version;
> +bool acpi_rtc;
>  } VirtGuestInfo;
>  
>  
> 

I realize that Peter is not buying the argument just yet, but I'd like
to offer a review here nonetheless.

I think the patch is good, except the location and the wording of the
code comment.

(1) The code comment should be located right above the

guest_info->acpi_rtc = !firmware_loaded;

assignment.

(2) I think the code comment should simply use indicative mood:

When booting the VM with UEFI, UEFI takes ownership of the RTC
hardware. While UEFI can use libfdt to disable the RTC device node
in the DTB that it passes to the OS, it cannot modify AML.
Therefore, we won't generate the RTC ACPI device at all when using
UEFI.

With those changes, I'm willing to R-b.

Thanks
Laszlo

Re: [Qemu-devel] [PATCH v2 1/5] virtio-net: use the backend cross-endian capabilities

[Greg Kurz]

On Wed, 13 Jan 2016 10:53:11 +0100
Laurent Vivier  wrote:

> On 13/01/2016 10:06, Greg Kurz wrote:
> > On Tue, 12 Jan 2016 18:24:28 +0100
> > Laurent Vivier  wrote:
> >   
> >> On 11/01/2016 17:12, Greg Kurz wrote:  
> >>> When running a fully emulated device in cross-endian conditions, including
> >>> a virtio 1.0 device offered to a big endian guest, we need to fix the vnet
> >>> headers. This is currently handled by the virtio_net_hdr_swap() function
> >>> in the core virtio-net code but it should actually be handled by the net
> >>> backend.
> >>>
> >>> With this patch, virtio-net now tries to configure the backend to do the
> >>> endian fixing when the device starts (i.e. drivers sets the CONFIG_OK 
> >>> bit).
> >>> If the backend cannot support the requested endiannes, we have to fallback
> >>> onto virtio_net_hdr_swap(): this is recorded in the needs_vnet_hdr_swap 
> >>> flag,
> >>> to be used in the TX and RX paths.
> >>>
> >>> Note that we reset the backend to the default behaviour (guest native
> >>> endianness) when the device stops (i.e. device status had CONFIG_OK bit 
> >>> and
> >>> driver unsets it). This is needed, with the linux tap backend at least,
> >>> otherwise the guest may loose network connectivity if rebooted into a
> >>> different endianness.
> >>>
> >>> The current vhost-net code also tries to configure net backends. This will
> >>> be no more needed and will be reverted in a subsequent patch.
> >>>
> >>> Signed-off-by: Greg Kurz 
> >>> ---
> >>> v2:
> >>> - dropped useless check in the 'else if' branch in 
> >>> virtio_net_vnet_status()
> >>> - merged virtio_net_vhost_status() change from patch 2
> >>> - use semicolon in "backend does no support..." error message
> >>> - merged patch 3 (drop the virtio_needs_swap() helper)
> >>> - provided some more details in changelog and comments
> >>> ---
> >>>  hw/net/virtio-net.c   |   49 
> >>> +++--
> >>>  include/hw/virtio/virtio-access.h |9 ---
> >>>  include/hw/virtio/virtio-net.h|1 +
> >>>  3 files changed, 48 insertions(+), 11 deletions(-)
> >>>
> >>> diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> >>> index a877614e3e7a..497fb7119a08 100644
> >>> --- a/hw/net/virtio-net.c
> >>> +++ b/hw/net/virtio-net.c
> >>> @@ -128,6 +128,13 @@ static void virtio_net_vhost_status(VirtIONet *n, 
> >>> uint8_t status)
> >>>  if (!n->vhost_started) {
> >>>  int r, i;
> >>>  
> >>> +if (n->needs_vnet_hdr_swap) {
> >>> +error_report("backend does not support %s vnet headers; "
> >>> + "falling back on userspace virtio",
> >>> + virtio_is_big_endian(vdev) ? "BE" : "LE");
> >>> +return;
> >>> +}
> >>> +
> >>>  /* Any packets outstanding? Purge them to avoid touching rings
> >>>   * when vhost is running.
> >>>   */
> >>> @@ -152,6 +159,40 @@ static void virtio_net_vhost_status(VirtIONet *n, 
> >>> uint8_t status)
> >>>  }
> >>>  }
> >>>  
> >>> +static void virtio_net_vnet_status(VirtIONet *n, uint8_t status)
> >>> +{
> >>> +VirtIODevice *vdev = VIRTIO_DEVICE(n);
> >>> +NetClientState *peer = qemu_get_queue(n->nic)->peer;
> >>> +
> >>> +if (virtio_net_started(n, status)) {
> >>> +int r;
> >>> +
> >>> +/* Before using the device, we tell the network backend about the
> >>> + * endianness to use when parsing vnet headers. If the backend 
> >>> can't
> >>> + * do it, we fallback onto fixing the headers in the core 
> >>> virtio-net
> >>> + * code.
> >>> + */
> >>> +if (virtio_is_big_endian(vdev)) {
> >>> +r = qemu_set_vnet_be(peer, true);
> >>> +} else {
> >>> +r = qemu_set_vnet_le(peer, true);
> >>> +}
> >>
> >> If endianess of the guest and the virtio device is the same, but r is <
> >> 0 (-ENOSYS or -EINVAL) you will badly swap header (and disable vhost).
> >>  
> > 
> > This can only happen if the endianness of the host is not the same as the  
> 
> OK, you're right, I was studying sources without commit:
> 
> 052bd52 net: don't set native endianness
> 
> Sorry for the noise...
> 

No problem. Thank you again for your time !


> > endianness of the device. In this case (we usually call cross-endian) the
> > vnet headers must be byteswapped but the backend cannot handle it. This
> > has two consequences:
> > - vhost cannot be used since it requires the backend to support cross-endian
> >   vnet headers, so we fallback onto full emulation in QEMU
> > - the emulation code must byteswap vnet headers
> >   
> >> I think you need something like this to fall back to the old method:
> >>
> >> if (r < 0) {
> >> #ifdef HOST_WORDS_BIGENDIAN
> >> r = virtio_access_is_big_endian(vdev) ? false : true;
> >> #else
> >> r = virtio_access_is_big_endian(vdev) ? true : 

Re: [Qemu-devel] [PATCH v2 4/6] Migration: Emit event at start of pass

[Amit Shah]

On (Wed) 16 Dec 2015 [16:52:14], Dr. David Alan Gilbert wrote:
> * Eric Blake (ebl...@redhat.com) wrote:
> > On 12/16/2015 04:47 AM, Dr. David Alan Gilbert (git) wrote:
> > > From: "Dr. David Alan Gilbert" 
> > > 
> > > Emit an event each time we sync the dirty bitmap on the source;
> > > this helps libvirt use postcopy by giving it a kick when it
> > > might be a good idea to start the postcopy.
> > > 
> > > Signed-off-by: Dr. David Alan Gilbert 
> > > ---
> > >  docs/qmp-events.txt | 14 ++
> > >  migration/ram.c |  4 
> > >  qapi/event.json | 13 +
> > >  3 files changed, 31 insertions(+)
> > > 
> > 
> > >  
> > > +MIGRATION_PASS
> > > +--
> > > +
> > > +Emitted from the source side of a migration at the start of each pass
> > > +(when it syncs the dirty bitmap)
> > > +
> > > +Data: None.
> > > +
> > > +  - "pass": An incrementing count (starting at 1 on the first pass)
> > > +
> > > +Example:
> > > +{"timestamp": {"seconds": 1449669631, "microseconds": 239225},
> > > + "event": "MIGRATION_PASS", "data": {"pass": 2}}
> > 
> > How frequently can this event be emitted?  It is not under guest
> > control, so it's harder to argue that it could be abused as a way for
> > the guest to DoS the host.  And hopefully it is slow enough (considering
> > that each pass also requires lots more effort for actually transmitting
> > state from source to dest), so I don't think we have to worry about
> > adding rate-limiting to avoid overwhelming the monitor client.
> 
> The only way that you'd get a rapid repetition of the events
> is if the pass was very short.  However a very short pass is normally
> the signal to exit the iterative loop of migration and send the
> last blob at the end of migration.  And that definition of 'short' is
> determined by the downtime set by the management layer anyway.

Yes, and this can also give us stats on how quickly migration is
progressing.

Amit

[Qemu-devel] [PULL 0/1] virtio-serial qom'ification fix

[Amit Shah]

The following changes since commit 649a1bbaf95adb228f1030ab0618a932bc26aa8b:

  Merge remote-tracking branch 'remotes/kvaneesh/tags/for-upstream-signed' into 
staging (2016-01-12 17:37:22 +)

are available in the git repository at:

  https://git.kernel.org/pub/scm/virt/qemu/amit/virtio-serial.git 
tags/vs-for-2.6-1

for you to fetch changes up to d9eb0be229635a8c625a0a3d29d2d88aba1508a5:

  virtio serial port: fix to incomplete QOMify (2016-01-13 15:19:51 +0530)


small change to qom'ify virtio-serial




Cao jin (1):
  virtio serial port: fix to incomplete QOMify

 hw/char/virtio-serial-bus.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.5.0

Re: [Qemu-devel] [PATCH 1/1] blk: do not select PFLASH device for internal snapshot

[Laszlo Ersek]

On 01/12/16 18:40, Markus Armbruster wrote:
> Kevin Wolf  writes:
> 
>> Am 12.01.2016 um 17:35 hat Denis V. Lunev geschrieben:
>>> On 01/12/2016 06:47 PM, Denis V. Lunev wrote:
 On 01/12/2016 06:20 PM, Kevin Wolf wrote:
> Am 12.01.2016 um 15:59 hat Paolo Bonzini geschrieben:
>>
>> On 12/01/2016 15:16, Kevin Wolf wrote:
 Thus we should avoid selection of "pflash" drives for VM
 state saving.

 For now "pflash" is read-write raw image as it configured by libvirt.
 Thus there are no such images in the field and we could
 safely disable
 ability to save state to those images inside QEMU.
>>> This is obviously broken. If you write to the pflash, then it needs to
>>> be snapshotted in order to keep a consistent state.
>>>
>>> If you want to avoid snapshotting the image, make it read-only and it
>>> will be skipped even today.
>> Sort of.  The point of having flash is to _not_ make it read-only, so
>> that is not a solution.
>>
>> Flash is already being snapshotted as part of saving RAM state.  In
>> fact, for this reason the device (at least the one used with OVMF; I
>> haven't checked other pflash devices) can simply save it back to disk
>> on the migration destination, without the need to use "migrate -b" or
>> shared storage.
>> [...]
>> I don't like very much using IF_PFLASH this way, which is why I hadn't
>> replied to the patch so far---I hadn't made up my mind about *what* to
>> suggest instead, or whether to just accept it.  However, it does work.
>>
>> Perhaps a separate "I know what I am doing" skip-snapshot option?  Or
>> a device callback saying "not snapshotting this is fine"?
> Boy, is this ugly...
>
> What do you do with disk-only snapshots? The recovery only works as long
> as you have VM state.
>
> Kevin
 actually I am in a bit of trouble :(

 I understand that this is ugly, but I would like to make working
 'virsh snapshot' for OVFM VMs. This is necessary for us to make
 a release.

 Currently libvirt guys generate XML in the following way:

  
hvm
>>> type='pflash'>/usr/share/OVMF/OVMF_CODE_new.fd
 /var/lib/libvirt/qemu/nvram/f20efi_VARS.fd
  

 This results in:

 qemu -drive 
 file=/usr/share/OVMF/OVMF_CODE_new.fd,if=pflash,format=raw,unit=0,readonly=on
 \
 -drive 
 file=/var/lib/libvirt/qemu/nvram/f20efi_VARS.fd,if=pflash,format=raw,unit=1

 This obviously can not pass check in bdrv_all_can_snapshot()
 as 'pflash' is RW and raw, i.e. can not be snapshoted.

 They have discussed the switch to the following command line:

 qemu -drive 
 file=/usr/share/OVMF/OVMF_CODE_new.fd,if=pflash,format=raw,unit=0,readonly=on
 \
 -drive 
 file=/var/lib/libvirt/qemu/nvram/f20efi_VARS.fd.qcow2,if=pflash,format=qcow2,unit=1

 and say that in this case VM state could fall into PFLASH
 drive which is should not be big as the location of the
 file is different. This means that I am doomed here.

 Either we should force libvirt people to forget about their
 opinion that pflash should be small which I am unable to
 do or I should invent a way to ban VM state saving into
 pflash.

 OK. There are 2 options.

 1) Ban pflash as it was done.
 2) Add 'no-vmstate' flag to -drive (invented just now).

>>> something like this:
>>>
>>> diff --git a/block.c b/block.c
>>> index 3e1877d..8900589 100644
>>> --- a/block.c
>>> +++ b/block.c
>>> @@ -881,6 +881,11 @@ static QemuOptsList bdrv_runtime_opts = {
>>>  .help = "Block driver to use for the node",
>>>  },
>>>  {
>>> +.name = "novmstate",
>>> +.type = QEMU_OPT_BOOL,
>>> +.help = "Ignore for selecting to save VM state",
>>> +},
>>> +{
>>>  .name = BDRV_OPT_CACHE_WB,
>>>  .type = QEMU_OPT_BOOL,
>>>  .help = "Enable writeback mode",
>>> @@ -957,6 +962,7 @@ static int bdrv_open_common(BlockDriverState
>>> *bs, BdrvChild *file,
>>>  bs->request_alignment = 512;
>>>  bs->zero_beyond_eof = true;
>>>  bs->read_only = !(bs->open_flags & BDRV_O_RDWR);
>>> +bs->disable_vmstate_save = qemu_opt_get_bool(opts, "novmstate", false);
>>>
>>>  if (use_bdrv_whitelist && !bdrv_is_whitelisted(drv, bs->read_only)) {
>>>  error_setg(errp,
>>> diff --git a/block/snapshot.c b/block/snapshot.c
>>> index 2d86b88..33cdd86 100644
>>> --- a/block/snapshot.c
>>> +++ b/block/snapshot.c
>>> @@ -483,6 +483,10 @@ BlockDriverState *bdrv_all_find_vmstate_bs(void)
>>>  while (not_found && (bs = bdrv_next(bs))) {
>>>  AioContext *ctx = bdrv_get_aio_context(bs);
>>>
>>> +if (bs->disable_vmstate_save) {
>>> +continue;
>>> +}
>>> +
>>> 

[Qemu-devel] [PATCH] qemu-doc: Do not promote deprecated -smb and -redir options

[Thomas Huth]

Since -smb and -redir are deprecated options, we should not
use them as examples in the documentation anymore.

Signed-off-by: Thomas Huth 
---
 qemu-doc.texi | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/qemu-doc.texi b/qemu-doc.texi
index 7bc3882..2596503 100644
--- a/qemu-doc.texi
+++ b/qemu-doc.texi
@@ -1237,9 +1237,9 @@ echo 100 100 > /proc/sys/net/ipv4/ping_group_range
 When using the built-in TFTP server, the router is also the TFTP
 server.
 
-When using the @option{-redir} option, TCP or UDP connections can be
-redirected from the host to the guest. It allows for example to
-redirect X11, telnet or SSH connections.
+When using the @option{'-netdev user,hostfwd=...'} option, TCP or UDP
+connections can be redirected from the host to the guest. It allows for
+example to redirect X11, telnet or SSH connections.
 
 @subsection Connecting VLANs between QEMU instances
 
@@ -1889,7 +1889,8 @@ correctly instructs QEMU to shutdown at the appropriate 
moment.
 
 @subsubsection Share a directory between Unix and Windows
 
-See @ref{sec_invocation} about the help of the option @option{-smb}.
+See @ref{sec_invocation} about the help of the option
+@option{'-netdev user,smb=...'}.
 
 @subsubsection Windows XP security problem
 
-- 
1.8.3.1

Re: [Qemu-devel] [PATCH 1/5] block: added lock image option and callback

[Markus Armbruster]

Kevin Wolf  writes:

> Am 11.01.2016 um 18:58 hat Daniel P. Berrange geschrieben:
>> On Mon, Jan 11, 2016 at 06:31:06PM +0100, Kevin Wolf wrote:
>> > Am 23.12.2015 um 08:46 hat Denis V. Lunev geschrieben:
>> > > From: Olga Krishtal 
>> > > 
>> > > While opening the image we want to be sure that we are the
>> > > one who works with image, anf if it is not true -
>> > > opening the image for writing should fail.
>> > > 
>> > > There are 2 ways at the moment: no lock at all and lock the file
>> > > image.
>> > > 
>> > > Signed-off-by: Olga Krishtal 
>> > > Signed-off-by: Denis V. Lunev 
>> > > CC: Kevin Wolf 
>> > > CC: Max Reitz 
>> > > CC: Eric Blake 
>> > > CC: Fam Zheng 
>> > 
>> > As long as locking is disabled by default, it's useless and won't
>> > prevent people from corrupting their images. These corruptions happen
>> > exactly because people don't know how to use qemu properly. You can't
>> > expect them to enable locking manually.
>> > 
>> > Also, you probably need to consider bdrv_reopen() and live migration.
>> > I think live migration would be blocked if source and destination both
>> > see the lock; which is admittedly less likely than with the qcow2 patch
>> > (and generally a problem of this series), but with localhost migration
>> > and potentially with some NFS setups it can be the case.
>> 
>> Note that when libvirt does locking it will release locks when a VM
>> is paused, and acquire locks prior to resuming CPUs. This allows live
>> migration to work because you never have CPUs running on both src + dst
>> at the same time. This does mean that libvirt does not allow QEMU to
>> automatically re-start CPUs when migration completes, as it needs to
>> take some action to acquire locks before allowing the dst to start
>> running again.
>
> This assumes that block devices can only be written to if CPUs are
> running. In the days of qemu 0.9, this was probably right, but with
> things like block jobs and built-in NBD servers, I wouldn't be as sure
> these days.

Sounds like QEMU and libvirt should cooperate more closely to get the
locking less wrong.

QEMU should have more accurate knowledge on how it is using the image.
Libvirt may be able to provide better locks, with the help of its
virtlockd daemon.

Re: [Qemu-devel] [PATCH 1/5] block: added lock image option and callback

[Daniel P. Berrange]

On Mon, Jan 11, 2016 at 07:35:57PM +0100, Kevin Wolf wrote:
> Am 11.01.2016 um 18:58 hat Daniel P. Berrange geschrieben:
> > On Mon, Jan 11, 2016 at 06:31:06PM +0100, Kevin Wolf wrote:
> > > Am 23.12.2015 um 08:46 hat Denis V. Lunev geschrieben:
> > > > From: Olga Krishtal 
> > > > 
> > > > While opening the image we want to be sure that we are the
> > > > one who works with image, anf if it is not true -
> > > > opening the image for writing should fail.
> > > > 
> > > > There are 2 ways at the moment: no lock at all and lock the file
> > > > image.
> > > > 
> > > > Signed-off-by: Olga Krishtal 
> > > > Signed-off-by: Denis V. Lunev 
> > > > CC: Kevin Wolf 
> > > > CC: Max Reitz 
> > > > CC: Eric Blake 
> > > > CC: Fam Zheng 
> > > 
> > > As long as locking is disabled by default, it's useless and won't
> > > prevent people from corrupting their images. These corruptions happen
> > > exactly because people don't know how to use qemu properly. You can't
> > > expect them to enable locking manually.
> > > 
> > > Also, you probably need to consider bdrv_reopen() and live migration.
> > > I think live migration would be blocked if source and destination both
> > > see the lock; which is admittedly less likely than with the qcow2 patch
> > > (and generally a problem of this series), but with localhost migration
> > > and potentially with some NFS setups it can be the case.
> > 
> > Note that when libvirt does locking it will release locks when a VM
> > is paused, and acquire locks prior to resuming CPUs. This allows live
> > migration to work because you never have CPUs running on both src + dst
> > at the same time. This does mean that libvirt does not allow QEMU to
> > automatically re-start CPUs when migration completes, as it needs to
> > take some action to acquire locks before allowing the dst to start
> > running again.
> 
> This assumes that block devices can only be written to if CPUs are
> running. In the days of qemu 0.9, this was probably right, but with
> things like block jobs and built-in NBD servers, I wouldn't be as sure
> these days.

True, libvirt knows when it is using block jobs & NBD servers, so it
should not be difficult to address this.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] [PATCH 1/5] block: added lock image option and callback

[Daniel P. Berrange]

On Wed, Jan 13, 2016 at 12:12:10PM +0300, Denis V. Lunev wrote:
> On 01/13/2016 11:52 AM, Markus Armbruster wrote:
> >Kevin Wolf  writes:
> >
> >>Am 11.01.2016 um 18:58 hat Daniel P. Berrange geschrieben:
> >>>On Mon, Jan 11, 2016 at 06:31:06PM +0100, Kevin Wolf wrote:
> Am 23.12.2015 um 08:46 hat Denis V. Lunev geschrieben:
> >From: Olga Krishtal 
> >
> >While opening the image we want to be sure that we are the
> >one who works with image, anf if it is not true -
> >opening the image for writing should fail.
> >
> >There are 2 ways at the moment: no lock at all and lock the file
> >image.
> >
> >Signed-off-by: Olga Krishtal 
> >Signed-off-by: Denis V. Lunev 
> >CC: Kevin Wolf 
> >CC: Max Reitz 
> >CC: Eric Blake 
> >CC: Fam Zheng 
> As long as locking is disabled by default, it's useless and won't
> prevent people from corrupting their images. These corruptions happen
> exactly because people don't know how to use qemu properly. You can't
> expect them to enable locking manually.
> 
> Also, you probably need to consider bdrv_reopen() and live migration.
> I think live migration would be blocked if source and destination both
> see the lock; which is admittedly less likely than with the qcow2 patch
> (and generally a problem of this series), but with localhost migration
> and potentially with some NFS setups it can be the case.
> >>>Note that when libvirt does locking it will release locks when a VM
> >>>is paused, and acquire locks prior to resuming CPUs. This allows live
> >>>migration to work because you never have CPUs running on both src + dst
> >>>at the same time. This does mean that libvirt does not allow QEMU to
> >>>automatically re-start CPUs when migration completes, as it needs to
> >>>take some action to acquire locks before allowing the dst to start
> >>>running again.
> >>This assumes that block devices can only be written to if CPUs are
> >>running. In the days of qemu 0.9, this was probably right, but with
> >>things like block jobs and built-in NBD servers, I wouldn't be as sure
> >>these days.
> >Sounds like QEMU and libvirt should cooperate more closely to get the
> >locking less wrong.
> >
> >QEMU should have more accurate knowledge on how it is using the image.
> >Libvirt may be able to provide better locks, with the help of its
> >virtlockd daemon.
> daemon owning locks is a problem:
> - there are distributed cases
> - daemons restart from time to time

The virtlockd daemon copes with both of these cases just fine. There is
one daemon per virtualization host, and they can be configured acquire
locks in a way that they will be enforced across all hosts. The reason
we do it in a separate virtlockd daemon instead of libvirtd is that we
designed it to be able to re-exec() itself while maintaining all locks
to allow for seemless upgrade.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

[Qemu-devel] [PULL 2/6] migration: Add state records for migration incoming

[Amit Shah]

From: zhanghailiang 

For migration destination, we also need to know its state,
we will use it in COLO.

Here we add a new member 'state' for MigrationIncomingState,
and also use migrate_set_state() to modify its value.

Signed-off-by: zhanghailiang 

dgilbert: Fixed early free of MigraitonIncomingState
Signed-off-by: Dr. David Alan Gilbert 
Reviewed-by: Juan Quintela 
Reviewed-by: Amit Shah 
Message-Id: <1450266458-3178-3-git-send-email-dgilb...@redhat.com>
Signed-off-by: Amit Shah 
---
 include/migration/migration.h |  1 +
 migration/migration.c | 16 ++--
 2 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/include/migration/migration.h b/include/migration/migration.h
index a64ca7c..0fc1ffa 100644
--- a/include/migration/migration.h
+++ b/include/migration/migration.h
@@ -105,6 +105,7 @@ struct MigrationIncomingState {
 QemuMutex rp_mutex;/* We send replies from multiple threads */
 void *postcopy_tmp_page;
 
+int state;
 /* See savevm.c */
 LoadStateEntry_Head loadvm_handlers;
 };
diff --git a/migration/migration.c b/migration/migration.c
index 5db6227..bc611e4 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -111,6 +111,7 @@ MigrationIncomingState 
*migration_incoming_state_new(QEMUFile* f)
 {
 mis_current = g_new0(MigrationIncomingState, 1);
 mis_current->from_src_file = f;
+mis_current->state = MIGRATION_STATUS_NONE;
 QLIST_INIT(_current->loadvm_handlers);
 qemu_mutex_init(_current->rp_mutex);
 qemu_event_init(_current->main_thread_load_event, false);
@@ -331,8 +332,8 @@ static void process_incoming_migration_co(void *opaque)
 
 mis = migration_incoming_state_new(f);
 postcopy_state_set(POSTCOPY_INCOMING_NONE);
-migrate_generate_event(MIGRATION_STATUS_ACTIVE);
-
+migrate_set_state(>state, MIGRATION_STATUS_NONE,
+  MIGRATION_STATUS_ACTIVE);
 ret = qemu_loadvm_state(f);
 
 ps = postcopy_state_get();
@@ -358,10 +359,10 @@ static void process_incoming_migration_co(void *opaque)
 
 qemu_fclose(f);
 free_xbzrle_decoded_buf();
-migration_incoming_state_destroy();
 
 if (ret < 0) {
-migrate_generate_event(MIGRATION_STATUS_FAILED);
+migrate_set_state(>state, MIGRATION_STATUS_ACTIVE,
+  MIGRATION_STATUS_FAILED);
 error_report("load of migration failed: %s", strerror(-ret));
 migrate_decompress_threads_join();
 exit(EXIT_FAILURE);
@@ -370,7 +371,8 @@ static void process_incoming_migration_co(void *opaque)
 /* Make sure all file formats flush their mutable metadata */
 bdrv_invalidate_cache_all(_err);
 if (local_err) {
-migrate_generate_event(MIGRATION_STATUS_FAILED);
+migrate_set_state(>state, MIGRATION_STATUS_ACTIVE,
+  MIGRATION_STATUS_FAILED);
 error_report_err(local_err);
 migrate_decompress_threads_join();
 exit(EXIT_FAILURE);
@@ -402,7 +404,9 @@ static void process_incoming_migration_co(void *opaque)
  * observer sees this event they might start to prod at the VM assuming
  * it's ready to use.
  */
-migrate_generate_event(MIGRATION_STATUS_COMPLETED);
+migrate_set_state(>state, MIGRATION_STATUS_ACTIVE,
+  MIGRATION_STATUS_COMPLETED);
+migration_incoming_state_destroy();
 }
 
 void process_incoming_migration(QEMUFile *f)
-- 
2.5.0

Re: [Qemu-devel] [Bug 1531632] [NEW] Can't compile qemu because of errors in the Xen code

[Stefano Stabellini]

On Wed, 6 Jan 2016, Leo wrote:
> Public bug reported:
> 
> I'm using Arch Linux, with all needed libs packages installed via ABS 
> (compiled from source).
> I tried to clone the master repository, the v2.5.0 and the stable-2.4.0, all 
> I had the same problems:

Hello Leo,

what is the version of Xen installed on your system?

The problem seems to be that QEMU detects a Xen < 4.5, but actually
ioservid_t is already defined (it shouldn't be, if Xen was a regular
4.5).


> First I have to disable -Werror, because it claims about some
> uninitialized variables.
> 
> Trying to compile the code, it stops when compiling the xen code
> (hw/block/xendisk.o), complaining that ioservid_t is declared twice,
> first as 16bit and then as 32bit.
> 
> Output of make:
> 
>   CChw/block/xen_disk.o
> In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0,
>  from /home/leo/qemu/hw/block/xen_disk.c:39:
> /home/leo/qemu/include/hw/xen/xen_common.h:198:18: error: conflicting types 
> for ‘ioservid_t’
>  typedef uint16_t ioservid_t;
>   ^
> In file included from /usr/include/xenctrl.h:37:0,
>  from /home/leo/qemu/include/hw/xen/xen_common.h:9,
>  from /home/leo/qemu/include/hw/xen/xen_backend.h:4,
>  from /home/leo/qemu/hw/block/xen_disk.c:39:
> /usr/include/xen/xen.h:353:18: note: previous declaration of ‘ioservid_t’ was 
> here
>  typedef uint32_t ioservid_t;
>   ^

I don't know where this is coming from. I cannot find it in the sources
anywhere.


> In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0,
>  from /home/leo/qemu/hw/block/xen_disk.c:39:
> /home/leo/qemu/include/hw/xen/xen_common.h: In function 
> ‘xen_get_ioreq_server_info’:
> /home/leo/qemu/include/hw/xen/xen_common.h:256:36: error: 
> ‘HVM_PARAM_IOREQ_PFN’ undeclared (first use in this function)
>  rc = xc_get_hvm_param(xc, dom, HVM_PARAM_IOREQ_PFN, );
> ^
> /home/leo/qemu/include/hw/xen/xen_common.h:256:36: note: each undeclared 
> identifier is reported only once for each function it appears in
> In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0,
>  from /home/leo/qemu/hw/block/xen_disk.c:39:
> /home/leo/qemu/include/hw/xen/xen_common.h:264:36: error: 
> ‘HVM_PARAM_BUFIOREQ_PFN’ undeclared (first use in this function)
>  rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_PFN, );
> ^
> /home/leo/qemu/rules.mak:57: recipe for target 'hw/block/xen_disk.o' failed
> make: *** [hw/block/xen_disk.o] Error 1
> [leo@AlphaArch build]$ make
>   CChw/block/xen_disk.o
> In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0,
>  from /home/leo/qemu/hw/block/xen_disk.c:39:
> /home/leo/qemu/include/hw/xen/xen_common.h:198:18: error: conflicting types 
> for ‘ioservid_t’
>  typedef uint16_t ioservid_t;
>   ^
> In file included from /usr/include/xenctrl.h:37:0,
>  from /home/leo/qemu/include/hw/xen/xen_common.h:9,
>  from /home/leo/qemu/include/hw/xen/xen_backend.h:4,
>  from /home/leo/qemu/hw/block/xen_disk.c:39:
> /usr/include/xen/xen.h:353:18: note: previous declaration of ‘ioservid_t’ was 
> here
>  typedef uint32_t ioservid_t;
>   ^
> In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0,
>  from /home/leo/qemu/hw/block/xen_disk.c:39:
> /home/leo/qemu/include/hw/xen/xen_common.h: In function 
> ‘xen_get_ioreq_server_info’:
> /home/leo/qemu/include/hw/xen/xen_common.h:256:36: error: 
> ‘HVM_PARAM_IOREQ_PFN’ undeclared (first use in this function)
>  rc = xc_get_hvm_param(xc, dom, HVM_PARAM_IOREQ_PFN, );
> ^
> /home/leo/qemu/include/hw/xen/xen_common.h:256:36: note: each undeclared 
> identifier is reported only once for each function it appears in
> In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0,
>  from /home/leo/qemu/hw/block/xen_disk.c:39:
> /home/leo/qemu/include/hw/xen/xen_common.h:264:36: error: 
> ‘HVM_PARAM_BUFIOREQ_PFN’ undeclared (first use in this function)
>  rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_PFN, );
> ^
> /home/leo/qemu/rules.mak:57: recipe for target 'hw/block/xen_disk.o' failed
> make: *** [hw/block/xen_disk.o] Error 1
> [leo@AlphaArch build]$ make
>   CChw/block/xen_disk.o
> In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0,
>  from /home/leo/qemu/hw/block/xen_disk.c:39:
> /home/leo/qemu/include/hw/xen/xen_common.h:198:18: error: conflicting types 
> for ‘ioservid_t’
>  typedef uint16_t ioservid_t;
>   ^
> In file included from /usr/include/xenctrl.h:37:0,
>  from /home/leo/qemu/include/hw/xen/xen_common.h:9,
>  from 

Re: [Qemu-devel] [PATCH 1/1] blk: do not select PFLASH device for internal snapshot

[Denis V. Lunev]

On 01/13/2016 01:37 PM, Laszlo Ersek wrote:

meta comment here:

On 01/12/16 16:47, Denis V. Lunev wrote:


P.S. Here is a summary that my colleague has receiver from libvirt
list.

 Forwarded Message 
Subject: Re: Snapshotting OVMF guests
Date: Mon, 11 Jan 2016 13:56:29 +0100
From: Laszlo Ersek 
To: Dmitry Andreev 
CC: Michal Privoznik , Markus Armbruster


Hello Dmitry,

[...]

Your colleague Dmitry did not receive this from the libvirt list. He
received the from me in private. See the headers above.

Please do not publicize a private exchange without asking for permission
first.

In the present case I don't mind it. I stand by everything I said, and I
would have written mostly the same if I had been contacted publicly,
on-list.

But if you contact me in private *first*, then I expect the discussion
to remain private. If you want to forward the email to a public list,
please ask for permission. Otherwise I might consider it more prudent
for myself to answer all private queries with just "please ask me this
on the list instead".

I appreciate that you guys are working on this, but let's handle emails
sensibly.

Thanks
Laszlo


Sorry :( I have not properly checked the message :(

I am guilty..

Den

Re: [Qemu-devel] [Avocado-devel] [PATCH] net/slirp: Tell the users when they are using deprecated options

[Jason Wang]

On 01/13/2016 03:27 PM, Thomas Huth wrote:
> On 13.01.2016 04:13, Jason Wang wrote:
>>
>> On 01/13/2016 10:58 AM, Jason Wang wrote:
>>> On 01/12/2016 07:45 PM, Cleber Rosa wrote:
 - Original Message -
> From: "Thomas Huth" 
> To: "Jason Wang" , "Jan Kiszka" 
> , qemu-devel@nongnu.org
> Cc: "Paolo Bonzini" , avocado-de...@redhat.com, 
> "Markus Armbruster" 
> Sent: Tuesday, January 12, 2016 5:26:36 AM
> Subject: Re: [Qemu-devel] [PATCH] net/slirp: Tell the users when they are 
> using deprecated options
>
> On 12.01.2016 04:42, Jason Wang wrote:
>> On 01/11/2016 11:55 PM, Thomas Huth wrote:
>>> On 15.12.2015 09:35, Thomas Huth wrote:
 We don't want to support the legacy -tftp, -bootp, -smb and
 -net channel options forever. So let's start telling the users
 that they will go away in a future version.

 Signed-off-by: Thomas Huth 
 ---
  net/slirp.c | 3 +++
  os-posix.c  | 3 +++
  vl.c| 6 ++
  3 files changed, 12 insertions(+)

 diff --git a/net/slirp.c b/net/slirp.c
 index f505570..65e3766 100644
 --- a/net/slirp.c
 +++ b/net/slirp.c
 @@ -784,6 +784,9 @@ int net_slirp_parse_legacy(QemuOptsList *opts_list,
 const char *optarg, int *ret
  return 0;
  }
  
 +error_report("The -net channel option is deprecated and "
 + "will be removed in a future version.");
 +
  /* handle legacy -net channel,port:chr */
  optarg += strlen("channel,");
  
 diff --git a/os-posix.c b/os-posix.c
 index e4da406..3f62f7c 100644
 --- a/os-posix.c
 +++ b/os-posix.c
 @@ -40,6 +40,7 @@
  #include "net/slirp.h"
  #include "qemu-options.h"
  #include "qemu/rcu.h"
 +#include "qemu/error-report.h"
  
  #ifdef CONFIG_LINUX
  #include 
 @@ -139,6 +140,8 @@ void os_parse_cmd_args(int index, const char 
 *optarg)
  switch (index) {
  #ifdef CONFIG_SLIRP
  case QEMU_OPTION_smb:
 +error_report("The -smb option is deprecated and "
 + "will be removed in a future version.");
  if (net_slirp_smb(optarg) < 0)
  exit(1);
  break;
 diff --git a/vl.c b/vl.c
 index 4211ff1..fa829c0 100644
 --- a/vl.c
 +++ b/vl.c
 @@ -3314,12 +3314,18 @@ int main(int argc, char **argv, char **envp)
  #endif
  #ifdef CONFIG_SLIRP
  case QEMU_OPTION_tftp:
 +error_report("The -tftp option is deprecated and "
 + "will be removed in a future version.");
  legacy_tftp_prefix = optarg;
  break;
  case QEMU_OPTION_bootp:
 +error_report("The -bootp option is deprecated and "
 + "will be removed in a future version.");
  legacy_bootp_filename = optarg;
  break;
  case QEMU_OPTION_redir:
 +error_report("The -redir option is deprecated and "
 + "will be removed in a future version.");
  if (net_slirp_redir(optarg) < 0)
  exit(1);
  break;
>>> *ping*
>>>
>>> Any comments on these old options? I hope Paolo does not want to keep
>>> them, too, forever ;-)
>> I vaguely remember autotest use those options in the past for guest os
>> installation. May need input from autotest guys.
> Looking at
>  
> https://github.com/avocado-framework/avocado-vt/blob/master/virttest/qemu_vm.py
> it seems like that latest incarnation of autotest is doing it
> right already:
> ...
> def add_tftp(devices, filename):
> # If the new syntax is supported, don't add -tftp
> if "[,tftp=" in devices.get_help_text():
> return ""
> else:
> return " -tftp '%s'" % filename
> ...
> def add_net(devices, vlan, nettype, ifname=None, tftp=None,
> bootfile=None, hostfwd=[], netdev_id=None,
> netdev_extra_params=None, tapfds=None, script=None,
> downscript=None, vhost=None, queues=None, 
> vhostfds=None,
> add_queues=None, helper=None, add_tapfd=None,
> add_vhostfd=None, vhostforce=None):
> ...
> 

Re: [Qemu-devel] [Qemu-block] [PATCH 00/10] qcow2: Implement image locking

[Denis V. Lunev]

On 01/13/2016 11:56 AM, Markus Armbruster wrote:

Kevin Wolf  writes:


Am 23.12.2015 um 11:47 hat Daniel P. Berrange geschrieben:

On Wed, Dec 23, 2015 at 11:14:12AM +0800, Fam Zheng wrote:

On Tue, 12/22 17:46, Kevin Wolf wrote:

Enough innocent images have died because users called 'qemu-img
snapshot' while
the VM was still running. Educating the users doesn't seem to be a working
strategy, so this series adds locking to qcow2 that refuses to
access the image
read-write from two processes.

Eric, this will require a libvirt update to deal with qemu
crashes which leave
locked images behind. The simplest thinkable way would be to
unconditionally
override the lock in libvirt whenever the option is present. In that case,
libvirt VMs would be protected against concurrent non-libvirt
accesses, but not
the other way round. If you want more than that, libvirt would
have to check
somehow if it was its own VM that used the image and left the
lock behind. I
imagine that can't be too hard either.

The motivation is great, but I'm not sure I like the side-effect that an
unclean shutdown will require a "forced" open, because it makes
using qcow2 in
development cumbersome, and like you said, management/user also
needs to handle
this explicitly. This is a bit of a personal preference, but it's
strong enough
that I want to speak up.

Yeah, I am also not really a big fan of locking mechanisms which are not
automatically cleaned up on process exit. On the other hand you could
say that people who choose to run qemu-img manually are already taking
fate into their own hands, and ending up with a dirty image on unclean
exit is still miles better than loosing all your data.


As an alternative, can we introduce .bdrv_flock() in protocol drivers, with
similar semantics to flock(2) or lockf(3)? That way all formats can benefit,
and a program crash will automatically drop the lock.

FWIW, the libvirt locking daemon (virtlockd) will already attempt to take
out locks using fcntl()/lockf() on all disk images associated with a VM.

Does this actually mean that if QEMU did try to use flock(), it would
fail because libvirt is already holding the lock?

I considered adding both locking schemes (the qcow2 flag for qcow2 on
any backend; flock() for anything else on local files), but if this is
true, that's game over for any flock() based patches.

"Game over" for any patches that use the same locking mechanism as
libvirt without coordinating with libvirt.

Of course, patches that use a new locking mechanism will almost
certainly need some libvirt work, too.

Can we come up with a more integrated solution where QEMU cooperates
with libvirt on locking when libvirt is in play, and does a more limited
job itself when libvirt isn't in play?


for me this seems viable. But this requires a serious efforts to
do and serious coordination.

How this could be done and how this could be coordinated
with the current state of uncertainty.

Den

Re: [Qemu-devel] [PATCH 1/5] block: added lock image option and callback

[Denis V. Lunev]

On 01/13/2016 11:52 AM, Markus Armbruster wrote:

Kevin Wolf  writes:


Am 11.01.2016 um 18:58 hat Daniel P. Berrange geschrieben:

On Mon, Jan 11, 2016 at 06:31:06PM +0100, Kevin Wolf wrote:

Am 23.12.2015 um 08:46 hat Denis V. Lunev geschrieben:

From: Olga Krishtal 

While opening the image we want to be sure that we are the
one who works with image, anf if it is not true -
opening the image for writing should fail.

There are 2 ways at the moment: no lock at all and lock the file
image.

Signed-off-by: Olga Krishtal 
Signed-off-by: Denis V. Lunev 
CC: Kevin Wolf 
CC: Max Reitz 
CC: Eric Blake 
CC: Fam Zheng 

As long as locking is disabled by default, it's useless and won't
prevent people from corrupting their images. These corruptions happen
exactly because people don't know how to use qemu properly. You can't
expect them to enable locking manually.

Also, you probably need to consider bdrv_reopen() and live migration.
I think live migration would be blocked if source and destination both
see the lock; which is admittedly less likely than with the qcow2 patch
(and generally a problem of this series), but with localhost migration
and potentially with some NFS setups it can be the case.

Note that when libvirt does locking it will release locks when a VM
is paused, and acquire locks prior to resuming CPUs. This allows live
migration to work because you never have CPUs running on both src + dst
at the same time. This does mean that libvirt does not allow QEMU to
automatically re-start CPUs when migration completes, as it needs to
take some action to acquire locks before allowing the dst to start
running again.

This assumes that block devices can only be written to if CPUs are
running. In the days of qemu 0.9, this was probably right, but with
things like block jobs and built-in NBD servers, I wouldn't be as sure
these days.

Sounds like QEMU and libvirt should cooperate more closely to get the
locking less wrong.

QEMU should have more accurate knowledge on how it is using the image.
Libvirt may be able to provide better locks, with the help of its
virtlockd daemon.

daemon owning locks is a problem:
- there are distributed cases
- daemons restart from time to time

Re: [Qemu-devel] [PATCH v2] net/slirp: Tell the users when they are using deprecated options

[Jason Wang]

On 01/13/2016 04:05 PM, Thomas Huth wrote:
> We don't want to support the legacy -tftp, -bootp, -smb and
> -net channel options forever. So let's start telling the users
> that they are deprecated and what option should be used instead.
>
> Signed-off-by: Thomas Huth 
> ---
>  v2: Changed the texts to tell the users what options should be used instead.

Applied to my -net.

Thanks

>
>  net/slirp.c | 3 +++
>  os-posix.c  | 3 +++
>  vl.c| 6 ++
>  3 files changed, 12 insertions(+)
>
> diff --git a/net/slirp.c b/net/slirp.c
> index f505570..eac4fc2 100644
> --- a/net/slirp.c
> +++ b/net/slirp.c
> @@ -784,6 +784,9 @@ int net_slirp_parse_legacy(QemuOptsList *opts_list, const 
> char *optarg, int *ret
>  return 0;
>  }
>  
> +error_report("The '-net channel' option is deprecated. "
> + "Please use '-netdev user,guestfwd=...' instead.");
> +
>  /* handle legacy -net channel,port:chr */
>  optarg += strlen("channel,");
>  
> diff --git a/os-posix.c b/os-posix.c
> index e4da406..87e2a16 100644
> --- a/os-posix.c
> +++ b/os-posix.c
> @@ -40,6 +40,7 @@
>  #include "net/slirp.h"
>  #include "qemu-options.h"
>  #include "qemu/rcu.h"
> +#include "qemu/error-report.h"
>  
>  #ifdef CONFIG_LINUX
>  #include 
> @@ -139,6 +140,8 @@ void os_parse_cmd_args(int index, const char *optarg)
>  switch (index) {
>  #ifdef CONFIG_SLIRP
>  case QEMU_OPTION_smb:
> +error_report("The -smb option is deprecated. "
> + "Please use '-netdev user,smb=...' instead.");
>  if (net_slirp_smb(optarg) < 0)
>  exit(1);
>  break;
> diff --git a/vl.c b/vl.c
> index 5aaea77..71c4eee 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -3314,12 +3314,18 @@ int main(int argc, char **argv, char **envp)
>  #endif
>  #ifdef CONFIG_SLIRP
>  case QEMU_OPTION_tftp:
> +error_report("The -tftp option is deprecated. "
> + "Please use '-netdev user,tftp=...' instead.");
>  legacy_tftp_prefix = optarg;
>  break;
>  case QEMU_OPTION_bootp:
> +error_report("The -bootp option is deprecated. "
> + "Please use '-netdev user,bootfile=...' 
> instead.");
>  legacy_bootp_filename = optarg;
>  break;
>  case QEMU_OPTION_redir:
> +error_report("The -redir option is deprecated. "
> + "Please use '-netdev user,hostfwd=...' 
> instead.");
>  if (net_slirp_redir(optarg) < 0)
>  exit(1);
>  break;

Re: [Qemu-devel] [PATCH v2 1/5] virtio-net: use the backend cross-endian capabilities

[Laurent Vivier]

On 13/01/2016 10:06, Greg Kurz wrote:
> On Tue, 12 Jan 2016 18:24:28 +0100
> Laurent Vivier  wrote:
> 
>> On 11/01/2016 17:12, Greg Kurz wrote:
>>> When running a fully emulated device in cross-endian conditions, including
>>> a virtio 1.0 device offered to a big endian guest, we need to fix the vnet
>>> headers. This is currently handled by the virtio_net_hdr_swap() function
>>> in the core virtio-net code but it should actually be handled by the net
>>> backend.
>>>
>>> With this patch, virtio-net now tries to configure the backend to do the
>>> endian fixing when the device starts (i.e. drivers sets the CONFIG_OK bit).
>>> If the backend cannot support the requested endiannes, we have to fallback
>>> onto virtio_net_hdr_swap(): this is recorded in the needs_vnet_hdr_swap 
>>> flag,
>>> to be used in the TX and RX paths.
>>>
>>> Note that we reset the backend to the default behaviour (guest native
>>> endianness) when the device stops (i.e. device status had CONFIG_OK bit and
>>> driver unsets it). This is needed, with the linux tap backend at least,
>>> otherwise the guest may loose network connectivity if rebooted into a
>>> different endianness.
>>>
>>> The current vhost-net code also tries to configure net backends. This will
>>> be no more needed and will be reverted in a subsequent patch.
>>>
>>> Signed-off-by: Greg Kurz 
>>> ---
>>> v2:
>>> - dropped useless check in the 'else if' branch in virtio_net_vnet_status()
>>> - merged virtio_net_vhost_status() change from patch 2
>>> - use semicolon in "backend does no support..." error message
>>> - merged patch 3 (drop the virtio_needs_swap() helper)
>>> - provided some more details in changelog and comments
>>> ---
>>>  hw/net/virtio-net.c   |   49 
>>> +++--
>>>  include/hw/virtio/virtio-access.h |9 ---
>>>  include/hw/virtio/virtio-net.h|1 +
>>>  3 files changed, 48 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
>>> index a877614e3e7a..497fb7119a08 100644
>>> --- a/hw/net/virtio-net.c
>>> +++ b/hw/net/virtio-net.c
>>> @@ -128,6 +128,13 @@ static void virtio_net_vhost_status(VirtIONet *n, 
>>> uint8_t status)
>>>  if (!n->vhost_started) {
>>>  int r, i;
>>>  
>>> +if (n->needs_vnet_hdr_swap) {
>>> +error_report("backend does not support %s vnet headers; "
>>> + "falling back on userspace virtio",
>>> + virtio_is_big_endian(vdev) ? "BE" : "LE");
>>> +return;
>>> +}
>>> +
>>>  /* Any packets outstanding? Purge them to avoid touching rings
>>>   * when vhost is running.
>>>   */
>>> @@ -152,6 +159,40 @@ static void virtio_net_vhost_status(VirtIONet *n, 
>>> uint8_t status)
>>>  }
>>>  }
>>>  
>>> +static void virtio_net_vnet_status(VirtIONet *n, uint8_t status)
>>> +{
>>> +VirtIODevice *vdev = VIRTIO_DEVICE(n);
>>> +NetClientState *peer = qemu_get_queue(n->nic)->peer;
>>> +
>>> +if (virtio_net_started(n, status)) {
>>> +int r;
>>> +
>>> +/* Before using the device, we tell the network backend about the
>>> + * endianness to use when parsing vnet headers. If the backend 
>>> can't
>>> + * do it, we fallback onto fixing the headers in the core 
>>> virtio-net
>>> + * code.
>>> + */
>>> +if (virtio_is_big_endian(vdev)) {
>>> +r = qemu_set_vnet_be(peer, true);
>>> +} else {
>>> +r = qemu_set_vnet_le(peer, true);
>>> +}  
>>
>> If endianess of the guest and the virtio device is the same, but r is <
>> 0 (-ENOSYS or -EINVAL) you will badly swap header (and disable vhost).
>>
> 
> This can only happen if the endianness of the host is not the same as the

OK, you're right, I was studying sources without commit:

052bd52 net: don't set native endianness

Sorry for the noise...

> endianness of the device. In this case (we usually call cross-endian) the
> vnet headers must be byteswapped but the backend cannot handle it. This
> has two consequences:
> - vhost cannot be used since it requires the backend to support cross-endian
>   vnet headers, so we fallback onto full emulation in QEMU
> - the emulation code must byteswap vnet headers
> 
>> I think you need something like this to fall back to the old method:
>>
>> if (r < 0) {
>> #ifdef HOST_WORDS_BIGENDIAN
>> r = virtio_access_is_big_endian(vdev) ? false : true;
>> #else
>> r = virtio_access_is_big_endian(vdev) ? true : false;
>> #endif
>> }
>>
>>
>> But...
>>
>>> +n->needs_vnet_hdr_swap = !!r;
>>> +} else if (virtio_net_started(n, vdev->status)) {
>>> +/* After using the device, we need to reset the network backend to
>>> + * the default (guest native endianness), otherwise the guest may
>>> + * loose network connectivity if it is rebooted into a 

Re: [Qemu-devel] [PATCH] ARM: Virt: Don't generate RTC ACPI node when using UEFI

[Laszlo Ersek]

On 01/12/16 16:30, Peter Maydell wrote:
> On 12 January 2016 at 15:24, Shannon Zhao  wrote:
>> When booting VM through UEFI, UEFI takes ownership of the RTC hardware.
>> To DTB UEFI could call libfdt api to disable the RTC device node, but to
>> ACPI it couldn't do that. Therefore, we don't generate the RTC ACPI
>> device in QEMU when using UEFI.
> 
> I don't really understand this. I thought that if we were
> using ACPI then we would always be doing it via UEFI?

Yes.

Let my try to summarize here too:

- kernel booted without UEFI: consumes DTB, accesses RTC directly

- kernel booted with UEFI, consumes DTB: UEFI owns RTC, kernel uses UEFI
services, UEFI keeps kernel from directly accessing the RTC by disabling
the RTC node in the DTB, using libfdt

- kernel booted with UEFI, consumes ACPI: UEFI owns RTC, kernel uses
UEFI services, UEFI keeps kernel from directly accessing the RTC by...,
well, it can't, because we don't *parse* AML in UEFI.

> Also I think if UEFI wants to take command of some of the
> hardware it ought to be UEFI's job to adjust the tables
> accordingly before it passes them on to the guest OS.

In theory, maybe.

In practice, no; we have the ACPI linker/loader for that. Either the
generated AML must not contain the RTC node, or else some linker/loader
script command(s) have to be added that cause the guest firmware's
linker/loader client to patch the device out. Generally speaking
however, the linker/loader can only patch data tables, not definition
blocks (AML).

You might ask why the DTB is different then. Why aren't I suggesting, in
paralle, that the DTB generator behave similarly in QEMU? The answer is
that the firmware needs the RTC node in the DTB for its *own* purposes
as well, so the RTC node must be in the DTB in any case.

ACPI is different. The firmware downloads it, patches it blindly (=
processes the linker/loader script), then passes it to the OS. That's all.

Formatting AML is doable in the firmware; parsing / modifying AML that
was originally generated by QEMU is practically impossible. If you
recall the *original* introducion of the ACPI interpreter into the
kernel -- there was a huge uproar. Today Linux has a customized version
of the ACPI CA framework. edk2 doesn't, and shouldn't.

Plus, *intelligently* modifying AML in the firmware defeats the purpose
of the ACPI linker/loader -- which is to allow the firmware to remain
ignorant about ACPI.

Thanks
Laszlo

Re: [Qemu-devel] [PATCH] ARM: Virt: Don't generate RTC ACPI node when using UEFI

[Ard Biesheuvel]

On 13 January 2016 at 11:18, Laszlo Ersek  wrote:
> On 01/12/16 16:24, Shannon Zhao wrote:
>> When booting VM through UEFI, UEFI takes ownership of the RTC hardware.
>> To DTB UEFI could call libfdt api to disable the RTC device node, but to
>> ACPI it couldn't do that. Therefore, we don't generate the RTC ACPI
>> device in QEMU when using UEFI.
>>
>> Signed-off-by: Shannon Zhao 
>> ---
>>  hw/arm/virt-acpi-build.c | 13 +++--
>>  hw/arm/virt.c|  5 -
>>  include/hw/arm/virt-acpi-build.h |  1 +
>>  3 files changed, 16 insertions(+), 3 deletions(-)
>>
>> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
>> index 0caf5ce..cccec79 100644
>> --- a/hw/arm/virt-acpi-build.c
>> +++ b/hw/arm/virt-acpi-build.c
>> @@ -575,8 +575,17 @@ build_dsdt(GArray *table_data, GArray *linker, 
>> VirtGuestInfo *guest_info)
>>  acpi_dsdt_add_cpus(scope, guest_info->smp_cpus);
>>  acpi_dsdt_add_uart(scope, [VIRT_UART],
>> (irqmap[VIRT_UART] + ARM_SPI_BASE));
>> -acpi_dsdt_add_rtc(scope, [VIRT_RTC],
>> -  (irqmap[VIRT_RTC] + ARM_SPI_BASE));
>> +
>> +/* When booting VM through UEFI, UEFI takes ownership of the RTC 
>> hardware.
>> + * To DTB UEFI could call libfdt api to disable the RTC device node, 
>> but to
>> + * ACPI it couldn't do that. Therefore, we don't generate the RTC ACPI
>> + * device here when using UEFI.
>> + */
>> +if (guest_info->acpi_rtc) {
>> +acpi_dsdt_add_rtc(scope, [VIRT_RTC],
>> +  (irqmap[VIRT_RTC] + ARM_SPI_BASE));
>> +}
>> +
>>  acpi_dsdt_add_flash(scope, [VIRT_FLASH]);
>>  acpi_dsdt_add_virtio(scope, [VIRT_MMIO],
>>  (irqmap[VIRT_MMIO] + ARM_SPI_BASE), 
>> NUM_VIRTIO_TRANSPORTS);
>> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
>> index fd52b76..de12037 100644
>> --- a/hw/arm/virt.c
>> +++ b/hw/arm/virt.c
>> @@ -1002,6 +1002,7 @@ static void machvirt_init(MachineState *machine)
>>  VirtGuestInfoState *guest_info_state = g_malloc0(sizeof 
>> *guest_info_state);
>>  VirtGuestInfo *guest_info = _info_state->info;
>>  char **cpustr;
>> +bool firmware_loaded;
>>
>>  if (!cpu_model) {
>>  cpu_model = "cortex-a15";
>> @@ -1124,12 +1125,14 @@ static void machvirt_init(MachineState *machine)
>>  create_fw_cfg(vbi, _space_memory);
>>  rom_set_fw(fw_cfg_find());
>>
>> +firmware_loaded = bios_name || drive_get(IF_PFLASH, 0, 0);
>>  guest_info->smp_cpus = smp_cpus;
>>  guest_info->fw_cfg = fw_cfg_find();
>>  guest_info->memmap = vbi->memmap;
>>  guest_info->irqmap = vbi->irqmap;
>>  guest_info->use_highmem = vms->highmem;
>>  guest_info->gic_version = gic_version;
>> +guest_info->acpi_rtc = !firmware_loaded;
>>  guest_info_state->machine_done.notify = virt_guest_info_machine_done;
>>  qemu_add_machine_init_done_notifier(_info_state->machine_done);
>>
>> @@ -1141,7 +1144,7 @@ static void machvirt_init(MachineState *machine)
>>  vbi->bootinfo.board_id = -1;
>>  vbi->bootinfo.loader_start = vbi->memmap[VIRT_MEM].base;
>>  vbi->bootinfo.get_dtb = machvirt_dtb;
>> -vbi->bootinfo.firmware_loaded = bios_name || drive_get(IF_PFLASH, 0, 0);
>> +vbi->bootinfo.firmware_loaded = firmware_loaded;
>>  arm_load_kernel(ARM_CPU(first_cpu), >bootinfo);
>>
>>  /*
>> diff --git a/include/hw/arm/virt-acpi-build.h 
>> b/include/hw/arm/virt-acpi-build.h
>> index 744b666..6f412a4 100644
>> --- a/include/hw/arm/virt-acpi-build.h
>> +++ b/include/hw/arm/virt-acpi-build.h
>> @@ -33,6 +33,7 @@ typedef struct VirtGuestInfo {
>>  const int *irqmap;
>>  bool use_highmem;
>>  int gic_version;
>> +bool acpi_rtc;
>>  } VirtGuestInfo;
>>
>>
>>
>
> I realize that Peter is not buying the argument just yet, but I'd like
> to offer a review here nonetheless.
>

I am not buying it either, to be honest. In fact, I think it is
another reason why we should mandate UEFI when using ACPI (which is
already the case in practice). Then, we can simply omit the RTC ACPI
node entirely.


> I think the patch is good, except the location and the wording of the
> code comment.
>
> (1) The code comment should be located right above the
>
> guest_info->acpi_rtc = !firmware_loaded;
>
> assignment.
>
> (2) I think the code comment should simply use indicative mood:
>
> When booting the VM with UEFI, UEFI takes ownership of the RTC
> hardware. While UEFI can use libfdt to disable the RTC device node
> in the DTB that it passes to the OS, it cannot modify AML.
> Therefore, we won't generate the RTC ACPI device at all when using
> UEFI.
>
> With those changes, I'm willing to R-b.
>
> Thanks
> Laszlo

Re: [Qemu-devel] Status of my hacks on the MTTCG WIP branch

[Alex Bennée]

Pranith Kumar  writes:

> Hi Alex,
>
> On Tue, Jan 12, 2016 at 12:29 PM, Alex Bennée 
> wrote:
>
>>
> https://github.com/stsquad/qemu/tree/mttcg/multi_tcg_v8_wip_ajb_fix_locks
>>
>
> I built this branch and ran an arm64 guest. It seems to be failing
> similarly to what I reported earlier:
>
> #0  0x72211cc9 in __GI_raise (sig=sig@entry=6) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:56
> #1  0x722150d8 in __GI_abort () at abort.c:89
> #2  0x5572014c in qemu_ram_addr_from_host_nofail
> (ptr=0xffc000187863) at /home/pranith/devops/code/qemu/cputlb.c:357
> #3  0x557209dd in get_page_addr_code (env1=0x56702058,
> addr=18446743798833248356) at /home/pranith/devops/code/qemu/cputlb.c:568
> #4  0x556db98c in tb_find_physical (cpu=0x566f9dd0,
> pc=18446743798833248356, cs_base=0, flags=18446744071830503424) at
> /home/pranith/devops/code/qemu/cpu-exec.c:224
> #5  0x556dbaf4 in tb_find_slow (cpu=0x566f9dd0,
> pc=18446743798833248356, cs_base=0, flags=18446744071830503424) at
> /home/pranith/devops/code/qemu/cpu-exec.c:268
> #6  0x556dbc77 in tb_find_fast (cpu=0x566f9dd0) at
> /home/pranith/devops/code/qemu/cpu-exec.c:311
> #7  0x556dc0f1 in cpu_arm_exec (cpu=0x566f9dd0) at
> /home/pranith/devops/code/qemu/cpu-exec.c:492
> #8  0x557050ee in tcg_cpu_exec (cpu=0x566f9dd0) at
> /home/pranith/devops/code/qemu/cpus.c:1486
> #9  0x557051af in tcg_exec_all (cpu=0x566f9dd0) at
> /home/pranith/devops/code/qemu/cpus.c:1515
> #10 0x55704800 in qemu_tcg_cpu_thread_fn (arg=0x566f9dd0) at
> /home/pranith/devops/code/qemu/cpus.c:1187
> #11 0x725a8182 in start_thread (arg=0x7fffd20c8700) at
> pthread_create.c:312
> #12 0x722d547d in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
>
> The arguments I used are as follows:
>
> (gdb) show args
>
> Argument list to give program being debugged when it is started is "-m
> 1024M -M virt -cpu cortex-a57 -global virtio-blk-device.scsi=off -device
> virtio-scsi-device,id=scsi -drive
> file=arm64disk.qcow2,id=coreimg,cache=unsafe,if=none -device
> scsi-hd,drive=coreimg -netdev user,id=unet -device
> virtio-net-device,netdev=unet -kernel vmlinuz -initrd initrd.img -append
> root=/dev/sda2 -display sdl -redir tcp:::22 -smp 2".

With my command line:

/home/alex/lsrc/qemu/qemu.git/aarch64-softmmu/qemu-system-aarch64
-machine type=virt -display none -smp 1 -m 4096 -cpu cortex-a57 -serial
telnet:127.0.0.1: -monitor stdio -netdev
user,id=unet,hostfwd=tcp::-:22 -device virtio-net-device,netdev=unet
-drive
file=/home/alex/lsrc/qemu/images/jessie-arm64.qcow2,id=myblock,index=0,if=none
-device virtio-blk-device,drive=myblock -kernel
/home/alex/lsrc/qemu/images/aarch64-current-linux-kernel-only.img
-append console=ttyAMA0 root=/dev/vda1 -s -name arm,debug-threads=on
-smp 4

I see the bad ram pointer failure in aarch64. It work in plain arm. Time
to dig out the debugging tools again ;-)

>
> Does something look obviously wrong to you in the arg list?
>
> Thanks!


--
Alex Bennée

Re: [Qemu-devel] [PATCH 1/1] blk: do not select PFLASH device for internal snapshot

[Laszlo Ersek]

meta comment here:

On 01/12/16 16:47, Denis V. Lunev wrote:

> P.S. Here is a summary that my colleague has receiver from libvirt
>list.
> 
>  Forwarded Message 
> Subject: Re: Snapshotting OVMF guests
> Date: Mon, 11 Jan 2016 13:56:29 +0100
> From: Laszlo Ersek 
> To: Dmitry Andreev 
> CC: Michal Privoznik , Markus Armbruster
> 
> 
> Hello Dmitry,
> 
> [...]

Your colleague Dmitry did not receive this from the libvirt list. He
received the from me in private. See the headers above.

Please do not publicize a private exchange without asking for permission
first.

In the present case I don't mind it. I stand by everything I said, and I
would have written mostly the same if I had been contacted publicly,
on-list.

But if you contact me in private *first*, then I expect the discussion
to remain private. If you want to forward the email to a public list,
please ask for permission. Otherwise I might consider it more prudent
for myself to answer all private queries with just "please ask me this
on the list instead".

I appreciate that you guys are working on this, but let's handle emails
sensibly.

Thanks
Laszlo

Re: [Qemu-devel] [PATCH] vnc: fix tls-creds error message

[Daniel P. Berrange]

On Wed, Jan 13, 2016 at 11:36:00AM +0100, Wolfgang Bumiller wrote:
> The parameter is called 'tls-creds', 'credid' is just the
> variable name in the code.
> 
> Signed-off-by: Wolfgang Bumiller 
> ---
>  ui/vnc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Daniel P. Berrange 

Re: [Qemu-devel] [PATCH v2 1/2] blockdev: Error out on negative throttling option values

[Alberto Garcia]

On Wed 13 Jan 2016 12:02:00 PM CET, Fam Zheng wrote:

>> > Check the number range so this case is catched and reported.
>> 
>> I still don't know why qemu_opt_get_number() convert silently
>> negative numbers into positive ones, shouldn't it just fail with an
>> "invalid parameter" error?
>
> Because the parsing is done with strtoull(3) and unfortunately its man
> page says "negative values are considered valid input and are silently
> converted to the equivalent unsigned long int value."

I see... parse_uint() from cutils.c handles that by making an explicit
check for negative numbers. It probably makes sense to apply the same
solution (or even merge the code to the extent to which it's possible).

I also noticed that there's a couple of places where we're calling
qemu_opt_get_number() passing -1 as default value, so maybe that API
needs to be reviewed anyway.

Berto

[Qemu-devel] [PATCH] replay: character devices

[Pavel Dovgalyuk]

This patch implements record and replay of character devices.
It records chardevs communication in replay mode. Recorded information
include data read from backend and counter of bytes written
from frontend to backend to preserve frontend internal state.
If character device was configured through the command line in record mode,
then in replay mode it should be also added to command line. Backend of
the character device could be changed in replay mode.
Replaying of devices that perform ioctl and get_msgfd operations is not
supported.
gdbstub which also acts as a backend is not recorded to allow controlling
the replaying through gdb.

Signed-off-by: Pavel Dovgalyuk 
---
 gdbstub.c|2 -
 include/sysemu/char.h|   26 
 include/sysemu/replay.h  |   12 ++
 qemu-char.c  |   56 ---
 replay/Makefile.objs |1 
 replay/replay-char.c |   97 ++
 replay/replay-events.c   |   17 +++-
 replay/replay-internal.h |   15 +++
 replay/replay.c  |   25 +++-
 9 files changed, 240 insertions(+), 11 deletions(-)
 create mode 100755 replay/replay-char.c

diff --git a/gdbstub.c b/gdbstub.c
index 9c29aa0..7eddc9d 100644
--- a/gdbstub.c
+++ b/gdbstub.c
@@ -1751,7 +1751,7 @@ int gdbserver_start(const char *device)
 sigaction(SIGINT, , NULL);
 }
 #endif
-chr = qemu_chr_new("gdb", device, NULL);
+chr = qemu_chr_new_noreplay("gdb", device, NULL);
 if (!chr)
 return -1;
 
diff --git a/include/sysemu/char.h b/include/sysemu/char.h
index aff193f..1218526 100644
--- a/include/sysemu/char.h
+++ b/include/sysemu/char.h
@@ -85,6 +85,7 @@ struct CharDriverState {
 int is_mux;
 guint fd_in_tag;
 QemuOpts *opts;
+bool replay;
 QTAILQ_ENTRY(CharDriverState) next;
 };
 
@@ -126,6 +127,22 @@ CharDriverState *qemu_chr_new(const char *label, const 
char *filename,
   void (*init)(struct CharDriverState *s));
 
 /**
+ * @qemu_chr_new_noreplay:
+ *
+ * Create a new character backend from a URI.
+ * Character device communications are not written
+ * into the replay log.
+ *
+ * @label the name of the backend
+ * @filename the URI
+ * @init not sure..
+ *
+ * Returns: a new character backend
+ */
+CharDriverState *qemu_chr_new_noreplay(const char *label, const char *filename,
+   void (*init)(struct CharDriverState 
*s));
+
+/**
  * @qemu_chr_delete:
  *
  * Destroy a character backend and remove it from the list of
@@ -328,6 +345,15 @@ int qemu_chr_be_can_write(CharDriverState *s);
  */
 void qemu_chr_be_write(CharDriverState *s, uint8_t *buf, int len);
 
+/**
+ * @qemu_chr_be_write_impl:
+ *
+ * Implementation of back end writing. Used by replay module.
+ *
+ * @buf a buffer to receive data from the front end
+ * @len the number of bytes to receive from the front end
+ */
+void qemu_chr_be_write_impl(CharDriverState *s, uint8_t *buf, int len);
 
 /**
  * @qemu_chr_be_event:
diff --git a/include/sysemu/replay.h b/include/sysemu/replay.h
index abb4688..3c4a988 100644
--- a/include/sysemu/replay.h
+++ b/include/sysemu/replay.h
@@ -117,4 +117,16 @@ void replay_input_event(QemuConsole *src, InputEvent *evt);
 /*! Adds input sync event to the queue */
 void replay_input_sync_event(void);
 
+/* Character device */
+
+/*! Registers char driver to save it's events */
+void replay_register_char_driver(struct CharDriverState *chr);
+/*! Saves write to char device event to the log */
+void replay_chr_be_write(struct CharDriverState *s, uint8_t *buf, int len);
+
+/* Other data */
+
+/*! Writes or reads integer value to/from replay log. */
+void replay_data_int(int *data);
+
 #endif
diff --git a/qemu-char.c b/qemu-char.c
index 2969c44..b2a1b7d 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -32,6 +32,7 @@
 #include "qapi/qmp-input-visitor.h"
 #include "qapi/qmp-output-visitor.h"
 #include "qapi-visit.h"
+#include "sysemu/replay.h"
 
 #include 
 #include 
@@ -193,6 +194,9 @@ int qemu_chr_fe_write(CharDriverState *s, const uint8_t 
*buf, int len)
 
 qemu_mutex_lock(>chr_write_lock);
 ret = s->chr_write(s, buf, len);
+if (s->replay) {
+replay_data_int();
+}
 qemu_mutex_unlock(>chr_write_lock);
 return ret;
 }
@@ -262,9 +266,19 @@ int qemu_chr_fe_read_all(CharDriverState *s, uint8_t *buf, 
int len)
 
 int qemu_chr_fe_ioctl(CharDriverState *s, int cmd, void *arg)
 {
-if (!s->chr_ioctl)
-return -ENOTSUP;
-return s->chr_ioctl(s, cmd, arg);
+int res;
+if (!s->chr_ioctl) {
+res = -ENOTSUP;
+} else {
+res = s->chr_ioctl(s, cmd, arg);
+if (s->replay) {
+fprintf(stderr,
+"Replay: ioctl is not supported for serial devices yet\n");
+exit(1);
+}
+}
+
+return res;
 }
 
 int qemu_chr_be_can_write(CharDriverState *s)
@@ -274,17 

Re: [Qemu-devel] [PATCH v2 1/2] blockdev: Error out on negative throttling option values

[Alberto Garcia]

On Wed 13 Jan 2016 01:52:29 AM CET, Fam Zheng wrote:

> The implicit casting from unsigned int to double changes negative values
> into large positive numbers and accepts them.  We should instead print
> an error.
>
> Check the number range so this case is catched and reported.

I still don't know why qemu_opt_get_number() convert silently negative
numbers into positive ones, shouldn't it just fail with an "invalid
parameter" error?

> +#define THROTTLE_VALUE_MAX 1000L

This is larger than LONG_MAX in 32-bit systems, I don't know if you need
to use LL instead.

Berto

Re: [Qemu-devel] [PATCH v6 0/3] i386: expose floppy-related objects in SSDT

[Igor Mammedov]

On Mon, 11 Jan 2016 16:35:31 +0100
Igor Mammedov  wrote:

> v5->v6:
>  - rebased on top DSDT converted to AMP API
>  - dropped intermediate structs for one time used floppy parameters
>which simplifies code a bit.
Roman,
I don't have OVMF+Win setup,
Could you test this series and reply with Tested-by if it works?


> 
> Windows on UEFI systems is only capable of detecting the presence and
> the type of floppy drives via corresponding ACPI objects.
> 
> Those objects are added in patch 5; the preceding ones pave the way to
> it, by making the necessary data public and by moving the whole
> floppy drive controller description into runtime-generated SSDT.
> 
> Roman Kagan (3):
>   i386/acpi: make floppy controller object dynamic
>   expose floppy drive geometry and CMOS type
>   i386: populate floppy drive information in DSDT
> 
>  hw/block/fdc.c | 11 +++
>  hw/i386/acpi-build.c   | 84 
> +++---
>  hw/i386/pc.c   |  2 +-
>  include/hw/block/fdc.h |  2 ++
>  include/hw/i386/pc.h   |  1 +
>  5 files changed, 74 insertions(+), 26 deletions(-)
> 

Re: [Qemu-devel] [PATCH] ARM: Virt: Don't generate RTC ACPI node when using UEFI

[Laszlo Ersek]

On 01/13/16 11:20, Ard Biesheuvel wrote:
> On 13 January 2016 at 11:18, Laszlo Ersek  wrote:
>> On 01/12/16 16:24, Shannon Zhao wrote:
>>> When booting VM through UEFI, UEFI takes ownership of the RTC hardware.
>>> To DTB UEFI could call libfdt api to disable the RTC device node, but to
>>> ACPI it couldn't do that. Therefore, we don't generate the RTC ACPI
>>> device in QEMU when using UEFI.
>>>
>>> Signed-off-by: Shannon Zhao 
>>> ---
>>>  hw/arm/virt-acpi-build.c | 13 +++--
>>>  hw/arm/virt.c|  5 -
>>>  include/hw/arm/virt-acpi-build.h |  1 +
>>>  3 files changed, 16 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
>>> index 0caf5ce..cccec79 100644
>>> --- a/hw/arm/virt-acpi-build.c
>>> +++ b/hw/arm/virt-acpi-build.c
>>> @@ -575,8 +575,17 @@ build_dsdt(GArray *table_data, GArray *linker, 
>>> VirtGuestInfo *guest_info)
>>>  acpi_dsdt_add_cpus(scope, guest_info->smp_cpus);
>>>  acpi_dsdt_add_uart(scope, [VIRT_UART],
>>> (irqmap[VIRT_UART] + ARM_SPI_BASE));
>>> -acpi_dsdt_add_rtc(scope, [VIRT_RTC],
>>> -  (irqmap[VIRT_RTC] + ARM_SPI_BASE));
>>> +
>>> +/* When booting VM through UEFI, UEFI takes ownership of the RTC 
>>> hardware.
>>> + * To DTB UEFI could call libfdt api to disable the RTC device node, 
>>> but to
>>> + * ACPI it couldn't do that. Therefore, we don't generate the RTC ACPI
>>> + * device here when using UEFI.
>>> + */
>>> +if (guest_info->acpi_rtc) {
>>> +acpi_dsdt_add_rtc(scope, [VIRT_RTC],
>>> +  (irqmap[VIRT_RTC] + ARM_SPI_BASE));
>>> +}
>>> +
>>>  acpi_dsdt_add_flash(scope, [VIRT_FLASH]);
>>>  acpi_dsdt_add_virtio(scope, [VIRT_MMIO],
>>>  (irqmap[VIRT_MMIO] + ARM_SPI_BASE), 
>>> NUM_VIRTIO_TRANSPORTS);
>>> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
>>> index fd52b76..de12037 100644
>>> --- a/hw/arm/virt.c
>>> +++ b/hw/arm/virt.c
>>> @@ -1002,6 +1002,7 @@ static void machvirt_init(MachineState *machine)
>>>  VirtGuestInfoState *guest_info_state = g_malloc0(sizeof 
>>> *guest_info_state);
>>>  VirtGuestInfo *guest_info = _info_state->info;
>>>  char **cpustr;
>>> +bool firmware_loaded;
>>>
>>>  if (!cpu_model) {
>>>  cpu_model = "cortex-a15";
>>> @@ -1124,12 +1125,14 @@ static void machvirt_init(MachineState *machine)
>>>  create_fw_cfg(vbi, _space_memory);
>>>  rom_set_fw(fw_cfg_find());
>>>
>>> +firmware_loaded = bios_name || drive_get(IF_PFLASH, 0, 0);
>>>  guest_info->smp_cpus = smp_cpus;
>>>  guest_info->fw_cfg = fw_cfg_find();
>>>  guest_info->memmap = vbi->memmap;
>>>  guest_info->irqmap = vbi->irqmap;
>>>  guest_info->use_highmem = vms->highmem;
>>>  guest_info->gic_version = gic_version;
>>> +guest_info->acpi_rtc = !firmware_loaded;
>>>  guest_info_state->machine_done.notify = virt_guest_info_machine_done;
>>>  qemu_add_machine_init_done_notifier(_info_state->machine_done);
>>>
>>> @@ -1141,7 +1144,7 @@ static void machvirt_init(MachineState *machine)
>>>  vbi->bootinfo.board_id = -1;
>>>  vbi->bootinfo.loader_start = vbi->memmap[VIRT_MEM].base;
>>>  vbi->bootinfo.get_dtb = machvirt_dtb;
>>> -vbi->bootinfo.firmware_loaded = bios_name || drive_get(IF_PFLASH, 0, 
>>> 0);
>>> +vbi->bootinfo.firmware_loaded = firmware_loaded;
>>>  arm_load_kernel(ARM_CPU(first_cpu), >bootinfo);
>>>
>>>  /*
>>> diff --git a/include/hw/arm/virt-acpi-build.h 
>>> b/include/hw/arm/virt-acpi-build.h
>>> index 744b666..6f412a4 100644
>>> --- a/include/hw/arm/virt-acpi-build.h
>>> +++ b/include/hw/arm/virt-acpi-build.h
>>> @@ -33,6 +33,7 @@ typedef struct VirtGuestInfo {
>>>  const int *irqmap;
>>>  bool use_highmem;
>>>  int gic_version;
>>> +bool acpi_rtc;
>>>  } VirtGuestInfo;
>>>
>>>
>>>
>>
>> I realize that Peter is not buying the argument just yet, but I'd like
>> to offer a review here nonetheless.
>>
> 
> I am not buying it either, to be honest. In fact, I think it is
> another reason why we should mandate UEFI when using ACPI (which is
> already the case in practice). Then, we can simply omit the RTC ACPI
> node entirely.

Good point.

Laszlo

> 
> 
>> I think the patch is good, except the location and the wording of the
>> code comment.
>>
>> (1) The code comment should be located right above the
>>
>> guest_info->acpi_rtc = !firmware_loaded;
>>
>> assignment.
>>
>> (2) I think the code comment should simply use indicative mood:
>>
>> When booting the VM with UEFI, UEFI takes ownership of the RTC
>> hardware. While UEFI can use libfdt to disable the RTC device node
>> in the DTB that it passes to the OS, it cannot modify AML.
>> Therefore, we won't generate the RTC ACPI device at all when using
>> UEFI.
>>
>> With those changes, I'm willing to R-b.
>>
>> Thanks
>> Laszlo

[Qemu-devel] [PATCH] qemu-img: Speed up comparing empty/zero images

[Fam Zheng]

Two empty raw files are always compared by actually reading data even if
there is no data, because BDRV_BLOCK_ZERO is considered "allocated" in
bdrv_is_allocated_above().  That is inefficient.

Use bdrv_get_block_status_above() for more information, and skip the
consecutive zero sectors.

This brings a huge speed up in comparing sparse/empty raw images:

$ qemu-img create a 1G

$ time ~/build/master/bin/qemu-img compare a a
Images are identical.

real0m6.583s
user0m0.191s
sys 0m6.367s

$ time qemu-img compare a a
Images are identical.

real0m0.033s
user0m0.003s
sys 0m0.031s

Signed-off-by: Fam Zheng 
---
 qemu-img.c | 45 ++---
 1 file changed, 30 insertions(+), 15 deletions(-)

diff --git a/qemu-img.c b/qemu-img.c
index 3d48b4f..82f704f 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -1074,28 +1074,50 @@ static int img_compare(int argc, char **argv)
 }
 
 for (;;) {
+int64_t status1, status2;
 nb_sectors = sectors_to_process(total_sectors, sector_num);
 if (nb_sectors <= 0) {
 break;
 }
-allocated1 = bdrv_is_allocated_above(bs1, NULL, sector_num, nb_sectors,
- );
-if (allocated1 < 0) {
+status1 = bdrv_get_block_status_above(bs1, NULL, sector_num,
+  total_sectors1 - sector_num,
+  );
+if (status1 < 0) {
 ret = 3;
 error_report("Sector allocation test failed for %s", filename1);
 goto out;
 }
+allocated1 = status1 & BDRV_BLOCK_ALLOCATED;
 
-allocated2 = bdrv_is_allocated_above(bs2, NULL, sector_num, nb_sectors,
- );
-if (allocated2 < 0) {
+status2 = bdrv_get_block_status_above(bs2, NULL, sector_num,
+  total_sectors2 - sector_num,
+  );
+if (status2 < 0) {
 ret = 3;
 error_report("Sector allocation test failed for %s", filename2);
 goto out;
 }
-nb_sectors = MIN(pnum1, pnum2);
+allocated2 = status2 & BDRV_BLOCK_ALLOCATED;
+if (pnum1) {
+nb_sectors = MIN(nb_sectors, pnum1);
+}
+if (pnum2) {
+nb_sectors = MIN(nb_sectors, pnum2);
+}
 
-if (allocated1 == allocated2) {
+if (strict) {
+if ((status1 & ~BDRV_BLOCK_OFFSET_MASK) !=
+(status2 & ~BDRV_BLOCK_OFFSET_MASK)) {
+ret = 1;
+qprintf(quiet, "Strict mode: Offset %" PRId64
+" block status mismatch!\n",
+sectors_to_bytes(sector_num));
+goto out;
+}
+}
+if ((status1 & BDRV_BLOCK_ZERO) && (status2 & BDRV_BLOCK_ZERO)) {
+nb_sectors = MIN(pnum1, pnum2);
+} else if (allocated1 == allocated2) {
 if (allocated1) {
 ret = blk_read(blk1, sector_num, buf1, nb_sectors);
 if (ret < 0) {
@@ -1123,13 +1145,6 @@ static int img_compare(int argc, char **argv)
 }
 }
 } else {
-if (strict) {
-ret = 1;
-qprintf(quiet, "Strict mode: Offset %" PRId64
-" allocation mismatch!\n",
-sectors_to_bytes(sector_num));
-goto out;
-}
 
 if (allocated1) {
 ret = check_empty_sectors(blk1, sector_num, nb_sectors,
-- 
2.4.3

Re: [Qemu-devel] [PATCH 00/10] qcow2: Implement image locking

[Markus Armbruster]

Kevin Wolf  writes:

> Am 23.12.2015 um 11:47 hat Daniel P. Berrange geschrieben:
>> On Wed, Dec 23, 2015 at 11:14:12AM +0800, Fam Zheng wrote:
>> > On Tue, 12/22 17:46, Kevin Wolf wrote:
>> > > Enough innocent images have died because users called 'qemu-img
>> > > snapshot' while
>> > > the VM was still running. Educating the users doesn't seem to be a 
>> > > working
>> > > strategy, so this series adds locking to qcow2 that refuses to
>> > > access the image
>> > > read-write from two processes.
>> > > 
>> > > Eric, this will require a libvirt update to deal with qemu
>> > > crashes which leave
>> > > locked images behind. The simplest thinkable way would be to
>> > > unconditionally
>> > > override the lock in libvirt whenever the option is present. In that 
>> > > case,
>> > > libvirt VMs would be protected against concurrent non-libvirt
>> > > accesses, but not
>> > > the other way round. If you want more than that, libvirt would
>> > > have to check
>> > > somehow if it was its own VM that used the image and left the
>> > > lock behind. I
>> > > imagine that can't be too hard either.
>> > 
>> > The motivation is great, but I'm not sure I like the side-effect that an
>> > unclean shutdown will require a "forced" open, because it makes
>> > using qcow2 in
>> > development cumbersome, and like you said, management/user also
>> > needs to handle
>> > this explicitly. This is a bit of a personal preference, but it's
>> > strong enough
>> > that I want to speak up.
>> 
>> Yeah, I am also not really a big fan of locking mechanisms which are not
>> automatically cleaned up on process exit. On the other hand you could
>> say that people who choose to run qemu-img manually are already taking
>> fate into their own hands, and ending up with a dirty image on unclean
>> exit is still miles better than loosing all your data.
>> 
>> > As an alternative, can we introduce .bdrv_flock() in protocol drivers, with
>> > similar semantics to flock(2) or lockf(3)? That way all formats can 
>> > benefit,
>> > and a program crash will automatically drop the lock.
>> 
>> FWIW, the libvirt locking daemon (virtlockd) will already attempt to take
>> out locks using fcntl()/lockf() on all disk images associated with a VM.
>
> Does this actually mean that if QEMU did try to use flock(), it would
> fail because libvirt is already holding the lock?
>
> I considered adding both locking schemes (the qcow2 flag for qcow2 on
> any backend; flock() for anything else on local files), but if this is
> true, that's game over for any flock() based patches.

"Game over" for any patches that use the same locking mechanism as
libvirt without coordinating with libvirt.

Of course, patches that use a new locking mechanism will almost
certainly need some libvirt work, too.

Can we come up with a more integrated solution where QEMU cooperates
with libvirt on locking when libvirt is in play, and does a more limited
job itself when libvirt isn't in play?

Re: [Qemu-devel] [PATCH 1/1] blk: do not select PFLASH device for internal snapshot

[Laszlo Ersek]

On 01/12/16 18:50, Kevin Wolf wrote:
> Am 12.01.2016 um 18:40 hat Markus Armbruster geschrieben:
>> Kevin Wolf  writes:
>>
>>> Am 12.01.2016 um 17:35 hat Denis V. Lunev geschrieben:
 On 01/12/2016 06:47 PM, Denis V. Lunev wrote:
> On 01/12/2016 06:20 PM, Kevin Wolf wrote:
>> Am 12.01.2016 um 15:59 hat Paolo Bonzini geschrieben:
>>>
>>> On 12/01/2016 15:16, Kevin Wolf wrote:
> Thus we should avoid selection of "pflash" drives for VM
> state saving.
>
> For now "pflash" is read-write raw image as it configured by libvirt.
> Thus there are no such images in the field and we could
> safely disable
> ability to save state to those images inside QEMU.
 This is obviously broken. If you write to the pflash, then it needs to
 be snapshotted in order to keep a consistent state.

 If you want to avoid snapshotting the image, make it read-only and it
 will be skipped even today.
>>> Sort of.  The point of having flash is to _not_ make it read-only, so
>>> that is not a solution.
>>>
>>> Flash is already being snapshotted as part of saving RAM state.  In
>>> fact, for this reason the device (at least the one used with OVMF; I
>>> haven't checked other pflash devices) can simply save it back to disk
>>> on the migration destination, without the need to use "migrate -b" or
>>> shared storage.
>>> [...]
>>> I don't like very much using IF_PFLASH this way, which is why I hadn't
>>> replied to the patch so far---I hadn't made up my mind about *what* to
>>> suggest instead, or whether to just accept it.  However, it does work.
>>>
>>> Perhaps a separate "I know what I am doing" skip-snapshot option?  Or
>>> a device callback saying "not snapshotting this is fine"?
>> Boy, is this ugly...
>>
>> What do you do with disk-only snapshots? The recovery only works as long
>> as you have VM state.
>>
>> Kevin
> actually I am in a bit of trouble :(
>
> I understand that this is ugly, but I would like to make working
> 'virsh snapshot' for OVFM VMs. This is necessary for us to make
> a release.
>
> Currently libvirt guys generate XML in the following way:
>
>  
>hvm
> type='pflash'>/usr/share/OVMF/OVMF_CODE_new.fd
> /var/lib/libvirt/qemu/nvram/f20efi_VARS.fd
>  
>
> This results in:
>
> qemu -drive 
> file=/usr/share/OVMF/OVMF_CODE_new.fd,if=pflash,format=raw,unit=0,readonly=on
> \
> -drive 
> file=/var/lib/libvirt/qemu/nvram/f20efi_VARS.fd,if=pflash,format=raw,unit=1
>
> This obviously can not pass check in bdrv_all_can_snapshot()
> as 'pflash' is RW and raw, i.e. can not be snapshoted.
>
> They have discussed the switch to the following command line:
>
> qemu -drive 
> file=/usr/share/OVMF/OVMF_CODE_new.fd,if=pflash,format=raw,unit=0,readonly=on
> \
> -drive 
> file=/var/lib/libvirt/qemu/nvram/f20efi_VARS.fd.qcow2,if=pflash,format=qcow2,unit=1
>
> and say that in this case VM state could fall into PFLASH
> drive which is should not be big as the location of the
> file is different. This means that I am doomed here.
>
> Either we should force libvirt people to forget about their
> opinion that pflash should be small which I am unable to
> do or I should invent a way to ban VM state saving into
> pflash.
>
> OK. There are 2 options.
>
> 1) Ban pflash as it was done.
> 2) Add 'no-vmstate' flag to -drive (invented just now).
>
 something like this:

 diff --git a/block.c b/block.c
 index 3e1877d..8900589 100644
 --- a/block.c
 +++ b/block.c
 @@ -881,6 +881,11 @@ static QemuOptsList bdrv_runtime_opts = {
  .help = "Block driver to use for the node",
  },
  {
 +.name = "novmstate",
 +.type = QEMU_OPT_BOOL,
 +.help = "Ignore for selecting to save VM state",
 +},
 +{
  .name = BDRV_OPT_CACHE_WB,
  .type = QEMU_OPT_BOOL,
  .help = "Enable writeback mode",
 @@ -957,6 +962,7 @@ static int bdrv_open_common(BlockDriverState
 *bs, BdrvChild *file,
  bs->request_alignment = 512;
  bs->zero_beyond_eof = true;
  bs->read_only = !(bs->open_flags & BDRV_O_RDWR);
 +bs->disable_vmstate_save = qemu_opt_get_bool(opts, "novmstate", 
 false);

  if (use_bdrv_whitelist && !bdrv_is_whitelisted(drv, bs->read_only)) {
  error_setg(errp,
 diff --git a/block/snapshot.c b/block/snapshot.c
 index 2d86b88..33cdd86 100644
 --- a/block/snapshot.c
 +++ b/block/snapshot.c
 @@ -483,6 +483,10 @@ BlockDriverState *bdrv_all_find_vmstate_bs(void)
  while (not_found && (bs = 

[Qemu-devel] [PULL 5/6] Use qemu_get_buffer_in_place for xbzrle data

[Amit Shah]

From: "Dr. David Alan Gilbert" 

Avoid a data copy (if we're lucky) in the xbzrle code.

Signed-off-by: Dr. David Alan Gilbert 
Reviewed-by: Juan Quintela 
Reviewed-by: Amit Shah 
Message-Id: <1450266458-3178-6-git-send-email-dgilb...@redhat.com>
Signed-off-by: Amit Shah 
---
 migration/ram.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/migration/ram.c b/migration/ram.c
index 102d1f2..994552c 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -2088,10 +2088,12 @@ static int load_xbzrle(QEMUFile *f, ram_addr_t addr, 
void *host)
 {
 unsigned int xh_len;
 int xh_flags;
+uint8_t *loaded_data;
 
 if (!xbzrle_decoded_buf) {
 xbzrle_decoded_buf = g_malloc(TARGET_PAGE_SIZE);
 }
+loaded_data = xbzrle_decoded_buf;
 
 /* extract RLE header */
 xh_flags = qemu_get_byte(f);
@@ -2107,10 +2109,10 @@ static int load_xbzrle(QEMUFile *f, ram_addr_t addr, 
void *host)
 return -1;
 }
 /* load data and decode */
-qemu_get_buffer(f, xbzrle_decoded_buf, xh_len);
+qemu_get_buffer_in_place(f, _data, xh_len);
 
 /* decode RLE */
-if (xbzrle_decode_buffer(xbzrle_decoded_buf, xh_len, host,
+if (xbzrle_decode_buffer(loaded_data, xh_len, host,
  TARGET_PAGE_SIZE) == -1) {
 error_report("Failed to load XBZRLE page - decode error!");
 return -1;
-- 
2.5.0

[Qemu-devel] [PULL 1/1] virtio serial port: fix to incomplete QOMify

[Amit Shah]

From: Cao jin 

Signed-off-by: Cao jin 
Message-Id: <1452068575-21543-1-git-send-email-caoj.f...@cn.fujitsu.com>
Reviewed-by: Amit Shah 
Signed-off-by: Amit Shah 
---
 hw/char/virtio-serial-bus.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c
index 497b0af..2d2a659 100644
--- a/hw/char/virtio-serial-bus.c
+++ b/hw/char/virtio-serial-bus.c
@@ -798,7 +798,7 @@ static const TypeInfo virtser_bus_info = {
 
 static void virtser_bus_dev_print(Monitor *mon, DeviceState *qdev, int indent)
 {
-VirtIOSerialPort *port = DO_UPCAST(VirtIOSerialPort, dev, qdev);
+VirtIOSerialPort *port = VIRTIO_SERIAL_PORT(qdev);
 
 monitor_printf(mon, "%*sport %d, guest %s, host %s, throttle %s\n",
indent, "", port->id,
-- 
2.5.0

Re: [Qemu-devel] [Avocado-devel] [PATCH] net/slirp: Tell the users when they are using deprecated options

[Jason Wang]

On 01/13/2016 03:25 PM, Paolo Bonzini wrote:
>
> On 13/01/2016 04:13, Jason Wang wrote:
>> Rethinking about this.  I'm not quite sure we can remove those
>> especially "-net user". Google qemu "-net user" gives about 15,900
>> results (and the first link is qemu wiki). Maybe we can replace "will be
>> removed in a future version." with something like "was suggested to use
>> -netdev user,XXX" instead?
> -net vs. -netdev was a completely separate topic, and I was very much
> against removing -net or even listing it as deprecated.

Right, I misread the patch.

>
> "-net channel"  seems to be an old version of guestfwd, and I can hardly
> find any mention of it on the net.
>
> Paolo

Re: [Qemu-devel] [PATCH v2 1/5] virtio-net: use the backend cross-endian capabilities

[Greg Kurz]

On Tue, 12 Jan 2016 18:24:28 +0100
Laurent Vivier  wrote:

> On 11/01/2016 17:12, Greg Kurz wrote:
> > When running a fully emulated device in cross-endian conditions, including
> > a virtio 1.0 device offered to a big endian guest, we need to fix the vnet
> > headers. This is currently handled by the virtio_net_hdr_swap() function
> > in the core virtio-net code but it should actually be handled by the net
> > backend.
> > 
> > With this patch, virtio-net now tries to configure the backend to do the
> > endian fixing when the device starts (i.e. drivers sets the CONFIG_OK bit).
> > If the backend cannot support the requested endiannes, we have to fallback
> > onto virtio_net_hdr_swap(): this is recorded in the needs_vnet_hdr_swap 
> > flag,
> > to be used in the TX and RX paths.
> > 
> > Note that we reset the backend to the default behaviour (guest native
> > endianness) when the device stops (i.e. device status had CONFIG_OK bit and
> > driver unsets it). This is needed, with the linux tap backend at least,
> > otherwise the guest may loose network connectivity if rebooted into a
> > different endianness.
> > 
> > The current vhost-net code also tries to configure net backends. This will
> > be no more needed and will be reverted in a subsequent patch.
> > 
> > Signed-off-by: Greg Kurz 
> > ---
> > v2:
> > - dropped useless check in the 'else if' branch in virtio_net_vnet_status()
> > - merged virtio_net_vhost_status() change from patch 2
> > - use semicolon in "backend does no support..." error message
> > - merged patch 3 (drop the virtio_needs_swap() helper)
> > - provided some more details in changelog and comments
> > ---
> >  hw/net/virtio-net.c   |   49 
> > +++--
> >  include/hw/virtio/virtio-access.h |9 ---
> >  include/hw/virtio/virtio-net.h|1 +
> >  3 files changed, 48 insertions(+), 11 deletions(-)
> > 
> > diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> > index a877614e3e7a..497fb7119a08 100644
> > --- a/hw/net/virtio-net.c
> > +++ b/hw/net/virtio-net.c
> > @@ -128,6 +128,13 @@ static void virtio_net_vhost_status(VirtIONet *n, 
> > uint8_t status)
> >  if (!n->vhost_started) {
> >  int r, i;
> >  
> > +if (n->needs_vnet_hdr_swap) {
> > +error_report("backend does not support %s vnet headers; "
> > + "falling back on userspace virtio",
> > + virtio_is_big_endian(vdev) ? "BE" : "LE");
> > +return;
> > +}
> > +
> >  /* Any packets outstanding? Purge them to avoid touching rings
> >   * when vhost is running.
> >   */
> > @@ -152,6 +159,40 @@ static void virtio_net_vhost_status(VirtIONet *n, 
> > uint8_t status)
> >  }
> >  }
> >  
> > +static void virtio_net_vnet_status(VirtIONet *n, uint8_t status)
> > +{
> > +VirtIODevice *vdev = VIRTIO_DEVICE(n);
> > +NetClientState *peer = qemu_get_queue(n->nic)->peer;
> > +
> > +if (virtio_net_started(n, status)) {
> > +int r;
> > +
> > +/* Before using the device, we tell the network backend about the
> > + * endianness to use when parsing vnet headers. If the backend 
> > can't
> > + * do it, we fallback onto fixing the headers in the core 
> > virtio-net
> > + * code.
> > + */
> > +if (virtio_is_big_endian(vdev)) {
> > +r = qemu_set_vnet_be(peer, true);
> > +} else {
> > +r = qemu_set_vnet_le(peer, true);
> > +}  
> 
> If endianess of the guest and the virtio device is the same, but r is <
> 0 (-ENOSYS or -EINVAL) you will badly swap header (and disable vhost).
> 

This can only happen if the endianness of the host is not the same as the
endianness of the device. In this case (we usually call cross-endian) the
vnet headers must be byteswapped but the backend cannot handle it. This
has two consequences:
- vhost cannot be used since it requires the backend to support cross-endian
  vnet headers, so we fallback onto full emulation in QEMU
- the emulation code must byteswap vnet headers

> I think you need something like this to fall back to the old method:
> 
> if (r < 0) {
> #ifdef HOST_WORDS_BIGENDIAN
> r = virtio_access_is_big_endian(vdev) ? false : true;
> #else
> r = virtio_access_is_big_endian(vdev) ? true : false;
> #endif
> }
> 
> 
> But...
> 
> > +n->needs_vnet_hdr_swap = !!r;
> > +} else if (virtio_net_started(n, vdev->status)) {
> > +/* After using the device, we need to reset the network backend to
> > + * the default (guest native endianness), otherwise the guest may
> > + * loose network connectivity if it is rebooted into a different
> > + * endianness.
> > + */
> > +if (virtio_is_big_endian(vdev)) {
> > +qemu_set_vnet_be(peer, false);
> > +} else {
> > +

Re: [Qemu-devel] [PATCH v2 0/6] Migration: Small fixes and improvements

[Amit Shah]

On (Wed) 16 Dec 2015 [11:47:32], Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert" 
> 
> This is a set of 4 small fixes and improvements I've been collecting
> during the 2.5 freeze; I've added in a couple of Zhanghailiang's patches
> that are easier to merge before rather than after.
> (Of which one I've added a small fix of my own, see the message)
> 
> Jiri was after events from the incoming postcopy side to make it
> easy for libvirt; I'd forgotten to add them - Zhanghailiang's
> patches change the way the events get sent on the incoming side.
> 
> Jiri also wanted an event on the outgoing side at each pass,
> which makes it easy for libvirt to trigger the transition to postcopy.
> 
> The other two patches avoid a couple of buffer copies on the incoming
> side; although in both xbzrle and multithread compression it's rare that
> the destination is the slow path (but one patch is trivial and the
> other saves code).

Reviewed-by: Amit Shah 

Amit

Re: [Qemu-devel] [PATCH v2 01/15] qom: add helpers for UserCreatable object types

[Daniel P. Berrange]

Copying Andreas into the qom: related patch in this series

On Mon, Jan 11, 2016 at 03:00:45PM +, Daniel P. Berrange wrote:
> The QMP monitor code has two helper methods object_add
> and qmp_object_del that are called from several places
> in the code (QMP, HMP and main emulator startup).
> 
> The HMP and main emulator startup code also share
> further logic that extracts the qom-type & id
> values from a qdict.
> 
> We soon need to use this logic from qemu-img, qemu-io
> and qemu-nbd too, but don't want those to depend on
> the monitor, nor do we want to duplicate the code.
> 
> To avoid this, move some code out of qmp.c and hmp.c
> adding 3 new methods to qom/object_interfaces.c
> 
>  - user_creatable_add - takes a QDict holding a full
>object definition & instantiates it
>  - user_creatable_add_type - takes an ID, type name,
>and QDict holding object properties & instantiates
>it
>  - user_creatable_del - takes an ID and deletes the
>corresponding object
> 
> The existing code is updated to use these new methods.
> 
> Signed-off-by: Daniel P. Berrange 
> ---
>  hmp.c   |  52 ---
>  include/monitor/monitor.h   |   3 -
>  include/qom/object_interfaces.h |  48 ++
>  qmp.c   |  76 ++
>  qom/object_interfaces.c | 139 
> 
>  vl.c|  48 --
>  6 files changed, 216 insertions(+), 150 deletions(-)
> 
> diff --git a/hmp.c b/hmp.c
> index c2b2c16..6a9c51d 100644
> --- a/hmp.c
> +++ b/hmp.c
> @@ -29,6 +29,7 @@
>  #include "qapi/string-output-visitor.h"
>  #include "qapi/util.h"
>  #include "qapi-visit.h"
> +#include "qom/object_interfaces.h"
>  #include "ui/console.h"
>  #include "block/qapi.h"
>  #include "qemu-io.h"
> @@ -1663,58 +1664,27 @@ void hmp_netdev_del(Monitor *mon, const QDict *qdict)
>  void hmp_object_add(Monitor *mon, const QDict *qdict)
>  {
>  Error *err = NULL;
> -Error *err_end = NULL;
>  QemuOpts *opts;
> -char *type = NULL;
> -char *id = NULL;
> -void *dummy = NULL;
>  OptsVisitor *ov;
> -QDict *pdict;
> +Object *obj = NULL;
>  
>  opts = qemu_opts_from_qdict(qemu_find_opts("object"), qdict, );
>  if (err) {
> -goto out;
> +hmp_handle_error(mon, );
> +return;
>  }
>  
>  ov = opts_visitor_new(opts);
> -pdict = qdict_clone_shallow(qdict);
> -
> -visit_start_struct(opts_get_visitor(ov), , NULL, NULL, 0, );
> -if (err) {
> -goto out_clean;
> -}
> -
> -qdict_del(pdict, "qom-type");
> -visit_type_str(opts_get_visitor(ov), , "qom-type", );
> -if (err) {
> -goto out_end;
> -}
> +obj = user_creatable_add(qdict, opts_get_visitor(ov), );
> +opts_visitor_cleanup(ov);
> +qemu_opts_del(opts);
>  
> -qdict_del(pdict, "id");
> -visit_type_str(opts_get_visitor(ov), , "id", );
>  if (err) {
> -goto out_end;
> +hmp_handle_error(mon, );
>  }
> -
> -object_add(type, id, pdict, opts_get_visitor(ov), );
> -
> -out_end:
> -visit_end_struct(opts_get_visitor(ov), _end);
> -if (!err && err_end) {
> -qmp_object_del(id, NULL);
> +if (obj) {
> +object_unref(obj);
>  }
> -error_propagate(, err_end);
> -out_clean:
> -opts_visitor_cleanup(ov);
> -
> -QDECREF(pdict);
> -qemu_opts_del(opts);
> -g_free(id);
> -g_free(type);
> -g_free(dummy);
> -
> -out:
> -hmp_handle_error(mon, );
>  }
>  
>  void hmp_getfd(Monitor *mon, const QDict *qdict)
> @@ -1944,7 +1914,7 @@ void hmp_object_del(Monitor *mon, const QDict *qdict)
>  const char *id = qdict_get_str(qdict, "id");
>  Error *err = NULL;
>  
> -qmp_object_del(id, );
> +user_creatable_del(id, );
>  hmp_handle_error(mon, );
>  }
>  
> diff --git a/include/monitor/monitor.h b/include/monitor/monitor.h
> index 91b95ae..aa0f373 100644
> --- a/include/monitor/monitor.h
> +++ b/include/monitor/monitor.h
> @@ -43,9 +43,6 @@ void monitor_read_command(Monitor *mon, int show_prompt);
>  int monitor_read_password(Monitor *mon, ReadLineFunc *readline_func,
>void *opaque);
>  
> -void object_add(const char *type, const char *id, const QDict *qdict,
> -Visitor *v, Error **errp);
> -
>  AddfdInfo *monitor_fdset_add_fd(int fd, bool has_fdset_id, int64_t fdset_id,
>  bool has_opaque, const char *opaque,
>  Error **errp);
> diff --git a/include/qom/object_interfaces.h b/include/qom/object_interfaces.h
> index 283ae0d..7bbaf2f 100644
> --- a/include/qom/object_interfaces.h
> +++ b/include/qom/object_interfaces.h
> @@ -2,6 +2,8 @@
>  #define OBJECT_INTERFACES_H
>  
>  #include "qom/object.h"
> +#include "qapi/qmp/qdict.h"
> +#include "qapi/visitor.h"
>  
>  #define TYPE_USER_CREATABLE "user-creatable"
>  
> @@ -72,4 +74,50 

[Qemu-devel] [PATCH] vnc: fix tls-creds error message

[Wolfgang Bumiller]

The parameter is called 'tls-creds', 'credid' is just the
variable name in the code.

Signed-off-by: Wolfgang Bumiller 
---
 ui/vnc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ui/vnc.c b/ui/vnc.c
index 09756cd..2270ac2 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -3605,7 +3605,7 @@ void vnc_display_open(const char *id, Error **errp)
 qemu_opt_get(opts, "x509") ||
 qemu_opt_get(opts, "x509verify")) {
 error_setg(errp,
-   "'credid' parameter is mutually exclusive with "
+   "'tls-creds' parameter is mutually exclusive with "
"'tls', 'x509' and 'x509verify' parameters");
 goto fail;
 }
-- 
2.1.4

Re: [Qemu-devel] [PATCH v2 1/2] blockdev: Error out on negative throttling option values

[Fam Zheng]

On Wed, 01/13 11:17, Alberto Garcia wrote:
> On Wed 13 Jan 2016 01:52:29 AM CET, Fam Zheng wrote:
> 
> > The implicit casting from unsigned int to double changes negative values
> > into large positive numbers and accepts them.  We should instead print
> > an error.
> >
> > Check the number range so this case is catched and reported.
> 
> I still don't know why qemu_opt_get_number() convert silently negative
> numbers into positive ones, shouldn't it just fail with an "invalid
> parameter" error?

Because the parsing is done with strtoull(3) and unfortunately its man page
says "negative values are considered valid input and are silently converted to
the equivalent unsigned long int value."

> 
> > +#define THROTTLE_VALUE_MAX 1000L
> 
> This is larger than LONG_MAX in 32-bit systems, I don't know if you need
> to use LL instead.

I assume a compiler will handle that okay but yes it's safer to use LL.

Fam

[Qemu-devel] [PATCH 0/6] virtio-gpu: fixes and spice preparation

[Gerd Hoffmann]

  Hi,

This patch series brings some minor opengl bug fixes and also
some virtio-gpu preparations for spice support.

please review,
  Gerd

Gerd Hoffmann (6):
  zap qemu_egl_has_ext in include/ui/egl-helpers.h
  console: block rendering until client is done
  virtio-gpu: fix memory leak in error path
  virtio-gpu: maintain command queue
  virtio-gpu: add support to enable/disable command processing
  virtio-gpu: block any rendering until client (ui) is done

 hw/display/virtio-gpu-3d.c | 11 +--
 hw/display/virtio-gpu.c| 71 +-
 hw/display/virtio-vga.c| 10 ++
 include/hw/virtio/virtio-gpu.h |  4 +++
 include/ui/console.h   |  2 ++
 include/ui/egl-helpers.h   |  1 -
 ui/console.c   | 10 ++
 7 files changed, 84 insertions(+), 25 deletions(-)

-- 
1.8.3.1

[Qemu-devel] [PATCH 1/6] zap qemu_egl_has_ext in include/ui/egl-helpers.h

[Gerd Hoffmann]

Drop leftover prototype which sneaked in by mistake

Signed-off-by: Gerd Hoffmann 
---
 include/ui/egl-helpers.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/ui/egl-helpers.h b/include/ui/egl-helpers.h
index 5ad5dc3..8c84398 100644
--- a/include/ui/egl-helpers.h
+++ b/include/ui/egl-helpers.h
@@ -11,6 +11,5 @@ EGLSurface qemu_egl_init_surface_x11(EGLContext ectx, Window 
win);
 
 int qemu_egl_init_dpy(EGLNativeDisplayType dpy, bool gles, bool debug);
 EGLContext qemu_egl_init_ctx(void);
-bool qemu_egl_has_ext(const char *haystack, const char *needle);
 
 #endif /* EGL_HELPERS_H */
-- 
1.8.3.1

Re: [Qemu-devel] [PATCH v6 0/3] i386: expose floppy-related objects in SSDT

[Roman Kagan]

On Wed, Jan 13, 2016 at 11:25:22AM +0100, Igor Mammedov wrote:
> On Mon, 11 Jan 2016 16:35:31 +0100
> Igor Mammedov  wrote:
> 
> > v5->v6:
> >  - rebased on top DSDT converted to AMP API
> >  - dropped intermediate structs for one time used floppy parameters
> >which simplifies code a bit.
> Roman,
> I don't have OVMF+Win setup,
> Could you test this series and reply with Tested-by if it works?

Sure.

I just did a brief test booting qemu (master + this series) with RHEL7
OVMF off an installation DVD image for w2k8r2sp1 and w2k12r2, connecting
either 1 or 2 floopy drives of different size.  Each time the floopies
were correctly identified and their contents was visibile in the guest.

So

Tested-by: Roman Kagan 

Roman.

[Qemu-devel] [PATCH 3/6] virtio-gpu: fix memory leak in error path

[Gerd Hoffmann]

Found by Coverity Scan, buf not freed on error.

Signed-off-by: Gerd Hoffmann 
---
 hw/display/virtio-gpu-3d.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/display/virtio-gpu-3d.c b/hw/display/virtio-gpu-3d.c
index 28dccfd..d2af327 100644
--- a/hw/display/virtio-gpu-3d.c
+++ b/hw/display/virtio-gpu-3d.c
@@ -197,7 +197,7 @@ static void virgl_cmd_submit_3d(VirtIOGPU *g,
 qemu_log_mask(LOG_GUEST_ERROR, "%s: size mismatch (%zd/%d)",
   __func__, s, cs.size);
 cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_PARAMETER;
-return;
+goto out;
 }
 
 if (virtio_gpu_stats_enabled(g->conf)) {
@@ -207,6 +207,7 @@ static void virgl_cmd_submit_3d(VirtIOGPU *g,
 
 virgl_renderer_submit_cmd(buf, cs.hdr.ctx_id, cs.size / 4);
 
+out:
 g_free(buf);
 }
 
-- 
1.8.3.1

Re: [Qemu-devel] [Xen-devel] [PATCH v3 13/13] xen-hvm: Mark inappropriate error handling FIXME

[Markus Armbruster]

Markus Armbruster  writes:

> Stefano Stabellini  writes:
>
>> On Thu, 17 Dec 2015, Markus Armbruster wrote:
>>> Cc: Stefano Stabellini 
>>> Cc: xen-de...@lists.xensource.com
>>> Signed-off-by: Markus Armbruster 
>>> ---
>>>  xen-hvm.c | 7 +++
>>>  1 file changed, 7 insertions(+)
>>> 
>>> diff --git a/xen-hvm.c b/xen-hvm.c
>>> index 3d78a0c..2a93390 100644
>>> --- a/xen-hvm.c
>>> +++ b/xen-hvm.c
>>> @@ -240,6 +240,7 @@ static void xen_ram_init(PCMachineState *pcms,
>>>  
>>>  void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr)
>>>  {
>>> +/* FIXME caller ram_block_add() wants error_setg() on failure */
>>>  unsigned long nr_pfn;
>>>  xen_pfn_t *pfn_list;
>>>  int i;
>>> @@ -1192,6 +1193,12 @@ static void xen_wakeup_notifier(Notifier *notifier, 
>>> void *data)
>>>  int xen_hvm_init(PCMachineState *pcms,
>>>   MemoryRegion **ram_memory)
>>>  {
>>> +/*
>>> + * FIXME Returns -1 without cleaning up on some errors (harmless
>>> + * as long as the caller exit()s on error), dies with hw_error()
>>
>> Could you please stop the comment here and just replace hw_error() with
>> either return -1 or exit(1) within xen_hvm_init?
>
> If compile-testing is okay, I can either
>
> (1) replace hw_error() by return -1, or
>
> (2) replace both hw_error() and return -1 by exit(1), and make
> xen_hvm_init() return void.
>
> Your pick?

If you don't mind, I'll do (2) as a follow-up patch.  (2) because I like
it better, and follow-up patch because I'd prefer not to delay my error
pull request any longer.

Re: [Qemu-devel] [PATCH 5/6] virtio-gpu: add support to enable/disable command processing

[Marc-André Lureau]

Hi

On Wed, Jan 13, 2016 at 1:02 PM, Gerd Hoffmann  wrote:
> So we can stop rendering for a while in case we have to.
>
> Signed-off-by: Gerd Hoffmann 

Reviewed-by: Marc-André Lureau 

> ---
>  hw/display/virtio-gpu-3d.c | 3 ++-
>  hw/display/virtio-gpu.c| 5 -
>  include/hw/virtio/virtio-gpu.h | 2 ++
>  3 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/hw/display/virtio-gpu-3d.c b/hw/display/virtio-gpu-3d.c
> index d2af327..65926b1 100644
> --- a/hw/display/virtio-gpu-3d.c
> +++ b/hw/display/virtio-gpu-3d.c
> @@ -553,7 +553,8 @@ static void virtio_gpu_fence_poll(void *opaque)
>  VirtIOGPU *g = opaque;
>
>  virgl_renderer_poll();
> -if (g->inflight) {
> +virtio_cpu_process_cmdq(g);
> +if (!QTAILQ_EMPTY(>cmdq) || !QTAILQ_EMPTY(>fenceq)) {
>  timer_mod(g->fence_poll, qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) + 10);
>  }
>  }
> diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
> index 4433c12..9087e63 100644
> --- a/hw/display/virtio-gpu.c
> +++ b/hw/display/virtio-gpu.c
> @@ -754,7 +754,7 @@ static void virtio_gpu_handle_cursor_cb(VirtIODevice 
> *vdev, VirtQueue *vq)
>  qemu_bh_schedule(g->cursor_bh);
>  }
>
> -static void virtio_cpu_process_cmdq(VirtIOGPU *g)
> +void virtio_cpu_process_cmdq(VirtIOGPU *g)
>  {
>  struct virtio_gpu_ctrl_command *cmd;
>
> @@ -764,6 +764,9 @@ static void virtio_cpu_process_cmdq(VirtIOGPU *g)
>  /* process command */
>  VIRGL(g, virtio_gpu_virgl_process_cmd, virtio_gpu_simple_process_cmd,
>g, cmd);
> +if (cmd->waiting) {
> +break;
> +}
>  QTAILQ_REMOVE(>cmdq, cmd, next);
>  if (virtio_gpu_stats_enabled(g->conf)) {
>  g->stats.requests++;
> diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
> index f7e7a52..fdf0091 100644
> --- a/include/hw/virtio/virtio-gpu.h
> +++ b/include/hw/virtio/virtio-gpu.h
> @@ -76,6 +76,7 @@ struct virtio_gpu_ctrl_command {
>  VirtQueue *vq;
>  struct virtio_gpu_ctrl_hdr cmd_hdr;
>  uint32_t error;
> +bool waiting;
>  bool finished;
>  QTAILQ_ENTRY(virtio_gpu_ctrl_command) next;
>  };
> @@ -152,6 +153,7 @@ int virtio_gpu_create_mapping_iov(struct 
> virtio_gpu_resource_attach_backing *ab,
>struct virtio_gpu_ctrl_command *cmd,
>struct iovec **iov);
>  void virtio_gpu_cleanup_mapping_iov(struct iovec *iov, uint32_t count);
> +void virtio_cpu_process_cmdq(VirtIOGPU *g);
>
>  /* virtio-gpu-3d.c */
>  void virtio_gpu_virgl_process_cmd(VirtIOGPU *g,
> --
> 1.8.3.1
>



-- 
Marc-André Lureau

[Qemu-devel] [PATCH v14 3/8] Backup: clear all bitmap when doing block checkpoint

[Changlong Xie]

From: Wen Congyang 

Signed-off-by: Wen Congyang 
Signed-off-by: zhanghailiang 
Signed-off-by: Gonglei 
Signed-off-by: Changlong Xie 
Reviewed-by: Jeff Cody 
---
 block/backup.c   | 14 ++
 blockjob.c   | 11 +++
 include/block/blockjob.h | 12 
 3 files changed, 37 insertions(+)

diff --git a/block/backup.c b/block/backup.c
index 705bb77..0a27d01 100644
--- a/block/backup.c
+++ b/block/backup.c
@@ -253,11 +253,25 @@ static void backup_abort(BlockJob *job)
 }
 }
 
+static void backup_do_checkpoint(BlockJob *job, Error **errp)
+{
+BackupBlockJob *backup_job = container_of(job, BackupBlockJob, common);
+
+if (backup_job->sync_mode != MIRROR_SYNC_MODE_NONE) {
+error_setg(errp, "The backup job only supports block checkpoint in"
+   " sync=none mode");
+return;
+}
+
+hbitmap_reset_all(backup_job->bitmap);
+}
+
 static const BlockJobDriver backup_job_driver = {
 .instance_size  = sizeof(BackupBlockJob),
 .job_type   = BLOCK_JOB_TYPE_BACKUP,
 .set_speed  = backup_set_speed,
 .iostatus_reset = backup_iostatus_reset,
+.do_checkpoint  = backup_do_checkpoint,
 .commit = backup_commit,
 .abort  = backup_abort,
 };
diff --git a/blockjob.c b/blockjob.c
index 80adb9d..0c8edfe 100644
--- a/blockjob.c
+++ b/blockjob.c
@@ -533,3 +533,14 @@ void block_job_txn_add_job(BlockJobTxn *txn, BlockJob *job)
 QLIST_INSERT_HEAD(>jobs, job, txn_list);
 block_job_txn_ref(txn);
 }
+
+void block_job_do_checkpoint(BlockJob *job, Error **errp)
+{
+if (!job->driver->do_checkpoint) {
+error_setg(errp, "The job %s doesn't support block checkpoint",
+   BlockJobType_lookup[job->driver->job_type]);
+return;
+}
+
+job->driver->do_checkpoint(job, errp);
+}
diff --git a/include/block/blockjob.h b/include/block/blockjob.h
index d84ccd8..abdba7c 100644
--- a/include/block/blockjob.h
+++ b/include/block/blockjob.h
@@ -70,6 +70,9 @@ typedef struct BlockJobDriver {
  * never both.
  */
 void (*abort)(BlockJob *job);
+
+/** Optional callback for job types that support checkpoint. */
+void (*do_checkpoint)(BlockJob *job, Error **errp);
 } BlockJobDriver;
 
 /**
@@ -443,4 +446,13 @@ void block_job_txn_unref(BlockJobTxn *txn);
  */
 void block_job_txn_add_job(BlockJobTxn *txn, BlockJob *job);
 
+/**
+ * block_job_do_checkpoint:
+ * @job: The job.
+ * @errp: Error object.
+ *
+ * Do block checkpoint on the specified job.
+ */
+void block_job_do_checkpoint(BlockJob *job, Error **errp);
+
 #endif
-- 
1.9.3

Re: [Qemu-devel] [Xen-devel] [PATCH v3 13/13] xen-hvm: Mark inappropriate error handling FIXME

[Stefano Stabellini]

On Wed, 13 Jan 2016, Markus Armbruster wrote:
> Markus Armbruster  writes:
> 
> > Stefano Stabellini  writes:
> >
> >> On Thu, 17 Dec 2015, Markus Armbruster wrote:
> >>> Cc: Stefano Stabellini 
> >>> Cc: xen-de...@lists.xensource.com
> >>> Signed-off-by: Markus Armbruster 
> >>> ---
> >>>  xen-hvm.c | 7 +++
> >>>  1 file changed, 7 insertions(+)
> >>> 
> >>> diff --git a/xen-hvm.c b/xen-hvm.c
> >>> index 3d78a0c..2a93390 100644
> >>> --- a/xen-hvm.c
> >>> +++ b/xen-hvm.c
> >>> @@ -240,6 +240,7 @@ static void xen_ram_init(PCMachineState *pcms,
> >>>  
> >>>  void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion 
> >>> *mr)
> >>>  {
> >>> +/* FIXME caller ram_block_add() wants error_setg() on failure */
> >>>  unsigned long nr_pfn;
> >>>  xen_pfn_t *pfn_list;
> >>>  int i;
> >>> @@ -1192,6 +1193,12 @@ static void xen_wakeup_notifier(Notifier 
> >>> *notifier, void *data)
> >>>  int xen_hvm_init(PCMachineState *pcms,
> >>>   MemoryRegion **ram_memory)
> >>>  {
> >>> +/*
> >>> + * FIXME Returns -1 without cleaning up on some errors (harmless
> >>> + * as long as the caller exit()s on error), dies with hw_error()
> >>
> >> Could you please stop the comment here and just replace hw_error() with
> >> either return -1 or exit(1) within xen_hvm_init?
> >
> > If compile-testing is okay, I can either
> >
> > (1) replace hw_error() by return -1, or
> >
> > (2) replace both hw_error() and return -1 by exit(1), and make
> > xen_hvm_init() return void.
> >
> > Your pick?
> 
> If you don't mind, I'll do (2) as a follow-up patch.  (2) because I like
> it better, and follow-up patch because I'd prefer not to delay my error
> pull request any longer.

That's fine. Sorry, I lost your previous email.

[Qemu-devel] [PATCH 5/6] virtio-gpu: add support to enable/disable command processing

[Gerd Hoffmann]

So we can stop rendering for a while in case we have to.

Signed-off-by: Gerd Hoffmann 
---
 hw/display/virtio-gpu-3d.c | 3 ++-
 hw/display/virtio-gpu.c| 5 -
 include/hw/virtio/virtio-gpu.h | 2 ++
 3 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/hw/display/virtio-gpu-3d.c b/hw/display/virtio-gpu-3d.c
index d2af327..65926b1 100644
--- a/hw/display/virtio-gpu-3d.c
+++ b/hw/display/virtio-gpu-3d.c
@@ -553,7 +553,8 @@ static void virtio_gpu_fence_poll(void *opaque)
 VirtIOGPU *g = opaque;
 
 virgl_renderer_poll();
-if (g->inflight) {
+virtio_cpu_process_cmdq(g);
+if (!QTAILQ_EMPTY(>cmdq) || !QTAILQ_EMPTY(>fenceq)) {
 timer_mod(g->fence_poll, qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) + 10);
 }
 }
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index 4433c12..9087e63 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -754,7 +754,7 @@ static void virtio_gpu_handle_cursor_cb(VirtIODevice *vdev, 
VirtQueue *vq)
 qemu_bh_schedule(g->cursor_bh);
 }
 
-static void virtio_cpu_process_cmdq(VirtIOGPU *g)
+void virtio_cpu_process_cmdq(VirtIOGPU *g)
 {
 struct virtio_gpu_ctrl_command *cmd;
 
@@ -764,6 +764,9 @@ static void virtio_cpu_process_cmdq(VirtIOGPU *g)
 /* process command */
 VIRGL(g, virtio_gpu_virgl_process_cmd, virtio_gpu_simple_process_cmd,
   g, cmd);
+if (cmd->waiting) {
+break;
+}
 QTAILQ_REMOVE(>cmdq, cmd, next);
 if (virtio_gpu_stats_enabled(g->conf)) {
 g->stats.requests++;
diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
index f7e7a52..fdf0091 100644
--- a/include/hw/virtio/virtio-gpu.h
+++ b/include/hw/virtio/virtio-gpu.h
@@ -76,6 +76,7 @@ struct virtio_gpu_ctrl_command {
 VirtQueue *vq;
 struct virtio_gpu_ctrl_hdr cmd_hdr;
 uint32_t error;
+bool waiting;
 bool finished;
 QTAILQ_ENTRY(virtio_gpu_ctrl_command) next;
 };
@@ -152,6 +153,7 @@ int virtio_gpu_create_mapping_iov(struct 
virtio_gpu_resource_attach_backing *ab,
   struct virtio_gpu_ctrl_command *cmd,
   struct iovec **iov);
 void virtio_gpu_cleanup_mapping_iov(struct iovec *iov, uint32_t count);
+void virtio_cpu_process_cmdq(VirtIOGPU *g);
 
 /* virtio-gpu-3d.c */
 void virtio_gpu_virgl_process_cmd(VirtIOGPU *g,
-- 
1.8.3.1

[Qemu-devel] [PATCH v14 1/8] unblock backup operations in backing file

[Changlong Xie]

From: Wen Congyang 

Signed-off-by: Wen Congyang 
Signed-off-by: Changlong Xie 
---
 block.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/block.c b/block.c
index e90b6cf..12b5231 100644
--- a/block.c
+++ b/block.c
@@ -1275,6 +1275,24 @@ void bdrv_set_backing_hd(BlockDriverState *bs, 
BlockDriverState *backing_hd)
 /* Otherwise we won't be able to commit due to check in bdrv_commit */
 bdrv_op_unblock(backing_hd, BLOCK_OP_TYPE_COMMIT_TARGET,
 bs->backing_blocker);
+/*
+ * We do backup in 3 ways:
+ * 1. drive backup
+ *The target bs is new opened, and the source is top BDS
+ * 2. blockdev backup
+ *Both the source and the target are top BDSes.
+ * 3. internal backup(used for block replication)
+ *Both the source and the target are backing file
+ *
+ * In case 1, and 2, the backing file is neither the source nor
+ * the target.
+ * In case 3, we will block the top BDS, so there is only one block
+ * job for the top BDS and its backing chain.
+ */
+bdrv_op_unblock(backing_hd, BLOCK_OP_TYPE_BACKUP_SOURCE,
+bs->backing_blocker);
+bdrv_op_unblock(backing_hd, BLOCK_OP_TYPE_BACKUP_TARGET,
+bs->backing_blocker);
 out:
 bdrv_refresh_limits(bs, NULL);
 }
-- 
1.9.3

[Qemu-devel] [PATCH v14 6/8] auto complete active commit

[Changlong Xie]

From: Wen Congyang 

Auto complete mirror job in background to prevent from
blocking synchronously

Signed-off-by: Wen Congyang 
Signed-off-by: Changlong Xie 
---
 block/mirror.c| 13 +
 blockdev.c|  2 +-
 include/block/block_int.h |  3 ++-
 qemu-img.c|  2 +-
 4 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/block/mirror.c b/block/mirror.c
index f201f2b..b8e51f8 100644
--- a/block/mirror.c
+++ b/block/mirror.c
@@ -716,7 +716,8 @@ static void mirror_start_job(BlockDriverState *bs, 
BlockDriverState *target,
  BlockCompletionFunc *cb,
  void *opaque, Error **errp,
  const BlockJobDriver *driver,
- bool is_none_mode, BlockDriverState *base)
+ bool is_none_mode, BlockDriverState *base,
+ bool auto_complete)
 {
 MirrorBlockJob *s;
 BlockDriverState *replaced_bs;
@@ -772,6 +773,9 @@ static void mirror_start_job(BlockDriverState *bs, 
BlockDriverState *target,
 s->granularity = granularity;
 s->buf_size = ROUND_UP(buf_size, granularity);
 s->unmap = unmap;
+if (auto_complete) {
+s->should_complete = true;
+}
 
 s->dirty_bitmap = bdrv_create_dirty_bitmap(bs, granularity, NULL, errp);
 if (!s->dirty_bitmap) {
@@ -813,14 +817,15 @@ void mirror_start(BlockDriverState *bs, BlockDriverState 
*target,
 mirror_start_job(bs, target, replaces,
  speed, granularity, buf_size,
  on_source_error, on_target_error, unmap, cb, opaque, errp,
- _job_driver, is_none_mode, base);
+ _job_driver, is_none_mode, base, false);
 }
 
 void commit_active_start(BlockDriverState *bs, BlockDriverState *base,
  int64_t speed,
  BlockdevOnError on_error,
  BlockCompletionFunc *cb,
- void *opaque, Error **errp)
+ void *opaque, Error **errp,
+ bool auto_complete)
 {
 int64_t length, base_length;
 int orig_base_flags;
@@ -861,7 +866,7 @@ void commit_active_start(BlockDriverState *bs, 
BlockDriverState *base,
 bdrv_ref(base);
 mirror_start_job(bs, base, NULL, speed, 0, 0,
  on_error, on_error, false, cb, opaque, _err,
- _active_job_driver, false, base);
+ _active_job_driver, false, base, auto_complete);
 if (local_err) {
 error_propagate(errp, local_err);
 goto error_restore_flags;
diff --git a/blockdev.c b/blockdev.c
index 574a365..603e858 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -3038,7 +3038,7 @@ void qmp_block_commit(const char *device,
 goto out;
 }
 commit_active_start(bs, base_bs, speed, on_error, block_job_cb,
-bs, _err);
+bs, _err, false);
 } else {
 commit_start(bs, base_bs, top_bs, speed, on_error, block_job_cb, bs,
  has_backing_file ? backing_file : NULL, _err);
diff --git a/include/block/block_int.h b/include/block/block_int.h
index 19c02b6..1b2d51a 100644
--- a/include/block/block_int.h
+++ b/include/block/block_int.h
@@ -634,13 +634,14 @@ void commit_start(BlockDriverState *bs, BlockDriverState 
*base,
  * @cb: Completion function for the job.
  * @opaque: Opaque pointer value passed to @cb.
  * @errp: Error object.
+ * @auto_complete: Auto complete the job.
  *
  */
 void commit_active_start(BlockDriverState *bs, BlockDriverState *base,
  int64_t speed,
  BlockdevOnError on_error,
  BlockCompletionFunc *cb,
- void *opaque, Error **errp);
+ void *opaque, Error **errp, bool auto_complete);
 /*
  * mirror_start:
  * @bs: Block device to operate on.
diff --git a/qemu-img.c b/qemu-img.c
index 3d48b4f..4b8b092 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -759,7 +759,7 @@ static int img_commit(int argc, char **argv)
 };
 
 commit_active_start(bs, base_bs, 0, BLOCKDEV_ON_ERROR_REPORT,
-common_block_job_cb, , _err);
+common_block_job_cb, , _err, false);
 if (local_err) {
 goto done;
 }
-- 
1.9.3

[Qemu-devel] [PATCH v14 4/8] Allow creating backup jobs when opening BDS

[Changlong Xie]

From: Wen Congyang 

When opening BDS, we need to create backup jobs for
image-fleecing.

Signed-off-by: Wen Congyang 
Signed-off-by: zhanghailiang 
Signed-off-by: Gonglei 
Signed-off-by: Changlong Xie 
Reviewed-by: Stefan Hajnoczi 
Reviewed-by: Jeff Cody 
---
 block/Makefile.objs | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/block/Makefile.objs b/block/Makefile.objs
index 58ef2ef..fa05f37 100644
--- a/block/Makefile.objs
+++ b/block/Makefile.objs
@@ -22,10 +22,10 @@ block-obj-$(CONFIG_ARCHIPELAGO) += archipelago.o
 block-obj-$(CONFIG_LIBSSH2) += ssh.o
 block-obj-y += accounting.o
 block-obj-y += write-threshold.o
+block-obj-y += backup.o
 
 common-obj-y += stream.o
 common-obj-y += commit.o
-common-obj-y += backup.o
 
 iscsi.o-cflags := $(LIBISCSI_CFLAGS)
 iscsi.o-libs   := $(LIBISCSI_LIBS)
-- 
1.9.3

[Qemu-devel] [PATCH v14 8/8] support replication driver in blockdev-add

[Changlong Xie]

From: Wen Congyang 

Signed-off-by: Wen Congyang 
Signed-off-by: zhanghailiang 
Signed-off-by: Gonglei 
Signed-off-by: Changlong Xie 
Reviewed-by: Eric Blake 
---
 qapi/block-core.json | 20 ++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/qapi/block-core.json b/qapi/block-core.json
index d73f46b..00350ed 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -220,6 +220,7 @@
 #   2.2: 'archipelago' added, 'cow' dropped
 #   2.3: 'host_floppy' deprecated
 #   2.5: 'host_floppy' dropped
+#   2.6: 'replication' added
 #
 # @backing_file: #optional the name of the backing file (for copy-on-write)
 #
@@ -1540,6 +1541,7 @@
 # Drivers that are supported in block device operations.
 #
 # @host_device, @host_cdrom: Since 2.1
+# @replication: Since 2.6
 #
 # Since: 2.0
 ##
@@ -1547,8 +1549,8 @@
   'data': [ 'archipelago', 'blkdebug', 'blkverify', 'bochs', 'cloop',
 'dmg', 'file', 'ftp', 'ftps', 'host_cdrom', 'host_device',
 'http', 'https', 'null-aio', 'null-co', 'parallels',
-'qcow', 'qcow2', 'qed', 'quorum', 'raw', 'tftp', 'vdi', 'vhdx',
-'vmdk', 'vpc', 'vvfat' ] }
+'qcow', 'qcow2', 'qed', 'quorum', 'raw', 'replication',
+'tftp', 'vdi', 'vhdx', 'vmdk', 'vpc', 'vvfat' ] }
 
 ##
 # @BlockdevOptionsBase
@@ -1988,6 +1990,19 @@
 { 'enum' : 'ReplicationMode', 'data' : [ 'primary', 'secondary' ] }
 
 ##
+# @BlockdevOptionsReplication
+#
+# Driver specific block device options for replication
+#
+# @mode: the replication mode
+#
+# Since: 2.6
+##
+{ 'struct': 'BlockdevOptionsReplication',
+  'base': 'BlockdevOptionsGenericFormat',
+  'data': { 'mode': 'ReplicationMode'  } }
+
+##
 # @BlockdevOptions
 #
 # Options for creating a block device.
@@ -2024,6 +2039,7 @@
   'quorum': 'BlockdevOptionsQuorum',
   'raw':'BlockdevOptionsGenericFormat',
 # TODO rbd: Wait for structured options
+  'replication':'BlockdevOptionsReplication',
 # TODO sheepdog: Wait for structured options
 # TODO ssh: Should take InetSocketAddress for 'host'?
   'tftp':   'BlockdevOptionsFile',
-- 
1.9.3

[Qemu-devel] [PATCH v14 2/8] Store parent BDS in BdrvChild

[Changlong Xie]

From: Wen Congyang 

We need to access the parent BDS to get the root BDS.

Signed-off-by: Wen Congyang 
Signed-off-by: Changlong Xie 
---
 block.c   | 1 +
 include/block/block_int.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/block.c b/block.c
index 12b5231..33d3427 100644
--- a/block.c
+++ b/block.c
@@ -1204,6 +1204,7 @@ BdrvChild *bdrv_attach_child(BlockDriverState *parent_bs,
 BdrvChild *child = g_new(BdrvChild, 1);
 *child = (BdrvChild) {
 .bs = child_bs,
+.parent = parent_bs,
 .name   = g_strdup(child_name),
 .role   = child_role,
 };
diff --git a/include/block/block_int.h b/include/block/block_int.h
index ebe8b1e..19c02b6 100644
--- a/include/block/block_int.h
+++ b/include/block/block_int.h
@@ -361,6 +361,7 @@ extern const BdrvChildRole child_format;
 
 struct BdrvChild {
 BlockDriverState *bs;
+BlockDriverState *parent;
 char *name;
 const BdrvChildRole *role;
 QLIST_ENTRY(BdrvChild) next;
-- 
1.9.3

[Qemu-devel] [PATCH v14 5/8] docs: block replication's description

[Changlong Xie]

From: Wen Congyang 

Signed-off-by: Wen Congyang 
Signed-off-by: zhanghailiang 
Signed-off-by: Gonglei 
Signed-off-by: Changlong Xie 
---
 docs/block-replication.txt | 229 +
 1 file changed, 229 insertions(+)
 create mode 100644 docs/block-replication.txt

diff --git a/docs/block-replication.txt b/docs/block-replication.txt
new file mode 100644
index 000..d1a231e
--- /dev/null
+++ b/docs/block-replication.txt
@@ -0,0 +1,229 @@
+Block replication
+
+Copyright Fujitsu, Corp. 2015
+Copyright (c) 2015 Intel Corporation
+Copyright (c) 2015 HUAWEI TECHNOLOGIES CO., LTD.
+
+This work is licensed under the terms of the GNU GPL, version 2 or later.
+See the COPYING file in the top-level directory.
+
+Block replication is used for continuous checkpoints. It is designed
+for COLO (COarse-grain LOck-stepping) where the Secondary VM is running.
+It can also be applied for FT/HA (Fault-tolerance/High Assurance) scenario,
+where the Secondary VM is not running.
+
+This document gives an overview of block replication's design.
+
+== Background ==
+High availability solutions such as micro checkpoint and COLO will do
+consecutive checkpoints. The VM state of Primary VM and Secondary VM is
+identical right after a VM checkpoint, but becomes different as the VM
+executes till the next checkpoint. To support disk contents checkpoint,
+the modified disk contents in the Secondary VM must be buffered, and are
+only dropped at next checkpoint time. To reduce the network transportation
+effort at the time of checkpoint, the disk modification operations of
+Primary disk are asynchronously forwarded to the Secondary node.
+
+== Workflow ==
+The following is the image of block replication workflow:
+
++--+++
+|Primary Write Requests||Secondary Write Requests|
++--+++
+  |   |
+  |  (4)
+  |   V
+  |  /-\
+  |  Copy and Forward| |
+  |-(1)--+   | Disk Buffer |
+  |  |   | |
+  | (3)  \-/
+  | speculative  ^
+  |write through(2)
+  |  |   |
+  V  V   |
+   +--+   ++
+   | Primary Disk |   | Secondary Disk |
+   +--+   ++
+
+1) Primary write requests will be copied and forwarded to Secondary
+   QEMU.
+2) Before Primary write requests are written to Secondary disk, the
+   original sector content will be read from Secondary disk and
+   buffered in the Disk buffer, but it will not overwrite the existing
+   sector content (it could be from either "Secondary Write Requests" or
+   previous COW of "Primary Write Requests") in the Disk buffer.
+3) Primary write requests will be written to Secondary disk.
+4) Secondary write requests will be buffered in the Disk buffer and it
+   will overwrite the existing sector content in the buffer.
+
+== Architecture ==
+We are going to implement block replication from many basic
+blocks that are already in QEMU.
+
+ virtio-blk   ||
+ ^||.--
+ |||| Secondary
+1 Quorum  ||'--
+ /  \ ||
+/\||
+   Primary2 filter
+ disk ^
 virtio-blk
+  |
  ^
+3 NBD  --->  3 NBD 
  |
+client|| server
  2 filter
+  ||^  
  ^
+. |||  
  |
+Primary | ||  Secondary disk <- hidden-disk 5 
<- active-disk 4
+' |||  backing^   backing
+  ||| |
+  ||| |
+ 

[Qemu-devel] [PATCH v14 7/8] Implement new driver for block replication

[Changlong Xie]

From: Wen Congyang 

Signed-off-by: Wen Congyang 
Signed-off-by: zhanghailiang 
Signed-off-by: Gonglei 
Signed-off-by: Changlong Xie 
---
 block/Makefile.objs  |   1 +
 block/replication-comm.c |  66 +
 block/replication.c  | 590 +++
 include/block/replication-comm.h |  50 
 qapi/block-core.json |  13 +
 5 files changed, 720 insertions(+)
 create mode 100644 block/replication-comm.c
 create mode 100644 block/replication.c
 create mode 100644 include/block/replication-comm.h

diff --git a/block/Makefile.objs b/block/Makefile.objs
index fa05f37..7037662 100644
--- a/block/Makefile.objs
+++ b/block/Makefile.objs
@@ -23,6 +23,7 @@ block-obj-$(CONFIG_LIBSSH2) += ssh.o
 block-obj-y += accounting.o
 block-obj-y += write-threshold.o
 block-obj-y += backup.o
+block-obj-y += replication-comm.o replication.o
 
 common-obj-y += stream.o
 common-obj-y += commit.o
diff --git a/block/replication-comm.c b/block/replication-comm.c
new file mode 100644
index 000..8af748b
--- /dev/null
+++ b/block/replication-comm.c
@@ -0,0 +1,66 @@
+/*
+ * Replication Block filter
+ *
+ * Copyright (c) 2015 HUAWEI TECHNOLOGIES CO., LTD.
+ * Copyright (c) 2015 Intel Corporation
+ * Copyright (c) 2015 FUJITSU LIMITED
+ *
+ * Author:
+ *   Wen Congyang 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include "block/replication-comm.h"
+
+static QLIST_HEAD(, BlockReplicationState) block_replication_states;
+
+BlockReplicationState *block_replication_new(BlockDriverState *bs,
+ BlockReplicationOps *ops)
+{
+BlockReplicationState *brs;
+
+brs = g_new0(BlockReplicationState, 1);
+brs->bs = bs;
+brs->ops = ops;
+QLIST_INSERT_HEAD(_replication_states, brs, node);
+
+return brs;
+}
+
+void block_replication_remove(BlockReplicationState *brs)
+{
+QLIST_REMOVE(brs, node);
+g_free(brs);
+}
+
+void block_replication_start_all(ReplicationMode mode, Error **errp)
+{
+BlockReplicationState *brs, *next;
+QLIST_FOREACH_SAFE(brs, _replication_states, node, next) {
+if (brs->ops && brs->ops->start) {
+brs->ops->start(brs, mode, errp);
+}
+}
+}
+
+void block_replication_do_checkpoint_all(Error **errp)
+{
+BlockReplicationState *brs, *next;
+QLIST_FOREACH_SAFE(brs, _replication_states, node, next) {
+if (brs->ops && brs->ops->checkpoint) {
+brs->ops->checkpoint(brs, errp);
+}
+}
+}
+
+void block_replication_stop_all(bool failover, Error **errp)
+{
+BlockReplicationState *brs, *next;
+QLIST_FOREACH_SAFE(brs, _replication_states, node, next) {
+if (brs->ops && brs->ops->stop) {
+brs->ops->stop(brs, failover, errp);
+}
+}
+}
diff --git a/block/replication.c b/block/replication.c
new file mode 100644
index 000..29c677a
--- /dev/null
+++ b/block/replication.c
@@ -0,0 +1,590 @@
+/*
+ * Replication Block filter
+ *
+ * Copyright (c) 2015 HUAWEI TECHNOLOGIES CO., LTD.
+ * Copyright (c) 2015 Intel Corporation
+ * Copyright (c) 2015 FUJITSU LIMITED
+ *
+ * Author:
+ *   Wen Congyang 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include "qemu-common.h"
+#include "block/blockjob.h"
+#include "block/nbd.h"
+#include "block/replication-comm.h"
+
+typedef struct BDRVReplicationState {
+ReplicationMode mode;
+int replication_state;
+BlockDriverState *active_disk;
+BlockDriverState *hidden_disk;
+BlockDriverState *secondary_disk;
+BlockDriverState *top_bs;
+BlockReplicationState *brs;
+Error *blocker;
+int orig_hidden_flags;
+int orig_secondary_flags;
+int error;
+} BDRVReplicationState;
+
+enum {
+BLOCK_REPLICATION_NONE, /* block replication is not started */
+BLOCK_REPLICATION_RUNNING,  /* block replication is running */
+BLOCK_REPLICATION_FAILOVER, /* failover is running in background */
+BLOCK_REPLICATION_FAILOVER_FAILED,  /* failover failed*/
+BLOCK_REPLICATION_DONE, /* block replication is done(after 
failover) */
+};
+
+static void replication_start(BlockReplicationState *brs, ReplicationMode mode,
+  Error **errp);
+static void replication_do_checkpoint(BlockReplicationState *brs, Error 
**errp);
+static void replication_stop(BlockReplicationState *brs, bool failover,
+ Error **errp);
+
+#define REPLICATION_MODE"mode"
+static QemuOptsList replication_runtime_opts = {
+.name = "replication",
+.head = 

[Qemu-devel] [PATCH 6/6] virtio-gpu: block any rendering until client (ui) is done

[Gerd Hoffmann]

Wire up gl_block callback, so ui code can request to stop
virtio-gpu rendering.

Signed-off-by: Gerd Hoffmann 
---
 hw/display/virtio-gpu-3d.c |  5 +
 hw/display/virtio-gpu.c|  8 
 hw/display/virtio-vga.c| 10 ++
 include/hw/virtio/virtio-gpu.h |  1 +
 4 files changed, 24 insertions(+)

diff --git a/hw/display/virtio-gpu-3d.c b/hw/display/virtio-gpu-3d.c
index 65926b1..321a959 100644
--- a/hw/display/virtio-gpu-3d.c
+++ b/hw/display/virtio-gpu-3d.c
@@ -382,6 +382,11 @@ void virtio_gpu_virgl_process_cmd(VirtIOGPU *g,
 {
 VIRTIO_GPU_FILL_CMD(cmd->cmd_hdr);
 
+cmd->waiting = g->renderer_blocked;
+if (cmd->waiting) {
+return;
+}
+
 virgl_renderer_force_ctx_0();
 switch (cmd->cmd_hdr.type) {
 case VIRTIO_GPU_CMD_CTX_CREATE:
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index 9087e63..09936c9 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -893,11 +893,19 @@ static int virtio_gpu_ui_info(void *opaque, uint32_t idx, 
QemuUIInfo *info)
 return 0;
 }
 
+static void virtio_gpu_gl_block(void *opaque, bool block)
+{
+VirtIOGPU *g = opaque;
+
+g->renderer_blocked = block;
+}
+
 const GraphicHwOps virtio_gpu_ops = {
 .invalidate = virtio_gpu_invalidate_display,
 .gfx_update = virtio_gpu_update_display,
 .text_update = virtio_gpu_text_update,
 .ui_info = virtio_gpu_ui_info,
+.gl_block = virtio_gpu_gl_block,
 };
 
 static void virtio_gpu_device_realize(DeviceState *qdev, Error **errp)
diff --git a/hw/display/virtio-vga.c b/hw/display/virtio-vga.c
index f7e539f..255d419 100644
--- a/hw/display/virtio-vga.c
+++ b/hw/display/virtio-vga.c
@@ -65,11 +65,21 @@ static int virtio_vga_ui_info(void *opaque, uint32_t idx, 
QemuUIInfo *info)
 return -1;
 }
 
+static void virtio_vga_gl_block(void *opaque, bool block)
+{
+VirtIOVGA *vvga = opaque;
+
+if (virtio_gpu_ops.gl_block) {
+virtio_gpu_ops.gl_block(>vdev, block);
+}
+}
+
 static const GraphicHwOps virtio_vga_ops = {
 .invalidate = virtio_vga_invalidate_display,
 .gfx_update = virtio_vga_update_display,
 .text_update = virtio_vga_text_update,
 .ui_info = virtio_vga_ui_info,
+.gl_block = virtio_vga_gl_block,
 };
 
 /* VGA device wrapper around PCI device around virtio GPU */
diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
index fdf0091..7249fcd 100644
--- a/include/hw/virtio/virtio-gpu.h
+++ b/include/hw/virtio/virtio-gpu.h
@@ -107,6 +107,7 @@ typedef struct VirtIOGPU {
 
 bool use_virgl_renderer;
 bool renderer_inited;
+bool renderer_blocked;
 QEMUTimer *fence_poll;
 QEMUTimer *print_stats;
 
-- 
1.8.3.1

[Qemu-devel] [PATCH 2/6] console: block rendering until client is done

[Gerd Hoffmann]

Allow gl user interfaces to block display device gl rendering.
The ui code might want to do that in case it takes a little
longer to bring things to screen, for example because we'll
hand over a dma-buf to another process (spice will do that).

Signed-off-by: Gerd Hoffmann 
---
 include/ui/console.h |  2 ++
 ui/console.c | 10 ++
 2 files changed, 12 insertions(+)

diff --git a/include/ui/console.h b/include/ui/console.h
index adac36d..12ad627 100644
--- a/include/ui/console.h
+++ b/include/ui/console.h
@@ -362,6 +362,7 @@ typedef struct GraphicHwOps {
 void (*text_update)(void *opaque, console_ch_t *text);
 void (*update_interval)(void *opaque, uint64_t interval);
 int (*ui_info)(void *opaque, uint32_t head, QemuUIInfo *info);
+void (*gl_block)(void *opaque, bool block);
 } GraphicHwOps;
 
 QemuConsole *graphic_console_init(DeviceState *dev, uint32_t head,
@@ -374,6 +375,7 @@ void graphic_console_set_hwops(QemuConsole *con,
 void graphic_hw_update(QemuConsole *con);
 void graphic_hw_invalidate(QemuConsole *con);
 void graphic_hw_text_update(QemuConsole *con, console_ch_t *chardata);
+void graphic_hw_gl_block(QemuConsole *con, bool block);
 
 QemuConsole *qemu_console_lookup_by_index(unsigned int index);
 QemuConsole *qemu_console_lookup_by_device(DeviceState *dev, uint32_t head);
diff --git a/ui/console.c b/ui/console.c
index 4b65c34..f0a4bd8 100644
--- a/ui/console.c
+++ b/ui/console.c
@@ -261,6 +261,16 @@ void graphic_hw_update(QemuConsole *con)
 }
 }
 
+void graphic_hw_gl_block(QemuConsole *con, bool block)
+{
+if (!con) {
+con = active_console;
+}
+if (con && con->hw_ops->gl_block) {
+con->hw_ops->gl_block(con->hw, block);
+}
+}
+
 void graphic_hw_invalidate(QemuConsole *con)
 {
 if (!con) {
-- 
1.8.3.1

Re: [Qemu-devel] [PATCH] qemu-img: Speed up comparing empty/zero images

[Paolo Bonzini]

On 13/01/2016 09:37, Fam Zheng wrote:
> Two empty raw files are always compared by actually reading data even if
> there is no data, because BDRV_BLOCK_ZERO is considered "allocated" in
> bdrv_is_allocated_above().  That is inefficient.
> 
> Use bdrv_get_block_status_above() for more information, and skip the
> consecutive zero sectors.
> 
> This brings a huge speed up in comparing sparse/empty raw images:
> 
> $ qemu-img create a 1G
> 
> $ time ~/build/master/bin/qemu-img compare a a
> Images are identical.
> 
> real0m6.583s
> user0m0.191s
> sys 0m6.367s
> 
> $ time qemu-img compare a a
> Images are identical.
> 
> real0m0.033s
> user0m0.003s
> sys 0m0.031s
> 
> Signed-off-by: Fam Zheng 
> ---
>  qemu-img.c | 45 ++---
>  1 file changed, 30 insertions(+), 15 deletions(-)
> 
> diff --git a/qemu-img.c b/qemu-img.c
> index 3d48b4f..82f704f 100644
> --- a/qemu-img.c
> +++ b/qemu-img.c
> @@ -1074,28 +1074,50 @@ static int img_compare(int argc, char **argv)
>  }
>  
>  for (;;) {
> +int64_t status1, status2;
>  nb_sectors = sectors_to_process(total_sectors, sector_num);
>  if (nb_sectors <= 0) {
>  break;
>  }
> -allocated1 = bdrv_is_allocated_above(bs1, NULL, sector_num, 
> nb_sectors,
> - );
> -if (allocated1 < 0) {
> +status1 = bdrv_get_block_status_above(bs1, NULL, sector_num,
> +  total_sectors1 - sector_num,
> +  );
> +if (status1 < 0) {
>  ret = 3;
>  error_report("Sector allocation test failed for %s", filename1);
>  goto out;
>  }
> +allocated1 = status1 & BDRV_BLOCK_ALLOCATED;
>  
> -allocated2 = bdrv_is_allocated_above(bs2, NULL, sector_num, 
> nb_sectors,
> - );
> -if (allocated2 < 0) {
> +status2 = bdrv_get_block_status_above(bs2, NULL, sector_num,
> +  total_sectors2 - sector_num,
> +  );
> +if (status2 < 0) {
>  ret = 3;
>  error_report("Sector allocation test failed for %s", filename2);
>  goto out;
>  }
> -nb_sectors = MIN(pnum1, pnum2);
> +allocated2 = status2 & BDRV_BLOCK_ALLOCATED;
> +if (pnum1) {
> +nb_sectors = MIN(nb_sectors, pnum1);
> +}
> +if (pnum2) {
> +nb_sectors = MIN(nb_sectors, pnum2);
> +}
>  
> -if (allocated1 == allocated2) {
> +if (strict) {
> +if ((status1 & ~BDRV_BLOCK_OFFSET_MASK) !=
> +(status2 & ~BDRV_BLOCK_OFFSET_MASK)) {

This is not exactly the same definition as before, but if that's okay:

Reviewed-by: Paolo Bonzini 

> +ret = 1;
> +qprintf(quiet, "Strict mode: Offset %" PRId64
> +" block status mismatch!\n",
> +sectors_to_bytes(sector_num));
> +goto out;
> +}
> +}
> +if ((status1 & BDRV_BLOCK_ZERO) && (status2 & BDRV_BLOCK_ZERO)) {
> +nb_sectors = MIN(pnum1, pnum2);
> +} else if (allocated1 == allocated2) {
>  if (allocated1) {
>  ret = blk_read(blk1, sector_num, buf1, nb_sectors);
>  if (ret < 0) {
> @@ -1123,13 +1145,6 @@ static int img_compare(int argc, char **argv)
>  }
>  }
>  } else {
> -if (strict) {
> -ret = 1;
> -qprintf(quiet, "Strict mode: Offset %" PRId64
> -" allocation mismatch!\n",
> -sectors_to_bytes(sector_num));
> -goto out;
> -}
>  
>  if (allocated1) {
>  ret = check_empty_sectors(blk1, sector_num, nb_sectors,
> 

Re: [Qemu-devel] [PATCH 2/6] console: block rendering until client is done

[Marc-André Lureau]

Hi

On Wed, Jan 13, 2016 at 1:02 PM, Gerd Hoffmann  wrote:
> Allow gl user interfaces to block display device gl rendering.
> The ui code might want to do that in case it takes a little
> longer to bring things to screen, for example because we'll
> hand over a dma-buf to another process (spice will do that).
>
> Signed-off-by: Gerd Hoffmann 

Reviewed-by: Marc-André Lureau 

> ---
>  include/ui/console.h |  2 ++
>  ui/console.c | 10 ++
>  2 files changed, 12 insertions(+)
>
> diff --git a/include/ui/console.h b/include/ui/console.h
> index adac36d..12ad627 100644
> --- a/include/ui/console.h
> +++ b/include/ui/console.h
> @@ -362,6 +362,7 @@ typedef struct GraphicHwOps {
>  void (*text_update)(void *opaque, console_ch_t *text);
>  void (*update_interval)(void *opaque, uint64_t interval);
>  int (*ui_info)(void *opaque, uint32_t head, QemuUIInfo *info);
> +void (*gl_block)(void *opaque, bool block);
>  } GraphicHwOps;
>
>  QemuConsole *graphic_console_init(DeviceState *dev, uint32_t head,
> @@ -374,6 +375,7 @@ void graphic_console_set_hwops(QemuConsole *con,
>  void graphic_hw_update(QemuConsole *con);
>  void graphic_hw_invalidate(QemuConsole *con);
>  void graphic_hw_text_update(QemuConsole *con, console_ch_t *chardata);
> +void graphic_hw_gl_block(QemuConsole *con, bool block);
>
>  QemuConsole *qemu_console_lookup_by_index(unsigned int index);
>  QemuConsole *qemu_console_lookup_by_device(DeviceState *dev, uint32_t head);
> diff --git a/ui/console.c b/ui/console.c
> index 4b65c34..f0a4bd8 100644
> --- a/ui/console.c
> +++ b/ui/console.c
> @@ -261,6 +261,16 @@ void graphic_hw_update(QemuConsole *con)
>  }
>  }
>
> +void graphic_hw_gl_block(QemuConsole *con, bool block)
> +{
> +if (!con) {
> +con = active_console;
> +}
> +if (con && con->hw_ops->gl_block) {
> +con->hw_ops->gl_block(con->hw, block);
> +}
> +}
> +
>  void graphic_hw_invalidate(QemuConsole *con)
>  {
>  if (!con) {
> --
> 1.8.3.1
>



-- 
Marc-André Lureau

Re: [Qemu-devel] [PATCH 1/6] zap qemu_egl_has_ext in include/ui/egl-helpers.h

[Marc-André Lureau]

Reviewed-by: Marc-André Lureau 

On Wed, Jan 13, 2016 at 1:02 PM, Gerd Hoffmann  wrote:
> Drop leftover prototype which sneaked in by mistake
>
> Signed-off-by: Gerd Hoffmann 
> ---
>  include/ui/egl-helpers.h | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/include/ui/egl-helpers.h b/include/ui/egl-helpers.h
> index 5ad5dc3..8c84398 100644
> --- a/include/ui/egl-helpers.h
> +++ b/include/ui/egl-helpers.h
> @@ -11,6 +11,5 @@ EGLSurface qemu_egl_init_surface_x11(EGLContext ectx, 
> Window win);
>
>  int qemu_egl_init_dpy(EGLNativeDisplayType dpy, bool gles, bool debug);
>  EGLContext qemu_egl_init_ctx(void);
> -bool qemu_egl_has_ext(const char *haystack, const char *needle);
>
>  #endif /* EGL_HELPERS_H */
> --
> 1.8.3.1
>



-- 
Marc-André Lureau

[Qemu-devel] [PATCH v14 0/8] Block replication for continuous checkpoints

[Changlong Xie]

Block replication is a very important feature which is used for
continuous checkpoints(for example: COLO).

You can get the detailed information about block replication from here:
http://wiki.qemu.org/Features/BlockReplication

Usage:
Please refer to docs/block-replication.txt

This patch series is based on the following patch series:
1. http://lists.nongnu.org/archive/html/qemu-devel/2015-12/msg04570.html

You can get the patch here:
https://github.com/Pating/qemu/tree/changlox/block-replication-v14

You can get the patch with framework here:
https://github.com/Pating/qemu/tree/changlox/colo_framework_v13

TODO:
1. Continuous block replication. It will be started after basic functions
   are accepted.

Changs Log:
V14:
1. Implement auto complete active commit
2. Implement active commit block job for replication.c
3. Address the comments from Stefan, add replication-specific API and data
   structure, also remove old block layer APIs
V13:
1. Rebase to the newest codes
2. Remove redundant marcos and semicolon in replication.c 
3. Fix typos in block-replication.txt
V12:
1. Rebase to the newest codes
2. Use backing reference to replcace 'allow-write-backing-file'
V11:
1. Reopen the backing file when starting blcok replication if it is not
   opened in R/W mode
2. Unblock BLOCK_OP_TYPE_BACKUP_SOURCE and BLOCK_OP_TYPE_BACKUP_TARGET
   when opening backing file
3. Block the top BDS so there is only one block job for the top BDS and
   its backing chain.
V10:
1. Use blockdev-remove-medium and blockdev-insert-medium to replace backing
   reference.
2. Address the comments from Eric Blake
V9:
1. Update the error messages
2. Rebase to the newest qemu
3. Split child add/delete support. These patches are sent in another patchset.
V8:
1. Address Alberto Garcia's comments
V7:
1. Implement adding/removing quorum child. Remove the option non-connect.
2. Simplify the backing refrence option according to Stefan Hajnoczi's 
suggestion
V6:
1. Rebase to the newest qemu.
V5:
1. Address the comments from Gong Lei
2. Speed the failover up. The secondary vm can take over very quickly even
   if there are too many I/O requests.
V4:
1. Introduce a new driver replication to avoid touch nbd and qcow2.
V3:
1: use error_setg() instead of error_set()
2. Add a new block job API
3. Active disk, hidden disk and nbd target uses the same AioContext
4. Add a testcase to test new hbitmap API
V2:
1. Redesign the secondary qemu(use image-fleecing)
2. Use Error objects to return error message
3. Address the comments from Max Reitz and Eric Blake

Wen Congyang (8):
  unblock backup operations in backing file
  Store parent BDS in BdrvChild
  Backup: clear all bitmap when doing block checkpoint
  Allow creating backup jobs when opening BDS
  docs: block replication's description
  auto complete active commit
  Implement new driver for block replication
  support replication driver in blockdev-add

 block.c  |  19 ++
 block/Makefile.objs  |   3 +-
 block/backup.c   |  14 +
 block/mirror.c   |  13 +-
 block/replication-comm.c |  66 +
 block/replication.c  | 590 +++
 blockdev.c   |   2 +-
 blockjob.c   |  11 +
 docs/block-replication.txt   | 229 +++
 include/block/block_int.h|   4 +-
 include/block/blockjob.h |  12 +
 include/block/replication-comm.h |  50 
 qapi/block-core.json |  33 ++-
 qemu-img.c   |   2 +-
 14 files changed, 1038 insertions(+), 10 deletions(-)
 create mode 100644 block/replication-comm.c
 create mode 100644 block/replication.c
 create mode 100644 docs/block-replication.txt
 create mode 100644 include/block/replication-comm.h

-- 
1.9.3

Re: [Qemu-devel] [PATCH] ARM: Virt: Don't generate RTC ACPI node when using UEFI

[Peter Maydell]

On 13 January 2016 at 10:48, Laszlo Ersek  wrote:
> On 01/13/16 11:20, Ard Biesheuvel wrote:
>> I am not buying it either, to be honest. In fact, I think it is
>> another reason why we should mandate UEFI when using ACPI (which is
>> already the case in practice). Then, we can simply omit the RTC ACPI
>> node entirely.
>
> Good point.

Yes, a patch that simply removed the RTC device from the
ACPI table altogether would I think be better. That then
continues with the current approach that the tables provided
by QEMU are intended for use only with a UEFI bios in
the picture.

thanks
-- PMM

[Qemu-devel] [PATCH 4/6] virtio-gpu: maintain command queue

[Gerd Hoffmann]

We'll go take out the commands we receive out of the virt queue and put
them into a linked list, to decouple virtio queue handling from actual
command processing.

Also move cmd processing to new virtio_gpu_handle_ctrl func, so we can
easily kick it from different places.

Signed-off-by: Gerd Hoffmann 
---
 hw/display/virtio-gpu.c| 60 ++
 include/hw/virtio/virtio-gpu.h |  1 +
 2 files changed, 39 insertions(+), 22 deletions(-)

diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index 7e79a9c..4433c12 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -754,33 +754,21 @@ static void virtio_gpu_handle_cursor_cb(VirtIODevice 
*vdev, VirtQueue *vq)
 qemu_bh_schedule(g->cursor_bh);
 }
 
-static void virtio_gpu_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
+static void virtio_cpu_process_cmdq(VirtIOGPU *g)
 {
-VirtIOGPU *g = VIRTIO_GPU(vdev);
 struct virtio_gpu_ctrl_command *cmd;
 
-if (!virtio_queue_ready(vq)) {
-return;
-}
-
-#ifdef CONFIG_VIRGL
-if (!g->renderer_inited && g->use_virgl_renderer) {
-virtio_gpu_virgl_init(g);
-g->renderer_inited = true;
-}
-#endif
-
-cmd = g_new(struct virtio_gpu_ctrl_command, 1);
-while (virtqueue_pop(vq, >elem)) {
-cmd->vq = vq;
-cmd->error = 0;
-cmd->finished = false;
-if (virtio_gpu_stats_enabled(g->conf)) {
-g->stats.requests++;
-}
+while (!QTAILQ_EMPTY(>cmdq)) {
+cmd = QTAILQ_FIRST(>cmdq);
 
+/* process command */
 VIRGL(g, virtio_gpu_virgl_process_cmd, virtio_gpu_simple_process_cmd,
   g, cmd);
+QTAILQ_REMOVE(>cmdq, cmd, next);
+if (virtio_gpu_stats_enabled(g->conf)) {
+g->stats.requests++;
+}
+
 if (!cmd->finished) {
 QTAILQ_INSERT_TAIL(>fenceq, cmd, next);
 g->inflight++;
@@ -790,11 +778,38 @@ static void virtio_gpu_handle_ctrl(VirtIODevice *vdev, 
VirtQueue *vq)
 }
 fprintf(stderr, "inflight: %3d (+)\r", g->inflight);
 }
-cmd = g_new(struct virtio_gpu_ctrl_command, 1);
 }
 }
+}
+
+static void virtio_gpu_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
+{
+VirtIOGPU *g = VIRTIO_GPU(vdev);
+struct virtio_gpu_ctrl_command *cmd;
+
+if (!virtio_queue_ready(vq)) {
+return;
+}
+
+#ifdef CONFIG_VIRGL
+if (!g->renderer_inited && g->use_virgl_renderer) {
+virtio_gpu_virgl_init(g);
+g->renderer_inited = true;
+}
+#endif
+
+cmd = g_new0(struct virtio_gpu_ctrl_command, 1);
+while (virtqueue_pop(vq, >elem)) {
+cmd->vq = vq;
+cmd->error = 0;
+cmd->finished = false;
+QTAILQ_INSERT_TAIL(>cmdq, cmd, next);
+cmd = g_new0(struct virtio_gpu_ctrl_command, 1);
+}
 g_free(cmd);
 
+virtio_cpu_process_cmdq(g);
+
 #ifdef CONFIG_VIRGL
 if (g->use_virgl_renderer) {
 virtio_gpu_virgl_fence_poll(g);
@@ -920,6 +935,7 @@ static void virtio_gpu_device_realize(DeviceState *qdev, 
Error **errp)
 g->ctrl_bh = qemu_bh_new(virtio_gpu_ctrl_bh, g);
 g->cursor_bh = qemu_bh_new(virtio_gpu_cursor_bh, g);
 QTAILQ_INIT(>reslist);
+QTAILQ_INIT(>cmdq);
 QTAILQ_INIT(>fenceq);
 
 g->enabled_output_bitmask = 1;
diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
index 9b279d7..f7e7a52 100644
--- a/include/hw/virtio/virtio-gpu.h
+++ b/include/hw/virtio/virtio-gpu.h
@@ -94,6 +94,7 @@ typedef struct VirtIOGPU {
 DeviceState *qdev;
 
 QTAILQ_HEAD(, virtio_gpu_simple_resource) reslist;
+QTAILQ_HEAD(, virtio_gpu_ctrl_command) cmdq;
 QTAILQ_HEAD(, virtio_gpu_ctrl_command) fenceq;
 
 struct virtio_gpu_scanout scanout[VIRTIO_GPU_MAX_SCANOUT];
-- 
1.8.3.1

[Qemu-devel] [PATCH v5 2/5] Add Error **errp for xen_host_pci_device_get()

[Cao jin]

To catch the error msg. Also modify the caller

Signed-off-by: Cao jin 
---
 hw/xen/xen-host-pci-device.c | 142 +--
 hw/xen/xen-host-pci-device.h |   5 +-
 hw/xen/xen_pt.c  |  13 ++--
 3 files changed, 80 insertions(+), 80 deletions(-)

diff --git a/hw/xen/xen-host-pci-device.c b/hw/xen/xen-host-pci-device.c
index 351b61a..3e22de8 100644
--- a/hw/xen/xen-host-pci-device.c
+++ b/hw/xen/xen-host-pci-device.c
@@ -31,25 +31,20 @@
 #define IORESOURCE_PREFETCH 0x1000  /* No side effects */
 #define IORESOURCE_MEM_64   0x0010
 
-static int xen_host_pci_sysfs_path(const XenHostPCIDevice *d,
-   const char *name, char *buf, ssize_t size)
+static void xen_host_pci_sysfs_path(const XenHostPCIDevice *d,
+const char *name, char *buf, ssize_t size)
 {
 int rc;
 
 rc = snprintf(buf, size, "/sys/bus/pci/devices/%04x:%02x:%02x.%d/%s",
   d->domain, d->bus, d->dev, d->func, name);
-
-if (rc >= size || rc < 0) {
-/* The output is truncated, or some other error was encountered */
-return -ENODEV;
-}
-return 0;
+assert(rc >= 0 && rc < size);
 }
 
 
 /* This size should be enough to read the first 7 lines of a resource file */
 #define XEN_HOST_PCI_RESOURCE_BUFFER_SIZE 400
-static int xen_host_pci_get_resource(XenHostPCIDevice *d)
+static void xen_host_pci_get_resource(XenHostPCIDevice *d, Error **errp)
 {
 int i, rc, fd;
 char path[PATH_MAX];
@@ -58,25 +53,22 @@ static int xen_host_pci_get_resource(XenHostPCIDevice *d)
 char *endptr, *s;
 uint8_t type;
 
-rc = xen_host_pci_sysfs_path(d, "resource", path, sizeof (path));
-if (rc) {
-return rc;
-}
+xen_host_pci_sysfs_path(d, "resource", path, sizeof(path));
+
 fd = open(path, O_RDONLY);
 if (fd == -1) {
-XEN_HOST_PCI_LOG("Error: Can't open %s: %s\n", path, strerror(errno));
-return -errno;
+error_setg_file_open(errp, errno, path);
+return;
 }
 
 do {
-rc = read(fd, , sizeof (buf) - 1);
+rc = read(fd, , sizeof(buf) - 1);
 if (rc < 0 && errno != EINTR) {
-rc = -errno;
+error_setg_errno(errp, errno, "read err");
 goto out;
 }
 } while (rc < 0);
 buf[rc] = 0;
-rc = 0;
 
 s = buf;
 for (i = 0; i < PCI_NUM_REGIONS; i++) {
@@ -129,65 +121,65 @@ static int xen_host_pci_get_resource(XenHostPCIDevice *d)
 d->rom.bus_flags = flags & IORESOURCE_BITS;
 }
 }
+
 if (i != PCI_NUM_REGIONS) {
-/* Invalid format or input to short */
-rc = -ENODEV;
+error_setg(errp, "Invalid format or input too short: %s", buf);
 }
 
 out:
 close(fd);
-return rc;
 }
 
 /* This size should be enough to read a long from a file */
 #define XEN_HOST_PCI_GET_VALUE_BUFFER_SIZE 22
-static int xen_host_pci_get_value(XenHostPCIDevice *d, const char *name,
-  unsigned int *pvalue, int base)
+static void xen_host_pci_get_value(XenHostPCIDevice *d, const char *name,
+   unsigned int *pvalue, int base, Error 
**errp)
 {
 char path[PATH_MAX];
 char buf[XEN_HOST_PCI_GET_VALUE_BUFFER_SIZE];
 int fd, rc;
-unsigned long value;
 const char *endptr;
 
-rc = xen_host_pci_sysfs_path(d, name, path, sizeof (path));
-if (rc) {
-return rc;
-}
+xen_host_pci_sysfs_path(d, name, path, sizeof(path));
+
 fd = open(path, O_RDONLY);
 if (fd == -1) {
-XEN_HOST_PCI_LOG("Error: Can't open %s: %s\n", path, strerror(errno));
-return -errno;
+error_setg_file_open(errp, errno, path);
+return;
 }
+
 do {
-rc = read(fd, , sizeof (buf) - 1);
+rc = read(fd, , sizeof(buf) - 1);
 if (rc < 0 && errno != EINTR) {
-rc = -errno;
+error_setg_errno(errp, errno, "read err");
 goto out;
 }
 } while (rc < 0);
+
 buf[rc] = 0;
-rc = qemu_strtoul(buf, , base, );
-if (!rc) {
-*pvalue = value;
+rc = qemu_strtoul(buf, , base, (unsigned long *)pvalue);
+if (rc) {
+error_setg_errno(errp, -rc, "failed to parse value '%s'", buf);
 }
+
 out:
 close(fd);
-return rc;
 }
 
-static inline int xen_host_pci_get_hex_value(XenHostPCIDevice *d,
- const char *name,
- unsigned int *pvalue)
+static inline void xen_host_pci_get_hex_value(XenHostPCIDevice *d,
+  const char *name,
+  unsigned int *pvalue,
+  Error **errp)
 {
-return xen_host_pci_get_value(d, name, pvalue, 16);
+xen_host_pci_get_value(d, name, pvalue, 16, errp);
 }
 
-static 

[Qemu-devel] [PATCH v5 1/5] Xen: use qemu_strtoul instead of strtol

[Cao jin]

No need to roll our own (with slightly incorrect handling of errno),
when we can use the common version.

Change signed parsing to unsigned, because what it read are values in
PCI config space, which are non-negative.

Signed-off-by: Cao jin 
---
 hw/xen/xen-host-pci-device.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/hw/xen/xen-host-pci-device.c b/hw/xen/xen-host-pci-device.c
index 7d8a023..351b61a 100644
--- a/hw/xen/xen-host-pci-device.c
+++ b/hw/xen/xen-host-pci-device.c
@@ -148,7 +148,7 @@ static int xen_host_pci_get_value(XenHostPCIDevice *d, 
const char *name,
 char buf[XEN_HOST_PCI_GET_VALUE_BUFFER_SIZE];
 int fd, rc;
 unsigned long value;
-char *endptr;
+const char *endptr;
 
 rc = xen_host_pci_sysfs_path(d, name, path, sizeof (path));
 if (rc) {
@@ -167,13 +167,8 @@ static int xen_host_pci_get_value(XenHostPCIDevice *d, 
const char *name,
 }
 } while (rc < 0);
 buf[rc] = 0;
-value = strtol(buf, , base);
-if (endptr == buf || *endptr != '\n') {
-rc = -1;
-} else if ((value == LONG_MIN || value == LONG_MAX) && errno == ERANGE) {
-rc = -errno;
-} else {
-rc = 0;
+rc = qemu_strtoul(buf, , base, );
+if (!rc) {
 *pvalue = value;
 }
 out:
-- 
2.1.0

[Qemu-devel] [PATCH v5 3/5] Add Error **errp for xen_pt_setup_vga()

[Cao jin]

To catch the error msg. Also modify the caller

Signed-off-by: Cao jin 
---
 hw/xen/xen_pt.c  |  7 +--
 hw/xen/xen_pt.h  |  3 ++-
 hw/xen/xen_pt_graphics.c | 11 ++-
 3 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
index 53b5bca..07bfcec 100644
--- a/hw/xen/xen_pt.c
+++ b/hw/xen/xen_pt.c
@@ -808,8 +808,11 @@ static int xen_pt_initfn(PCIDevice *d)
 return -1;
 }
 
-if (xen_pt_setup_vga(s, >real_device) < 0) {
-XEN_PT_ERR(d, "Setup VGA BIOS of passthrough GFX failed!\n");
+xen_pt_setup_vga(s, >real_device, );
+if (err) {
+error_append_hint(, "Setup VGA BIOS of passthrough"
+" GFX failed");
+error_report_err(err);
 xen_host_pci_device_put(>real_device);
 return -1;
 }
diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
index c545280..dc74d3e 100644
--- a/hw/xen/xen_pt.h
+++ b/hw/xen/xen_pt.h
@@ -328,5 +328,6 @@ static inline bool is_igd_vga_passthrough(XenHostPCIDevice 
*dev)
 }
 int xen_pt_register_vga_regions(XenHostPCIDevice *dev);
 int xen_pt_unregister_vga_regions(XenHostPCIDevice *dev);
-int xen_pt_setup_vga(XenPCIPassthroughState *s, XenHostPCIDevice *dev);
+void xen_pt_setup_vga(XenPCIPassthroughState *s, XenHostPCIDevice *dev,
+ Error **errp);
 #endif /* !XEN_PT_H */
diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
index df6069b..25b6126 100644
--- a/hw/xen/xen_pt_graphics.c
+++ b/hw/xen/xen_pt_graphics.c
@@ -161,7 +161,8 @@ struct pci_data {
 uint16_t reserved;
 } __attribute__((packed));
 
-int xen_pt_setup_vga(XenPCIPassthroughState *s, XenHostPCIDevice *dev)
+void xen_pt_setup_vga(XenPCIPassthroughState *s, XenHostPCIDevice *dev,
+ Error **errp)
 {
 unsigned char *bios = NULL;
 struct rom_header *rom;
@@ -172,13 +173,14 @@ int xen_pt_setup_vga(XenPCIPassthroughState *s, 
XenHostPCIDevice *dev)
 struct pci_data *pd = NULL;
 
 if (!is_igd_vga_passthrough(dev)) {
-return -1;
+error_setg(errp, "Need to enable igd-passthrough");
+return;
 }
 
 bios = get_vgabios(s, _size, dev);
 if (!bios) {
-XEN_PT_ERR(>dev, "VGA: Can't getting VBIOS!\n");
-return -1;
+error_setg(errp, "VGA: Can't getting VBIOS");
+return;
 }
 
 /* Currently we fixed this address as a primary. */
@@ -203,7 +205,6 @@ int xen_pt_setup_vga(XenPCIPassthroughState *s, 
XenHostPCIDevice *dev)
 
 /* Currently we fixed this address as a primary for legacy BIOS. */
 cpu_physical_memory_rw(0xc, bios, bios_size, 1);
-return 0;
 }
 
 uint32_t igd_read_opregion(XenPCIPassthroughState *s)
-- 
2.1.0

[Qemu-devel] [PATCH v5 4/5] Add Error **errp for xen_pt_config_init()

[Cao jin]

To catch the error msg. Also modify the caller

Signed-off-by: Cao jin 
---
 hw/xen/xen_pt.c |  8 ---
 hw/xen/xen_pt.h |  2 +-
 hw/xen/xen_pt_config_init.c | 51 -
 3 files changed, 33 insertions(+), 28 deletions(-)

diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
index 07bfcec..9eef3df 100644
--- a/hw/xen/xen_pt.c
+++ b/hw/xen/xen_pt.c
@@ -825,9 +825,11 @@ static int xen_pt_initfn(PCIDevice *d)
 xen_pt_register_regions(s, );
 
 /* reinitialize each config register to be emulated */
-rc = xen_pt_config_init(s);
-if (rc) {
-XEN_PT_ERR(d, "PCI Config space initialisation failed.\n");
+xen_pt_config_init(s, );
+if (err) {
+error_append_hint(, "PCI Config space initialisation failed");
+error_report_err(err);
+rc = -1;
 goto err_out;
 }
 
diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
index dc74d3e..466525f 100644
--- a/hw/xen/xen_pt.h
+++ b/hw/xen/xen_pt.h
@@ -228,7 +228,7 @@ struct XenPCIPassthroughState {
 bool listener_set;
 };
 
-int xen_pt_config_init(XenPCIPassthroughState *s);
+void xen_pt_config_init(XenPCIPassthroughState *s, Error **errp);
 void xen_pt_config_delete(XenPCIPassthroughState *s);
 XenPTRegGroup *xen_pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t 
address);
 XenPTReg *xen_pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address);
diff --git a/hw/xen/xen_pt_config_init.c b/hw/xen/xen_pt_config_init.c
index 3d8686d..128ccba 100644
--- a/hw/xen/xen_pt_config_init.c
+++ b/hw/xen/xen_pt_config_init.c
@@ -1899,8 +1899,9 @@ static uint8_t find_cap_offset(XenPCIPassthroughState *s, 
uint8_t cap)
 return 0;
 }
 
-static int xen_pt_config_reg_init(XenPCIPassthroughState *s,
-  XenPTRegGroup *reg_grp, XenPTRegInfo *reg)
+static void xen_pt_config_reg_init(XenPCIPassthroughState *s,
+   XenPTRegGroup *reg_grp, XenPTRegInfo *reg,
+   Error **errp)
 {
 XenPTReg *reg_entry;
 uint32_t data = 0;
@@ -1919,12 +1920,13 @@ static int 
xen_pt_config_reg_init(XenPCIPassthroughState *s,
reg_grp->base_offset + reg->offset, );
 if (rc < 0) {
 g_free(reg_entry);
-return rc;
+error_setg(errp, "Init emulate register fail");
+return;
 }
 if (data == XEN_PT_INVALID_REG) {
 /* free unused BAR register entry */
 g_free(reg_entry);
-return 0;
+return;
 }
 /* Sync up the data to dev.config */
 offset = reg_grp->base_offset + reg->offset;
@@ -1942,7 +1944,8 @@ static int xen_pt_config_reg_init(XenPCIPassthroughState 
*s,
 if (rc) {
 /* Serious issues when we cannot read the host values! */
 g_free(reg_entry);
-return rc;
+error_setg(errp, "Cannot read host values");
+return;
 }
 /* Set bits in emu_mask are the ones we emulate. The dev.config shall
  * contain the emulated view of the guest - therefore we flip the mask
@@ -1967,10 +1970,10 @@ static int 
xen_pt_config_reg_init(XenPCIPassthroughState *s,
 val = data;
 
 if (val & ~size_mask) {
-XEN_PT_ERR(>dev,"Offset 0x%04x:0x%04x expands past register 
size(%d)!\n",
-   offset, val, reg->size);
+error_setg(errp, "Offset 0x%04x:0x%04x expands past"
+" register size (%d)", offset, val, reg->size);
 g_free(reg_entry);
-return -ENXIO;
+return;
 }
 /* This could be just pci_set_long as we don't modify the bits
  * past reg->size, but in case this routine is run in parallel or the
@@ -1990,13 +1993,12 @@ static int 
xen_pt_config_reg_init(XenPCIPassthroughState *s,
 }
 /* list add register entry */
 QLIST_INSERT_HEAD(_grp->reg_tbl_list, reg_entry, entries);
-
-return 0;
 }
 
-int xen_pt_config_init(XenPCIPassthroughState *s)
+void xen_pt_config_init(XenPCIPassthroughState *s, Error **errp)
 {
 int i, rc;
+Error *err = NULL;
 
 QLIST_INIT(>reg_grps);
 
@@ -2039,11 +2041,12 @@ int xen_pt_config_init(XenPCIPassthroughState *s)
   reg_grp_offset,
   _grp_entry->size);
 if (rc < 0) {
-XEN_PT_LOG(>dev, "Failed to initialize %d/%ld, type=0x%x, 
rc:%d\n",
-   i, ARRAY_SIZE(xen_pt_emu_reg_grps),
+error_setg(, "Failed to initialize %d/%zu, type = 0x%x,"
+   " rc: %d", i, ARRAY_SIZE(xen_pt_emu_reg_grps),
xen_pt_emu_reg_grps[i].grp_type, rc);
+error_propagate(errp, err);
 xen_pt_config_delete(s);
-return rc;
+return;
  

[Qemu-devel] [PATCH v5 5/5] Xen PCI passthru: convert to realize()

[Cao jin]

Signed-off-by: Cao jin 
---
 hw/xen/xen_pt.c | 53 -
 1 file changed, 28 insertions(+), 25 deletions(-)

diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
index 9eef3df..d33221b 100644
--- a/hw/xen/xen_pt.c
+++ b/hw/xen/xen_pt.c
@@ -760,10 +760,10 @@ static void xen_pt_destroy(PCIDevice *d) {
 }
 /* init */
 
-static int xen_pt_initfn(PCIDevice *d)
+static void xen_pt_realize(PCIDevice *d, Error **errp)
 {
 XenPCIPassthroughState *s = XEN_PT_DEVICE(d);
-int rc = 0;
+int i, rc = 0;
 uint8_t machine_irq = 0, scratch;
 uint16_t cmd = 0;
 int pirq = XEN_PT_UNASSIGNED_PIRQ;
@@ -781,8 +781,8 @@ static int xen_pt_initfn(PCIDevice *d)
 );
 if (err) {
 error_append_hint(, "Failed to \"open\" the real pci device");
-error_report_err(err);
-return -1;
+error_propagate(errp, err);
+return;
 }
 
 s->is_virtfn = s->real_device.is_virtfn;
@@ -802,19 +802,19 @@ static int xen_pt_initfn(PCIDevice *d)
 if ((s->real_device.domain == 0) && (s->real_device.bus == 0) &&
 (s->real_device.dev == 2) && (s->real_device.func == 0)) {
 if (!is_igd_vga_passthrough(>real_device)) {
-XEN_PT_ERR(d, "Need to enable igd-passthru if you're trying"
-   " to passthrough IGD GFX.\n");
+error_setg(errp, "Need to enable igd-passthru if you're trying"
+" to passthrough IGD GFX");
 xen_host_pci_device_put(>real_device);
-return -1;
+return;
 }
 
 xen_pt_setup_vga(s, >real_device, );
 if (err) {
 error_append_hint(, "Setup VGA BIOS of passthrough"
 " GFX failed");
-error_report_err(err);
+error_propagate(errp, err);
 xen_host_pci_device_put(>real_device);
-return -1;
+return;
 }
 
 /* Register ISA bridge for passthrough GFX. */
@@ -836,20 +836,19 @@ static int xen_pt_initfn(PCIDevice *d)
 /* Bind interrupt */
 rc = xen_host_pci_get_byte(>real_device, PCI_INTERRUPT_PIN, );
 if (rc) {
-XEN_PT_ERR(d, "Failed to read PCI_INTERRUPT_PIN! (rc:%d)\n", rc);
+error_setg_errno(errp, errno, "Failed to read PCI_INTERRUPT_PIN");
 goto err_out;
 }
 if (!scratch) {
-XEN_PT_LOG(d, "no pin interrupt\n");
+error_setg(errp, "no pin interrupt");
 goto out;
 }
 
 machine_irq = s->real_device.irq;
 rc = xc_physdev_map_pirq(xen_xc, xen_domid, machine_irq, );
-
 if (rc < 0) {
-XEN_PT_ERR(d, "Mapping machine irq %u to pirq %i failed, (err: %d)\n",
-   machine_irq, pirq, errno);
+error_setg_errno(errp, errno, "Mapping machine irq %u to"
+ " pirq %i failed", machine_irq, pirq);
 
 /* Disable PCI intx assertion (turn on bit10 of devctl) */
 cmd |= PCI_COMMAND_INTX_DISABLE;
@@ -870,8 +869,8 @@ static int xen_pt_initfn(PCIDevice *d)
PCI_SLOT(d->devfn),
e_intx);
 if (rc < 0) {
-XEN_PT_ERR(d, "Binding of interrupt %i failed! (err: %d)\n",
-   e_intx, errno);
+error_setg_errno(errp, errno, "Binding of interrupt %u failed",
+ e_intx);
 
 /* Disable PCI intx assertion (turn on bit10 of devctl) */
 cmd |= PCI_COMMAND_INTX_DISABLE;
@@ -879,8 +878,8 @@ static int xen_pt_initfn(PCIDevice *d)
 
 if (xen_pt_mapped_machine_irq[machine_irq] == 0) {
 if (xc_physdev_unmap_pirq(xen_xc, xen_domid, machine_irq)) {
-XEN_PT_ERR(d, "Unmapping of machine interrupt %i failed!"
-   " (err: %d)\n", machine_irq, errno);
+error_setg_errno(errp, errno, "Unmapping of machine"
+" interrupt %u failed", machine_irq);
 }
 }
 s->machine_irq = 0;
@@ -893,14 +892,14 @@ out:
 
 rc = xen_host_pci_get_word(>real_device, PCI_COMMAND, );
 if (rc) {
-XEN_PT_ERR(d, "Failed to read PCI_COMMAND! (rc: %d)\n", rc);
+error_setg_errno(errp, errno, "Failed to read PCI_COMMAND");
 goto err_out;
 } else {
 val |= cmd;
 rc = xen_host_pci_set_word(>real_device, PCI_COMMAND, val);
 if (rc) {
-XEN_PT_ERR(d, "Failed to write PCI_COMMAND val=0x%x!(rc: 
%d)\n",
-   val, rc);
+error_setg_errno(errp, errno, "Failed to write PCI_COMMAND"
+ " val = 0x%x", val);
 goto err_out;
 }
 }
@@ -910,15 +909,19 @@ out:
 memory_listener_register(>io_listener, _space_io);
 s->listener_set = true;
 

[Qemu-devel] [PATCH v5 0/5] Xen PCI passthru: Convert to realize()

[Cao jin]

v5 changelog:
1. tweaked the commit message of patch 1/5 as sugguested.
2. xen_host_pci_sysfs_path() modification as sugguested.
3. remove local 'value' variable in xen_host_pci_get_value()
4. Indentation fix in patch 2/5.
5. Still use error_append_hint() because error_prepend() doesn`t exist.

Cao jin (5):
  Xen: use qemu_strtoul instead of strtol
  Add Error **errp for xen_host_pci_device_get()
  Add Error **errp for xen_pt_setup_vga()
  Add Error **errp for xen_pt_config_init()
  Xen PCI passthru: convert to realize()

 hw/xen/xen-host-pci-device.c | 149 ---
 hw/xen/xen-host-pci-device.h |   5 +-
 hw/xen/xen_pt.c  |  77 --
 hw/xen/xen_pt.h  |   5 +-
 hw/xen/xen_pt_config_init.c  |  51 ---
 hw/xen/xen_pt_graphics.c |  11 ++--
 6 files changed, 153 insertions(+), 145 deletions(-)

-- 
2.1.0

Re: [Qemu-devel] [PATCH 3/6] virtio-gpu: fix memory leak in error path

[Marc-André Lureau]

Hi

On Wed, Jan 13, 2016 at 1:02 PM, Gerd Hoffmann  wrote:
> Found by Coverity Scan, buf not freed on error.
>
> Signed-off-by: Gerd Hoffmann 
> ---

Reviewed-by: Marc-André Lureau 

>  hw/display/virtio-gpu-3d.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/hw/display/virtio-gpu-3d.c b/hw/display/virtio-gpu-3d.c
> index 28dccfd..d2af327 100644
> --- a/hw/display/virtio-gpu-3d.c
> +++ b/hw/display/virtio-gpu-3d.c
> @@ -197,7 +197,7 @@ static void virgl_cmd_submit_3d(VirtIOGPU *g,
>  qemu_log_mask(LOG_GUEST_ERROR, "%s: size mismatch (%zd/%d)",
>__func__, s, cs.size);
>  cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_PARAMETER;
> -return;
> +goto out;
>  }
>
>  if (virtio_gpu_stats_enabled(g->conf)) {
> @@ -207,6 +207,7 @@ static void virgl_cmd_submit_3d(VirtIOGPU *g,
>
>  virgl_renderer_submit_cmd(buf, cs.hdr.ctx_id, cs.size / 4);
>
> +out:
>  g_free(buf);
>  }
>
> --
> 1.8.3.1
>



-- 
Marc-André Lureau

Re: [Qemu-devel] [PATCH 1/1] blk: do not select PFLASH device for internal snapshot

[Laszlo Ersek]

On 01/13/16 12:11, Denis V. Lunev wrote:
> On 01/13/2016 01:37 PM, Laszlo Ersek wrote:
>> meta comment here:
>>
>> On 01/12/16 16:47, Denis V. Lunev wrote:
>>
>>> P.S. Here is a summary that my colleague has receiver from libvirt
>>> list.
>>>
>>>  Forwarded Message 
>>> Subject: Re: Snapshotting OVMF guests
>>> Date: Mon, 11 Jan 2016 13:56:29 +0100
>>> From: Laszlo Ersek 
>>> To: Dmitry Andreev 
>>> CC: Michal Privoznik , Markus Armbruster
>>> 
>>>
>>> Hello Dmitry,
>>>
>>> [...]
>> Your colleague Dmitry did not receive this from the libvirt list. He
>> received the from me in private. See the headers above.
>>
>> Please do not publicize a private exchange without asking for permission
>> first.
>>
>> In the present case I don't mind it. I stand by everything I said, and I
>> would have written mostly the same if I had been contacted publicly,
>> on-list.
>>
>> But if you contact me in private *first*, then I expect the discussion
>> to remain private. If you want to forward the email to a public list,
>> please ask for permission. Otherwise I might consider it more prudent
>> for myself to answer all private queries with just "please ask me this
>> on the list instead".
>>
>> I appreciate that you guys are working on this, but let's handle emails
>> sensibly.
>>
>> Thanks
>> Laszlo
>>
> Sorry :( I have not properly checked the message :(
> 
> I am guilty..

No prob, it's just that I've burned myself a few times before, hence
I've grown to double check the address list when receiving & sending email.

"List address not present" implies "other guy wants it to be private" to
me. :)

Cheers
Laszlo

Re: [Qemu-devel] [PATCH 6/6] virtio-gpu: block any rendering until client (ui) is done

[Marc-André Lureau]

Hi

On Wed, Jan 13, 2016 at 1:02 PM, Gerd Hoffmann  wrote:
> Wire up gl_block callback, so ui code can request to stop
> virtio-gpu rendering.
>
> Signed-off-by: Gerd Hoffmann 
> ---
>  hw/display/virtio-gpu-3d.c |  5 +
>  hw/display/virtio-gpu.c|  8 
>  hw/display/virtio-vga.c| 10 ++
>  include/hw/virtio/virtio-gpu.h |  1 +
>  4 files changed, 24 insertions(+)
>
> diff --git a/hw/display/virtio-gpu-3d.c b/hw/display/virtio-gpu-3d.c
> index 65926b1..321a959 100644
> --- a/hw/display/virtio-gpu-3d.c
> +++ b/hw/display/virtio-gpu-3d.c
> @@ -382,6 +382,11 @@ void virtio_gpu_virgl_process_cmd(VirtIOGPU *g,
>  {
>  VIRTIO_GPU_FILL_CMD(cmd->cmd_hdr);
>
> +cmd->waiting = g->renderer_blocked;
> +if (cmd->waiting) {
> +return;
> +}
> +
>  virgl_renderer_force_ctx_0();
>  switch (cmd->cmd_hdr.type) {
>  case VIRTIO_GPU_CMD_CTX_CREATE:
> diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
> index 9087e63..09936c9 100644
> --- a/hw/display/virtio-gpu.c
> +++ b/hw/display/virtio-gpu.c
> @@ -893,11 +893,19 @@ static int virtio_gpu_ui_info(void *opaque, uint32_t 
> idx, QemuUIInfo *info)
>  return 0;
>  }
>
> +static void virtio_gpu_gl_block(void *opaque, bool block)
> +{
> +VirtIOGPU *g = opaque;
> +
> +g->renderer_blocked = block;
> +}

Why not add here?:

+if (!block) {
+virtio_cpu_process_cmdq(g);
+}


> +
>  const GraphicHwOps virtio_gpu_ops = {
>  .invalidate = virtio_gpu_invalidate_display,
>  .gfx_update = virtio_gpu_update_display,
>  .text_update = virtio_gpu_text_update,
>  .ui_info = virtio_gpu_ui_info,
> +.gl_block = virtio_gpu_gl_block,
>  };
>
>  static void virtio_gpu_device_realize(DeviceState *qdev, Error **errp)
> diff --git a/hw/display/virtio-vga.c b/hw/display/virtio-vga.c
> index f7e539f..255d419 100644
> --- a/hw/display/virtio-vga.c
> +++ b/hw/display/virtio-vga.c
> @@ -65,11 +65,21 @@ static int virtio_vga_ui_info(void *opaque, uint32_t idx, 
> QemuUIInfo *info)
>  return -1;
>  }
>
> +static void virtio_vga_gl_block(void *opaque, bool block)
> +{
> +VirtIOVGA *vvga = opaque;
> +
> +if (virtio_gpu_ops.gl_block) {
> +virtio_gpu_ops.gl_block(>vdev, block);
> +}
> +}
> +
>  static const GraphicHwOps virtio_vga_ops = {
>  .invalidate = virtio_vga_invalidate_display,
>  .gfx_update = virtio_vga_update_display,
>  .text_update = virtio_vga_text_update,
>  .ui_info = virtio_vga_ui_info,
> +.gl_block = virtio_vga_gl_block,
>  };
>
>  /* VGA device wrapper around PCI device around virtio GPU */
> diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
> index fdf0091..7249fcd 100644
> --- a/include/hw/virtio/virtio-gpu.h
> +++ b/include/hw/virtio/virtio-gpu.h
> @@ -107,6 +107,7 @@ typedef struct VirtIOGPU {
>
>  bool use_virgl_renderer;
>  bool renderer_inited;
> +bool renderer_blocked;
>  QEMUTimer *fence_poll;
>  QEMUTimer *print_stats;
>
> --
> 1.8.3.1
>



-- 
Marc-André Lureau

Re: [Qemu-devel] [PATCH 4/6] virtio-gpu: maintain command queue

[Marc-André Lureau]

Hi

On Wed, Jan 13, 2016 at 1:02 PM, Gerd Hoffmann  wrote:
> We'll go take out the commands we receive out of the virt queue and put
> them into a linked list, to decouple virtio queue handling from actual
> command processing.
>
> Also move cmd processing to new virtio_gpu_handle_ctrl func, so we can
> easily kick it from different places.
>
> Signed-off-by: Gerd Hoffmann 
> ---
>  hw/display/virtio-gpu.c| 60 
> ++
>  include/hw/virtio/virtio-gpu.h |  1 +
>  2 files changed, 39 insertions(+), 22 deletions(-)
>
> diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
> index 7e79a9c..4433c12 100644
> --- a/hw/display/virtio-gpu.c
> +++ b/hw/display/virtio-gpu.c
> @@ -754,33 +754,21 @@ static void virtio_gpu_handle_cursor_cb(VirtIODevice 
> *vdev, VirtQueue *vq)
>  qemu_bh_schedule(g->cursor_bh);
>  }
>
> -static void virtio_gpu_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
> +static void virtio_cpu_process_cmdq(VirtIOGPU *g)

cpu/gpu

>  {
> -VirtIOGPU *g = VIRTIO_GPU(vdev);
>  struct virtio_gpu_ctrl_command *cmd;
>
> -if (!virtio_queue_ready(vq)) {
> -return;
> -}
> -
> -#ifdef CONFIG_VIRGL
> -if (!g->renderer_inited && g->use_virgl_renderer) {
> -virtio_gpu_virgl_init(g);
> -g->renderer_inited = true;
> -}
> -#endif
> -
> -cmd = g_new(struct virtio_gpu_ctrl_command, 1);
> -while (virtqueue_pop(vq, >elem)) {
> -cmd->vq = vq;
> -cmd->error = 0;
> -cmd->finished = false;
> -if (virtio_gpu_stats_enabled(g->conf)) {
> -g->stats.requests++;
> -}
> +while (!QTAILQ_EMPTY(>cmdq)) {
> +cmd = QTAILQ_FIRST(>cmdq);
>
> +/* process command */
>  VIRGL(g, virtio_gpu_virgl_process_cmd, virtio_gpu_simple_process_cmd,
>g, cmd);
> +QTAILQ_REMOVE(>cmdq, cmd, next);
> +if (virtio_gpu_stats_enabled(g->conf)) {
> +g->stats.requests++;
> +}
> +
>  if (!cmd->finished) {
>  QTAILQ_INSERT_TAIL(>fenceq, cmd, next);
>  g->inflight++;
> @@ -790,11 +778,38 @@ static void virtio_gpu_handle_ctrl(VirtIODevice *vdev, 
> VirtQueue *vq)
>  }
>  fprintf(stderr, "inflight: %3d (+)\r", g->inflight);
>  }
> -cmd = g_new(struct virtio_gpu_ctrl_command, 1);
>  }

else g_free(cmd)

>  }
> +}
> +
> +static void virtio_gpu_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
> +{
> +VirtIOGPU *g = VIRTIO_GPU(vdev);
> +struct virtio_gpu_ctrl_command *cmd;
> +
> +if (!virtio_queue_ready(vq)) {
> +return;
> +}
> +
> +#ifdef CONFIG_VIRGL
> +if (!g->renderer_inited && g->use_virgl_renderer) {
> +virtio_gpu_virgl_init(g);
> +g->renderer_inited = true;
> +}
> +#endif
> +
> +cmd = g_new0(struct virtio_gpu_ctrl_command, 1);

g_new0 is costly (the struct is big) and quite unnecessary here:

> +while (virtqueue_pop(vq, >elem)) {
> +cmd->vq = vq;
> +cmd->error = 0;
> +cmd->finished = false;

Add:
+ cmd->waiting = false;

and you can switch to g_new.

> +QTAILQ_INSERT_TAIL(>cmdq, cmd, next);
> +cmd = g_new0(struct virtio_gpu_ctrl_command, 1);

same

> +}
>  g_free(cmd);
>
> +virtio_cpu_process_cmdq(g);
> +
>  #ifdef CONFIG_VIRGL
>  if (g->use_virgl_renderer) {
>  virtio_gpu_virgl_fence_poll(g);
> @@ -920,6 +935,7 @@ static void virtio_gpu_device_realize(DeviceState *qdev, 
> Error **errp)
>  g->ctrl_bh = qemu_bh_new(virtio_gpu_ctrl_bh, g);
>  g->cursor_bh = qemu_bh_new(virtio_gpu_cursor_bh, g);
>  QTAILQ_INIT(>reslist);
> +QTAILQ_INIT(>cmdq);
>  QTAILQ_INIT(>fenceq);
>
>  g->enabled_output_bitmask = 1;
> diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
> index 9b279d7..f7e7a52 100644
> --- a/include/hw/virtio/virtio-gpu.h
> +++ b/include/hw/virtio/virtio-gpu.h
> @@ -94,6 +94,7 @@ typedef struct VirtIOGPU {
>  DeviceState *qdev;
>
>  QTAILQ_HEAD(, virtio_gpu_simple_resource) reslist;
> +QTAILQ_HEAD(, virtio_gpu_ctrl_command) cmdq;
>  QTAILQ_HEAD(, virtio_gpu_ctrl_command) fenceq;
>
>  struct virtio_gpu_scanout scanout[VIRTIO_GPU_MAX_SCANOUT];
> --
> 1.8.3.1
>



-- 
Marc-André Lureau

[Qemu-devel] [Bug 1490611] Re: Using qemu >=2.2.1 to convert raw->VHD (fixed) adds extra padding to the result file, which Microsoft Azure rejects as invalid

[Stephen Kent]

Which release contains this fix?

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

Title:
  Using qemu >=2.2.1 to convert raw->VHD (fixed) adds extra padding to
  the result file, which Microsoft Azure rejects as invalid

Status in QEMU:
  Fix Released

Bug description:
  Starting with a raw disk image, using "qemu-img convert" to convert
  from raw to VHD results in the output VHD file's virtual size being
  aligned to the nearest 516096 bytes (16 heads x 63 sectors per head x
  512 bytes per sector), instead of preserving the input file's size as
  the output VHD's virtual disk size.

  Microsoft Azure requires that disk images (VHDs) submitted for upload
  have virtual sizes aligned to a megabyte boundary. (Ex. 4096MB,
  4097MB, 4098MB, etc. are OK, 4096.5MB is rejected with an error.) This
  is reflected in Microsoft's documentation: https://azure.microsoft.com
  /en-us/documentation/articles/virtual-machines-linux-create-upload-
  vhd-generic/

  This is reproducible with the following set of commands (including the
  Azure command line tools from https://github.com/Azure/azure-xplat-
  cli). For the following example, I used qemu version 2.2.1:

  $ dd if=/dev/zero of=source-disk.img bs=1M count=4096

  $ stat source-disk.img 
File: ‘source-disk.img’
Size: 4294967296  Blocks: 798656 IO Block: 4096   regular file
  Device: fc01h/64513dInode: 13247963Links: 1
  Access: (0644/-rw-r--r--)  Uid: ( 1000/  smkent)   Gid: ( 1000/  smkent)
  Access: 2015-08-18 09:48:02.613988480 -0700
  Modify: 2015-08-18 09:48:02.825985646 -0700
  Change: 2015-08-18 09:48:02.825985646 -0700
   Birth: -

  $ qemu-img convert -f raw -o subformat=fixed -O vpc source-disk.img
  dest-disk.vhd

  $ stat dest-disk.vhd 
File: ‘dest-disk.vhd’
Size: 4296499712  Blocks: 535216 IO Block: 4096   regular file
  Device: fc01h/64513dInode: 13247964Links: 1
  Access: (0644/-rw-r--r--)  Uid: ( 1000/  smkent)   Gid: ( 1000/  smkent)
  Access: 2015-08-18 09:50:22.252077624 -0700
  Modify: 2015-08-18 09:49:24.424868868 -0700
  Change: 2015-08-18 09:49:24.424868868 -0700
   Birth: -

  $ azure vm image create testimage1 dest-disk.vhd -o linux -l "West US"
  info:Executing command vm image create
  + Retrieving storage accounts 
 
  info:VHD size : 4097 MB
  info:Uploading 4195800.5 KB
  Requested:100.0% Completed:100.0% Running:   0 Time: 1m 0s Speed:  6744 KB/s 
  info:https://[redacted].blob.core.windows.net/vm-images/dest-disk.vhd was 
uploaded successfully
  error:   The VHD 
https://[redacted].blob.core.windows.net/vm-images/dest-disk.vhd has an 
unsupported virtual size of 4296499200 bytes.  The size must be a whole number 
(in MBs).
  info:Error information has been recorded to /home/smkent/.azure/azure.err
  error:   vm image create command failed

  I also ran the above commands using qemu 2.4.0, which resulted in the
  same error as the conversion behavior is the same.

  However, qemu 2.1.1 and earlier (including qemu 2.0.0 installed by
  Ubuntu 14.04) does not pad the virtual disk size during conversion.
  Using qemu-img convert from qemu versions <=2.1.1 results in a VHD
  that is exactly the size of the raw input file plus 512 bytes (for the
  VHD footer). Those qemu versions do not attempt to realign the disk.
  As a result, Azure accepts VHD files created using those versions of
  qemu-img convert for upload.

  Is there a reason why newer qemu realigns the converted VHD file? It
  would be useful if an option were added to disable this feature, as
  current versions of qemu cannot be used to create VHD files for Azure
  using Microsoft's official instructions.

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

Re: [Qemu-devel] [vfio-users] [PATCH v2 1/3] input: add qemu_input_qcode_to_linux + qemu_input_linux_to_qcode

[sL1pKn07 SpinFlo]

Today have notice the patch stop working on my VM

input_linux_event_mouse: read: Resource temporarily unavailable
input_linux_event_keyboard: read: Resource temporarily unavailable

i only rebuild qemu (from Gerd Hoffmann's input-dev-event barnch) with
some changes.

this is my options:

  ./configure \
--python=/usr/bin/python2 \
--prefix=/usr \
--sysconfdir=/etc \
--audio-drv-list='pa alsa sdl' \
--localstatedir=/var \
--libexecdir=/usr/lib/qemu \
--enable-sdl \
--with-sdlabi=2.0 \
--enable-linux-aio \
--enable-seccomp \
--enable-tpm \
--enable-modules \
--disable-gtk \
--disable-spice \
--disable-rbd \
--disable-libiscsi \
--disable-libnfs \
--disable-smartcard \
--disable-glusterfs \
--disable-docs \
--disable-vnc{,-sasl,-jpeg,-png}

I only disable spice,vnc,smartcard,glusterfs,iscsi,rbd,docs,libnfs and
add sdlabi=2.0

is a regression or one of the disable components is necessary to run the patch?

greetings

2016-01-07 5:57 GMT+01:00 sL1pKn07 SpinFlo :
> On Mi, 2016-01-06 at 13:42 +0100, sL1pKn07 SpinFlo wrote:
>> Yes, is like disconect the cable of USB.
>
> Ok.  That is not so easy.  Well, the first part (switch away) is easy,
> it is just a matter of catching read errors, so the device going away
> (unplug) doesn't screw up things.  But when it comes to reconnect after
> switching back it'll quickly becomes quite messy ...
>
> cheers,
>   Gerd

[Qemu-devel] [PATCH] docs: Style the command and its options in the synopsis

[Sitsofe Wheeler]

Signed-off-by: Sitsofe Wheeler 
---
 fsdev/virtfs-proxy-helper.texi | 2 +-
 qemu-doc.texi  | 8 
 qemu-ga.texi   | 2 +-
 qemu-img.texi  | 2 +-
 4 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/fsdev/virtfs-proxy-helper.texi b/fsdev/virtfs-proxy-helper.texi
index e60e3b9..9a25d7e 100644
--- a/fsdev/virtfs-proxy-helper.texi
+++ b/fsdev/virtfs-proxy-helper.texi
@@ -1,6 +1,6 @@
 @example
 @c man begin SYNOPSIS
-usage: virtfs-proxy-helper options
+@command{virtfs-proxy-helper} @var{options}
 @c man end
 @end example
 
diff --git a/qemu-doc.texi b/qemu-doc.texi
index 7bc3882..ca4d9de 100644
--- a/qemu-doc.texi
+++ b/qemu-doc.texi
@@ -259,7 +259,7 @@ Linux should boot and give you a prompt.
 
 @example
 @c man begin SYNOPSIS
-usage: qemu-system-i386 [options] [@var{disk_image}]
+@command{qemu-system-i386} [@var{options}] [@var{disk_image}]
 @c man end
 @end example
 
@@ -1406,7 +1406,7 @@ no type is given, the HCI logic corresponds to @code{-bt 
hci,vlan=0}.
 This USB device implements the USB Transport Layer of HCI.  Example
 usage:
 @example
-qemu-system-i386 [...OPTIONS...] -usbdevice bt:hci,vlan=3 -bt 
device:keyboard,vlan=3
+@command{qemu-system-i386} [...@var{OPTIONS}...] @option{-usbdevice} 
bt:hci,vlan=3 @option{-bt} device:keyboard,vlan=3
 @end example
 @end table
 
@@ -2755,7 +2755,7 @@ qemu-i386 /usr/local/qemu-i386/wine/bin/wine \
 @subsection Command line options
 
 @example
-usage: qemu-i386 [-h] [-d] [-L path] [-s size] [-cpu model] [-g port] [-B 
offset] [-R size] program [arguments...]
+@command{qemu-i386} [@option{-h]} [@option{-d]} [@option{-L} @var{path}] 
[@option{-s} @var{size}] [@option{-cpu} @var{model}] [@option{-g} @var{port}] 
[@option{-B} @var{offset}] [@option{-R} @var{size}] @var{program} 
[@var{arguments}...]
 @end example
 
 @table @option
@@ -2897,7 +2897,7 @@ qemu-sparc64 /bin/ls
 @subsection Command line options
 
 @example
-usage: qemu-sparc64 [-h] [-d] [-L path] [-s size] [-bsd type] program 
[arguments...]
+@command{qemu-sparc64} [@option{-h]} [@option{-d]} [@option{-L} @var{path}] 
[@option{-s} @var{size}] [@option{-bsd} @var{type}] @var{program} 
[@var{arguments}...]
 @end example
 
 @table @option
diff --git a/qemu-ga.texi b/qemu-ga.texi
index 536a9b5..0e53bf6 100644
--- a/qemu-ga.texi
+++ b/qemu-ga.texi
@@ -1,6 +1,6 @@
 @example
 @c man begin SYNOPSIS
-usage: qemu-ga [OPTIONS]
+@command{qemu-ga} [@var{OPTIONS}]
 @c man end
 @end example
 
diff --git a/qemu-img.texi b/qemu-img.texi
index 55c6be3..7163a10 100644
--- a/qemu-img.texi
+++ b/qemu-img.texi
@@ -1,6 +1,6 @@
 @example
 @c man begin SYNOPSIS
-usage: qemu-img command [command options]
+@command{qemu-img} @var{command} [@var{command} @var{options}]
 @c man end
 @end example
 
-- 
2.4.3

Re: [Qemu-devel] [PATCH] i2c-tiny-usb: add new usb to i2c bridge

[Peter Crosthwaite]

On Wed, Jan 13, 2016 at 8:07 AM, Tim Sander  wrote:
> Hi
> Am Donnerstag, 7. Januar 2016, 02:14:23 schrieb Peter Crosthwaite:
>> Patch subject prefix should contain the version number. Use the
>> --subject-prefix or -v options to git format-patch.
> Ok, i will try to remember this next time.
>>
>> On Wed, Jan 6, 2016 at 6:58 AM, Tim Sander  wrote:
>> > Version 4 with improvements suggested by Gerd Hoffmann:
>> Changelog information should go below the line ...
>>
>> > Signed-off-by: Tim Sander 
>>
>> Signed-off-by usually at end of the commit message.
>>
>> > i2c-tiny-usb is a small usb to i2c bridge:
>> >  http://www.harbaum.org/till/i2c_tiny_usb/index.shtml
>> >
>> > It is pretty simple and has no usb endpoints just a control.
>> > Reasons for adding this device:
>> > * Linux device driver available
>> > * adding an additional i2c bus via command line e.g.
>> >
>> >   -device usb-i2c-tiny,id=i2c-0 -device tmp105,bus=i2c,address=0x50
>> >
>> > ---
>>
>> ... here.
> Ok.
>
>> >  default-configs/usb.mak |   1 +
>> >  hw/usb/Makefile.objs|   1 +
>> >  hw/usb/dev-i2c-tiny.c   | 320
>> >   trace-events
>> >  |  11 ++
>> >  4 files changed, 333 insertions(+)
>> >  create mode 100644 hw/usb/dev-i2c-tiny.c
>> >
>> > diff --git a/default-configs/usb.mak b/default-configs/usb.mak
>> > index f4b8568..01d2c9f 100644
>> > --- a/default-configs/usb.mak
>> > +++ b/default-configs/usb.mak
>> > @@ -8,3 +8,4 @@ CONFIG_USB_AUDIO=y
>> >
>> >  CONFIG_USB_SERIAL=y
>> >  CONFIG_USB_NETWORK=y
>> >  CONFIG_USB_BLUETOOTH=y
>> >
>> > +CONFIG_USB_I2C_TINY=y
>> > diff --git a/hw/usb/Makefile.objs b/hw/usb/Makefile.objs
>> > index 8f00fbd..3a4c337 100644
>> > --- a/hw/usb/Makefile.objs
>> > +++ b/hw/usb/Makefile.objs
>> > @@ -20,6 +20,7 @@ common-obj-$(CONFIG_USB_AUDIO)+= dev-audio.o
>> >
>> >  common-obj-$(CONFIG_USB_SERIAL)   += dev-serial.o
>> >  common-obj-$(CONFIG_USB_NETWORK)  += dev-network.o
>> >  common-obj-$(CONFIG_USB_BLUETOOTH)+= dev-bluetooth.o
>> >
>> > +common-obj-$(CONFIG_USB_I2C_TINY) += dev-i2c-tiny.o
>> >
>> >  ifeq ($(CONFIG_USB_SMARTCARD),y)
>> >  common-obj-y  += dev-smartcard-reader.o
>> >
>> > diff --git a/hw/usb/dev-i2c-tiny.c b/hw/usb/dev-i2c-tiny.c
>> > new file mode 100644
>> > index 000..c28d7a5
>> > --- /dev/null
>> > +++ b/hw/usb/dev-i2c-tiny.c
>> > @@ -0,0 +1,320 @@
>> > +/*
>> > + * I2C tiny usb device emulation
>> > + *
>> > + * i2c-tiny-usb is a small usb to i2c bridge:
>> > + *
>> > + * http://www.harbaum.org/till/i2c_tiny_usb/index.shtml
>> > + *
>> > + * The simulated device is pretty simple and has no usb endpoints.
>> > + * There is a Linux device driver available named i2c-tiny-usb.
>> > + *
>> > + * Below is an example how to use this device from command line:
>> > + *  -device usb-i2c-tiny,id=i2c-0 -device tmp105,bus=i2c,address=0x50
>> > + *
>> > + * Copyright (c) 2015 Tim Sander 
>> > + *
>> > + * Loosly based on usb dev-serial.c:
>> > + * Copyright (c) 2006 CodeSourcery.
>> > + * Copyright (c) 2008 Samuel Thibault 
>> > + * Written by Paul Brook, reused for FTDI by Samuel Thibault
>> > + *
>> > + * This code is licensed under the LGPL.
>> > + *
>> > + */
>> > +
>> > +#include "trace.h"
>> > +#include "qemu-common.h"
>> > +#include "qemu/error-report.h"
>> > +#include "hw/usb.h"
>> > +#include "hw/usb/desc.h"
>> > +#include "hw/i2c/i2c.h"
>> > +#include "hw/i2c/smbus.h"
>> > +#include "sysemu/char.h"
>> > +#include "endian.h"
>> > +
>> > +/* commands from USB, must e.g. match command ids in kernel driver */
>> > +#define CMD_ECHO   0
>> > +#define CMD_GET_FUNC   1
>> > +#define CMD_SET_DELAY  2
>> > +#define CMD_GET_STATUS 3
>> > +
>> > +/* To determine what functionality is present */
>> > +#define I2C_FUNC_I2C0x0001
>> > +#define I2C_FUNC_10BIT_ADDR 0x0002
>> > +#define I2C_FUNC_PROTOCOL_MANGLING  0x0004
>> > +#define I2C_FUNC_SMBUS_HWPEC_CALC   0x0008 /* SMBus 2.0
>> > */
>> > +#define I2C_FUNC_SMBUS_READ_WORD_DATA_PEC   0x0800 /* SMBus 2.0
>> > */
>> > +#define I2C_FUNC_SMBUS_WRITE_WORD_DATA_PEC  0x1000 /* SMBus 2.0
>> > */
>> > +#define I2C_FUNC_SMBUS_PROC_CALL_PEC0x2000 /* SMBus 2.0
>> > */
>> > +#define I2C_FUNC_SMBUS_BLOCK_PROC_CALL_PEC  0x4000 /* SMBus 2.0
>> > */
>> > +#define I2C_FUNC_SMBUS_BLOCK_PROC_CALL  0x8000 /* SMBus 2.0
>> > */
>> > +#define I2C_FUNC_SMBUS_QUICK0x0001
>> > +#define I2C_FUNC_SMBUS_READ_BYTE0x0002
>> > +#define I2C_FUNC_SMBUS_WRITE_BYTE   0x0004
>> > +#define I2C_FUNC_SMBUS_READ_BYTE_DATA   0x0008
>> > +#define I2C_FUNC_SMBUS_WRITE_BYTE_DATA  0x0010
>> > +#define I2C_FUNC_SMBUS_READ_WORD_DATA   0x0020
>> 

[Qemu-devel] bug with io/channel-socket.c - variable-sized object may not be initialized

[Programmingkid]

This code causes an error to occur during compiling: 

char control[CMSG_SPACE(sizeof(int) * SOCKET_MAX_FDS)] = { 0 };

It is located at line 496 in io/channel-socket.c. 

Here is the full error message:
io/channel-socket.c: In function 'qio_channel_socket_writev':
io/channel-socket.c:496:18: error: variable-sized object may not be initialized
 char control[CMSG_SPACE(sizeof(int) * SOCKET_MAX_FDS)] = { 0 };

This is from gcc 4.9 running on Mac OS 10.6.8. 

A quick fix to this problem is to replace everything in the parentheses with 
1000. 

Re: [Qemu-devel] [PATCH V6 2/8] introduce aux-bus

[Peter Crosthwaite]

On Mon, Jan 4, 2016 at 10:25 AM,   wrote:
> From: KONRAD Frederic 
>
> This introduces a new bus: aux-bus.
>
> It contains an address space for aux slaves devices and a bridge to an I2C bus
> for I2C through AUX transactions.
>
> Signed-off-by: KONRAD Frederic 
> Tested-By: Hyun Kwon 
> ---
>  default-configs/aarch64-softmmu.mak |   1 +
>  hw/misc/Makefile.objs   |   1 +
>  hw/misc/aux.c   | 348 
> 
>  include/hw/misc/aux.h   | 124 +
>  4 files changed, 474 insertions(+)
>  create mode 100644 hw/misc/aux.c
>  create mode 100644 include/hw/misc/aux.h
>
> diff --git a/default-configs/aarch64-softmmu.mak 
> b/default-configs/aarch64-softmmu.mak
> index 96dd994..d3a2665 100644
> --- a/default-configs/aarch64-softmmu.mak
> +++ b/default-configs/aarch64-softmmu.mak
> @@ -3,4 +3,5 @@
>  # We support all the 32 bit boards so need all their config
>  include arm-softmmu.mak
>
> +CONFIG_AUX=y
>  CONFIG_XLNX_ZYNQMP=y
> diff --git a/hw/misc/Makefile.objs b/hw/misc/Makefile.objs
> index d4765c2..4af5fbe 100644
> --- a/hw/misc/Makefile.objs
> +++ b/hw/misc/Makefile.objs
> @@ -44,3 +44,4 @@ obj-$(CONFIG_STM32F2XX_SYSCFG) += stm32f2xx_syscfg.o
>  obj-$(CONFIG_PVPANIC) += pvpanic.o
>  obj-$(CONFIG_EDU) += edu.o
>  obj-$(CONFIG_HYPERV_TESTDEV) += hyperv_testdev.o
> +obj-$(CONFIG_AUX) += aux.o
> diff --git a/hw/misc/aux.c b/hw/misc/aux.c
> new file mode 100644
> index 000..cdfec67
> --- /dev/null
> +++ b/hw/misc/aux.c
> @@ -0,0 +1,348 @@
> +/*
> + * aux.c
> + *
> + *  Copyright 2015 : GreenSocs Ltd
> + *  http://www.greensocs.com/ , email: i...@greensocs.com
> + *
> + *  Developed by :
> + *  Frederic Konrad   
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation, either version 2 of the License, or
> + * (at your option)any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program; if not, see .
> + *
> + */
> +
> +/*
> + * This is an implementation of the AUX bus for VESA Display Port v1.1a.
> + */
> +
> +#include "hw/misc/aux.h"
> +#include "hw/i2c/i2c.h"
> +#include "monitor/monitor.h"
> +
> +#ifndef DEBUG_AUX
> +#define DEBUG_AUX 0
> +#endif
> +
> +#define DPRINTF(fmt, ...) do {   
>   \
> +if (DEBUG_AUX) { 
>   \
> +qemu_log("aux: " fmt , ## __VA_ARGS__);  
>   \
> +}
>   \
> +} while (0);
> +
> +#define TYPE_AUXTOI2C "aux-to-i2c-bridge"
> +#define AUXTOI2C(obj) OBJECT_CHECK(AUXTOI2CState, (obj), TYPE_AUXTOI2C)
> +
> +#define TYPE_AUX_BUS "aux-bus"
> +#define AUX_BUS(obj) OBJECT_CHECK(AUXBus, (obj), TYPE_AUX_BUS)
> +
> +static void aux_slave_dev_print(Monitor *mon, DeviceState *dev, int indent);
> +
> +static void aux_bus_class_init(ObjectClass *klass, void *data)
> +{
> +BusClass *k = BUS_CLASS(klass);
> +
> +/* AUXSlave has an MMIO so we need to change the way we print information
> + * in monitor.
> + */
> +k->print_dev = aux_slave_dev_print;
> +}
> +
> +static const TypeInfo aux_bus_info = {
> +.name = TYPE_AUX_BUS,
> +.parent = TYPE_BUS,
> +.instance_size = sizeof(AUXBus),
> +.class_init = aux_bus_class_init
> +};
> +
> +AUXBus *aux_init_bus(DeviceState *parent, const char *name)
> +{
> +AUXBus *bus;
> +
> +bus = AUX_BUS(qbus_create(TYPE_AUX_BUS, parent, name));
> +bus->bridge = AUXTOI2C(qdev_create(BUS(bus), TYPE_AUXTOI2C));
> +
> +/* Memory related. */
> +bus->aux_io = g_malloc(sizeof(*bus->aux_io));
> +memory_region_init(bus->aux_io, OBJECT(bus), "aux-io", (1 << 20));
> +address_space_init(>aux_addr_space, bus->aux_io, "aux-io");
> +return bus;
> +}
> +
> +static void aux_bus_map_device(AUXBus *bus, AUXSlave *dev, hwaddr addr)
> +{
> +memory_region_add_subregion(bus->aux_io, addr, dev->mmio);
> +}
> +
> +static bool aux_bus_is_bridge(AUXBus *bus, DeviceState *dev)
> +{
> +return (dev == DEVICE(bus->bridge));
> +}
> +
> +AUXReply aux_request(AUXBus *bus, AUXCommand cmd, uint32_t address,
> +  uint8_t len, uint8_t *data)
> +{
> +int temp;
> +AUXReply ret = AUX_NACK;
> +I2CBus *i2c_bus = aux_get_i2c_bus(bus);
> +size_t i;
> +bool is_write = false;
> +
> +DPRINTF("request 

Re: [Qemu-devel] [Qemu-block] [PATCH v1 10/15] qcow2: convert QCow2 to use QCryptoBlock for encryption

[Kevin Wolf]

Am 12.01.2016 um 19:56 hat Daniel P. Berrange geschrieben:
> This converts the qcow2 driver to make use of the QCryptoBlock
> APIs for encrypting image content. As well as continued support
> for the legacy QCow2 encryption format, the appealing benefit
> is that it enables support for the LUKS format inside qcow2.
> 
> With the LUKS format it is neccessary to store the LUKS
> partition header and key material in the QCow2 file. This
> data can be many MB in size, so cannot go into the QCow2
> header region directly. Thus the spec is defines a FDE
> (Full Disk Encryption) header extension that specifies
> the offset of a set of clusters to hold the FDE headers,
> as well as the length of that region. The LUKS header is
> thus stored in these extra allocated clusters before the
> main image payload.
> 
> With this change it is now required to use the QCryptoSecret
> object for providing passwords, instead of the current block
> password APIs / interactive prompting.
> 
>   $QEMU \
> -object secret,id=sec0,filename=/home/berrange/encrypted.pw \
> -drive file=/home/berrange/encrypted.qcow2,key-id=sec0
> 
> The new LUKS format is set as the new default format when
> creating encrypted images. ie
> 
>   # qemu-img create --object secret,data=123456,id=sec0 \
>-f qcow2 -o encryption,key-id=sec0 \
>test.qcow2 10G
> 
> Results in creation of an image using the LUKS format.
> 
> For compatibility the old qcow2 AES format can still be used
> via the 'encryption-format' parameter which accepts the
> values 'luks' or 'qcowaes'.
> 
>   # qemu-img create --object secret,data=123456,id=sec0 \
>-f qcow2 -o encryption,key-id=sec0,encryption-format=qcowaes \
>test.qcow2 10G
> 
> Signed-off-by: Daniel P. Berrange 

I think for your additional pointer to some clusters you need to change
some function(s) called by qcow2_check_refcounts(). Otherwise 'qemu-img
check' won't count the reference and helpfully free the "leaked"
cluster.

> diff --git a/block/qcow2.c b/block/qcow2.c
> index c0fc259..288aada 100644
> --- a/block/qcow2.c
> +++ b/block/qcow2.c
> @@ -34,6 +34,8 @@
>  #include "qapi-event.h"
>  #include "trace.h"
>  #include "qemu/option_int.h"
> +#include "qapi/opts-visitor.h"
> +#include "qapi-visit.h"
>  
>  /*
>Differences with QCOW:
> @@ -60,6 +62,7 @@ typedef struct {
>  #define  QCOW2_EXT_MAGIC_END 0
>  #define  QCOW2_EXT_MAGIC_BACKING_FORMAT 0xE2792ACA
>  #define  QCOW2_EXT_MAGIC_FEATURE_TABLE 0x6803f857
> +#define  QCOW2_EXT_MAGIC_FDE_HEADER 0x4c554b53

General naming comment on this series: I would prefer avoiding "FDE" in
favour of "encryption" or "crypt" in the block layer parts. With all
image formats having their own terminology, "FDE" could mean anything.

>  static int qcow2_probe(const uint8_t *buf, int buf_size, const char 
> *filename)
>  {
> @@ -74,6 +77,83 @@ static int qcow2_probe(const uint8_t *buf, int buf_size, 
> const char *filename)
>  }
>  
>  
> +static ssize_t qcow2_fde_header_read_func(QCryptoBlock *block,
> +  size_t offset,
> +  uint8_t *buf,
> +  size_t buflen,
> +  Error **errp,
> +  void *opaque)
> +{
> +BlockDriverState *bs = opaque;
> +BDRVQcow2State *s = bs->opaque;
> +ssize_t ret;
> +
> +if ((offset + buflen) > s->fde_header.length) {
> +error_setg_errno(errp, EINVAL,
> + "Request for data outside of extension header");

error_setg_errno() with a constant errno doesn't look very useful.
Better use plain error_setg() in such cases.

> +return -1;

Here returning -EINVAL could be useful, I'm not sure what your crypto
API requires. At least you seem to be returning -errno below and mixing
-1 and -errno is probably a bad idea.

> +}
> +
> +ret = bdrv_pread(bs->file->bs,
> + s->fde_header.offset + offset, buf, buflen);
> +if (ret < 0) {
> +error_setg_errno(errp, -ret, "Could not read encryption header");
> +return ret;
> +}
> +return ret;

return 0? You already processed ret in the if block and two 'return ret'
in a row look odd.

> +}
> +
> +
> +static ssize_t qcow2_fde_header_init_func(QCryptoBlock *block,
> +  size_t headerlen,
> +  Error **errp,
> +  void *opaque)
> +{
> +BlockDriverState *bs = opaque;
> +BDRVQcow2State *s = bs->opaque;
> +int64_t ret;
> +
> +s->fde_header.length = headerlen + (headerlen % s->cluster_size);
> +
> +ret = qcow2_alloc_clusters(bs, s->fde_header.length);
> +if (ret < 0) {
> +s->fde_header.length = 0;
> +error_setg(errp, "Cannot allocate cluster for LUKS header size %zu",
> +   headerlen);

I think ret is 

[Qemu-devel] [PATCH] net: set endianness on all backend devices

[Laurent Vivier]

commit 5be7d9f1b1452613b95c6ba70b8d7ad3d0797991
   vhost-net: tell tap backend about the vnet endianness

makes vhost net to set the endianness of the device, but only for
the first device.

In case of multiqueue, we have multiple devices... This patch sets the
endianness for all the devices of the interface.

Signed-off-by: Laurent Vivier 
---
 hw/net/vhost_net.c | 23 +++
 1 file changed, 11 insertions(+), 12 deletions(-)

diff --git a/hw/net/vhost_net.c b/hw/net/vhost_net.c
index 318c3e6..10e233a 100644
--- a/hw/net/vhost_net.c
+++ b/hw/net/vhost_net.c
@@ -300,21 +300,19 @@ int vhost_net_start(VirtIODevice *dev, NetClientState 
*ncs,
 BusState *qbus = BUS(qdev_get_parent_bus(DEVICE(dev)));
 VirtioBusState *vbus = VIRTIO_BUS(qbus);
 VirtioBusClass *k = VIRTIO_BUS_GET_CLASS(vbus);
-int r, e, i;
+int r, e, i, j;
 
 if (!k->set_guest_notifiers) {
 error_report("binding does not support guest notifiers");
-r = -ENOSYS;
-goto err;
+return -ENOSYS;
 }
 
-r = vhost_net_set_vnet_endian(dev, ncs[0].peer, true);
-if (r < 0) {
-goto err;
-}
-
-for (i = 0; i < total_queues; i++) {
-vhost_net_set_vq_index(get_vhost_net(ncs[i].peer), i * 2);
+for (j = 0; j < total_queues; j++) {
+r = vhost_net_set_vnet_endian(dev, ncs[j].peer, true);
+if (r < 0) {
+goto err_endian;
+}
+vhost_net_set_vq_index(get_vhost_net(ncs[j].peer), j * 2);
 }
 
 r = k->set_guest_notifiers(qbus->parent, total_queues * 2, true);
@@ -343,8 +341,9 @@ err_start:
 fflush(stderr);
 }
 err_endian:
-vhost_net_set_vnet_endian(dev, ncs[0].peer, false);
-err:
+while (--j >= 0) {
+vhost_net_set_vnet_endian(dev, ncs[j].peer, false);
+}
 return r;
 }
 
-- 
1.8.3.1

[Qemu-devel] [PATCH] linux-user/syscall.c: Let lv always match val in do_getsockopt()

[chengang]

From: Chen Gang 

After host_to_target_sock_type(), the length of val may be changed, so
calculate the related lv, too.

Signed-off-by: Chen Gang 
---
 linux-user/syscall.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index fcdca2a..0e95f35 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -1841,6 +1841,7 @@ static abi_long do_getsockopt(int sockfd, int level, int 
optname,
 return ret;
 if (optname == SO_TYPE) {
 val = host_to_target_sock_type(val);
+lv = (val >> 8) ? 4 : 1;
 }
 if (len > lv)
 len = lv;
-- 
1.9.1

Re: [Qemu-devel] [PATCH v2 0/2] qga: guest-set-user-password - added ability to create new user

[Denis V. Lunev]

On 01/06/2016 03:01 PM, Denis V. Lunev wrote:

These patches add optional 'create' flag to guest-set-user-password command.
When it is specified, a new user will be created if it does not
exist yet.

Since v1:
- fixed english language mistakes in comments
- json description now mentions 'create' as default to false
- capture stdout/stderr from useradd/chpasswd and send iti back with the
   error message to caller
- split to two patches

Signed-off-by: Yuri Pudgorodskiy 
Signed-off-by: Denis V. Lunev 
CC: Eric Blake 
CC: Michael Roth 

Yuriy Pudgorodskiy (2):
   create ga_run_program() helper for guest-set-user-password
   guest-set-user-password - added ability to create new user

  qga/commands-posix.c | 215 +--
  qga/commands-win32.c |  25 +-
  qga/qapi-schema.json |   5 +-
  3 files changed, 186 insertions(+), 59 deletions(-)


ping

[Qemu-devel] [PATCH] intel_iommu: large page support

[Jason Wang]

Current intel_iommu only supports 4K page which may not be sufficient
to cover guest working set. This patch tries to enable 2M and 1G mapping
for intel_iommu. This is also useful for future device IOTLB
implementation to have a better hit rate.

Major work is adding a page mask field on IOTLB entry to make it
support large page. And also use the slpte level as key to do IOTLB
lookup. MAMV was increased to 18 to support direct invalidation for 1G
mapping.

Cc: Michael S. Tsirkin 
Cc: Paolo Bonzini 
Cc: Richard Henderson 
Cc: Eduardo Habkost 
Signed-off-by: Jason Wang 
---
Test was done by virtio-net-pmd/vfio with 2M or 1G mapping in guest.
---
 hw/i386/intel_iommu.c  | 76 ++
 hw/i386/intel_iommu_internal.h |  6 ++--
 include/hw/i386/intel_iommu.h  |  1 +
 3 files changed, 59 insertions(+), 24 deletions(-)

diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
index 3fe27fa..68940a0 100644
--- a/hw/i386/intel_iommu.c
+++ b/hw/i386/intel_iommu.c
@@ -152,14 +152,27 @@ static gboolean vtd_hash_remove_by_domain(gpointer key, 
gpointer value,
 return entry->domain_id == domain_id;
 }
 
+/* The shift of an addr for a certain level of paging structure */
+static inline uint32_t vtd_slpt_level_shift(uint32_t level)
+{
+return VTD_PAGE_SHIFT_4K + (level - 1) * VTD_SL_LEVEL_BITS;
+}
+
+static inline uint64_t vtd_slpt_level_page_mask(uint32_t level)
+{
+return ~((1ULL << vtd_slpt_level_shift(level)) - 1);
+}
+
 static gboolean vtd_hash_remove_by_page(gpointer key, gpointer value,
 gpointer user_data)
 {
 VTDIOTLBEntry *entry = (VTDIOTLBEntry *)value;
 VTDIOTLBPageInvInfo *info = (VTDIOTLBPageInvInfo *)user_data;
-uint64_t gfn = info->gfn & info->mask;
+uint64_t gfn = (info->addr >> VTD_PAGE_SHIFT_4K) & info->mask;
+uint64_t gfn_tlb = (info->addr & entry->mask) >> VTD_PAGE_SHIFT_4K;
 return (entry->domain_id == info->domain_id) &&
-((entry->gfn & info->mask) == gfn);
+(((entry->gfn & info->mask) == gfn) ||
+ (entry->gfn == gfn_tlb));
 }
 
 /* Reset all the gen of VTDAddressSpace to zero and set the gen of
@@ -193,24 +206,46 @@ static void vtd_reset_iotlb(IntelIOMMUState *s)
 g_hash_table_remove_all(s->iotlb);
 }
 
+static uint64_t vtd_get_iotlb_key(uint64_t gfn, uint8_t source_id,
+  uint32_t level)
+{
+return gfn | ((uint64_t)(source_id) << VTD_IOTLB_SID_SHIFT) |
+   ((uint64_t)(level) << VTD_IOTLB_LVL_SHIFT);
+}
+
+static uint64_t vtd_get_iotlb_gfn(hwaddr addr, uint32_t level)
+{
+return (addr & vtd_slpt_level_page_mask(level)) >> VTD_PAGE_SHIFT_4K;
+}
+
 static VTDIOTLBEntry *vtd_lookup_iotlb(IntelIOMMUState *s, uint16_t source_id,
hwaddr addr)
 {
+VTDIOTLBEntry *entry;
 uint64_t key;
+int level;
+
+for (level = VTD_SL_PT_LEVEL; level < VTD_SL_PML4_LEVEL; level++) {
+key = vtd_get_iotlb_key(vtd_get_iotlb_gfn(addr, level),
+source_id, level);
+entry = g_hash_table_lookup(s->iotlb, );
+if (entry) {
+goto out;
+}
+}
 
-key = (addr >> VTD_PAGE_SHIFT_4K) |
-   ((uint64_t)(source_id) << VTD_IOTLB_SID_SHIFT);
-return g_hash_table_lookup(s->iotlb, );
-
+out:
+return entry;
 }
 
 static void vtd_update_iotlb(IntelIOMMUState *s, uint16_t source_id,
  uint16_t domain_id, hwaddr addr, uint64_t slpte,
- bool read_flags, bool write_flags)
+ bool read_flags, bool write_flags,
+ uint32_t level)
 {
 VTDIOTLBEntry *entry = g_malloc(sizeof(*entry));
 uint64_t *key = g_malloc(sizeof(*key));
-uint64_t gfn = addr >> VTD_PAGE_SHIFT_4K;
+uint64_t gfn = vtd_get_iotlb_gfn(addr, level);
 
 VTD_DPRINTF(CACHE, "update iotlb sid 0x%"PRIx16 " gpa 0x%"PRIx64
 " slpte 0x%"PRIx64 " did 0x%"PRIx16, source_id, addr, slpte,
@@ -225,7 +260,8 @@ static void vtd_update_iotlb(IntelIOMMUState *s, uint16_t 
source_id,
 entry->slpte = slpte;
 entry->read_flags = read_flags;
 entry->write_flags = write_flags;
-*key = gfn | ((uint64_t)(source_id) << VTD_IOTLB_SID_SHIFT);
+entry->mask = vtd_slpt_level_page_mask(level);
+*key = vtd_get_iotlb_key(gfn, source_id, level);
 g_hash_table_replace(s->iotlb, key, entry);
 }
 
@@ -500,12 +536,6 @@ static inline dma_addr_t 
vtd_get_slpt_base_from_context(VTDContextEntry *ce)
 return ce->lo & VTD_CONTEXT_ENTRY_SLPTPTR;
 }
 
-/* The shift of an addr for a certain level of paging structure */
-static inline uint32_t vtd_slpt_level_shift(uint32_t level)
-{
-return VTD_PAGE_SHIFT_4K + (level - 1) * VTD_SL_LEVEL_BITS;
-}
-
 static inline uint64_t vtd_get_slpte_addr(uint64_t slpte)
 {
  

Re: [Qemu-devel] [PATCH v4 00/11] simplify usage of tracepoints, and connect them to logging

[Denis V. Lunev]

On 01/07/2016 04:55 PM, Denis V. Lunev wrote:

This series does three things:

1) add a "-trace [enable=]foo" option to enable one or more trace
events, and a "-trace help" option to show the list of tracepoints
(patches 4-5)

2) change the stderr tracing backend so that it prints to the
-D log file, and enable it by default.  "-trace file=..." is
now a synonym of -D if the log backend is enabled (patches 7-8)

3) add a "-d trace:foo" option that is a synonym for "-trace foo";
this makes the new functionality more discoverable to people used
to "-d", makes it available for user-mode emulation (which does
not have -trace), and is somewhat nice if you want to enable both
tracepoints and some other "-d" flag (patch 9).  When globbing
it is also less susceptible to unwanted shell expansion.

For example, you can trace block device I/O and save the result
to a file just by adding "-trace bdrv_aio_*,file=trace.txt", or
correlate it to guest PCs with "-d exec,nochain,trace:bdrv_aio_*".

Opinions?  I would like to have this in 2.5 if there is agreement.

Signed-off-by: Paolo Bonzini 
Signed-off-by: Denis V. Lunev 

Changes from v3:
- fixed compilation of target-arm/translate-a64.c (patch 7)
- this warning is not observed in my environment
   /aarch64/qom/xlnx-ep108:
 WARNING: RAM size 800 is small for EP108OK
- this warning after patch 10 is seen
   /microblaze/qom/petalogix-s3adsp1800:
 Invalid MicroBlaze version number: (null)
 OK
   though the problem is here even before any patch of the set. It is
   just hidden as log is not enabled
- no problem for Win32 compilation with
 COLLECT_GCC=x86_64-w64-mingw32-gcc
 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-w64-mingw32/4.9-win32/lto-wrapper
 Target: x86_64-w64-mingw32
 Configured with: ../../src/configure --build=x86_64-linux-gnu 
--prefix=/usr --includedir='/usr/include' --mandir='/usr/share/man' 
--infodir='/usr/share/info' --sysconfdir=/etc --localstatedir=/var 
--disable-silent-rules --libexecdir='/usr/lib/gcc-mingw-w64' 
--disable-maintainer-mode --disable-dependency-tracking --prefix=/usr 
--enable-shared --enable-static --disable-multilib --with-system-zlib 
--libexecdir=/usr/lib --without-included-gettext --libdir=/usr/lib 
--enable-libstdcxx-time=yes --with-tune=generic 
--enable-version-specific-runtime-libs --enable-fully-dynamic-string 
--enable-libgomp --enable-languages=c,c++,fortran,objc,obj-c++ --enable-lto 
--with-plugin-ld --enable-threads=win32 --program-suffix=-win32 
--program-prefix=x86_64-w64-mingw32- --target=x86_64-w64-mingw32 
--with-as=/usr/bin/x86_64-w64-mingw32-as 
--with-ld=/usr/bin/x86_64-w64-mingw32-ld
 Thread model: win32
 gcc version 4.9.2 (GCC)

Changes from v2:
- compilation fix was extended to patch 2 and 3
- replaced Reviewed-by with Acked-by by request from Christian

Changes from v1:
- small cleanup to vl.c is added as patch (4)
- compilation is fixed in patch (2)
- moved qemu-log.c to util/log.c to fix linking of qemu-io/qemu-nbd

Denis V. Lunev (2):
   trace: no need to call trace_backend_init in different branches now
   log: move qemu-log.c into util/ directory

Paolo Bonzini (9):
   trace: fix documentation
   trace: split trace_init_events out of trace_init_backends
   trace: split trace_init_file out of trace_init_backends
   trace: add "-trace enable=..."
   trace: add "-trace help"
   log: do not unnecessarily include qom/cpu.h
   trace: convert stderr backend to log
   trace: switch default backend to "log"
   log: add "-d trace:PATTERN"

  Makefile.objs   |  1 -
  bsd-user/main.c |  1 +
  configure   |  6 +-
  cpu-exec.c  |  1 +
  exec.c  |  1 +
  hw/acpi/cpu_hotplug.c   |  1 +
  hw/timer/a9gtimer.c |  1 +
  include/exec/log.h  | 60 
  include/qemu/log.h  | 60 +---
  linux-user/main.c   |  1 +
  qemu-io.c   |  2 +-
  qemu-options.hx | 22 --
  qom/cpu.c   |  1 +
  scripts/tracetool/backend/{stderr.py => log.py} |  9 +--
  target-alpha/translate.c|  1 +
  target-arm/translate-a64.c  |  1 +
  target-arm/translate.c  |  1 +
  target-cris/translate.c |  1 +
  target-i386/seg_helper.c|  1 +
  target-i386/smm_helper.c|  1 +
  target-i386/translate.c |  1 +
  target-lm32/helper.c|  1 +
  target-lm32/translate.c |  1 +
  target-m68k/translate.c |  1 +
  

Re: [Qemu-devel] [PATCH 1/5] block: added lock image option and callback

[Denis V. Lunev]

On 01/13/2016 07:44 PM, Eric Blake wrote:

On 01/12/2016 05:10 PM, Fam Zheng wrote:


If we will switch default in my patch from 'nolock' to 'lock' then
pour guys which are calling qemu-img etc stuff will see the lock
as necessary while 'proper management software' aka libvirt
will be able to call qemu/qemu-img etc with proper 'nolock'
flag as they do care about the locking.

That is wrong because then we break old libvirt with the new qemu-img (acquires
lock by default), which is IMO a breakage of backward compatibility.

In the big software stack picture, it is okay to reject 'old libvirt/new
qemu' as an invalid combination.  Upgrade-wise, we specifically support
'new libvirt/old qemu' - but it is fair game to say that 'if you want to
run new qemu, you must first upgrade to new libvirt that knows how to
drive it'.

That said, minimizing back-compat breaks, so that old libvirt can
(usually) correctly drive new qemu, is a worthy design goal for qemu.


there is one other thing I have originally missed to add to the
picture.

Locking could be complex and format specific. In original
Parallels disk format (not image but entire bundle), the locking
is performed on a very special file.

Thus either libvirt must know exact format details or it must
rely on something which really does know details, i.e. QEMU/qemu-img.

Den

[Qemu-devel] [PATCH] translate-all.c: Remove writable protection feature for tb_alloc_page()

[chengang]

From: Chen Gang 

Guest may allocate a readable, writable, and executable page, then write
data on the page, and execute data as code on the page too, then write
anther data still within the page.

So remove this feature from linux-user: it not only consumes a little
performance, but also causes issue with the old Linux kernel under some
of architectures (they will directly generate segment fault for it).

Signed-off-by: Chen Gang 
---
 translate-all.c | 29 +
 1 file changed, 1 insertion(+), 28 deletions(-)

diff --git a/translate-all.c b/translate-all.c
index 042a857..1b6e95d 100644
--- a/translate-all.c
+++ b/translate-all.c
@@ -1430,34 +1430,7 @@ static inline void tb_alloc_page(TranslationBlock *tb,
 p->first_tb = (TranslationBlock *)((uintptr_t)tb | n);
 invalidate_page_bitmap(p);
 
-#if defined(CONFIG_USER_ONLY)
-if (p->flags & PAGE_WRITE) {
-target_ulong addr;
-PageDesc *p2;
-int prot;
-
-/* force the host page as non writable (writes will have a
-   page fault + mprotect overhead) */
-page_addr &= qemu_host_page_mask;
-prot = 0;
-for (addr = page_addr; addr < page_addr + qemu_host_page_size;
-addr += TARGET_PAGE_SIZE) {
-
-p2 = page_find(addr >> TARGET_PAGE_BITS);
-if (!p2) {
-continue;
-}
-prot |= p2->flags;
-p2->flags &= ~PAGE_WRITE;
-  }
-mprotect(g2h(page_addr), qemu_host_page_size,
- (prot & PAGE_BITS) & ~PAGE_WRITE);
-#ifdef DEBUG_TB_INVALIDATE
-printf("protecting code page: 0x" TARGET_FMT_lx "\n",
-   page_addr);
-#endif
-}
-#else
+#if !defined(CONFIG_USER_ONLY)
 /* if some code is already present, then the pages are already
protected. So we handle the case where only the first TB is
allocated in a physical page */
-- 
1.9.1

[Qemu-devel] [Bug 1490611] Re: Using qemu >=2.2.1 to convert raw->VHD (fixed) adds extra padding to the result file, which Microsoft Azure rejects as invalid

[willmo]

Judging by their comments on bug 1399191, jan-wang1989 doesn't appear to
be a QEMU developer.

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

Title:
  Using qemu >=2.2.1 to convert raw->VHD (fixed) adds extra padding to
  the result file, which Microsoft Azure rejects as invalid

Status in QEMU:
  Fix Released

Bug description:
  Starting with a raw disk image, using "qemu-img convert" to convert
  from raw to VHD results in the output VHD file's virtual size being
  aligned to the nearest 516096 bytes (16 heads x 63 sectors per head x
  512 bytes per sector), instead of preserving the input file's size as
  the output VHD's virtual disk size.

  Microsoft Azure requires that disk images (VHDs) submitted for upload
  have virtual sizes aligned to a megabyte boundary. (Ex. 4096MB,
  4097MB, 4098MB, etc. are OK, 4096.5MB is rejected with an error.) This
  is reflected in Microsoft's documentation: https://azure.microsoft.com
  /en-us/documentation/articles/virtual-machines-linux-create-upload-
  vhd-generic/

  This is reproducible with the following set of commands (including the
  Azure command line tools from https://github.com/Azure/azure-xplat-
  cli). For the following example, I used qemu version 2.2.1:

  $ dd if=/dev/zero of=source-disk.img bs=1M count=4096

  $ stat source-disk.img 
File: ‘source-disk.img’
Size: 4294967296  Blocks: 798656 IO Block: 4096   regular file
  Device: fc01h/64513dInode: 13247963Links: 1
  Access: (0644/-rw-r--r--)  Uid: ( 1000/  smkent)   Gid: ( 1000/  smkent)
  Access: 2015-08-18 09:48:02.613988480 -0700
  Modify: 2015-08-18 09:48:02.825985646 -0700
  Change: 2015-08-18 09:48:02.825985646 -0700
   Birth: -

  $ qemu-img convert -f raw -o subformat=fixed -O vpc source-disk.img
  dest-disk.vhd

  $ stat dest-disk.vhd 
File: ‘dest-disk.vhd’
Size: 4296499712  Blocks: 535216 IO Block: 4096   regular file
  Device: fc01h/64513dInode: 13247964Links: 1
  Access: (0644/-rw-r--r--)  Uid: ( 1000/  smkent)   Gid: ( 1000/  smkent)
  Access: 2015-08-18 09:50:22.252077624 -0700
  Modify: 2015-08-18 09:49:24.424868868 -0700
  Change: 2015-08-18 09:49:24.424868868 -0700
   Birth: -

  $ azure vm image create testimage1 dest-disk.vhd -o linux -l "West US"
  info:Executing command vm image create
  + Retrieving storage accounts 
 
  info:VHD size : 4097 MB
  info:Uploading 4195800.5 KB
  Requested:100.0% Completed:100.0% Running:   0 Time: 1m 0s Speed:  6744 KB/s 
  info:https://[redacted].blob.core.windows.net/vm-images/dest-disk.vhd was 
uploaded successfully
  error:   The VHD 
https://[redacted].blob.core.windows.net/vm-images/dest-disk.vhd has an 
unsupported virtual size of 4296499200 bytes.  The size must be a whole number 
(in MBs).
  info:Error information has been recorded to /home/smkent/.azure/azure.err
  error:   vm image create command failed

  I also ran the above commands using qemu 2.4.0, which resulted in the
  same error as the conversion behavior is the same.

  However, qemu 2.1.1 and earlier (including qemu 2.0.0 installed by
  Ubuntu 14.04) does not pad the virtual disk size during conversion.
  Using qemu-img convert from qemu versions <=2.1.1 results in a VHD
  that is exactly the size of the raw input file plus 512 bytes (for the
  VHD footer). Those qemu versions do not attempt to realign the disk.
  As a result, Azure accepts VHD files created using those versions of
  qemu-img convert for upload.

  Is there a reason why newer qemu realigns the converted VHD file? It
  would be useful if an option were added to disable this feature, as
  current versions of qemu cannot be used to create VHD files for Azure
  using Microsoft's official instructions.

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

Re: [Qemu-devel] [PATCH v1 08/15] block: add generic full disk encryption driver

[Eric Blake]

On 01/12/2016 11:56 AM, Daniel P. Berrange wrote:
> Add a block driver that is capable of supporting any full disk
> encryption format. This utilizes the previously added block
> encryption code, and at this time supports the LUKS format.
> 
> The driver code is capable of supporting any format supported
> by the QCryptoBlock module, so it registers one block driver
> for each format.
> 
> At this time, the "luks" driver is registered. New LUKS
> compatible volume can be formatted using qemu-img
> 
> $ qemu-img create --object secret,data=123456,id=sec0 \
>   -f luks -o key-id=sec0,cipher-alg=aes-256,\
>   cipher-mode=cbc,ivgen-alg=plain64,hash-alg=sha256 \
>   demo.luks 10G
> 

> @@ -1664,6 +1664,21 @@
>'data': { 'file': 'BlockdevRef' } }
>  
>  ##
> +# @BlockdevOptionsLUKS
> +#
> +# Driver specific block device options for LUKS.
> +#
> +# @key-id:  #optional the ID of a QCryptoSecret object providing
> +#   the decryption key (since 2.6)
> +#
> +# Since: 2.6
> +##
> +{ 'struct': 'BlockdevOptionsLUKS',
> +  'base': 'BlockdevOptionsGenericFormat',
> +  'data': { '*key-id': 'str' } }

And if key-id is omitted, how does it work?

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v1 06/15] crypto: implement the LUKS block encryption format

[Eric Blake]

On 01/12/2016 11:56 AM, Daniel P. Berrange wrote:
> Provide a block encryption implementation that follows the
> LUKS/dm-crypt specification.
> 
> This supports all combinations of hash, cipher algorithm,
> cipher mode and iv generator that are implemented by the
> current crypto layer.
> 
> The notable missing feature is support for the 'xts'
> cipher mode, which is commonly used for disk encryption
> instead of 'cbc'. This is because it is not provided by
> either nettle or libgcrypt. A suitable implementation
> will be identified & integrated later.
> 
> There is support for opening existing volumes formatted
> by dm-crypt, and for formatting new volumes. In the latter
> case it will only use key slot 0.
> 
> Signed-off-by: Daniel P. Berrange 
> ---

> +++ b/qapi/crypto.json
> @@ -101,12 +101,13 @@
>  # The supported full disk encryption formats
>  #
>  # @qcowaes: QCow/QCow2 built-in AES-CBC encryption. Do not use
> +# @luks: LUKS encryption format. Recommended
>  #
>  # Since: 2.6
>  ##
>  { 'enum': 'QCryptoBlockFormat',
>  #  'prefix': 'QCRYPTO_BLOCK_FORMAT',
> -  'data': ['qcowaes']}
> +  'data': ['qcowaes', 'luks']}
>  
>  ##
>  # QCryptoBlockOptionsBase:
> @@ -134,6 +135,39 @@
>'data': { '*key-id': 'str' }}
>  
>  ##
> +# QCryptoBlockOptionsLUKS:
> +#
> +# The options that apply to LUKS encryption format
> +#
> +# @key-id: the ID of a QCryptoSecret object providing the decryption key

Is the key-id really optional?  If so, missing the '#optional' tag.

> +# Since: 2.6
> +##
> +{ 'struct': 'QCryptoBlockOptionsLUKS',
> +  'data': { '*key-id': 'str' }}
> +
> +
> +##
> +# QCryptoBlockCreateOptionsLUKS:
> +#
> +# The options that apply to LUKS encryption format initialization
> +#
> +# @cipher-alg: (optional) the cipher algorithm for data encryption

Marc-Andre's pending patches to auto-generate docs from the .json files
want this to be s/(optional)/#optional/ (here and elsewhere).

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature