Re: [Qemu-devel] [PATCH 1/2] net: make iov_to_buf take right size argument in nc_sendv_compat()

[Jason Wang]

On 10/20/2015 09:51 AM, Yang Hongyang wrote:
> We want "buf, sizeof(buf)" here.  sizeof(buffer) is the size of a
> pointer, which is wrong.
> Thanks to Paolo for pointing it out.
>
> Signed-off-by: Yang Hongyang 
> Cc: Jason Wang 
> Cc: Paolo Bonzini 
> ---
>  net/net.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/net.c b/net/net.c
> index 39af893..0c4a012 100644
> --- a/net/net.c
> +++ b/net/net.c
> @@ -700,7 +700,7 @@ static ssize_t nc_sendv_compat(NetClientState *nc, const 
> struct iovec *iov,
>  offset = iov[0].iov_len;
>  } else {
>  buffer = buf;
> -offset = iov_to_buf(iov, iovcnt, 0, buffer, sizeof(buffer));
> +offset = iov_to_buf(iov, iovcnt, 0, buf, sizeof(buf));
>  }
>  
>  if (flags & QEMU_NET_PACKET_FLAG_RAW && nc->info->receive_raw) {

Both two patches were applied in:

https://github.com/jasowang/qemu/commits/net

Thanks

[Qemu-devel] [PATCH v2] scripts/text2pod.pl: Escape left brace

[Fam Zheng]

Latest perl now deprecates "{" literal in regex and print warnings like
"unescaped left brace in regex is deprecated".  Add escapes to keep it
happy.

Signed-off-by: Fam Zheng 

---

v2: Drop superfluous hunk.
---
 scripts/texi2pod.pl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/texi2pod.pl b/scripts/texi2pod.pl
index 94097fb..8767662 100755
--- a/scripts/texi2pod.pl
+++ b/scripts/texi2pod.pl
@@ -317,7 +317,7 @@ while(<$inf>) {
@columns = ();
for $column (split (/\s*\@tab\s*/, $1)) {
# @strong{...} is used a @headitem work-alike
-   $column =~ s/^\@strong{(.*)}$/$1/;
+   $column =~ s/^\@strong\{(.*)\}$/$1/;
push @columns, $column;
}
$_ = "\n=item ".join (" : ", @columns)."\n";
-- 
2.4.3

Re: [Qemu-devel] [PATCH v9 04/17] vnc: hoist allocation of VncBasicInfo to callers

[Markus Armbruster]

Eric Blake  writes:

> A future qapi patch will rework generated structs with a base
> class to be unboxed.  In preparation for that, change the code
> that allocates then populates an info struct to instead merely
> populate the fields of an info field passed in as a parameter.
> Add rudimentary Error handling for cases where the old code
> returned NULL; but as before, callers merely ignore errors for
> now.

Actually, the call chain rooted at vnc_qmp_event() does handle failure
before this patch.  It ignores the error *object* after the patch.

>
> Signed-off-by: Eric Blake 
>
> ---
> v9: (no v6-8): hoist from v5 33/46
> ---
>  ui/vnc.c | 52 
>  1 file changed, 28 insertions(+), 24 deletions(-)
>
> diff --git a/ui/vnc.c b/ui/vnc.c
> index d73966a..61af4ba 100644
> --- a/ui/vnc.c
> +++ b/ui/vnc.c
> @@ -156,10 +156,11 @@ char *vnc_socket_remote_addr(const char *format, int 
> fd) {
>  return addr_to_string(format, &sa, salen);
>  }
>
> -static VncBasicInfo *vnc_basic_info_get(struct sockaddr_storage *sa,
> -socklen_t salen)
> +static void vnc_basic_info_get(struct sockaddr_storage *sa,
> +   socklen_t salen,
> +   VncBasicInfo *info,
> +   Error **errp)
>  {
> -VncBasicInfo *info;
>  char host[NI_MAXHOST];
>  char serv[NI_MAXSERV];
>  int err;
> @@ -168,42 +169,44 @@ static VncBasicInfo *vnc_basic_info_get(struct 
> sockaddr_storage *sa,
> host, sizeof(host),
> serv, sizeof(serv),
> NI_NUMERICHOST | NI_NUMERICSERV)) != 0) {
> -VNC_DEBUG("Cannot resolve address %d: %s\n",
> -  err, gai_strerror(err));
> -return NULL;
> +error_setg(errp, "Cannot resolve address %d: %s",
> +   err, gai_strerror(err));

Printing err is fine for a debug message.  Less so for an error message.
Drop it?

> +return;
>  }
>
> -info = g_malloc0(sizeof(VncBasicInfo));
>  info->host = g_strdup(host);
>  info->service = g_strdup(serv);
>  info->family = inet_netfamily(sa->ss_family);
> -return info;
>  }

The function no longer "gets info", it merely initializes it.  Rename it
accordingly?  Gerd?

More of the same below.

>
> -static VncBasicInfo *vnc_basic_info_get_from_server_addr(int fd)
> +static void vnc_basic_info_get_from_server_addr(int fd, VncBasicInfo *info,
> +Error **errp)
>  {
>  struct sockaddr_storage sa;
>  socklen_t salen;
>
>  salen = sizeof(sa);
>  if (getsockname(fd, (struct sockaddr*)&sa, &salen) < 0) {
> -return NULL;
> +error_setg_errno(errp, errno, "getsockname failed");
> +return;
>  }
>
> -return vnc_basic_info_get(&sa, salen);
> +vnc_basic_info_get(&sa, salen, info, errp);
>  }
>
> -static VncBasicInfo *vnc_basic_info_get_from_remote_addr(int fd)
> +static void vnc_basic_info_get_from_remote_addr(int fd, VncBasicInfo *info,
> +Error **errp)
>  {
>  struct sockaddr_storage sa;
>  socklen_t salen;
>
>  salen = sizeof(sa);
>  if (getpeername(fd, (struct sockaddr*)&sa, &salen) < 0) {
> -return NULL;
> +error_setg_errno(errp, errno, "getpeername failed");
> +return;
>  }
>
> -return vnc_basic_info_get(&sa, salen);
> +vnc_basic_info_get(&sa, salen, info, errp);
>  }
>
>  static const char *vnc_auth_name(VncDisplay *vd) {
> @@ -256,13 +259,10 @@ static const char *vnc_auth_name(VncDisplay *vd) {
>  static VncServerInfo *vnc_server_info_get(VncDisplay *vd)
>  {
>  VncServerInfo *info;
> -VncBasicInfo *bi = vnc_basic_info_get_from_server_addr(vd->lsock);
> -if (!bi) {
> -return NULL;
> -}
>
>  info = g_malloc(sizeof(*info));
> -info->base = bi;
> +info->base = g_malloc(sizeof(*info->base));
> +vnc_basic_info_get_from_server_addr(vd->lsock, info->base, NULL);
>  info->has_auth = true;
>  info->auth = g_strdup(vnc_auth_name(vd));
>  return info;

Uh, doesn't this change the return value when getsockname() in
vnc_basic_info_get_from_server_addr() fails?

> @@ -291,11 +291,15 @@ static void vnc_client_cache_auth(VncState *client)
>
>  static void vnc_client_cache_addr(VncState *client)
>  {
> -VncBasicInfo *bi = vnc_basic_info_get_from_remote_addr(client->csock);
> -
> -if (bi) {
> -client->info = g_malloc0(sizeof(*client->info));
> -client->info->base = bi;
> +Error *err = NULL;
> +client->info = g_malloc0(sizeof(*client->info));
> +client->info->base = g_malloc0(sizeof(*client->info->base));
> +vnc_basic_info_get_from_remote_addr(client->csock, client->info->base,
> +&err);
> +if (err) {
> +qapi_free_VncClientInfo(client

Re: [Qemu-devel] Trouble with numlock and SDL

[Gerd Hoffmann]

On Mo, 2015-10-19 at 18:02 +0200, Erik Rull wrote:
> Hi Gerd,
> 
> any ideas if there was an update or patch on this point? I tried to check
> the commits since April but didn't find something that may fit...

Nobody coded this up so far ...

cheers,
  Gerd

Re: [Qemu-devel] [RFC] transactions: add transaction-wide property

[Fam Zheng]

On Thu, 09/24 17:40, John Snow wrote:
> This replaces the per-action property as in Fam's series.
> Instead, we have a transaction-wide property that is shared
> with each action.
> 
> At the action level, if a property supplied transaction-wide
> is disagreeable, we return error and the transaction is aborted.
> 
> RFC:
> 
> Where this makes sense: Any transactional actions that aren't
> prepared to accept this new paradigm of transactional behavior
> can error_setg and return.
> 
> Where this may not make sense: consider the transactions which
> do not use BlockJobs to perform their actions, i.e. they are
> synchronous during the transactional phase. Because they either
> fail or succeed so early, we might say that of course they can
> support this property ...
> 
> ...however, consider the case where we create a new bitmap and
> perform a full backup, using allow_partial=false. If the backup
> fails, we might well expect the bitmap to be deleted because a
> member of the transaction ultimately/eventually failed. However,
> the bitmap creation was not undone because it does not have a
> pending/delayed abort/commit action -- those are only for jobs
> in this implementation.
> 
> How do we fix this?
> 
> (1) We just say "No, you can't use the new block job transaction
> completion mechanic in conjunction with these commands,"
> 
> (2) We make Bitmap creation/resetting small, synchronous blockjobs
> that can join the BlockJobTxn

We could categorize commands as synchronous ones and long running ones, and
make it explicit that only long running jobs are affected by "allow_partial".

> 
> Signed-off-by: John Snow 
> ---
>  blockdev.c | 87 
> --
>  blockjob.c |  2 +-
>  qapi-schema.json   | 15 +++--
>  qapi/block-core.json   | 26 ---
>  qmp-commands.hx|  2 +-
>  tests/qemu-iotests/124 | 12 +++
>  6 files changed, 83 insertions(+), 61 deletions(-)
> 
> diff --git a/blockdev.c b/blockdev.c
> index 45a9fe7..02b1a83 100644
> --- a/blockdev.c
> +++ b/blockdev.c
> @@ -1061,7 +1061,7 @@ static void blockdev_do_action(int kind, void *data, 
> Error **errp)
>  action.data = data;
>  list.value = &action;
>  list.next = NULL;
> -qmp_transaction(&list, errp);
> +qmp_transaction(&list, false, NULL, errp);
>  }
>  
>  void qmp_blockdev_snapshot_sync(bool has_device, const char *device,
> @@ -1286,6 +1286,7 @@ struct BlkActionState {
>  TransactionAction *action;
>  const BlkActionOps *ops;
>  BlockJobTxn *block_job_txn;
> +TransactionProperties *txn_props;
>  QSIMPLEQ_ENTRY(BlkActionState) entry;
>  };
>  
> @@ -1322,6 +1323,12 @@ static void internal_snapshot_prepare(BlkActionState 
> *common,
>  name = internal->name;
>  
>  /* 2. check for validation */
> +if (!common->txn_props->allow_partial) {
> +error_setg(errp,
> +   "internal_snapshot does not support allow_partial = 
> false");
> +return;
> +}
> +
>  blk = blk_by_name(device);
>  if (!blk) {
>  error_set(errp, ERROR_CLASS_DEVICE_NOT_FOUND,
> @@ -1473,6 +1480,12 @@ static void external_snapshot_prepare(BlkActionState 
> *common,
>  }
>  
>  /* start processing */
> +if (!common->txn_props->allow_partial) {
> +error_setg(errp,
> +   "external_snapshot does not support allow_partial = 
> false");
> +return;
> +}
> +
>  state->old_bs = bdrv_lookup_bs(has_device ? device : NULL,
> has_node_name ? node_name : NULL,
> &local_err);
> @@ -1603,14 +1616,11 @@ static void drive_backup_prepare(BlkActionState 
> *common, Error **errp)
>  DriveBackupState *state = DO_UPCAST(DriveBackupState, common, common);
>  BlockDriverState *bs;
>  BlockBackend *blk;
> -DriveBackupTxn *backup_txn;
>  DriveBackup *backup;
> -BlockJobTxn *txn = NULL;
>  Error *local_err = NULL;
>  
>  assert(common->action->kind == TRANSACTION_ACTION_KIND_DRIVE_BACKUP);
> -backup_txn = common->action->drive_backup;
> -backup = backup_txn->base;
> +backup = common->action->drive_backup->base;
>  
>  blk = blk_by_name(backup->device);
>  if (!blk) {
> @@ -1624,11 +1634,6 @@ static void drive_backup_prepare(BlkActionState 
> *common, Error **errp)
>  state->aio_context = bdrv_get_aio_context(bs);
>  aio_context_acquire(state->aio_context);
>  
> -if (backup_txn->has_transactional_cancel &&
> -backup_txn->transactional_cancel) {
> -txn = common->block_job_txn;
> -}
> -
>  do_drive_backup(backup->device, backup->target,
>  backup->has_format, backup->format,
>  backup->sync,
> @@ -1637,7 +1642,7 @@ static void drive_backup_prepare(BlkActionState 
> *common, Error **errp)
>  backup->has_bitmap, backup->bitmap,
>  b

Re: [Qemu-devel] [PATCH COLO-Frame v9 06/32] migration: Integrate COLO checkpoint process into loadvm

[zhanghailiang]

On 2015/10/19 17:17, Dr. David Alan Gilbert wrote:

* zhanghailiang (zhang.zhanghaili...@huawei.com) wrote:

Switch from normal migration loadvm process into COLO checkpoint process if
COLO mode is enabled.
We add three new members to struct MigrationIncomingState, 
'have_colo_incoming_thread'
and 'colo_incoming_thread' record the colo related threads for secondary VM,
'migration_incoming_co' records the original migration incoming coroutine.

Signed-off-by: zhanghailiang 
Signed-off-by: Li Zhijian 
Signed-off-by: Yang Hongyang 


Mostly OK, some mostly minor comments, and one question below:


---
  include/migration/colo.h  |  7 +++
  include/migration/migration.h |  7 +++
  migration/colo-comm.c | 10 ++
  migration/colo.c  | 22 ++
  migration/migration.c | 33 +++--
  stubs/migration-colo.c| 10 ++
  trace-events  |  1 +
  7 files changed, 80 insertions(+), 10 deletions(-)

diff --git a/include/migration/colo.h b/include/migration/colo.h
index dface19..58849f7 100644
--- a/include/migration/colo.h
+++ b/include/migration/colo.h
@@ -15,6 +15,8 @@

  #include "qemu-common.h"
  #include "migration/migration.h"
+#include "block/coroutine.h"
+#include "qemu/thread.h"

  bool colo_supported(void);
  void colo_info_mig_init(void);
@@ -22,4 +24,9 @@ void colo_info_mig_init(void);
  void colo_init_checkpointer(MigrationState *s);
  bool migration_in_colo_state(void);

+/* loadvm */
+bool migration_incoming_enable_colo(void);
+void migration_incoming_exit_colo(void);
+void *colo_process_incoming_thread(void *opaque);
+bool migration_incoming_in_colo_state(void);
  #endif
diff --git a/include/migration/migration.h b/include/migration/migration.h
index a62068f..9cdd6b6 100644
--- a/include/migration/migration.h
+++ b/include/migration/migration.h
@@ -22,6 +22,7 @@
  #include "migration/vmstate.h"
  #include "qapi-types.h"
  #include "exec/cpu-common.h"
+#include "block/coroutine.h"

  #define QEMU_VM_FILE_MAGIC   0x5145564d
  #define QEMU_VM_FILE_VERSION_COMPAT  0x0002
@@ -51,6 +52,12 @@ struct MigrationIncomingState {
  QEMUFile *file;

  int state;
+
+bool have_colo_incoming_thread;
+QemuThread colo_incoming_thread;
+/* The coroutine we should enter (back) after failover */
+Coroutine *migration_incoming_co;
+
  /* See savevm.c */
  LoadStateEntry_Head loadvm_handlers;
  };
diff --git a/migration/colo-comm.c b/migration/colo-comm.c
index 4330bd8..0808d6c 100644
--- a/migration/colo-comm.c
+++ b/migration/colo-comm.c
@@ -52,3 +52,13 @@ void colo_info_mig_init(void)
  {
  vmstate_register(NULL, 0, &colo_state, &colo_info);
  }
+
+bool migration_incoming_enable_colo(void)
+{
+return colo_info.colo_requested;
+}
+
+void migration_incoming_exit_colo(void)
+{
+colo_info.colo_requested = 0;
+}
diff --git a/migration/colo.c b/migration/colo.c
index 97e64a3..a341eee 100644
--- a/migration/colo.c
+++ b/migration/colo.c
@@ -13,6 +13,7 @@
  #include "sysemu/sysemu.h"
  #include "migration/colo.h"
  #include "trace.h"
+#include "qemu/error-report.h"

  static QEMUBH *colo_bh;

@@ -28,6 +29,13 @@ bool migration_in_colo_state(void)
  return (s->state == MIGRATION_STATUS_COLO);
  }

+bool migration_incoming_in_colo_state(void)
+{
+MigrationIncomingState *mis = migration_incoming_get_current();
+
+return (mis && (mis->state == MIGRATION_STATUS_COLO));


Can remove outer brackets.



OK.


+}
+
  static void *colo_thread(void *opaque)
  {
  MigrationState *s = opaque;
@@ -74,3 +82,17 @@ void colo_init_checkpointer(MigrationState *s)
  colo_bh = qemu_bh_new(colo_start_checkpointer, s);
  qemu_bh_schedule(colo_bh);
  }
+
+void *colo_process_incoming_thread(void *opaque)
+{
+MigrationIncomingState *mis = opaque;
+
+migrate_set_state(&mis->state, MIGRATION_STATUS_ACTIVE,
+  MIGRATION_STATUS_COLO);
+
+/* TODO: COLO checkpoint restore loop */
+
+migration_incoming_exit_colo();
+
+return NULL;
+}
diff --git a/migration/migration.c b/migration/migration.c
index bee61aa..241689f 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -280,7 +280,28 @@ static void process_incoming_migration_co(void *opaque)
MIGRATION_STATUS_ACTIVE);
  ret = qemu_loadvm_state(f);

-qemu_fclose(f);
+if (!ret) {
+/* Make sure all file formats flush their mutable metadata */
+bdrv_invalidate_cache_all(&local_err);
+if (local_err) {
+error_report_err(local_err);
+migrate_decompress_threads_join();
+exit(EXIT_FAILURE);
+}
+}
+/* we get colo info, and know if we are in colo mode */
+if (!ret && migration_incoming_enable_colo()) {
+mis->migration_incoming_co = qemu_coroutine_self();
+qemu_thread_create(&mis->colo_incoming_thread, "colo incoming",
+ colo_process_incoming_t

[Qemu-devel] [PULL v2 5/7] Enable fw_cfg DMA interface for ARM

[Gerd Hoffmann]

From: Marc Marí 

Enable the fw_cfg DMA interface for the ARM virt machine.

Based on Gerd Hoffman's initial implementation.

Signed-off-by: Marc Marí 
Reviewed-by: Peter Maydell 
Reviewed-by: Laszlo Ersek 
Signed-off-by: Gerd Hoffmann 
---
 hw/arm/virt.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index b670bc6..5d38c47 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -119,7 +119,7 @@ static const MemMapEntry a15memmap[] = {
 [VIRT_GIC_REDIST] = { 0x080A, 0x00F6 },
 [VIRT_UART] =   { 0x0900, 0x1000 },
 [VIRT_RTC] ={ 0x0901, 0x1000 },
-[VIRT_FW_CFG] = { 0x0902, 0x000a },
+[VIRT_FW_CFG] = { 0x0902, 0x0018 },
 [VIRT_MMIO] =   { 0x0a00, 0x0200 },
 /* ...repeating for a total of NUM_VIRTIO_TRANSPORTS, each of that size */
 [VIRT_PLATFORM_BUS] =   { 0x0c00, 0x0200 },
@@ -677,13 +677,13 @@ static void create_flash(const VirtBoardInfo *vbi)
 g_free(nodename);
 }
 
-static void create_fw_cfg(const VirtBoardInfo *vbi)
+static void create_fw_cfg(const VirtBoardInfo *vbi, AddressSpace *as)
 {
 hwaddr base = vbi->memmap[VIRT_FW_CFG].base;
 hwaddr size = vbi->memmap[VIRT_FW_CFG].size;
 char *nodename;
 
-fw_cfg_init_mem_wide(base + 8, base, 8, 0, NULL);
+fw_cfg_init_mem_wide(base + 8, base, 8, base + 16, as);
 
 nodename = g_strdup_printf("/fw-cfg@%" PRIx64, base);
 qemu_fdt_add_subnode(vbi->fdt, nodename);
@@ -1031,7 +1031,7 @@ static void machvirt_init(MachineState *machine)
  */
 create_virtio_devices(vbi, pic);
 
-create_fw_cfg(vbi);
+create_fw_cfg(vbi, &address_space_memory);
 rom_set_fw(fw_cfg_find());
 
 guest_info->smp_cpus = smp_cpus;
-- 
1.8.3.1

Re: [Qemu-devel] [ipxe-devel] EFI_PXE_BASE_CODE_PROTOCOL

[Gerd Hoffmann]

  Hi,

> The guids translate to:
> 
> 245DCA21-FB7B-11D3-8F01-00A0C969723B gEfiPxeBaseCodeCallbackProtocolGuid
> 41D94CD2-35B6-455A-8258-D4E51334AADD gEfiIp4ProtocolGuid
> 3AD9DF29-4501-478D-B1F8-7F7FE70E50F3 gEfiUdp4ProtocolGuid
> F4B427BB-BA21-4F16-BC4E-43E416AB619C gEfiArpProtocolGuid
> 245DCA21-FB7B-11D3-8F01-00A0C969723B gEfiPxeBaseCodeCallbackProtocolGuid
> 5B1B31A1-9562-11D2-8E3F-00A0C969723B gEfiLoadedImageProtocolGuid
> BC62157E-3E33-4FEC-9920-2D3B36D750DF
> gEfiLoadedImageDevicePathProtocolGuid
> 
> Hmm, EfiPxeBaseCode*Callback*Protocol?

Ping.  Any progress here?

Meanwhile I've noticed efi grub2 fails to load grub.cfg on microsoft
hyper-v too, so possibly this is something in grub not ipxe ...

cheers,
  Gerd

[Qemu-devel] [PULL v2 4/7] Implement fw_cfg DMA interface

[Gerd Hoffmann]

From: Marc Marí 

Based on the specifications on docs/specs/fw_cfg.txt

This interface is an addon. The old interface can still be used as usual.

Based on Gerd Hoffman's initial implementation.

Signed-off-by: Marc Marí 
Reviewed-by: Laszlo Ersek 
Signed-off-by: Gerd Hoffmann 
---
 hw/arm/virt.c |   2 +-
 hw/nvram/fw_cfg.c | 240 +++---
 include/hw/nvram/fw_cfg.h |  16 +++-
 tests/fw_cfg-test.c   |   4 +-
 4 files changed, 247 insertions(+), 15 deletions(-)

diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 4e7160c..b670bc6 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -683,7 +683,7 @@ static void create_fw_cfg(const VirtBoardInfo *vbi)
 hwaddr size = vbi->memmap[VIRT_FW_CFG].size;
 char *nodename;
 
-fw_cfg_init_mem_wide(base + 8, base, 8);
+fw_cfg_init_mem_wide(base + 8, base, 8, 0, NULL);
 
 nodename = g_strdup_printf("/fw-cfg@%" PRIx64, base);
 qemu_fdt_add_subnode(vbi->fdt, nodename);
diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
index 658f8c4..91829d4 100644
--- a/hw/nvram/fw_cfg.c
+++ b/hw/nvram/fw_cfg.c
@@ -23,6 +23,7 @@
  */
 #include "hw/hw.h"
 #include "sysemu/sysemu.h"
+#include "sysemu/dma.h"
 #include "hw/isa/isa.h"
 #include "hw/nvram/fw_cfg.h"
 #include "hw/sysbus.h"
@@ -30,7 +31,7 @@
 #include "qemu/error-report.h"
 #include "qemu/config-file.h"
 
-#define FW_CFG_SIZE 2
+#define FW_CFG_CTL_SIZE 2
 #define FW_CFG_NAME "fw_cfg"
 #define FW_CFG_PATH "/machine/" FW_CFG_NAME
 
@@ -42,6 +43,16 @@
 #define FW_CFG_IO(obj)  OBJECT_CHECK(FWCfgIoState,  (obj), TYPE_FW_CFG_IO)
 #define FW_CFG_MEM(obj) OBJECT_CHECK(FWCfgMemState, (obj), TYPE_FW_CFG_MEM)
 
+/* FW_CFG_VERSION bits */
+#define FW_CFG_VERSION  0x01
+#define FW_CFG_VERSION_DMA  0x02
+
+/* FW_CFG_DMA_CONTROL bits */
+#define FW_CFG_DMA_CTL_ERROR   0x01
+#define FW_CFG_DMA_CTL_READ0x02
+#define FW_CFG_DMA_CTL_SKIP0x04
+#define FW_CFG_DMA_CTL_SELECT  0x08
+
 typedef struct FWCfgEntry {
 uint32_t len;
 uint8_t *data;
@@ -59,6 +70,11 @@ struct FWCfgState {
 uint16_t cur_entry;
 uint32_t cur_offset;
 Notifier machine_ready;
+
+bool dma_enabled;
+dma_addr_t dma_addr;
+AddressSpace *dma_as;
+MemoryRegion dma_iomem;
 };
 
 struct FWCfgIoState {
@@ -67,7 +83,7 @@ struct FWCfgIoState {
 /*< public >*/
 
 MemoryRegion comb_iomem;
-uint32_t iobase;
+uint32_t iobase, dma_iobase;
 };
 
 struct FWCfgMemState {
@@ -292,6 +308,122 @@ static void fw_cfg_data_mem_write(void *opaque, hwaddr 
addr,
 } while (i);
 }
 
+static void fw_cfg_dma_transfer(FWCfgState *s)
+{
+dma_addr_t len;
+FWCfgDmaAccess dma;
+int arch;
+FWCfgEntry *e;
+int read;
+dma_addr_t dma_addr;
+
+/* Reset the address before the next access */
+dma_addr = s->dma_addr;
+s->dma_addr = 0;
+
+if (dma_memory_read(s->dma_as, dma_addr, &dma, sizeof(dma))) {
+stl_be_dma(s->dma_as, dma_addr + offsetof(FWCfgDmaAccess, control),
+   FW_CFG_DMA_CTL_ERROR);
+return;
+}
+
+dma.address = be64_to_cpu(dma.address);
+dma.length = be32_to_cpu(dma.length);
+dma.control = be32_to_cpu(dma.control);
+
+if (dma.control & FW_CFG_DMA_CTL_SELECT) {
+fw_cfg_select(s, dma.control >> 16);
+}
+
+arch = !!(s->cur_entry & FW_CFG_ARCH_LOCAL);
+e = &s->entries[arch][s->cur_entry & FW_CFG_ENTRY_MASK];
+
+if (dma.control & FW_CFG_DMA_CTL_READ) {
+read = 1;
+} else if (dma.control & FW_CFG_DMA_CTL_SKIP) {
+read = 0;
+} else {
+dma.length = 0;
+}
+
+dma.control = 0;
+
+while (dma.length > 0 && !(dma.control & FW_CFG_DMA_CTL_ERROR)) {
+if (s->cur_entry == FW_CFG_INVALID || !e->data ||
+s->cur_offset >= e->len) {
+len = dma.length;
+
+/* If the access is not a read access, it will be a skip access,
+ * tested before.
+ */
+if (read) {
+if (dma_memory_set(s->dma_as, dma.address, 0, len)) {
+dma.control |= FW_CFG_DMA_CTL_ERROR;
+}
+}
+
+} else {
+if (dma.length <= (e->len - s->cur_offset)) {
+len = dma.length;
+} else {
+len = (e->len - s->cur_offset);
+}
+
+if (e->read_callback) {
+e->read_callback(e->callback_opaque, s->cur_offset);
+}
+
+/* If the access is not a read access, it will be a skip access,
+ * tested before.
+ */
+if (read) {
+if (dma_memory_write(s->dma_as, dma.address,
+&e->data[s->cur_offset], len)) {
+dma.control |= FW_CFG_DMA_CTL_ERROR;
+}
+}
+
+s->cur_offset += len;
+}
+
+dma.address += len;
+dma.length  -= len;
+
+}
+
+stl_be_dma(s->

[Qemu-devel] Statically Compiling including SDL

[sai pavan]

Hi ,

I am trying to compile QEMU with --enable-sdl and --static. And i have
installed libsdl-dev.
I get the following error

ERROR: User requested feature sdl
   configure was not able to find it.
   Install SDL devel

Is there any know issue here ? or am i missing any more libraries.

FYI : Dynamic build is fine

Thanks,
Sai Pavan

Re: [Qemu-devel] [PATCH COLO-Frame v9 08/32] COLO/migration: establish a new communication path from destination to source

[zhanghailiang]

On 2015/10/19 17:54, Dr. David Alan Gilbert wrote:

* zhanghailiang (zhang.zhanghaili...@huawei.com) wrote:

Add a new member 'to_src_file' to MigrationIncomingState and a
new member 'from_dst_file' to MigrationState.
They will be used for returning messages from destination to source.
It will also be used by post-copy migration.

Signed-off-by: zhanghailiang 
Signed-off-by: Li Zhijian 
Cc: Dr. David Alan Gilbert 
---
  include/migration/migration.h |  3 ++-
  migration/colo.c  | 43 +++
  2 files changed, 45 insertions(+), 1 deletion(-)

diff --git a/include/migration/migration.h b/include/migration/migration.h
index 6488e03..0c94103 100644
--- a/include/migration/migration.h
+++ b/include/migration/migration.h
@@ -50,7 +50,7 @@ typedef QLIST_HEAD(, LoadStateEntry) LoadStateEntry_Head;
  /* State for the incoming migration */
  struct MigrationIncomingState {
  QEMUFile *from_src_file;
-
+QEMUFile *to_src_file;
  int state;

  bool have_colo_incoming_thread;
@@ -74,6 +74,7 @@ struct MigrationState
  QemuThread thread;
  QEMUBH *cleanup_bh;
  QEMUFile *to_dst_file;
+QEMUFile  *from_dst_file;
  int parameters[MIGRATION_PARAMETER_MAX];

  int state;
diff --git a/migration/colo.c b/migration/colo.c
index a341eee..5f4fb20 100644
--- a/migration/colo.c
+++ b/migration/colo.c
@@ -39,6 +39,20 @@ bool migration_incoming_in_colo_state(void)
  static void *colo_thread(void *opaque)
  {
  MigrationState *s = opaque;
+int fd, ret = 0;
+
+/* Dup the fd of to_dst_file */
+fd = dup(qemu_get_fd(s->to_dst_file));
+if (fd == -1) {
+ret = -errno;
+goto out;
+}
+s->from_dst_file = qemu_fopen_socket(fd, "rb");


In my postcopy code I add the return-path opening as a new
method on QEMUFile, that way if we get a return path working
on another transport (RDMA which I hope to do) then it
works;  have a look at 'Return path: Open a return path on QEMUFile for sockets'



I have looked at it. That's a good solution, we use the same fd for return 
path, and
i don't have to call qemu_file_shutdown two times in failover process.


+if (!s->from_dst_file) {
+ret = -EINVAL;
+error_report("Open QEMUFile failed!");


In errors, try to give detail of where a problem was;
e.g. 'colo_thread: Open QEMUFile from_dst failed'.



OK. I will fix it in next version.


+goto out;
+}

  qemu_mutex_lock_iothread();
  vm_start();
@@ -47,9 +61,17 @@ static void *colo_thread(void *opaque)

  /*TODO: COLO checkpoint savevm loop*/

+out:
+if (ret < 0) {
+error_report("Detect some error: %s", strerror(-ret));
+}


Again, best to say where the error happened.



Hmm, it is a little difficult to say where exactly this error happened here,
what i can do is to error out in the place where the error happened.
Here is only a summary for the error.




  migrate_set_state(&s->state, MIGRATION_STATUS_COLO,
MIGRATION_STATUS_COMPLETED);

+if (s->from_dst_file) {
+qemu_fclose(s->from_dst_file);
+}
+
  qemu_mutex_lock_iothread();
  qemu_bh_schedule(s->cleanup_bh);
  qemu_mutex_unlock_iothread();
@@ -86,12 +108,33 @@ void colo_init_checkpointer(MigrationState *s)
  void *colo_process_incoming_thread(void *opaque)
  {
  MigrationIncomingState *mis = opaque;
+int fd, ret = 0;

  migrate_set_state(&mis->state, MIGRATION_STATUS_ACTIVE,
MIGRATION_STATUS_COLO);

+fd = dup(qemu_get_fd(mis->from_src_file));
+if (fd < 0) {
+ret = -errno;
+goto out;
+}
+mis->to_src_file = qemu_fopen_socket(fd, "wb");
+if (!mis->to_src_file) {
+ret = -EINVAL;
+error_report("Can't open incoming channel!");
+goto out;
+}


Same as above.


OK. Will fix it.

Thanks,
zhanghailiang



  /* TODO: COLO checkpoint restore loop */

+out:
+if (ret < 0) {



+error_report("colo incoming thread will exit, detect error: %s",
+ strerror(-ret));
+}
+
+if (mis->to_src_file) {
+qemu_fclose(mis->to_src_file);
+}
  migration_incoming_exit_colo();

  return NULL;
--
1.8.3.1



--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

.

Re: [Qemu-devel] [PATCH v7 27/39] block: Add blk_remove_bs()

[Kevin Wolf]

Am 19.10.2015 um 17:53 hat Max Reitz geschrieben:
> This function removes the BlockDriverState associated with the given
> BlockBackend from that BB and sets the BDS pointer in the BB to NULL.
> 
> Signed-off-by: Max Reitz 
> ---
>  block/block-backend.c  | 12 
>  include/sysemu/block-backend.h |  1 +
>  2 files changed, 13 insertions(+)
> 
> diff --git a/block/block-backend.c b/block/block-backend.c
> index 19fdaae..eb7409c 100644
> --- a/block/block-backend.c
> +++ b/block/block-backend.c
> @@ -334,6 +334,18 @@ void blk_hide_on_behalf_of_hmp_drive_del(BlockBackend 
> *blk)
>  }
>  
>  /*
> + * Disassociates the currently associated BlockDriverState from @blk.
> + */
> +void blk_remove_bs(BlockBackend *blk)
> +{
> +blk_update_root_state(blk);
> +
> +bdrv_unref(blk->bs);
> +blk->bs->blk = NULL;

Use after free?

> +blk->bs = NULL;
> +}

Kevin

Re: [Qemu-devel] [PATCH 03/17] rbd: add support for getting password from QCryptoSecret object

[Daniel P. Berrange]

On Mon, Oct 19, 2015 at 03:57:29PM -0700, Josh Durgin wrote:
> On 10/19/2015 08:09 AM, Daniel P. Berrange wrote:
> >Currently RBD passwords must be provided on the command line
> >via
> >
> >   $QEMU -drive file=rbd:pool/image:id=myname:\
> > key=QVFDVm41aE82SHpGQWhBQXEwTkN2OGp0SmNJY0UrSE9CbE1RMUE=:\
> > auth_supported=cephx
> >
> >This is insecure because the key is visible in the OS process
> >listing.
> >
> >This adds support for an 'authsecret' parameter in the RBD
> >parameters that can be used with the QCryptoSecret object to
> >provide the password via a file:
> >
> >   echo "QVFDVm41aE82SHpGQWhBQXEwTkN2OGp0SmNJY0UrSE9CbE1RMUE=" > poolkey.b64
> >   $QEMU -object secret,id=secret0,file=poolkey.b64,format=base64 \
> >   -drive file=rbd:pool/image:id=myname:\
> >   auth_supported=cephx,authsecret=secret0
> >
> >Signed-off-by: Daniel P. Berrange 
> >---
> 
> Looks good in general, thanks for fixing this! Just one thing to fix
> below.
> 
> >  block/rbd.c | 42 ++
> >  1 file changed, 42 insertions(+)
> >
> >diff --git a/block/rbd.c b/block/rbd.c
> >index a60a19d..0acf777 100644
> >--- a/block/rbd.c
> >+++ b/block/rbd.c
> >@@ -16,6 +16,7 @@
> >  #include "qemu-common.h"
> >  #include "qemu/error-report.h"
> >  #include "block/block_int.h"
> >+#include "crypto/secret.h"
> >
> >  #include 
> >
> >@@ -228,6 +229,23 @@ static char *qemu_rbd_parse_clientname(const char 
> >*conf, char *clientname)
> >  return NULL;
> >  }
> >
> >+
> >+static int qemu_rbd_set_auth(rados_t cluster, const char *secretid,
> >+ Error **errp)
> >+{
> >+gchar *secret = qcrypto_secret_lookup_as_base64(secretid,
> >+errp);
> >+if (!secret) {
> >+return -1;
> >+}
> 
> It looks like this fails if no authsecret is provided. Ceph auth can be
> disabled, so it seems like we should skip the qemu_rbd_set_auth() calls
> in this case.

This failure scenario happens if the user provides a key ID, but the
corresponding QCryptoSecret does not exist. This is a usage error
by the user, so it is appropriate to have it be a fatal error.
In the case that they don't want any auth, they can just leave out
the keyid parameter.

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] Statically Compiling including SDL

[Peter Maydell]

On 20 October 2015 at 07:59, sai pavan  wrote:
> Hi ,
>
> I am trying to compile QEMU with --enable-sdl and --static. And i have
> installed libsdl-dev.
> I get the following error
>
> ERROR: User requested feature sdl
>configure was not able to find it.
>Install SDL devel
>
> Is there any know issue here ? or am i missing any more libraries.

This probably means you haven't installed the static library
version of libsdl, or possibly that your distro's static libsdl
packaging is broken. You can look at config.log to see what
test program command line configure was trying that didn't work.
You can also look in the configure script itself to see what
our libsdl test is checking for.

thanks
-- PMM

[Qemu-devel] [PULL 1/3] usb-host: add wakeup call for iso xfers

[Gerd Hoffmann]

Signed-off-by: Gerd Hoffmann 
---
 hw/usb/host-libusb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/usb/host-libusb.c b/hw/usb/host-libusb.c
index 5e492fd..7695a97 100644
--- a/hw/usb/host-libusb.c
+++ b/hw/usb/host-libusb.c
@@ -451,6 +451,7 @@ static void usb_host_req_complete_iso(struct 
libusb_transfer *transfer)
 }
 if (xfer->ring->ep->pid == USB_TOKEN_IN) {
 QTAILQ_INSERT_TAIL(&xfer->ring->copy, xfer, next);
+usb_wakeup(xfer->ring->ep, 0);
 } else {
 QTAILQ_INSERT_TAIL(&xfer->ring->unused, xfer, next);
 }
-- 
1.8.3.1

Re: [Qemu-devel] [PATCH] vmxnet3: Do not fill stats if device is inactive

[Jason Wang]

On 10/20/2015 03:11 PM, Dmitry Fleytman wrote:
> Hi Jason,
>
> Sure. No problem.
>
> Acked-by: Dmitry Fleytman mailto:dmi...@daynix.com>>
>
> Dmitry.

Thanks.

>
>> On 20 Oct 2015, at 06:08 AM, Jason Wang > > wrote:
>>
>>
>>
>> On 10/18/2015 03:16 PM, Dmitry Fleytman wrote:
>>> ACK
>>
>> Hi Dmitry:
>>
>> Thanks a lot for the reviewing.
>>
>> As I want to add your "Acked-by" in the patch, could you pls add a
>> formal one in the future? (Which can make my life a little bit easier).
>>
 On 15 Oct 2015, at 13:54 PM, Dana Rubin
 >>> > wrote:

 From: Shmulik Ladkani >>> >

 Guest OS may issue VMXNET3_CMD_GET_STATS even before device was
 activated (for example in linux, after insmod but prior net-dev open).

 Accessing shared descriptors prior device activation is illegal as the
 VMXNET3State structures have not been fully initialized.

 As a result, guest memory gets corrupted and may lead to guest OS
 crashes.

 Fix, by not filling the stats descriptors if device is inactive.

 Reported-by: Leonid Shatz >>> >
 Signed-off-by: Dana Rubin >>> >
 Signed-off-by: Shmulik Ladkani >>> >
 ---
 hw/net/vmxnet3.c | 4 
 1 file changed, 4 insertions(+)

 diff --git a/hw/net/vmxnet3.c b/hw/net/vmxnet3.c
 index 3c5e10d..5e3a233 100644
 --- a/hw/net/vmxnet3.c
 +++ b/hw/net/vmxnet3.c
 @@ -1289,6 +1289,10 @@ static uint32_t
 vmxnet3_get_interrupt_config(VMXNET3State *s)
 static void vmxnet3_fill_stats(VMXNET3State *s)
 {
int i;
 +
 +if (!s->device_active)
 +return;
 +
for (i = 0; i < s->txq_num; i++) {
cpu_physical_memory_write(s->txq_descr[i].tx_stats_pa,
  &s->txq_descr[i].txq_stats,
 -- 
 1.9.1

>>>
>>
>

[Qemu-devel] [PULL 2/3] usb: print device id in "info usb" monitor command

[Gerd Hoffmann]

Signed-off-by: Gerd Hoffmann 
---
 hw/usb/bus.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/hw/usb/bus.c b/hw/usb/bus.c
index 5f39e1e..ee6b43a 100644
--- a/hw/usb/bus.c
+++ b/hw/usb/bus.c
@@ -655,9 +655,12 @@ void hmp_info_usb(Monitor *mon, const QDict *qdict)
 dev = port->dev;
 if (!dev)
 continue;
-monitor_printf(mon, "  Device %d.%d, Port %s, Speed %s Mb/s, 
Product %s\n",
-   bus->busnr, dev->addr, port->path, 
usb_speed(dev->speed),
-   dev->product_desc);
+monitor_printf(mon, "  Device %d.%d, Port %s, Speed %s Mb/s, "
+   "Product %s%s%s\n",
+   bus->busnr, dev->addr, port->path,
+   usb_speed(dev->speed), dev->product_desc,
+   dev->qdev.id ? ", ID: " : "",
+   dev->qdev.id ?: "");
 }
 }
 }
-- 
1.8.3.1

Re: [Qemu-devel] [PATCH v9 04/17] vnc: hoist allocation of VncBasicInfo to callers

[Gerd Hoffmann]

  Hi,

> > -static VncBasicInfo *vnc_basic_info_get(struct sockaddr_storage *sa,
> > -socklen_t salen)
> > +static void vnc_basic_info_get(struct sockaddr_storage *sa,
> > +   socklen_t salen,
> > +   VncBasicInfo *info,
> > +   Error **errp)

> The function no longer "gets info", it merely initializes it.  Rename it
> accordingly?  Gerd?

vnc_fill_basic_info maybe?

> Outside this patch's scope, but since I'm looking at the code already...
> 
> Here's the only caller of vnc_server_info_get():
> 
> static void vnc_qmp_event(VncState *vs, QAPIEvent event)
> {
> VncServerInfo *si;
> 
> if (!vs->info) {
> return;
> }
> g_assert(vs->info->base);
> 
> si = vnc_server_info_get(vs->vd);
> if (!si) {
> --->return;
> }
> 
> switch (event) {
> case QAPI_EVENT_VNC_CONNECTED:
> qapi_event_send_vnc_connected(si, vs->info->base, &error_abort);
> break;
> case QAPI_EVENT_VNC_INITIALIZED:
> qapi_event_send_vnc_initialized(si, vs->info, &error_abort);
> break;
> case QAPI_EVENT_VNC_DISCONNECTED:
> qapi_event_send_vnc_disconnected(si, vs->info, &error_abort);
> break;
> default:
> break;
> }
> 
> qapi_free_VncServerInfo(si);
> }
> 
> When vnc_server_info_get() fails, the event is dropped.  Why is that
> okay?  Failure seems unlikely, though.

Suggestions what else to do?  I don't wanna crash qemu by calling
qapi_event_send_vnc_* with a NULL pointer.  And, yes, it should be
highly unlikely so trying some more sophisticated error handling would
probably be dead code ...

cheers,
  Gerd

Re: [Qemu-devel] [PATCH 0/6] e1000: Various fixes and registers' implementation

[Jason Wang]

On 10/18/2015 03:53 PM, Leonid Bloch wrote:
> This series fixes several issues with incorrect packet/octet counting in
> e1000's Statistic registers, fixes a bug in the packet address filtering
> procedure, and implements many MAC registers that were absent before.
> Additionally, some cosmetic changes are made.
>
> Leonid Bloch (6):
>   e1000: Cosmetic and alignment fixes
>   e1000: Trivial implementation of various MAC registers
>   e1000: Fixing the received/transmitted packets' counters
>   e1000: Fixing the received/transmitted octets' counters
>   e1000: Fixing the packet address filtering procedure
>   e1000: Implementing various counters
>
>  hw/net/e1000.c  | 313 
> ++--
>  hw/net/e1000_regs.h |   8 +-
>  2 files changed, 236 insertions(+), 85 deletions(-)
>

Looks good to me overall, just few comments in individual patches.

A question here, is there any real user/OSes that tries to use those
registers? If not, maintain them sees a burden and it's a little bit
hard the test them unless unit-test were implemented for those
registers. And I'd like to know the test status of this series. At least
both windows and linux guest need to be tested.

Thanks

[Qemu-devel] [PATCH v3 5/5] virtio-9p: add savem handlers

[Greg Kurz]

We don't support migration of mounted 9p shares. This is handled by a
migration blocker.

One would expect, however, to be able to migrate if the share is unmounted.
Unfortunately virtio-9p-device does not register savevm handlers at all !
Migration succeeds and leaves the guest with a dangling device...

This patch simply registers migration handlers for virtio-9p-device. Whether
migration is possible or not still depends on the migration blocker.

Signed-off-by: Greg Kurz 
---
 hw/9pfs/virtio-9p-device.c |   12 
 1 file changed, 12 insertions(+)

diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c
index ed133c40493a..bd7f10a0a902 100644
--- a/hw/9pfs/virtio-9p-device.c
+++ b/hw/9pfs/virtio-9p-device.c
@@ -43,6 +43,16 @@ static void virtio_9p_get_config(VirtIODevice *vdev, uint8_t 
*config)
 g_free(cfg);
 }
 
+static void virtio_9p_save(QEMUFile *f, void *opaque)
+{
+virtio_save(VIRTIO_DEVICE(opaque), f);
+}
+
+static int virtio_9p_load(QEMUFile *f, void *opaque, int version_id)
+{
+return virtio_load(VIRTIO_DEVICE(opaque), f, version_id);
+}
+
 static void virtio_9p_device_realize(DeviceState *dev, Error **errp)
 {
 VirtIODevice *vdev = VIRTIO_DEVICE(dev);
@@ -130,6 +140,7 @@ static void virtio_9p_device_realize(DeviceState *dev, 
Error **errp)
 }
 v9fs_path_free(&path);
 
+register_savevm(dev, "virtio-9p", -1, 1, virtio_9p_save, virtio_9p_load, 
s);
 return;
 out:
 g_free(s->ctx.fs_root);
@@ -146,6 +157,7 @@ static void virtio_9p_device_unrealize(DeviceState *dev, 
Error **errp)
 v9fs_release_worker_threads();
 g_free(s->ctx.fs_root);
 g_free(s->tag);
+unregister_savevm(dev, "virtio-9p", s);
 virtio_cleanup(vdev);
 }
 

[Qemu-devel] [PATCH v3 4/5] virtio-9p: add unrealize handler

[Greg Kurz]

This patch allows to hot-unplug a quiescent virtio-9p device, and free its
allocated resources. A refcount is added to the v9fs thread pool, so that
its resources are freed as well when the last virtio-9p device is unplugged.

Note that we have an unplug blocker which prevents this code to be reached
if the 9p share is mounted in the guest. No need to bother about in-flight
I/O requests in this case.

This patch fixes a QEMU crash on the source node if the user device_add
a virtio-9p device and then migrate.

Signed-off-by: Greg Kurz 
---
 hw/9pfs/virtio-9p-coth.c   |   15 ++-
 hw/9pfs/virtio-9p-coth.h   |2 ++
 hw/9pfs/virtio-9p-device.c |   12 
 3 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/hw/9pfs/virtio-9p-coth.c b/hw/9pfs/virtio-9p-coth.c
index 1d832ede1ebf..27ccc66c91d8 100644
--- a/hw/9pfs/virtio-9p-coth.c
+++ b/hw/9pfs/virtio-9p-coth.c
@@ -55,7 +55,7 @@ int v9fs_init_worker_threads(void)
 V9fsThPool *p = &v9fs_pool;
 sigset_t set, oldset;
 
-if (p->pool) {
+if (p->refcount++) {
 return 0;
 }
 
@@ -81,3 +81,16 @@ err_out:
 pthread_sigmask(SIG_SETMASK, &oldset, NULL);
 return ret;
 }
+
+void v9fs_release_worker_threads(void)
+{
+V9fsThPool *p = &v9fs_pool;
+
+if (--p->refcount) {
+return;
+}
+
+g_thread_pool_free(p->pool, TRUE, TRUE);
+g_async_queue_unref(p->completed);
+event_notifier_set_handler(&p->e, NULL);
+}
diff --git a/hw/9pfs/virtio-9p-coth.h b/hw/9pfs/virtio-9p-coth.h
index 4f51b250d1d4..2a2617e670a5 100644
--- a/hw/9pfs/virtio-9p-coth.h
+++ b/hw/9pfs/virtio-9p-coth.h
@@ -25,6 +25,7 @@ typedef struct V9fsThPool {
 
 GThreadPool *pool;
 GAsyncQueue *completed;
+unsigned refcount;
 } V9fsThPool;
 
 /*
@@ -56,6 +57,7 @@ typedef struct V9fsThPool {
 
 extern void co_run_in_worker_bh(void *);
 extern int v9fs_init_worker_threads(void);
+extern void v9fs_release_worker_threads(void);
 extern int v9fs_co_readlink(V9fsPDU *, V9fsPath *, V9fsString *);
 extern int v9fs_co_readdir_r(V9fsPDU *, V9fsFidState *,
struct dirent *, struct dirent **result);
diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c
index 93a407c45926..ed133c40493a 100644
--- a/hw/9pfs/virtio-9p-device.c
+++ b/hw/9pfs/virtio-9p-device.c
@@ -138,6 +138,17 @@ out:
 v9fs_path_free(&path);
 }
 
+static void virtio_9p_device_unrealize(DeviceState *dev, Error **errp)
+{
+VirtIODevice *vdev = VIRTIO_DEVICE(dev);
+V9fsState *s = VIRTIO_9P(dev);
+
+v9fs_release_worker_threads();
+g_free(s->ctx.fs_root);
+g_free(s->tag);
+virtio_cleanup(vdev);
+}
+
 /* virtio-9p device */
 
 static Property virtio_9p_properties[] = {
@@ -154,6 +165,7 @@ static void virtio_9p_class_init(ObjectClass *klass, void 
*data)
 dc->props = virtio_9p_properties;
 set_bit(DEVICE_CATEGORY_STORAGE, dc->categories);
 vdc->realize = virtio_9p_device_realize;
+vdc->unrealize = virtio_9p_device_unrealize;
 vdc->get_features = virtio_9p_get_features;
 vdc->get_config = virtio_9p_get_config;
 }

Re: [Qemu-devel] [PATCH 1/2] vl: trivial: minor tweaks to a max-cpu error msg

[Markus Armbruster]

Andrew Jones  writes:

> Signed-off-by: Andrew Jones 
> ---
>  vl.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/vl.c b/vl.c
> index 7c806a2428399..9a64b75ebbd24 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -4080,8 +4080,8 @@ int main(int argc, char **argv, char **envp)
>  
>  machine_class->max_cpus = machine_class->max_cpus ?: 1; /* Default to UP 
> */
>  if (max_cpus > machine_class->max_cpus) {
> -fprintf(stderr, "Number of SMP cpus requested (%d), exceeds max cpus 
> "
> -"supported by machine `%s' (%d)\n", max_cpus,
> +fprintf(stderr, "Number of SMP CPUs requested (%d) exceeds max CPUs "
> +"supported by machine '%s' (%d)\n", max_cpus,
>  machine_class->name, machine_class->max_cpus);
>  exit(1);
>  }

While you're touching this, error_report(), please.

[Qemu-devel] [PATCH v3 2/5] qdev: add the @unplug_is_blocked handler

[Greg Kurz]

This handler allows to ask a device instance if it can be hot-unplugged. It
is to be defined in device classes where hot-unpluggability depends on the
device state (for example, virtio-9p devices cannot be unplugged if the 9p
share is mounted in the guest).

Signed-off-by: Greg Kurz 
---
 hw/core/qdev.c |4 
 include/hw/qdev-core.h |4 
 2 files changed, 8 insertions(+)

diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index 4ab04aa31e78..b37a3801117a 100644
--- a/hw/core/qdev.c
+++ b/hw/core/qdev.c
@@ -287,6 +287,10 @@ void qdev_unplug(DeviceState *dev, Error **errp)
 return;
 }
 
+if (dc->unplug_is_blocked && !dc->unplug_is_blocked(dev, errp)) {
+return;
+}
+
 qdev_hot_removed = true;
 
 hotplug_ctrl = qdev_get_hotplug_handler(dev);
diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
index 8057aedaa6c0..a65d2be6f39b 100644
--- a/include/hw/qdev-core.h
+++ b/include/hw/qdev-core.h
@@ -38,6 +38,7 @@ typedef void (*DeviceRealize)(DeviceState *dev, Error **errp);
 typedef void (*DeviceUnrealize)(DeviceState *dev, Error **errp);
 typedef void (*BusRealize)(BusState *bus, Error **errp);
 typedef void (*BusUnrealize)(BusState *bus, Error **errp);
+typedef bool (*HotUnplugBlocked)(DeviceState *dev, Error **errp);
 
 struct VMStateDescription;
 
@@ -48,6 +49,8 @@ struct VMStateDescription;
  * property is changed to %true. The default invokes @init if not %NULL.
  * @unrealize: Callback function invoked when the #DeviceState:realized
  * property is changed to %false.
+ * @unplug_is_blocked: Callback function invoked by qdev_unplug(). Return 
%false
+ * to block hotunplug.
  * @init: Callback function invoked when the #DeviceState::realized property
  * is changed to %true. Deprecated, new types inheriting directly from
  * TYPE_DEVICE should use @realize instead, new leaf types should consult
@@ -133,6 +136,7 @@ typedef struct DeviceClass {
 void (*reset)(DeviceState *dev);
 DeviceRealize realize;
 DeviceUnrealize unrealize;
+HotUnplugBlocked unplug_is_blocked;
 
 /* device state */
 const struct VMStateDescription *vmsd;

[Qemu-devel] [PATCH v3 3/5] virtio-9p: block hot-unplug when device is active

[Greg Kurz]

Hot-unplug of an active virtio-9p device is not currently supported. Until
we have that, let's block hot-unplugging when the 9p share is mounted in
the guest.

This patch implements a hot-unplug blocker feature like we already have for
migration. Both virtio-9p-pci and virtio-9p-ccw were adapted accordingly.

Signed-off-by: Greg Kurz 
---
 hw/9pfs/virtio-9p.c|   14 ++
 hw/9pfs/virtio-9p.h|2 ++
 hw/s390x/virtio-ccw.c  |8 
 hw/virtio/virtio-pci.c |8 
 4 files changed, 32 insertions(+)

diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9p.c
index f972731f5a8d..bbf39ed33983 100644
--- a/hw/9pfs/virtio-9p.c
+++ b/hw/9pfs/virtio-9p.c
@@ -345,6 +345,7 @@ static int put_fid(V9fsPDU *pdu, V9fsFidState *fidp)
 migrate_del_blocker(pdu->s->migration_blocker);
 error_free(pdu->s->migration_blocker);
 pdu->s->migration_blocker = NULL;
+pdu->s->unplug_is_blocked = false;
 }
 }
 return free_fid(pdu, fidp);
@@ -991,6 +992,7 @@ static void v9fs_attach(void *opaque)
"Migration is disabled when VirtFS export path '%s' is 
mounted in the guest using mount_tag '%s'",
s->ctx.fs_root ? s->ctx.fs_root : "NULL", s->tag);
 migrate_add_blocker(s->migration_blocker);
+s->unplug_is_blocked = true;
 }
 out:
 put_fid(pdu, fidp);
@@ -3288,6 +3290,18 @@ void handle_9p_output(VirtIODevice *vdev, VirtQueue *vq)
 free_pdu(s, pdu);
 }
 
+bool v9fs_unplug_is_blocked(V9fsState *s, Error **errp)
+{
+if (s->unplug_is_blocked) {
+error_setg(errp,
+   "Unplug is disabled when VirtFS export path '%s' is mounted"
+   " in the guest using mount_tag '%s'",
+   s->ctx.fs_root ? s->ctx.fs_root : "NULL", s->tag);
+return false;
+}
+return true;
+}
+
 static void __attribute__((__constructor__)) virtio_9p_set_fd_limit(void)
 {
 struct rlimit rlim;
diff --git a/hw/9pfs/virtio-9p.h b/hw/9pfs/virtio-9p.h
index 2e7d48857083..8d4cbed2a5c4 100644
--- a/hw/9pfs/virtio-9p.h
+++ b/hw/9pfs/virtio-9p.h
@@ -218,6 +218,7 @@ typedef struct V9fsState
 CoRwlock rename_lock;
 int32_t root_fid;
 Error *migration_blocker;
+bool unplug_is_blocked;
 V9fsConf fsconf;
 } V9fsState;
 
@@ -381,6 +382,7 @@ extern void v9fs_path_free(V9fsPath *path);
 extern void v9fs_path_copy(V9fsPath *lhs, V9fsPath *rhs);
 extern int v9fs_name_to_path(V9fsState *s, V9fsPath *dirpath,
  const char *name, V9fsPath *path);
+extern bool v9fs_unplug_is_blocked(V9fsState *s, Error **errp);
 
 #define pdu_marshal(pdu, offset, fmt, args...)  \
 v9fs_marshal(pdu->elem.in_sg, pdu->elem.in_num, offset, 1, fmt, ##args)
diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c
index fb103b78ac28..5c13072ec96e 100644
--- a/hw/s390x/virtio-ccw.c
+++ b/hw/s390x/virtio-ccw.c
@@ -1924,6 +1924,13 @@ static void virtio_ccw_9p_realize(VirtioCcwDevice 
*ccw_dev, Error **errp)
 }
 }
 
+static bool virtio_ccw_9p_unplug_is_blocked(DeviceState *dev, Error **errp)
+{
+V9fsCCWState *v9fs_ccw_dev = VIRTIO_9P_CCW(dev);
+
+return v9fs_unplug_is_blocked(&v9fs_ccw_dev->vdev, errp);
+}
+
 static void virtio_ccw_9p_class_init(ObjectClass *klass, void *data)
 {
 DeviceClass *dc = DEVICE_CLASS(klass);
@@ -1931,6 +1938,7 @@ static void virtio_ccw_9p_class_init(ObjectClass *klass, 
void *data)
 
 k->exit = virtio_ccw_exit;
 k->realize = virtio_ccw_9p_realize;
+dc->unplug_is_blocked = virtio_ccw_9p_unplug_is_blocked;
 dc->reset = virtio_ccw_reset;
 dc->props = virtio_ccw_9p_properties;
 set_bit(DEVICE_CATEGORY_STORAGE, dc->categories);
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index e5c406d1d255..bf0d516528ee 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -1015,6 +1015,13 @@ static void virtio_9p_pci_realize(VirtIOPCIProxy 
*vpci_dev, Error **errp)
 object_property_set_bool(OBJECT(vdev), true, "realized", errp);
 }
 
+static bool virtio_9p_pci_unplug_is_blocked(DeviceState *dev, Error **errp)
+{
+V9fsPCIState *v9fs_pci_dev = VIRTIO_9P_PCI(dev);
+
+return v9fs_unplug_is_blocked(&v9fs_pci_dev->vdev, errp);
+}
+
 static Property virtio_9p_pci_properties[] = {
 DEFINE_PROP_BIT("ioeventfd", VirtIOPCIProxy, flags,
 VIRTIO_PCI_FLAG_USE_IOEVENTFD_BIT, true),
@@ -1035,6 +1042,7 @@ static void virtio_9p_pci_class_init(ObjectClass *klass, 
void *data)
 pcidev_k->class_id = 0x2;
 set_bit(DEVICE_CATEGORY_STORAGE, dc->categories);
 dc->props = virtio_9p_pci_properties;
+dc->unplug_is_blocked = virtio_9p_pci_unplug_is_blocked;
 }
 
 static void virtio_9p_pci_instance_init(Object *obj)

Re: [Qemu-devel] [PULL v4 00/14] qemu-ga patch queue

[Peter Maydell]

On 20 October 2015 at 00:38, Michael Roth  wrote:
> Hi Peter,
>
> Please note that 'glib-compat: add 2.38/2.40/2.46 asserts' is also in
> Marc-André's recent ivshmem PULL. The 2 versions of the patches are identical,
> but let me know if you'd prefer a re-send/re-base later.
>
> The following changes since commit 26c7be842637ee65a79cd77f96a99c23ddcd90ad:
>
>   Merge remote-tracking branch 'remotes/sstabellini/tags/2015-10-19-tag' into 
> staging (2015-10-19 12:13:27 +0100)
>
> are available in the git repository at:
>
>
>   git://github.com/mdroth/qemu.git tags/qga-pull-2015-10-14-v4-tag
>
> for you to fetch changes up to e853ea1cc68716c3d9c22d04578020c6dd743306:
>
>   qga: fix uninitialized value warning for win32 (2015-10-19 18:31:54 -0500)
>
> 
> qemu-ga patch queue
>
> * add unit tests for qemu-ga
> * add guest-exec support for posix/w32 guests
> * added 'qemu-ga' target for w32. this allows us to do full MSI build,
>   without overloading 'qemu-ga.exe' target with uneeded dependencies.
> * number of s/g_new/g_malloc/ conversions for qga
>
> v2:
> * commit message and qapi documentation spelling fixes
> * rename 'inp-data' guest-exec param to 'input-data'
>
> v3:
> * fix OSX build errors for test-qga by using PRId64
>   format in place of glib's, and dropping use of G_SPAWN_DEFAULT
>   macro for glib 2.22 compat
> * fix win32 build warnings for 32-bit builds by avoid int casts
>   of process HANDLEs
>
> v4:
> * assert connect_qga() doesn't fail
> * only enable test-qga for linux hosts
> * allow get-memory-block-info* to fail if memory blocks aren't exposed in
>   sysfs
>

Applied, thanks.

-- PMM

[Qemu-devel] [RFC PATCH v2 4/5] kvm_arm: Implement support for ITS emulation by KVM

[Pavel Fedin]

This patch relies on new kernel API which is not released yet.

Signed-off-by: Pavel Fedin 
---
 hw/intc/Makefile.objs  |  1 +
 hw/intc/arm_gicv3_its_common.c |  2 +-
 hw/intc/arm_gicv3_its_kvm.c| 88 ++
 3 files changed, 90 insertions(+), 1 deletion(-)
 create mode 100644 hw/intc/arm_gicv3_its_kvm.c

diff --git a/hw/intc/Makefile.objs b/hw/intc/Makefile.objs
index 2d6543b..8d5 100644
--- a/hw/intc/Makefile.objs
+++ b/hw/intc/Makefile.objs
@@ -19,6 +19,7 @@ common-obj-$(CONFIG_OPENPIC) += openpic.o
 obj-$(CONFIG_APIC) += apic.o apic_common.o
 obj-$(CONFIG_ARM_GIC_KVM) += arm_gic_kvm.o
 obj-$(call land,$(CONFIG_ARM_GIC_KVM),$(TARGET_AARCH64)) += arm_gicv3_kvm.o
+obj-$(call land,$(CONFIG_ARM_GIC_KVM),$(TARGET_AARCH64)) += arm_gicv3_its_kvm.o
 obj-$(CONFIG_STELLARIS) += armv7m_nvic.o
 obj-$(CONFIG_EXYNOS4) += exynos4210_gic.o exynos4210_combiner.o
 obj-$(CONFIG_GRLIB) += grlib_irqmp.o
diff --git a/hw/intc/arm_gicv3_its_common.c b/hw/intc/arm_gicv3_its_common.c
index 17a38a6..2f9abfb 100644
--- a/hw/intc/arm_gicv3_its_common.c
+++ b/hw/intc/arm_gicv3_its_common.c
@@ -69,7 +69,7 @@ static MemTxResult gicv3_its_trans_write(void *opaque, hwaddr 
offset,
 if (offset == 0x0040) {
 GICv3ITSState *s = ARM_GICV3_ITS_COMMON(opaque);
 GICv3ITSCommonClass *c = ARM_GICV3_ITS_COMMON_GET_CLASS(s);
-int ret = c->send_msi(s, le32_to_cpu(value), attrs.stream_id);
+int ret = c->send_msi(s, le32_to_cpu(value), attrs.requester_id);
 
 if (ret) {
 qemu_log_mask(LOG_GUEST_ERROR,
diff --git a/hw/intc/arm_gicv3_its_kvm.c b/hw/intc/arm_gicv3_its_kvm.c
new file mode 100644
index 000..62323c6
--- /dev/null
+++ b/hw/intc/arm_gicv3_its_kvm.c
@@ -0,0 +1,88 @@
+/*
+ * KVM-based ITS implementation for a GICv3-based system
+ *
+ * Copyright (c) 2015 Samsung Electronics Co., Ltd.
+ * Written by Pavel Fedin 
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library 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
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see .
+ */
+
+#include "hw/intc/arm_gicv3_its_common.h"
+#include "sysemu/kvm.h"
+#include "kvm_arm.h"
+
+#define TYPE_KVM_ARM_ITS "arm-its-kvm"
+#define KVM_ARM_ITS(obj) OBJECT_CHECK(GICv3ITSState, (obj), TYPE_KVM_ARM_ITS)
+
+static int kvm_its_send_msi(GICv3ITSState *s, uint32_t value, uint16_t devid)
+{
+struct kvm_msi msi;
+
+msi.address_lo = 0x0040;
+msi.address_hi = 0;
+msi.data = value;
+msi.flags = KVM_MSI_VALID_DEVID;
+msi.devid = devid;
+memset(msi.pad, 0, sizeof(msi.pad));
+
+return kvm_vm_ioctl(kvm_state, KVM_SIGNAL_MSI, &msi);
+}
+
+static void kvm_arm_its_realize(DeviceState *dev, Error **errp)
+{
+GICv3ITSState *s = ARM_GICV3_ITS_COMMON(dev);
+
+gicv3_its_init_mmio(s, NULL);
+kvm_arm_register_device(&s->iomem_its_cntrl, -1, KVM_DEV_ARM_VGIC_GRP_ADDR,
+KVM_VGIC_V3_ADDR_TYPE_ITS, s->gicv3->dev_fd);
+
+kvm_arm_msi_use_devid = true;
+kvm_gsi_routing_allowed = kvm_has_gsi_routing();
+kvm_msi_via_irqfd_allowed = kvm_gsi_routing_allowed;
+}
+
+static void kvm_arm_its_init(Object *obj)
+{
+GICv3ITSState *s = KVM_ARM_ITS(obj);
+
+object_property_add_link(obj, "parent-gicv3",
+ "kvm-arm-gicv3", (Object **)&s->gicv3,
+ object_property_allow_set_link,
+ OBJ_PROP_LINK_UNREF_ON_RELEASE,
+ &error_abort);
+}
+
+static void kvm_arm_its_class_init(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+GICv3ITSCommonClass *icc = ARM_GICV3_ITS_COMMON_CLASS(klass);
+
+dc->realize = kvm_arm_its_realize;
+icc->send_msi = kvm_its_send_msi;
+}
+
+static const TypeInfo kvm_arm_its_info = {
+.name = TYPE_KVM_ARM_ITS,
+.parent = TYPE_ARM_GICV3_ITS_COMMON,
+.instance_size = sizeof(GICv3ITSState),
+.instance_init = kvm_arm_its_init,
+.class_init = kvm_arm_its_class_init,
+};
+
+static void kvm_arm_its_register_types(void)
+{
+type_register_static(&kvm_arm_its_info);
+}
+
+type_init(kvm_arm_its_register_types)
-- 
2.4.4

[Qemu-devel] [RFC PATCH v2 1/5] hw/intc: Implement ITS base class

[Pavel Fedin]

This is the basic skeleton for both KVM and software-emulated ITS.

Signed-off-by: Pavel Fedin 
---
 hw/intc/Makefile.objs  |   1 +
 hw/intc/arm_gicv3_its_common.c | 154 +
 include/hw/intc/arm_gicv3_its_common.h |  72 +++
 target-arm/kvm_arm.h   |  10 +++
 target-arm/machine.c   |  16 
 5 files changed, 253 insertions(+)
 create mode 100644 hw/intc/arm_gicv3_its_common.c
 create mode 100644 include/hw/intc/arm_gicv3_its_common.h

diff --git a/hw/intc/Makefile.objs b/hw/intc/Makefile.objs
index 004b0c2..2d6543b 100644
--- a/hw/intc/Makefile.objs
+++ b/hw/intc/Makefile.objs
@@ -13,6 +13,7 @@ common-obj-$(CONFIG_ARM_GIC) += arm_gic_common.o
 common-obj-$(CONFIG_ARM_GIC) += arm_gic.o
 common-obj-$(CONFIG_ARM_GIC) += arm_gicv2m.o
 common-obj-$(CONFIG_ARM_GIC) += arm_gicv3_common.o
+common-obj-$(CONFIG_ARM_GIC) += arm_gicv3_its_common.o
 common-obj-$(CONFIG_OPENPIC) += openpic.o
 
 obj-$(CONFIG_APIC) += apic.o apic_common.o
diff --git a/hw/intc/arm_gicv3_its_common.c b/hw/intc/arm_gicv3_its_common.c
new file mode 100644
index 000..17a38a6
--- /dev/null
+++ b/hw/intc/arm_gicv3_its_common.c
@@ -0,0 +1,154 @@
+/*
+ * ITS base class for a GICv3-based system
+ *
+ * Copyright (c) 2015 Samsung Electronics Co., Ltd.
+ * Written by Pavel Fedin
+ *
+ * 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 .
+ */
+
+#include "hw/pci/msi.h"
+#include "hw/intc/arm_gicv3_its_common.h"
+
+static void gicv3_its_pre_save(void *opaque)
+{
+GICv3ITSState *s = (GICv3ITSState *)opaque;
+GICv3ITSCommonClass *c = ARM_GICV3_ITS_COMMON_GET_CLASS(s);
+
+if (c->pre_save) {
+c->pre_save(s);
+}
+}
+
+static int gicv3_its_post_load(void *opaque, int version_id)
+{
+GICv3ITSState *s = (GICv3ITSState *)opaque;
+GICv3ITSCommonClass *c = ARM_GICV3_ITS_COMMON_GET_CLASS(s);
+
+if (c->post_load) {
+c->post_load(s);
+}
+return 0;
+}
+
+static const VMStateDescription vmstate_its = {
+.name = "arm_gicv3_its",
+.pre_save = gicv3_its_pre_save,
+.post_load = gicv3_its_post_load,
+.fields = (VMStateField[]) {
+VMSTATE_UINT32(ctlr, GICv3ITSState),
+VMSTATE_UINT64(cbaser, GICv3ITSState),
+VMSTATE_UINT64(cwriter, GICv3ITSState),
+VMSTATE_UINT64(creadr, GICv3ITSState),
+VMSTATE_UINT64_ARRAY(baser, GICv3ITSState, 8),
+VMSTATE_END_OF_LIST()
+}
+};
+
+static uint64_t gicv3_its_trans_read(void *opaque, hwaddr offset, unsigned 
size)
+{
+qemu_log_mask(LOG_GUEST_ERROR, "ITS read at offset 0x%jX\n", offset);
+return ~0ULL;
+}
+
+static MemTxResult gicv3_its_trans_write(void *opaque, hwaddr offset,
+ uint64_t value, unsigned size,
+ MemTxAttrs attrs)
+{
+if (offset == 0x0040) {
+GICv3ITSState *s = ARM_GICV3_ITS_COMMON(opaque);
+GICv3ITSCommonClass *c = ARM_GICV3_ITS_COMMON_GET_CLASS(s);
+int ret = c->send_msi(s, le32_to_cpu(value), attrs.stream_id);
+
+if (ret) {
+qemu_log_mask(LOG_GUEST_ERROR,
+  "ITS: Error sending MSI: %s\n", strerror(-ret));
+return MEMTX_DECODE_ERROR;
+}
+
+return MEMTX_OK;
+} else {
+qemu_log_mask(LOG_GUEST_ERROR,
+  "ITS write at bad offset 0x%jX\n", offset);
+return MEMTX_DECODE_ERROR;
+}
+}
+
+static const MemoryRegionOps gicv3_its_trans_ops = {
+.read = gicv3_its_trans_read,
+.write_with_attrs = gicv3_its_trans_write,
+.impl = {
+ .min_access_size = 4,
+ .max_access_size = 4,
+ },
+.endianness = DEVICE_NATIVE_ENDIAN,
+};
+
+void gicv3_its_init_mmio(GICv3ITSState *s, const MemoryRegionOps *ops)
+{
+SysBusDevice *sbd = SYS_BUS_DEVICE(s);
+
+memory_region_init_io(&s->iomem_its_cntrl, OBJECT(s), ops, s,
+  "control", ITS_CONTROL_SIZE);
+memory_region_init_io(&s->iomem_its, OBJECT(s), &gicv3_its_trans_ops, s,
+  "translation", ITS_TRANS_SIZE);
+
+/* Our two regions are always adjacent, therefore we now combine them
+ * into a single one in order to make our users' life easier.
+ */
+memory_region_init(&s->iomem_main, OBJECT(s), "gicv3_its", ITS_SIZE);
+memory_region_add_subregion(&s->iomem_mai

Re: [Qemu-devel] [PATCH] xen-platform: Replace assert() with appropriate error reporting

[Stefano Stabellini]

On Mon, 19 Oct 2015, Paolo Bonzini wrote:
> On 19/10/2015 20:39, Eduardo Habkost wrote:
> > Commit dbb7405d8caad0814ceddd568cb49f163a847561 made it possible to
> > trigger an assert using "-device xen-platform". Replace it with
> > appropriate error reporting.
> > 
> > Before:
> > 
> >   $ qemu-system-x86_64 -device xen-platform
> >   qemu-system-x86_64: hw/i386/xen/xen_platform.c:391: xen_platform_initfn: 
> > Assertion `xen_enabled()' failed.
> >   Aborted (core dumped)
> >   $
> > 
> > After:
> > 
> >   $ qemu-system-x86_64 -device xen-platform
> >   qemu-system-x86_64: -device xen-platform: xen-platform device requires 
> > the Xen accelerator
> >   qemu-system-x86_64: -device xen-platform: Device initialization failed
> >   $
> > 
> > Signed-off-by: Eduardo Habkost 
> > ---
> >  hw/i386/xen/xen_platform.c | 6 +-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> > 
> > diff --git a/hw/i386/xen/xen_platform.c b/hw/i386/xen/xen_platform.c
> > index 8682c42..5667f29 100644
> > --- a/hw/i386/xen/xen_platform.c
> > +++ b/hw/i386/xen/xen_platform.c
> > @@ -33,6 +33,7 @@
> >  #include "trace.h"
> >  #include "exec/address-spaces.h"
> >  #include "sysemu/block-backend.h"
> > +#include "qemu/error-report.h"
> >  
> >  #include 
> >  
> > @@ -388,7 +389,10 @@ static int xen_platform_initfn(PCIDevice *dev)
> >  uint8_t *pci_conf;
> >  
> >  /* Device will crash on reset if xen is not initialized */
> > -assert(xen_enabled());
> > +if (!xen_enabled()) {
> > +error_report("xen-platform device requires the Xen accelerator");
> 
> You can use PCIDeviceClass's realize (see Stefano's
> http://thread.gmane.org/gmane.comp.emulators.qemu/369998) to achieve
> better error propagation.

Eduardo, if you are happy with that, I'll wait for your respin :-)


> 
> > +return -1;
> > +}
> >  
> >  pci_conf = dev->config;
> >  
> > 
> 

Re: [Qemu-devel] [PATCH v8 00/27] vhost-user: add migration support

[Michael S. Tsirkin]

On Tue, Oct 20, 2015 at 08:30:49AM +0200, Thibaut Collet wrote:
> On Mon, Oct 19, 2015 at 11:12 PM, Michael S. Tsirkin  wrote:
> > On Mon, Oct 19, 2015 at 06:42:43PM +0200, Thibaut Collet wrote:
> >> >
> >> > Can you pls check refs/heads/for_thibaut?
> >> > It should have your patch as the latest commit.
> >>
> >> I do not see yet my patch on the for_thibaut branch
> >
> > Ouch. I meant refs/tags/for_thibaut.
> > Sorry about that.
> >
> >
> 
> Sorry for the incorrect wording (I write to quickly my email and use
> the word branch rather than tag). I use the for_thibaut tag for my
> live migration test. The fixup for the double definition of
> vhost_kernel_get_vq_index function id for this tag.
> To do successfully live migration in any conditions I have removed
> this double definition and apply the recent sending patch "vhost: set
> the correct queue index in case of migration with multiqueue"
> 
> When you say " It should have your patch as the latest commit." you
> think about which patch ? The
> "0001-FIXUP-vhost-user-add-support-of-live-migration.patch" one or the
> "vhost: set the correct queue index in case of migration with
> multiqueue" one ?
> 
> Regards.
> 
> Thibaut.


This is where for_thibaut points at for me:

commit bf6830e2416f67571ee2e7196f3625725adec170
Author: Thibaut Collet 
Date:   Mon Oct 19 14:59:27 2015 +0200

vhost: set the correct queue index in case of migration with multiqueue

When a live migration is started the log address to mark dirty pages is 
provided
to the vhost backend through the vhost_dev_set_log function.
This function is called for each queue pairs but the queue index is wrongly 
set:
always set to the first queue pair. Then vhost backend lost descriptor 
addresses
of the queue pairs greater than 1 and behaviour of the vhost backend is
unpredictable.

The queue index is computed by taking account of the vq_index (to retrieve 
the
queue pair index) and calling the vhost_get_vq_index method of the backend.

Signed-off-by: Thibaut Collet 


hash might change if I find any issues.

If this is not what you see, you need to re-fetch the tag.

Please let me know whether this tag works for you.

-- 
MST

Re: [Qemu-devel] [PATCH v7 31/42] Page request: Process incoming page request

[Juan Quintela]

"Dr. David Alan Gilbert"  wrote:
> * Juan Quintela (quint...@redhat.com) wrote:

>> Once here, do we care about calling malloc with the rcu set?  or could
>> we just call malloc at the beggining of the function and free it in case
>> that it is not needed on err?
>
> Why would that be better?

We would make the rcu region smaller, not sure we should care, so
forget.

Later, Juan.

[Qemu-devel] [PULL 0/1] virtio-input: ignore events until the guest driver is ready

[Gerd Hoffmann]

  Hi,

One more pretty small queue, input with a single bugfix.

please pull,
  Gerd

The following changes since commit 26c7be842637ee65a79cd77f96a99c23ddcd90ad:

  Merge remote-tracking branch 'remotes/sstabellini/tags/2015-10-19-tag' into 
staging (2015-10-19 12:13:27 +0100)

are available in the git repository at:


  git://git.kraxel.org/qemu tags/pull-input-20151020-1

for you to fetch changes up to d9460a7557672af9c4d9d4f153200d1075ed5a78:

  virtio-input: ignore events until the guest driver is ready (2015-10-20 
08:53:40 +0200)


virtio-input: ignore events until the guest driver is ready


Gerd Hoffmann (1):
  virtio-input: ignore events until the guest driver is ready

 hw/input/virtio-input.c | 4 
 1 file changed, 4 insertions(+)

[Qemu-devel] [PATCH v3 0/5] virtio-9p: hotplug and migration support

[Greg Kurz]

We already have a blocker to prevent migration of an active virtio-9p device.
But in fact, there is no migration support at all for 9p, even if the device
is considered to be quiescent (when the VirtFS share is not mounted): migration
succeeds but the device is lost in the restarted guest.
Hotunplug of a virtio-9p device is not supported either (no unrealize handler)
and leads to a QEMU crash on the source node, if one unplugs and migrates.

This series tries to fix that and brings hotplug and migration support of
*quiescent* virtio-9p devices.

v2->v3:
 - renamed QDEV handler @unpluggable to @unplug_is_blocked (patches 2/5
   and 3/5)

v1->v2:
 - introduced unplug blocker (patches 2/5 and 3/5)
 - moved fixes to separate patches (see individual changelogs)

---

Greg Kurz (5):
  virtio-9p-coth: fix init function
  qdev: add the @unplug_is_blocked handler
  virtio-9p: block hot-unplug when device is active
  virtio-9p: add unrealize handler
  virtio-9p: add savem handlers


 hw/9pfs/virtio-9p-coth.c   |   22 ++
 hw/9pfs/virtio-9p-coth.h   |2 ++
 hw/9pfs/virtio-9p-device.c |   24 
 hw/9pfs/virtio-9p.c|   14 ++
 hw/9pfs/virtio-9p.h|2 ++
 hw/core/qdev.c |4 
 hw/s390x/virtio-ccw.c  |8 
 hw/virtio/virtio-pci.c |8 
 include/hw/qdev-core.h |4 
 9 files changed, 84 insertions(+), 4 deletions(-)

[Qemu-devel] [PULL 1/1] virtio-input: ignore events until the guest driver is ready

[Gerd Hoffmann]

Cc: qemu-sta...@nongnu.org
Signed-off-by: Gerd Hoffmann 
---
 hw/input/virtio-input.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/hw/input/virtio-input.c b/hw/input/virtio-input.c
index 7b25d27..1f5a40d 100644
--- a/hw/input/virtio-input.c
+++ b/hw/input/virtio-input.c
@@ -20,6 +20,10 @@ void virtio_input_send(VirtIOInput *vinput, 
virtio_input_event *event)
 unsigned have, need;
 int i, len;
 
+if (!vinput->active) {
+return;
+}
+
 /* queue up events ... */
 if (vinput->qindex == vinput->qsize) {
 vinput->qsize++;
-- 
1.8.3.1

[Qemu-devel] [PULL 0/3] usb patch queue

[Gerd Hoffmann]

  Hi,

Here is the usb patch queue with some small tweaks.

please pull,
  Gerd

The following changes since commit 26c7be842637ee65a79cd77f96a99c23ddcd90ad:

  Merge remote-tracking branch 'remotes/sstabellini/tags/2015-10-19-tag' into 
staging (2015-10-19 12:13:27 +0100)

are available in the git repository at:


  git://git.kraxel.org/qemu tags/pull-usb-20151020-1

for you to fetch changes up to 37bc43f7fbfb38003550b327002e59d21b80a3e4:

  usb-audio: increate default buffer size (2015-10-20 09:15:23 +0200)


usb: misc small tweaks.


Gerd Hoffmann (3):
  usb-host: add wakeup call for iso xfers
  usb: print device id in "info usb" monitor command
  usb-audio: increate default buffer size

 hw/usb/bus.c | 9 ++---
 hw/usb/dev-audio.c   | 2 +-
 hw/usb/host-libusb.c | 1 +
 3 files changed, 8 insertions(+), 4 deletions(-)

Re: [Qemu-devel] [PATCH 4/6] e1000: Fixing the received/transmitted octets' counters

[Jason Wang]

On 10/18/2015 03:53 PM, Leonid Bloch wrote:
> Previously, the lower parts of these counters (TORL, TOTL) were
> resetting after reaching their maximal values, and since the continuation
> of counting in the higher parts (TORH, TOTH) was triggered by an
> overflow event of the lower parts, the count was not correct.
>
> Additionally, TORH and TOTH were counting the corresponding frames, and
> not the octets, as they supposed to do.
>
> Additionally, these 64-bit registers did not stick at their maximal
> values when (and if) they reached them.
>
> This fix resolves all the issues mentioned above, and makes the octet
> counters behave according to Intel's specs.
>
> Signed-off-by: Leonid Bloch 
> Signed-off-by: Dmitry Fleytman 
> ---
>  hw/net/e1000.c | 34 ++
>  1 file changed, 26 insertions(+), 8 deletions(-)
>
> diff --git a/hw/net/e1000.c b/hw/net/e1000.c
> index 5530285..7f977b6 100644
> --- a/hw/net/e1000.c
> +++ b/hw/net/e1000.c
> @@ -583,6 +583,28 @@ inc_reg_if_not_full(E1000State *s, int index)
>  }
>  }
>  
> +static void
> +grow_8reg_if_not_full(E1000State *s, int index, int size)
> +{
> +uint32_t lo = s->mac_reg[index];
> +uint32_t hi = s->mac_reg[index+1];
> +
> +if (lo == 0x) {
> +if ((hi += size) > s->mac_reg[index+1]) {
> +s->mac_reg[index+1] = hi;
> +} else if (s->mac_reg[index+1] != 0x) {
> +s->mac_reg[index+1] = 0x;
> +}
> +} else {
> +if (((lo += size) < s->mac_reg[index])
> +&& (s->mac_reg[index] = 0x)) {  /* setting low to full */
> +s->mac_reg[index+1] += ++lo;
> +} else {
> +s->mac_reg[index] = lo;
> +}
> +}
> +}

How about something easier:

uint64_t sum = s->mac_reg[index] | (uint64_t)s->mac_reg[index+1] <<32;
if (sum + size < sum) {
sum = 0x;
} else {
sum += size;
}
s->max_reg[index] = sum;
s->max_reg[index+1] = sum >> 32;

> +
>  static inline int
>  vlan_enabled(E1000State *s)
>  {
> @@ -632,7 +654,7 @@ static void
>  xmit_seg(E1000State *s)
>  {
>  uint16_t len, *sp;
> -unsigned int frames = s->tx.tso_frames, css, sofar, n;
> +unsigned int frames = s->tx.tso_frames, css, sofar;
>  struct e1000_tx *tp = &s->tx;
>  
>  if (tp->tse && tp->cptse) {
> @@ -678,10 +700,8 @@ xmit_seg(E1000State *s)
>  } else
>  e1000_send_packet(s, tp->data, tp->size);
>  inc_reg_if_not_full(s, TPT);
> +grow_8reg_if_not_full(s, TOTL, s->tx.size);
>  s->mac_reg[GPTC] = s->mac_reg[TPT];
> -n = s->mac_reg[TOTL];
> -if ((s->mac_reg[TOTL] += s->tx.size) < n)
> -s->mac_reg[TOTH]++;
>  }
>  
>  static void
> @@ -1096,11 +1116,9 @@ e1000_receive_iov(NetClientState *nc, const struct 
> iovec *iov, int iovcnt)
>  /* TOR - Total Octets Received:
>   * This register includes bytes received in a packet from the 
>* Address> field through the  field, inclusively.
> + * Always include FCS length (4) in size.
>   */
> -n = s->mac_reg[TORL] + size + /* Always include FCS length. */ 4;
> -if (n < s->mac_reg[TORL])
> -s->mac_reg[TORH]++;
> -s->mac_reg[TORL] = n;
> +grow_8reg_if_not_full(s, TORL, size+4);
>  
>  n = E1000_ICS_RXT0;
>  if ((rdt = s->mac_reg[RDT]) < s->mac_reg[RDH])

Re: [Qemu-devel] [PATCH 1/3] block/gluster: add support for multiple gluster servers

[Prasanna Kumar Kalever]

On  Tuesday, October 20, 2015 1:38:37 AM, Eric Blake wrote: 
> On 10/19/2015 06:13 AM, Prasanna Kumar Kalever wrote:
> > This patch adds a way to specify multiple volfile servers to the gluster
> > block backend of QEMU with tcp|rdma transport types and their port numbers.
> 
> When sending a multi-patch series, it is best to also include a 0/3
> cover letter.  Git can be configured to do this automatically with:
> git config format.coverLetter auto
> 

Thanks for the tip Eric :)

[...]
> > +#define GLUSTER_DEFAULT_PORT   24007
> > +
> >  typedef struct GlusterAIOCB {
> >  int64_t size;
> >  int ret;
> > @@ -24,22 +34,72 @@ typedef struct BDRVGlusterState {
> >  struct glfs_fd *fd;
> >  } BDRVGlusterState;
> >  
> > -typedef struct GlusterConf {
> > +typedef struct GlusterServerConf {
> >  char *server;
> >  int port;
> > +char *transport;
> 
> How do you know how many transport tuples are present? I'd expect a size
> argument somewhere.
> 
Its based on users choice I don't want to make it static

> > +} GlusterServerConf;

[...]

> > @@ -117,16 +178,19 @@ static int qemu_gluster_parseuri(GlusterConf *gconf,
> > const char *filename)
> > return -EINVAL;
> > }
> > 
> > + gconf = g_new0(GlusterConf, 1);
> > + gconf->gsconf = g_new0(GlusterServerConf, 1);
> 
> Wow - you are hard-coding things to exactly one server.  The subject
> line of the patch claims multiple gluster servers, but I don't see
> anything that supports more than one.  So something needs to be fixed up
> (if this patch is just renaming things, and a later patch adds support
> for more than one, that's okay - but it needs to be described that way).
> 

[1] I think you need to check 'qemu_gluster_parsejson' function for multiple 
gluster servers
usage which parse JSON syntax with multiple tuples, 'qemu_gluster_parseuri' 
function is to
parse URI syntax only and that supports single server usage only (kept for 
compatibility)

> > +static int qemu_gluster_parsejson(GlusterConf **pgconf, QDict *options)
> > +{

[...]

> > +#
> > +# Since: 2.5
> > +##
> > +{ 'struct': 'GlusterTuple',
> > +  'data': { 'host': 'str',
> > +'*port': 'int',
> > +'*transport': 'GlusterTransport' } }
> > +
> > +##
> > +# @BlockdevOptionsGluster
> > +#
> > +# Driver specific block device options for Gluster
> > +#
> > +# @volume:   name of gluster volume where our VM image resides
> > +#
> > +# @path: absolute path to image file in gluster volume
> > +#
> > +# @servers:  holds multiple tuples of {host, transport, port}
> 
> For this patch, it looks like it holds exactly one tuple.  But it looks
> like you plan to support multiple tuples later on; maybe a better
> wording is:
> 
> @servers: one or more gluster host descriptions (host, port, and transport)
> 
... [1] should clarify your understanding, but yes still I will bind to your 
comment 

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

-Prasanna

[Qemu-devel] [RFC PATCH v2 5/5] arm/virt: Add ITS to the virt board

[Pavel Fedin]

If supported by the configuration, ITS will be added automatically.

This patch also renames v2m_phandle to msi_phandle because it's now used
by both MSI implementations.

Signed-off-by: Pavel Fedin 
---
 hw/arm/virt.c | 47 +--
 1 file changed, 41 insertions(+), 6 deletions(-)

diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 4e7160c..5f22bf2 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -70,7 +70,7 @@ typedef struct VirtBoardInfo {
 int fdt_size;
 uint32_t clock_phandle;
 uint32_t gic_phandle;
-uint32_t v2m_phandle;
+uint32_t msi_phandle;
 } VirtBoardInfo;
 
 typedef struct {
@@ -351,9 +351,22 @@ static void fdt_add_cpu_nodes(const VirtBoardInfo *vbi)
 }
 }
 
+static void fdt_add_its_gic_node(VirtBoardInfo *vbi)
+{
+vbi->msi_phandle = qemu_fdt_alloc_phandle(vbi->fdt);
+qemu_fdt_add_subnode(vbi->fdt, "/intc/its");
+qemu_fdt_setprop_string(vbi->fdt, "/intc/its", "compatible",
+"arm,gic-v3-its");
+qemu_fdt_setprop(vbi->fdt, "/intc/its", "msi-controller", NULL, 0);
+qemu_fdt_setprop_sized_cells(vbi->fdt, "/intc/its", "reg",
+ 2, vbi->memmap[VIRT_GIC_ITS].base,
+ 2, vbi->memmap[VIRT_GIC_ITS].size);
+qemu_fdt_setprop_cell(vbi->fdt, "/intc/its", "phandle", vbi->msi_phandle);
+}
+
 static void fdt_add_v2m_gic_node(VirtBoardInfo *vbi)
 {
-vbi->v2m_phandle = qemu_fdt_alloc_phandle(vbi->fdt);
+vbi->msi_phandle = qemu_fdt_alloc_phandle(vbi->fdt);
 qemu_fdt_add_subnode(vbi->fdt, "/intc/v2m");
 qemu_fdt_setprop_string(vbi->fdt, "/intc/v2m", "compatible",
 "arm,gic-v2m-frame");
@@ -361,7 +374,7 @@ static void fdt_add_v2m_gic_node(VirtBoardInfo *vbi)
 qemu_fdt_setprop_sized_cells(vbi->fdt, "/intc/v2m", "reg",
  2, vbi->memmap[VIRT_GIC_V2M].base,
  2, vbi->memmap[VIRT_GIC_V2M].size);
-qemu_fdt_setprop_cell(vbi->fdt, "/intc/v2m", "phandle", vbi->v2m_phandle);
+qemu_fdt_setprop_cell(vbi->fdt, "/intc/v2m", "phandle", vbi->msi_phandle);
 }
 
 static void fdt_add_gic_node(VirtBoardInfo *vbi, int type)
@@ -397,6 +410,26 @@ static void fdt_add_gic_node(VirtBoardInfo *vbi, int type)
 qemu_fdt_setprop_cell(vbi->fdt, "/intc", "phandle", vbi->gic_phandle);
 }
 
+static void create_its(VirtBoardInfo *vbi, DeviceState *gicdev)
+{
+const char *itsclass = its_class_name();
+DeviceState *dev;
+
+if (!itsclass) {
+/* Do nothing if not supported */
+return;
+}
+
+dev = qdev_create(NULL, itsclass);
+
+object_property_set_link(OBJECT(dev), OBJECT(gicdev), "parent-gicv3",
+ &error_abort);
+qdev_init_nofail(dev);
+sysbus_mmio_map(SYS_BUS_DEVICE(dev), 0, vbi->memmap[VIRT_GIC_ITS].base);
+
+fdt_add_its_gic_node(vbi);
+}
+
 static void create_v2m(VirtBoardInfo *vbi, qemu_irq *pic)
 {
 int i;
@@ -480,7 +513,9 @@ static void create_gic(VirtBoardInfo *vbi, qemu_irq *pic, 
int type, bool secure)
 
 fdt_add_gic_node(vbi, type);
 
-if (type == 2) {
+if (type == 3) {
+create_its(vbi, gicdev);
+} else {
 create_v2m(vbi, pic);
 }
 }
@@ -799,9 +834,9 @@ static void create_pcie(const VirtBoardInfo *vbi, qemu_irq 
*pic,
 qemu_fdt_setprop_cells(vbi->fdt, nodename, "bus-range", 0,
nr_pcie_buses - 1);
 
-if (vbi->v2m_phandle) {
+if (vbi->msi_phandle) {
 qemu_fdt_setprop_cells(vbi->fdt, nodename, "msi-parent",
-   vbi->v2m_phandle);
+   vbi->msi_phandle);
 }
 
 qemu_fdt_setprop_sized_cells(vbi->fdt, nodename, "reg",
-- 
2.4.4

Re: [Qemu-devel] [PULL 0/3] usb patch queue

[Peter Maydell]

On 20 October 2015 at 08:25, Gerd Hoffmann  wrote:
>   Hi,
>
> Here is the usb patch queue with some small tweaks.
>
> please pull,
>   Gerd
>
> The following changes since commit 26c7be842637ee65a79cd77f96a99c23ddcd90ad:
>
>   Merge remote-tracking branch 'remotes/sstabellini/tags/2015-10-19-tag' into 
> staging (2015-10-19 12:13:27 +0100)
>
> are available in the git repository at:
>
>
>   git://git.kraxel.org/qemu tags/pull-usb-20151020-1
>
> for you to fetch changes up to 37bc43f7fbfb38003550b327002e59d21b80a3e4:
>
>   usb-audio: increate default buffer size (2015-10-20 09:15:23 +0200)
>
> 
> usb: misc small tweaks.

Applied, thanks.

-- PMM

[Qemu-devel] [PULL 3/3] usb-audio: increate default buffer size

[Gerd Hoffmann]

Signed-off-by: Gerd Hoffmann 
---
 hw/usb/dev-audio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/usb/dev-audio.c b/hw/usb/dev-audio.c
index f092bb8..02fb110 100644
--- a/hw/usb/dev-audio.c
+++ b/hw/usb/dev-audio.c
@@ -664,7 +664,7 @@ static const VMStateDescription vmstate_usb_audio = {
 static Property usb_audio_properties[] = {
 DEFINE_PROP_UINT32("debug", USBAudioState, debug, 0),
 DEFINE_PROP_UINT32("buffer", USBAudioState, buffer,
-   8 * USBAUDIO_PACKET_SIZE),
+   32 * USBAUDIO_PACKET_SIZE),
 DEFINE_PROP_END_OF_LIST(),
 };
 
-- 
1.8.3.1

[Qemu-devel] [PATCH] gdb command: qemu aios, qemu aiohandlers

[Dr. David Alan Gilbert (git)]

From: "Dr. David Alan Gilbert" 

Two new gdb commands are added:

  qemu iohandlers

 that dumps the list of waiting iohandlers, this is particularly
 useful for trying to figure out where an incoming migration is
 blocked.  For 'fd_coroutine_enter' cases we dump a full backtrace.

  qemu aios
 that dumps the qemu_aio_context list.

This is a rewrite of an earlier version prior to Fam's changes
to the corresponding structures.

Signed-off-by: Dr. David Alan Gilbert 

  (gdb) qemu aios
  
  {pfd = {fd = 12, events = 25, revents = 0}, io_read = 0x5634d4033cc0
  , io_write = 0x0, deleted = 0, opaque =
  0x5634d601e8b8, node = {le_next = 0x5634d5fd2330, le_prev =
  0x5634d5fd22a0}}
  
  {pfd = {fd = 6, events = 25, revents = 0}, io_read = 0x5634d3ff1750
  , io_write = 0x0, deleted = 0, opaque =
  0x5634d5fd22e8, node = {le_next = 0x0, le_prev = 0x5634d5fe8458}}
  

  (gdb) qemu iohandlers
  
  {pfd = {fd = 15, events = 25, revents = 0}, io_read = 0x559a843bd850
  , io_write = 0x0, deleted = 0, opaque =
  0x7fef1c5fed30, node = {le_next = 0x559a84e9d180, le_prev =
  0x559a84e9c6b0}}
  #0  0x559a843bdcf0 in qemu_coroutine_switch
  (from_=from_@entry=0x559a865fd8e0, to_=to_@entry=0x7fef37774ac8,
  action=action@entry=COROUTINE_YIELD) at
  /home/dgilbert/git/qemu-world3/coroutine-ucontext.c:177
  #1  0x559a843bd0d0 in qemu_coroutine_yield () at
  /home/dgilbert/git/qemu-world3/qemu-coroutine.c:145
  #2  0x559a843bd9c5 in yield_until_fd_readable (fd=15) at
  /home/dgilbert/git/qemu-world3/qemu-coroutine-io.c:90
  #3  0x559a84362337 in socket_get_buffer (opaque=0x559a862f7a00,
  buf=0x559a84ea0a70 "", pos=, size=32768) at
  /home/dgilbert/git/qemu-world3/migration/qemu-file-unix.c:69
  #4  0x559a84360c9c in qemu_fill_buffer (f=0x559a84ea0a40)
  at /home/dgilbert/git/qemu-world3/migration/qemu-file.c:215
  #5  0x559a84361569 in qemu_peek_byte (f=0x559a84ea0a40, offset=0)
  at /home/dgilbert/git/qemu-world3/migration/qemu-file.c:448
  #6  0x559a843617d4 in qemu_get_be32 (f=0x559a84ea0a40)
  at /home/dgilbert/git/qemu-world3/migration/qemu-file.c:461
  #7  0x559a843617d4 in qemu_get_be32 (f=f@entry=0x559a84ea0a40)
  at /home/dgilbert/git/qemu-world3/migration/qemu-file.c:545
  #8  0x559a84187d92 in qemu_loadvm_state (f=f@entry=0x559a84ea0a40)
  at /home/dgilbert/git/qemu-world3/migration/savevm.c:1070
  #9  0x559a8435dc42 in process_incoming_migration_co
  (opaque=0x559a84ea0a40)
  at /home/dgilbert/git/qemu-world3/migration/migration.c:285
  #10 0x559a843bdd5a in coroutine_trampoline (i0=,
  i1=)
  at /home/dgilbert/git/qemu-world3/coroutine-ucontext.c:80
  #11 0x7fef2a462f10 in __start_context () at /lib64/libc.so.6
  #12 0x7fffb7437b50 in  ()
  #13 0x in  ()
  
  {pfd = {fd = 4, events = 25, revents = 0}, io_read = 0x559a843b7800
  , io_write = 0x0, deleted = 0, opaque = 0x4, node =
  {le_next = 0x559a84e9c740, le_prev = 0x559a86325498}}
  
  {pfd = {fd = 5, events = 25, revents = 0}, io_read = 0x559a843ac750
  , io_write = 0x0, deleted = 0, opaque =
  0x559a84e9c6f8, node = {le_next = 0x0, le_prev = 0x559a84e9d1a8}}
  
---
 scripts/qemu-gdb.py|  4 +++-
 scripts/qemugdb/aio.py | 52 ++
 2 files changed, 55 insertions(+), 1 deletion(-)
 create mode 100644 scripts/qemugdb/aio.py

diff --git a/scripts/qemu-gdb.py b/scripts/qemu-gdb.py
index d6f2e5a..99344c7 100644
--- a/scripts/qemu-gdb.py
+++ b/scripts/qemu-gdb.py
@@ -26,7 +26,7 @@ import os, sys
 
 sys.path.append(os.path.dirname(__file__))
 
-from qemugdb import mtree, coroutine
+from qemugdb import aio, mtree, coroutine
 
 class QemuCommand(gdb.Command):
 '''Prefix for QEMU debug support commands'''
@@ -37,6 +37,8 @@ class QemuCommand(gdb.Command):
 QemuCommand()
 coroutine.CoroutineCommand()
 mtree.MtreeCommand()
+aio.IOhandlersCommand()
+aio.AIOsCommand()
 
 # Default to silently passing through SIGUSR1, because QEMU sends it
 # to itself a lot.
diff --git a/scripts/qemugdb/aio.py b/scripts/qemugdb/aio.py
new file mode 100644
index 000..cda2c37
--- /dev/null
+++ b/scripts/qemugdb/aio.py
@@ -0,0 +1,52 @@
+#!/usr/bin/python
+
+# GDB debugging support: aio/iohandler debug
+#
+# Copyright (c) 2015 Red Hat, Inc.
+#
+# Author: Dr. David Alan Gilbert 
+#
+# This work is licensed under the terms of the GNU GPL, version 2 or
+# later.  See the COPYING file in the top-level directory.
+#
+
+import gdb
+from qemugdb import coroutine
+
+def isnull(ptr):
+return ptr == gdb.Value(0).cast(ptr.type)
+
+def dump_aiocontext(context):
+'''Display a dump and backtrace for an aiocontext'''
+cur = context['aio_handlers']['lh_first']
+# Get pointers to functions we're going to process specially
+sym_fd_coroutine_enter = gdb.parse_and_eval('fd_coroutine_enter')
+
+while not isnull(cur):
+entry = cur.dereference()
+gdb.write('\n%s\n' % entry)
+ 

Re: [Qemu-devel] [PATCH v7 00/39] blockdev: BlockBackend and media

[Kevin Wolf]

Am 19.10.2015 um 17:53 hat Max Reitz geschrieben:
> This series reworks a lot regarding BlockBackend and media. Basically,
> it allows empty BlockBackends, that is BBs without a BDS tree.
> 
> Before this series, empty drives are represented by a BlockBackend with
> an empty BDS attached to it (a BDS with a NULL driver). However, now we
> have BlockBackends, thus an empty drive should be represented by a
> BlockBackend without any BDS tree attached to it. This is what this
> series does.

Thanks, applied patches 1-26 to the block branch.

Kevin

Re: [Qemu-devel] [PATCH v8 18/54] Migration commands

[Juan Quintela]

"Dr. David Alan Gilbert (git)"  wrote:
> From: "Dr. David Alan Gilbert" 
>
> Create QEMU_VM_COMMAND section type for sending commands from
> source to destination.  These commands are not intended to convey
> guest state but to control the migration process.
>
> For use in postcopy.
>
> Signed-off-by: Dr. David Alan Gilbert 
> Reviewed-by: Amit Shah 

Reviewed-by: Juan Quintela 

Re: [Qemu-devel] [PATCH v8 19/54] Return path: Control commands

[Juan Quintela]

"Dr. David Alan Gilbert (git)"  wrote:
> From: "Dr. David Alan Gilbert" 
>
> Add two src->dest commands:
>* OPEN_RETURN_PATH - To request that the destination open the return path
>* PING - Request an acknowledge from the destination
>
> Signed-off-by: Dr. David Alan Gilbert 
> Reviewed-by: Amit Shah 

Reviewed-by: Juan Quintela 


> +void qemu_savevm_send_open_return_path(QEMUFile *f)
> +{
> +qemu_savevm_command_send(f, MIG_CMD_OPEN_RETURN_PATH, 0, NULL);


For consistency, I would have put a

   trace_savevm_send_open_return_path() here

The send in the loadvm path

Re: [Qemu-devel] [PATCH v8 21/54] Return path: Source handling of return path

[Juan Quintela]

"Dr. David Alan Gilbert (git)"  wrote:
> From: "Dr. David Alan Gilbert" 
>
> Open a return path, and handle messages that are received upon it.
>
> Signed-off-by: Dr. David Alan Gilbert 

Reviewed-by: Juan Quintela 

> +/*
> + * Return true if we're already in the middle of a migration
> + * (i.e. any of the active or setup states)
> + */
> +static bool migration_is_active(MigrationState *ms)
> +{
> +switch (ms->state) {
> +case MIGRATION_STATUS_ACTIVE:
> +case MIGRATION_STATUS_SETUP:
> +return true;
> +
> +default:
> +return false;
> +
> +}
> +}
> +


If you have to resend, you can split this bit, and update users around.

[Qemu-devel] PING: [PATCH v4 0/7] qom: more efficient object property handling

[Pavel Fedin]

 Hello! Is there any progress on this?
 6/7 significantly improves startup performance, i'd like to have it accepted.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia


> -Original Message-
> From: qemu-devel-bounces+p.fedin=samsung@nongnu.org [mailto:qemu-devel-
> bounces+p.fedin=samsung@nongnu.org] On Behalf Of Pavel Fedin
> Sent: Wednesday, October 14, 2015 9:58 AM
> To: 'Daniel P. Berrange'; qemu-devel@nongnu.org
> Cc: 'Paolo Bonzini'; 'Markus Armbruster'; 'Andreas Färber'
> Subject: Re: [Qemu-devel] [PATCH v4 0/7] qom: more efficient object property 
> handling
> 
>  Hello!
> 
> > This series introduces a concept of object property iterators
> > to QOM so callers are insulated from the specific data structures
> > used for storing properties against objects/classes. It then
> > converts Object to use a GHashTable for storing properties.
> > Finally it introduces ObjectClass properties.
> 
>  Tested-by: Pavel Fedin 
> 
> > Probably the only controversial thing is the item Pavel points
> > out about object_child_foreach iterators now being forbidden
> > from modifying the object composition tree.
> 
>  As i already wrote, current code does not modify the tree. If necessary, it 
> is possible to
> work around (e. g. make a decision about modification, stop iteration, then 
> do the
> modification). I think this would pop up anyway if we change list to anything 
> else. IMHO it's
> better just to acknowledge that we should not modify our tree inside iterator.
> 
> Kind regards,
> Pavel Fedin
> Expert Engineer
> Samsung Electronics Research center Russia
> 

Re: [Qemu-devel] [PATCH v8 00/27] vhost-user: add migration support

[Thibaut Collet]

On Tue, Oct 20, 2015 at 12:21 PM, Michael S. Tsirkin  wrote:
> On Tue, Oct 20, 2015 at 08:30:49AM +0200, Thibaut Collet wrote:
>> On Mon, Oct 19, 2015 at 11:12 PM, Michael S. Tsirkin  wrote:
>> > On Mon, Oct 19, 2015 at 06:42:43PM +0200, Thibaut Collet wrote:
>> >> >
>> >> > Can you pls check refs/heads/for_thibaut?
>> >> > It should have your patch as the latest commit.
>> >>
>> >> I do not see yet my patch on the for_thibaut branch
>> >
>> > Ouch. I meant refs/tags/for_thibaut.
>> > Sorry about that.
>> >
>> >
>>
>> Sorry for the incorrect wording (I write to quickly my email and use
>> the word branch rather than tag). I use the for_thibaut tag for my
>> live migration test. The fixup for the double definition of
>> vhost_kernel_get_vq_index function id for this tag.
>> To do successfully live migration in any conditions I have removed
>> this double definition and apply the recent sending patch "vhost: set
>> the correct queue index in case of migration with multiqueue"
>>
>> When you say " It should have your patch as the latest commit." you
>> think about which patch ? The
>> "0001-FIXUP-vhost-user-add-support-of-live-migration.patch" one or the
>> "vhost: set the correct queue index in case of migration with
>> multiqueue" one ?
>>
>> Regards.
>>
>> Thibaut.
>
>
> This is where for_thibaut points at for me:
>
> commit bf6830e2416f67571ee2e7196f3625725adec170
> Author: Thibaut Collet 
> Date:   Mon Oct 19 14:59:27 2015 +0200
>
> vhost: set the correct queue index in case of migration with multiqueue
>
> When a live migration is started the log address to mark dirty pages is 
> provided
> to the vhost backend through the vhost_dev_set_log function.
> This function is called for each queue pairs but the queue index is 
> wrongly set:
> always set to the first queue pair. Then vhost backend lost descriptor 
> addresses
> of the queue pairs greater than 1 and behaviour of the vhost backend is
> unpredictable.
>
> The queue index is computed by taking account of the vq_index (to 
> retrieve the
> queue pair index) and calling the vhost_get_vq_index method of the 
> backend.
>
> Signed-off-by: Thibaut Collet 
>
>
> hash might change if I find any issues.
>
> If this is not what you see, you need to re-fetch the tag.

Ok I got and tested the updated branch. The problem, with my previous
attempt, is there are a tag and a branch called for_thibaut. This
morning after re-fetch operation I do a "git checkout for_thibaut"
that takes the tag and not the branch.
I realize it with the commit sha-1 of the "vhost: set the correct
queue index in case of migration with multiqueue" patch (sha-1 of
commit of for_thibaut tag is e20cff854)

>
> Please let me know whether this tag works for you.
>

I have tested this version (commit bf6830e24) with live migration and
everything is OK.

tested-by: Thibaut Collet 

> --
> MST

[Qemu-devel] [RFC PATCH v2 0/5] vITS support

[Pavel Fedin]

This series introduces support for in-kernel GICv3 ITS emulation.
It is based on kernel API which is not released yet, therefore i post it
as an RFC.

Kernel patches which implement this functionality are:
- [PATCH v2 00/15] KVM: arm64: GICv3 ITS emulation
  http://www.spinics.net/lists/arm-kernel/msg430724.html
- [PATCH v3 0/7] KVM: arm/arm64: gsi routing support
  http://www.spinics.net/lists/kvm/msg119567.html

v1 => v2:
- Added registers and reset method
- Added unmigratable flag
- Rebased on top of current master, use kvm_arch_fixup_msi_route() now

Pavel Fedin (5):
  hw/intc: Implement ITS base class
  kernel: Add vGICv3 ITS definitions
  kvm_arm: Pass requester ID to MSI routing functions
  kvm_arm: Implement support for ITS emulation by KVM
  arm/virt: Add ITS to the virt board

 hw/arm/virt.c  |  47 --
 hw/intc/Makefile.objs  |   2 +
 hw/intc/arm_gicv3_its_common.c | 154 +
 hw/intc/arm_gicv3_its_kvm.c|  88 +++
 include/hw/intc/arm_gicv3_its_common.h |  72 +++
 linux-headers/asm-arm64/kvm.h  |   1 +
 linux-headers/linux/kvm.h  |   9 +-
 target-arm/kvm.c   |   6 ++
 target-arm/kvm_arm.h   |  13 +++
 target-arm/machine.c   |  16 
 10 files changed, 400 insertions(+), 8 deletions(-)
 create mode 100644 hw/intc/arm_gicv3_its_common.c
 create mode 100644 hw/intc/arm_gicv3_its_kvm.c
 create mode 100644 include/hw/intc/arm_gicv3_its_common.h

-- 
2.4.4

[Qemu-devel] [PATCH v3 1/5] virtio-9p-coth: fix init function

[Greg Kurz]

The v9fs thread pool is a singleton, shared by all virtio-9p devices.
The current code leaks underlying glib pointers each time a new virtio-9p
device gets realized. Let's fix that !

While we're here, we also fix the trivial error path when memory allocation
is failing.

Signed-off-by: Greg Kurz 
---
 hw/9pfs/virtio-9p-coth.c |9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/hw/9pfs/virtio-9p-coth.c b/hw/9pfs/virtio-9p-coth.c
index 8185c533c013..1d832ede1ebf 100644
--- a/hw/9pfs/virtio-9p-coth.c
+++ b/hw/9pfs/virtio-9p-coth.c
@@ -55,6 +55,10 @@ int v9fs_init_worker_threads(void)
 V9fsThPool *p = &v9fs_pool;
 sigset_t set, oldset;
 
+if (p->pool) {
+return 0;
+}
+
 sigfillset(&set);
 /* Leave signal handling to the iothread.  */
 pthread_sigmask(SIG_SETMASK, &set, &oldset);
@@ -66,10 +70,7 @@ int v9fs_init_worker_threads(void)
 }
 p->completed = g_async_queue_new();
 if (!p->completed) {
-/*
- * We are going to terminate.
- * So don't worry about cleanup
- */
+g_thread_pool_free(p->pool, TRUE, TRUE);
 ret = -1;
 goto err_out;
 }

Re: [Qemu-devel] [PATCH v8 24/54] Add wrappers and handlers for sending/receiving the postcopy-ram migration messages.

[Juan Quintela]

"Dr. David Alan Gilbert (git)"  wrote:
> From: "Dr. David Alan Gilbert" 
>
> The state of the postcopy process is managed via a series of messages;
>* Add wrappers and handlers for sending/receiving these messages
>* Add state variable that track the current state of postcopy
>
> Signed-off-by: Dr. David Alan Gilbert 
> Reviewed-by: Amit Shah 

Reviewed-by: Juan Quintela 


> +tmp[0] = cpu_to_be64(getpagesize());
> +tmp[1] = cpu_to_be64(1ul << qemu_target_page_bits());

 we don't have a qemu_target_pagesize()?

#fail

> +qemu_savevm_command_send(f, MIG_CMD_POSTCOPY_LISTEN, 0, NULL);

Should we create a macro

   qemu_savevm_command_noargs_send(f, MIG_CMD_POSTCOPY_LISTEN);

It is a "bit" clear, but saves a "whole" byte.  Not convinced one way or
other :-p




> +
> +case MIG_CMD_POSTCOPY_ADVISE:
> +tmp64a = qemu_get_be64(f); /* hps */
> +tmp64b = qemu_get_be64(f); /* tps */
> +return loadvm_postcopy_handle_advise(mis, tmp64a, tmp64b);

In the rest of the commands, you read the arguments inside the
loadvm_postocpy_handle_*(), I think you should do the same here.

Later, Juan.

Re: [Qemu-devel] [PATCH] vmxnet3: Do not fill stats if device is inactive

[Dmitry Fleytman]

Hi Jason,

Sure. No problem.

Acked-by: Dmitry Fleytman mailto:dmi...@daynix.com>>

Dmitry.

> On 20 Oct 2015, at 06:08 AM, Jason Wang  wrote:
> 
> 
> 
> On 10/18/2015 03:16 PM, Dmitry Fleytman wrote:
>> ACK
> 
> Hi Dmitry:
> 
> Thanks a lot for the reviewing.
> 
> As I want to add your "Acked-by" in the patch, could you pls add a
> formal one in the future? (Which can make my life a little bit easier).
> 
>>> On 15 Oct 2015, at 13:54 PM, Dana Rubin 
>>>  wrote:
>>> 
>>> From: Shmulik Ladkani 
>>> 
>>> Guest OS may issue VMXNET3_CMD_GET_STATS even before device was
>>> activated (for example in linux, after insmod but prior net-dev open).
>>> 
>>> Accessing shared descriptors prior device activation is illegal as the
>>> VMXNET3State structures have not been fully initialized.
>>> 
>>> As a result, guest memory gets corrupted and may lead to guest OS
>>> crashes.
>>> 
>>> Fix, by not filling the stats descriptors if device is inactive.
>>> 
>>> Reported-by: Leonid Shatz 
>>> Signed-off-by: Dana Rubin 
>>> Signed-off-by: Shmulik Ladkani 
>>> ---
>>> hw/net/vmxnet3.c | 4 
>>> 1 file changed, 4 insertions(+)
>>> 
>>> diff --git a/hw/net/vmxnet3.c b/hw/net/vmxnet3.c
>>> index 3c5e10d..5e3a233 100644
>>> --- a/hw/net/vmxnet3.c
>>> +++ b/hw/net/vmxnet3.c
>>> @@ -1289,6 +1289,10 @@ static uint32_t 
>>> vmxnet3_get_interrupt_config(VMXNET3State *s)
>>> static void vmxnet3_fill_stats(VMXNET3State *s)
>>> {
>>>int i;
>>> +
>>> +if (!s->device_active)
>>> +return;
>>> +
>>>for (i = 0; i < s->txq_num; i++) {
>>>cpu_physical_memory_write(s->txq_descr[i].tx_stats_pa,
>>>  &s->txq_descr[i].txq_stats,
>>> -- 
>>> 1.9.1
>>> 
>> 
> 

Re: [Qemu-devel] [PATCH v8 01/54] Add postcopy documentation

[Juan Quintela]

Rsend to proper list.

Removed cc'd

Juan Quintela  wrote:
> "Dr. David Alan Gilbert (git)"  wrote:
>> From: "Dr. David Alan Gilbert" 
>>
>> Signed-off-by: Dr. David Alan Gilbert 
>> Reviewed-by: Amit Shah 

Reviewed-by: Juan Quintela 

Re: [Qemu-devel] [PATCH v8 04/54] Move configuration section writing

[Juan Quintela]

Juan Quintela  wrote:

Post proper list

remove cc'd

> "Dr. David Alan Gilbert (git)"  wrote:
>> From: "Dr. David Alan Gilbert" 
>>
>> The vmstate_configuration is currently written
>> in 'qemu_savevm_state_begin', move it to
>> 'qemu_savevm_state_header' since it's got a hard
>> requirement that it must be the 1st thing after
>> the header.
>> (In postcopy some 'command' sections get sent
>> early before the saving of the main sections
>> and hence before qemu_savevm_state_begin).
>>
>> Signed-off-by: Dr. David Alan Gilbert 

Reviewed-by: Juan Quintela 

Re: [Qemu-devel] [PULL v4 00/14] qemu-ga patch queue

[Peter Maydell]

On 20 October 2015 at 10:52, Peter Maydell  wrote:
> On 20 October 2015 at 00:38, Michael Roth  wrote:
>> 
>> qemu-ga patch queue
>>
>> * add unit tests for qemu-ga
>> * add guest-exec support for posix/w32 guests
>> * added 'qemu-ga' target for w32. this allows us to do full MSI build,
>>   without overloading 'qemu-ga.exe' target with uneeded dependencies.
>> * number of s/g_new/g_malloc/ conversions for qga

> Applied, thanks.

...but it looks like this is causing one of our travis builds
to fail:
https://travis-ci.org/qemu/qemu/jobs/86374487

Any suggestions?

thanks
-- PMM

Re: [Qemu-devel] [PATCH v8 06/54] Rename mis->file to from_src_file

[Juan Quintela]

Juan Quintela  wrote:
> "Dr. David Alan Gilbert (git)"  wrote:

Post proper list

Remove cc'd

>> From: "Dr. David Alan Gilbert" 
>>
>> 'file' becomes confusing when you have flows in each direction;
>> rename to make it clear.
>> This leaves just the main forward direction ms->file, which is used
>> in a lot of places and is probably not worth renaming given the churn.
>>
>> Signed-off-by: Dr. David Alan Gilbert 

Reviewed-by: Juan Quintela 

Re: [Qemu-devel] [PATCH v8 09/54] Add QEMU_MADV_NOHUGEPAGE

[Juan Quintela]

Juan Quintela  wrote:

Post proper list

Remove cc'd


> "Dr. David Alan Gilbert (git)"  wrote:
>> From: "Dr. David Alan Gilbert" 
>>
>> Add QEMU_MADV_NOHUGEPAGE as an OS-independent version of
>> MADV_NOHUGEPAGE.
>>
>> We include sys/mman.h before making the test to ensure
>> that we pick up the system defines.
>>
>> Signed-off-by: Dr. David Alan Gilbert 

Reviewed-by: Juan Quintela 

Re: [Qemu-devel] [PULL 0/2] vga: enable virtio-vga for pseries, vmsvga cursor checks.

[Peter Maydell]

On 20 October 2015 at 08:42, Gerd Hoffmann  wrote:
>   Hi,
>
> vga patch queue, featuring two small fixes.
>
> please pull,
>   Gerd
>
> The following changes since commit 26c7be842637ee65a79cd77f96a99c23ddcd90ad:
>
>   Merge remote-tracking branch 'remotes/sstabellini/tags/2015-10-19-tag' into 
> staging (2015-10-19 12:13:27 +0100)
>
> are available in the git repository at:
>
>
>   git://git.kraxel.org/qemu tags/pull-vga-20151020-1
>
> for you to fetch changes up to 5829b097204189c56dd1fb62c7f827360394bb39:
>
>   vmsvga: more cursor checks (2015-10-20 09:26:36 +0200)
>
> 
> vga: enable virtio-vga for pseries, vmsvga cursor checks.
>

Applied, thanks.

-- PMM

Re: [Qemu-devel] [PATCH v8 10/54] migration/ram.c: Use RAMBlock rather than MemoryRegion

[Juan Quintela]

Juan Quintela  wrote:

Post proper list

Remove cc'd

> "Dr. David Alan Gilbert (git)"  wrote:
>> From: "Dr. David Alan Gilbert" 
>>
>> RAM migration mainly works on RAMBlocks but in a few places
>> uses data from MemoryRegions to access the same information that's
>> already held in RAMBlocks; clean it up just to avoid the
>> MemoryRegion use.
>>
>> Signed-off-by: Dr. David Alan Gilbert 

Reviewed-by: Juan Quintela 

This was a leftover of when I tried to convert migration to use Memory
regions, yes, it didn't went too well

Re: [Qemu-devel] [PATCH v8 17/54] Return path: socket_writev_buffer: Block even on non-blocking fd's

[Juan Quintela]

Juan Quintela  wrote:

Post proper list

Remove cc'd


> "Dr. David Alan Gilbert (git)"  wrote:
>> From: "Dr. David Alan Gilbert" 
>>
>> The destination sets the fd to non-blocking on incoming migrations;
>> this also affects the return path from the destination, and thus we
>> need to make sure we can safely write to the return path.
>>
>> Signed-off-by: Dr. David Alan Gilbert 
>> Reviewed-by: Amit Shah 

 Reviewed-by: Juan Quintela 

 I think that my review by got lost on previous series O:-)

Re: [Qemu-devel] [PATCH] file_ram_alloc: propagate error to caller instead of terminating QEMU

[Paolo Bonzini]

On 19/10/2015 19:11, Igor Mammedov wrote:
> QEMU shouldn't exits from file_ram_alloc() if -mem-prealloc option is 
> specified
> and "object_add memory-backend-file,..." fails allocation during memory 
> hotplug.
> 
> Propagate error to a caller and let it decide what to do with allocation 
> failure.
> That leaves QEMU alive if it can't create backend during hotplug time and
> kills QEMU at startup time if backends or initial memory were misconfigured/
> too large.
> 
> Signed-off-by: Igor Mammedov 
> ---
>  exec.c | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/exec.c b/exec.c
> index 7d90a52..0aadd41 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -1292,10 +1292,6 @@ static void *file_ram_alloc(RAMBlock *block,
>  return area;
>  
>  error:
> -if (mem_prealloc) {
> -error_report("%s", error_get_pretty(*errp));
> -exit(1);
> -}
>  return NULL;
>  }
>  #endif
> 

Queued, thanks.

Paolo

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Stefano Stabellini]

On Mon, 19 Oct 2015, Laszlo Ersek wrote:
> On 10/16/15 21:09, Laszlo Ersek wrote:
> > On 10/16/15 13:34, Fabio Fantoni wrote:
> >> Il 16/10/2015 12:47, Stefano Stabellini ha scritto:
> >>> On Fri, 16 Oct 2015, Fabio Fantoni wrote:
>  Il 16/10/2015 12:13, Anthony PERARD ha scritto:
> > On Fri, Oct 16, 2015 at 10:32:44AM +0200, Fabio Fantoni wrote:
> >> Il 15/10/2015 20:02, Anthony PERARD ha scritto:
> >>> On Thu, Oct 15, 2015 at 06:27:17PM +0200, Fabio Fantoni wrote:
>  Il 14/10/2015 13:06, Stefano Stabellini ha scritto:
> > I would suggest Fabio to avoid AHCI disks altogether and just use
> > OVMF
> > with PV disks only and Anthony's patch to libxl to avoid creating
> > any
> > IDE disks: http://marc.info/?l=xen-devel&m=144482080812353.
> >
> > Would that work for you?
>  Thanks for the advice, I tried it:
>  https://github.com/Fantu/Xen/commits/rebase/m2r-testing-4.6
> 
>  I installed W10 pro 64 bit with ide disk, installed the win pv
>  drivers
>  and
>  after changed to xvdX instead hdX, is the only change needed, right?
>  Initial boot is ok (ovmf part about pv disks seems ok) but windows
>  boot
>  fails with problem with pv drivers.
>  In attachment full qemu log with xen_platform trace and domU's xl
>  cfg.
> 
>  Someone have windows domUs with ovmf and pv disks only working?
>  If yes
>  can
>  tell me the difference to understand what can be the problem please?
> >>> When I worked on the PV disk implementation in OVMF, I was able to
> >>> boot
> >>> a Windows 8 with pv disk only.
> >>>
> >>> I don't have access to the guest configuration I was using, but I
> >>> think
> >>> one
> >>> difference would be the viridian setting, I'm pretty sure I did
> >>> not set
> >>> it.
> >>>
> >> I tried with viridian disabled but did the same thing, looking
> >> cdrom as
> >> latest thing before xenbug trace in qemu log I tried also to remove
> >> it but
> >> also in this case don't boot correctly, full qemu log in attachment.
> >> I don't know if is a ovmf thing to improve (like what seems in
> >> Laszlo and
> >> Kevin mails) or xen winpv drivers unexpected case, have you tried also
> >> with
> >> latest winpv builds? (for exclude regression)
> > No, I did not tried the latest winpv drivers.
> >
> > Sorry I can help much more that that. When I install this win8 guest
> > tried
> > to boot it with pv drivers only, that was more than a year ago. I
> > have not
> > check if it's still working. (Also I can not try anything more recent,
> > right now.)
> >
>  I did many other tests, retrying with ide first boot working but show pv
>  devices not working, I did another reboot (with ide) and pv devices was
>  working, after I retried with pv (xvdX) and boot correctly.
>  After other tests I found that with empty cdrom device (required for xl
>  cd-insert/cd-eject) boot stop at start (tianocore image), same result
>  with ide
>  instead.
>   From xl cfg:
>  disk=['/mnt/vm/disks/W10UEFI.disk1.cow-sn1,qcow2,xvda,rw',',raw,xvdb,ro,cdrom']
> 
>  With seabios domU boot also with empty cdrom.
>  In qemu log I found only these that can be related:
> > xen be: qdisk-51728: error: Could not open image: No such file or
> > directory
> > xen be: qdisk-51728: initialise() failed
>  And latest xl dmesg line is:
> > (d1) Invoking OVMF ...
>  If you need more informations/test tell me and I'll post them.
> >>> Are you saying that without any cdrom drives, it works correctly?
> >> Yes, I did also another test to be sure, starting with ide, installing
> >> windows, the pv drivers, rebooting 2 times (with one at boot of time
> >> boot with ide only and without net and disks pv drivers working) and
> >> after rebooting with pv disks (xvdX) works.
> >> With cdrom not empty (with iso) works, with empty not, tried with both
> >> ide (hdX) and pv (xvdX).
> >> Empty cdrom not working with ovmf I suppose is ovmf bug or inexpected case.
> >> About major of winpv drivers problem at boot I suppose can be solved
> >> improving ovmf and winpv driver removing bad hybrid thing actually, but
> >> I have too low knowledge to be sure.
> >> About the problem of pv start after install that requiring at least 2
> >> reboot can be also a windows 10 problem (only a suppose).
> >>
> >> About empty cdrom with ovmf can be solved please?
> >>
> > 
> > Sorry, I find your problem report impenetrable. :( Please slow down and
> > try to spend time on punctuation at least.
> > 
> > For me to make heads or tails of this, I'll need the following:
> > 
> > - The debug output of an OVMF binary built with the DEBUG_VERBOSE bit
> > (0x0040) enabled in PcdDebugPrintErro

Re: [Qemu-devel] [PATCH] xen: fix invalid assertion

[Stefano Stabellini]

On Mon, 19 Oct 2015, Paolo Bonzini wrote:
> Asserting "true" is not that useful.
> 
> Reported by Coverity.
> 
> Signed-off-by: Paolo Bonzini 

Acked-by: Stefano Stabellini 


>  hw/xen/xen_pt_config_init.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/xen/xen_pt_config_init.c b/hw/xen/xen_pt_config_init.c
> index 4a5bc11..f6969ad 100644
> --- a/hw/xen/xen_pt_config_init.c
> +++ b/hw/xen/xen_pt_config_init.c
> @@ -1937,7 +1937,7 @@ static int 
> xen_pt_config_reg_init(XenPCIPassthroughState *s,
>  break;
>  case 4: rc = xen_host_pci_get_long(&s->real_device, offset, &val);
>  break;
> -default: assert(1);
> +default: abort();
>  }
>  if (rc) {
>  /* Serious issues when we cannot read the host values! */
> @@ -1982,7 +1982,7 @@ static int 
> xen_pt_config_reg_init(XenPCIPassthroughState *s,
>  break;
>  case 4: pci_set_long(s->dev.config + offset, val);
>  break;
> -default: assert(1);
> +default: abort();
>  }
>  /* set register value pointer to the data. */
>  reg_entry->ptr.byte = s->dev.config + offset;
> -- 
> 2.5.0
> 
> 

Re: [Qemu-devel] [PATCH v2 6/9] target-i386: Handle I/O breakpoints

[Paolo Bonzini]

On 19/10/2015 19:57, Eduardo Habkost wrote:
> On Mon, Oct 19, 2015 at 07:46:51AM -1000, Richard Henderson wrote:
>> On 10/19/2015 07:30 AM, Eduardo Habkost wrote:
> +/* Notice when we should enable calls to bpt_io.  */
> +return (hw_breakpoint_enabled(env->dr[7], index)
> +? HF_IOBPT_MASK : 0);
>>> checkpatch.pl error:
>>>
>>>   ERROR: return is not a function, parentheses are not required
>>>   #57: FILE: target-i386/bpt_helper.c:69:
>>>   +return (hw_breakpoint_enabled(env->dr[7], index)
>>>
>>>   total: 1 errors, 0 warnings, 242 lines checked
>>>
>>> I will fix it in v3.
>>
>> In this case checkpatch is wrong, imo.  The parenthesis are not there to
>> "make return a function", but to make the multi-line expression indent
>> properly.
> 
> I understand if one thinks the expression looks better with the parenthesis,
> but I fail to see why they are needed to indent the expression properly.

Because Emacs indents this:

> +return hw_breakpoint_enabled(env->dr[7], index)
> +   ? HF_IOBPT_MASK : 0;

with the ? under the second "r" of "return", while it indents this as
written:

> -return (hw_breakpoint_enabled(env->dr[7], index)
> -? HF_IOBPT_MASK : 0);

Another random example:

static bool sdl_check_format(DisplayChangeListener *dcl,
 pixman_format_code_t format)
{
/*
 * We let SDL convert for us a few more formats than,
 * the native ones. Thes are the ones I have tested.
 */
return (format == PIXMAN_x8r8g8b8 ||
format == PIXMAN_b8g8r8x8 ||
format == PIXMAN_x1r5g5b5 ||
format == PIXMAN_r5g6b5);
}

There's no unanimity though, so your v3 is okay too.

Paolo

Re: [Qemu-devel] [PATCH 1/2] vl: trivial: minor tweaks to a max-cpu error msg

[Paolo Bonzini]

On 19/10/2015 20:51, Eduardo Habkost wrote:
> On Sun, Oct 18, 2015 at 07:35:27PM +0200, Andrew Jones wrote:
>> Signed-off-by: Andrew Jones 
> 
> Reviewed-by: Eduardo Habkost 
> Acked-by: Eduardo Habkost 
> 
> If this can go through my tree, please let me know.

Sure, why not.

Paolo

>> ---
>>  vl.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/vl.c b/vl.c
>> index 7c806a2428399..9a64b75ebbd24 100644
>> --- a/vl.c
>> +++ b/vl.c
>> @@ -4080,8 +4080,8 @@ int main(int argc, char **argv, char **envp)
>>  
>>  machine_class->max_cpus = machine_class->max_cpus ?: 1; /* Default to 
>> UP */
>>  if (max_cpus > machine_class->max_cpus) {
>> -fprintf(stderr, "Number of SMP cpus requested (%d), exceeds max 
>> cpus "
>> -"supported by machine `%s' (%d)\n", max_cpus,
>> +fprintf(stderr, "Number of SMP CPUs requested (%d) exceeds max CPUs 
>> "
>> +"supported by machine '%s' (%d)\n", max_cpus,
>>  machine_class->name, machine_class->max_cpus);
>>  exit(1);
>>  }
>> -- 
>> 2.4.3
>>
> 

Re: [Qemu-devel] [PATCH v2 02/16] sockets: move qapi_copy_SocketAddress into qemu-sockets.c

[Paolo Bonzini]

On 20/10/2015 00:05, Eric Blake wrote:
> > -qiv = qmp_input_visitor_new(obj);
> > -iv = qmp_input_get_visitor(qiv);
> > -visit_type_SocketAddress(iv, p_dest, NULL, &error_abort);
> > -qmp_input_visitor_cleanup(qiv);
> > -qobject_decref(obj);
> Interesting approach - it means that this copy will work no matter what
> further extensions we add into the qapi type.  But rather heavyweight
> compared to just doing a memberwise copy, no?  At any rate, this commit
> is straight code motion, so you did it correctly, but we may want to
> simplify things in a later commit.

A memberwise copy requires you to allocate embedded objects (I'm not
sure whether your boxing changes can simplify this).

Paolo

Re: [Qemu-devel] [PATCH v9 05/17] qapi: Unbox base members

[Markus Armbruster]

Eric Blake  writes:

> Rather than storing a base class as a pointer to a box, just
> store the fields of that base class in the same order, so that
> a child struct can be safely cast to its parent.  This gives
> less malloc overhead, less pointer dereferencing, and even less
> generated code.

Lovely!

> Without boxing, the corner case of one empty struct having
> another empty struct as its base type now requires inserting a
> dummy member (previously, the pointer to the base would have
> sufficed).
>
> And now that we no longer consume a 'base' member in the generated
> C struct, we can delete the former negative struct-base-clash-base
> test and replace it with a positive test in qapi-schema-test that
> ensures we don't reintroduce the naming collision.

This test protects against us foolishly adding a member called base to
the generated struct, but provides no protection against equally foolish
additions with other names.  I believe someone adding base back is about
as likely as someone adding other crap.  Therefore, I doubt the positive
test is worthwhile.

> Compare to the earlier commit 1e6c1616a "qapi: Generate a nicer
> struct for flat unions".

Should we mention the struct can be cast to its base?

> Signed-off-by: Eric Blake 
>
> ---
> v9: (no v6-8): hoist from v5 34/46, rebase to master
> ---
>  hmp.c |  6 +++---
>  scripts/qapi-types.py | 29 
> ++-
>  scripts/qapi-visit.py |  9 ++---
>  tests/Makefile|  1 -
>  tests/qapi-schema/qapi-schema-test.json   |  4 
>  tests/qapi-schema/qapi-schema-test.out|  3 +++
>  tests/qapi-schema/struct-base-clash-base.err  |  0
>  tests/qapi-schema/struct-base-clash-base.exit |  1 -
>  tests/qapi-schema/struct-base-clash-base.json |  9 -
>  tests/qapi-schema/struct-base-clash-base.out  |  5 -
>  tests/test-qmp-commands.c | 15 +-
>  tests/test-qmp-event.c|  8 ++--
>  tests/test-qmp-input-visitor.c|  4 ++--
>  tests/test-qmp-output-visitor.c   | 12 ---
>  tests/test-visitor-serialization.c| 14 ++---
>  ui/spice-core.c   | 23 -
>  ui/vnc.c  | 20 +-
>  17 files changed, 72 insertions(+), 91 deletions(-)
>  delete mode 100644 tests/qapi-schema/struct-base-clash-base.err
>  delete mode 100644 tests/qapi-schema/struct-base-clash-base.exit
>  delete mode 100644 tests/qapi-schema/struct-base-clash-base.json
>  delete mode 100644 tests/qapi-schema/struct-base-clash-base.out
>
> diff --git a/hmp.c b/hmp.c
> index 5048eee..88fd804 100644
> --- a/hmp.c
> +++ b/hmp.c
> @@ -569,8 +569,8 @@ void hmp_info_vnc(Monitor *mon, const QDict *qdict)
>  for (client = info->clients; client; client = client->next) {
>  monitor_printf(mon, "Client:\n");
>  monitor_printf(mon, " address: %s:%s\n",
> -   client->value->base->host,
> -   client->value->base->service);
> +   client->value->host,
> +   client->value->service);
>  monitor_printf(mon, "  x509_dname: %s\n",
> client->value->x509_dname ?
> client->value->x509_dname : "none");
> @@ -638,7 +638,7 @@ void hmp_info_spice(Monitor *mon, const QDict *qdict)
>  for (chan = info->channels; chan; chan = chan->next) {
>  monitor_printf(mon, "Channel:\n");
>  monitor_printf(mon, " address: %s:%s%s\n",
> -   chan->value->base->host, chan->value->base->port,
> +   chan->value->host, chan->value->port,
> chan->value->tls ? " [tls]" : "");
>  monitor_printf(mon, " session: %" PRId64 "\n",
> chan->value->connection_id);

Here you can see the the base box going away.

> diff --git a/scripts/qapi-types.py b/scripts/qapi-types.py
> index 4fe618e..bcef39d 100644
> --- a/scripts/qapi-types.py
> +++ b/scripts/qapi-types.py
> @@ -51,8 +51,19 @@ def gen_struct_field(name, typ, optional):
>  return ret
>
>
> -def gen_struct_fields(members):
> +def gen_struct_fields(members, base, nested=False):
>  ret = ''
> +if base:
> +if not nested:
> +ret += mcgen('''
> +/* Members inherited from %(c_name)s: */
> +''',
> + c_name=base.c_name())
> +ret += gen_struct_fields(base.local_members, base.base, True)
> +if not nested:
> +ret += mcgen('''
> +/* Own members: */
> +''')

Before: gen_struct_fields() emits *own* fields.

After: it emits *all* fields.

Since the signature changes, all callers are visible in the patch, and
can be reviewed.

Co

[Qemu-devel] [PULL 2/2] vmsvga: more cursor checks

[Gerd Hoffmann]

Check the cursor size more carefully.  Also switch to unsigned while
being at it, so they can't be negative.

Signed-off-by: Gerd Hoffmann 
---
 hw/display/vmware_vga.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/hw/display/vmware_vga.c b/hw/display/vmware_vga.c
index 8e93509..9354037 100644
--- a/hw/display/vmware_vga.c
+++ b/hw/display/vmware_vga.c
@@ -488,10 +488,10 @@ static inline int vmsvga_fill_rect(struct vmsvga_state_s 
*s,
 #endif
 
 struct vmsvga_cursor_definition_s {
-int width;
-int height;
+uint32_t width;
+uint32_t height;
 int id;
-int bpp;
+uint32_t bpp;
 int hot_x;
 int hot_y;
 uint32_t mask[1024];
@@ -658,7 +658,10 @@ static void vmsvga_fifo_run(struct vmsvga_state_s *s)
 cursor.bpp = vmsvga_fifo_read(s);
 
 args = SVGA_BITMAP_SIZE(x, y) + SVGA_PIXMAP_SIZE(x, y, cursor.bpp);
-if (SVGA_BITMAP_SIZE(x, y) > sizeof cursor.mask ||
+if (cursor.width > 256 ||
+cursor.height > 256 ||
+cursor.bpp > 32 ||
+SVGA_BITMAP_SIZE(x, y) > sizeof cursor.mask ||
 SVGA_PIXMAP_SIZE(x, y, cursor.bpp) > sizeof cursor.image) {
 goto badcmd;
 }
-- 
1.8.3.1

Re: [Qemu-devel] [PATCH] qxl: lock current_async update in qxl_soft_reset

[Paolo Bonzini]

On 20/10/2015 09:58, Gerd Hoffmann wrote:
> Cc: Paolo Bonzini 
> Signed-off-by: Gerd Hoffmann 
> ---
>  hw/display/qxl.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/hw/display/qxl.c b/hw/display/qxl.c
> index 9c961da..20dc72e 100644
> --- a/hw/display/qxl.c
> +++ b/hw/display/qxl.c
> @@ -1156,7 +1156,9 @@ static void qxl_soft_reset(PCIQXLDevice *d)
>  trace_qxl_soft_reset(d->id);
>  qxl_check_state(d);
>  qxl_clear_guest_bug(d);
> +qemu_mutex_lock(&d->async_lock);
>  d->current_async = QXL_UNDEFINED_IO;
> +qemu_mutex_unlock(&d->async_lock);
>  
>  if (d->id == 0) {
>  qxl_enter_vga_mode(d);
> 

Thanks, this should fix a defect report from Coverity.

Reviewed-by: Paolo Bonzini 

[Qemu-devel] [PULL 1/2] ppc/spapr: Allow VIRTIO_VGA

[Gerd Hoffmann]

From: Benjamin Herrenschmidt 

It works fine with the Linux driver out of the box

Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Gerd Hoffmann 
---
 default-configs/ppc64-softmmu.mak | 1 +
 hw/ppc/spapr.c| 1 +
 2 files changed, 2 insertions(+)

diff --git a/default-configs/ppc64-softmmu.mak 
b/default-configs/ppc64-softmmu.mak
index e77cb1a..bb71b23 100644
--- a/default-configs/ppc64-softmmu.mak
+++ b/default-configs/ppc64-softmmu.mak
@@ -3,6 +3,7 @@
 include pci.mak
 include sound.mak
 include usb.mak
+CONFIG_VIRTIO_VGA=y
 CONFIG_ISA_MMIO=y
 CONFIG_ESCC=y
 CONFIG_M48T59=y
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index d1b0e53..3852ad1 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -1169,6 +1169,7 @@ static int spapr_vga_init(PCIBus *pci_bus)
 case VGA_DEVICE:
 return true;
 case VGA_STD:
+case VGA_VIRTIO:
 return pci_vga_init(pci_bus) != NULL;
 default:
 fprintf(stderr, "This vga model is not supported,"
-- 
1.8.3.1

Re: [Qemu-devel] PING: [PATCH v4 0/7] qom: more efficient object property handling

[Paolo Bonzini]

On 20/10/2015 13:38, Pavel Fedin wrote:
>  Hello! Is there any progress on this?
>  6/7 significantly improves startup performance, i'd like to have it accepted.

Me too. :)

I am waiting for Andreas, since he's the maintainer for QOM.

Paolo

> 
>> -Original Message-
>> From: qemu-devel-bounces+p.fedin=samsung@nongnu.org [mailto:qemu-devel-
>> bounces+p.fedin=samsung@nongnu.org] On Behalf Of Pavel Fedin
>> Sent: Wednesday, October 14, 2015 9:58 AM
>> To: 'Daniel P. Berrange'; qemu-devel@nongnu.org
>> Cc: 'Paolo Bonzini'; 'Markus Armbruster'; 'Andreas Färber'
>> Subject: Re: [Qemu-devel] [PATCH v4 0/7] qom: more efficient object property 
>> handling
>>
>>  Hello!
>>
>>> This series introduces a concept of object property iterators
>>> to QOM so callers are insulated from the specific data structures
>>> used for storing properties against objects/classes. It then
>>> converts Object to use a GHashTable for storing properties.
>>> Finally it introduces ObjectClass properties.
>>
>>  Tested-by: Pavel Fedin 
>>
>>> Probably the only controversial thing is the item Pavel points
>>> out about object_child_foreach iterators now being forbidden
>>> from modifying the object composition tree.
>>
>>  As i already wrote, current code does not modify the tree. If necessary, it 
>> is possible to
>> work around (e. g. make a decision about modification, stop iteration, then 
>> do the
>> modification). I think this would pop up anyway if we change list to 
>> anything else. IMHO it's
>> better just to acknowledge that we should not modify our tree inside 
>> iterator.
>>
>> Kind regards,
>> Pavel Fedin
>> Expert Engineer
>> Samsung Electronics Research center Russia
>>
> 
> 

[Qemu-devel] [PULL 0/2] vga: enable virtio-vga for pseries, vmsvga cursor checks.

[Gerd Hoffmann]

  Hi,

vga patch queue, featuring two small fixes.

please pull,
  Gerd

The following changes since commit 26c7be842637ee65a79cd77f96a99c23ddcd90ad:

  Merge remote-tracking branch 'remotes/sstabellini/tags/2015-10-19-tag' into 
staging (2015-10-19 12:13:27 +0100)

are available in the git repository at:


  git://git.kraxel.org/qemu tags/pull-vga-20151020-1

for you to fetch changes up to 5829b097204189c56dd1fb62c7f827360394bb39:

  vmsvga: more cursor checks (2015-10-20 09:26:36 +0200)


vga: enable virtio-vga for pseries, vmsvga cursor checks.


Benjamin Herrenschmidt (1):
  ppc/spapr: Allow VIRTIO_VGA

Gerd Hoffmann (1):
  vmsvga: more cursor checks

 default-configs/ppc64-softmmu.mak |  1 +
 hw/display/vmware_vga.c   | 11 +++
 hw/ppc/spapr.c|  1 +
 3 files changed, 9 insertions(+), 4 deletions(-)

Re: [Qemu-devel] [PATCH 1/2] net: make iov_to_buf take right size argument in nc_sendv_compat()

[Paolo Bonzini]

On 20/10/2015 09:20, Jason Wang wrote:
> 
> 
> On 10/20/2015 09:51 AM, Yang Hongyang wrote:
>> We want "buf, sizeof(buf)" here.  sizeof(buffer) is the size of a
>> pointer, which is wrong.
>> Thanks to Paolo for pointing it out.
>>
>> Signed-off-by: Yang Hongyang 
>> Cc: Jason Wang 
>> Cc: Paolo Bonzini 
>> ---
>>  net/net.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/net/net.c b/net/net.c
>> index 39af893..0c4a012 100644
>> --- a/net/net.c
>> +++ b/net/net.c
>> @@ -700,7 +700,7 @@ static ssize_t nc_sendv_compat(NetClientState *nc, const 
>> struct iovec *iov,
>>  offset = iov[0].iov_len;
>>  } else {
>>  buffer = buf;
>> -offset = iov_to_buf(iov, iovcnt, 0, buffer, sizeof(buffer));
>> +offset = iov_to_buf(iov, iovcnt, 0, buf, sizeof(buf));
>>  }
>>  
>>  if (flags & QEMU_NET_PACKET_FLAG_RAW && nc->info->receive_raw) {
> 
> Both two patches were applied in:
> 
> https://github.com/jasowang/qemu/commits/net
> 
> Thanks

Thanks!

Paolo

Re: [Qemu-devel] PING: [PATCH v4 0/7] qom: more efficient object property handling

[Daniel P. Berrange]

On Tue, Oct 20, 2015 at 02:15:53PM +0200, Paolo Bonzini wrote:
> 
> 
> On 20/10/2015 13:38, Pavel Fedin wrote:
> >  Hello! Is there any progress on this?
> >  6/7 significantly improves startup performance, i'd like to have it 
> > accepted.
> 
> Me too. :)
> 
> I am waiting for Andreas, since he's the maintainer for QOM.

Andreas had asked me to rebase the new patches against the old v2
of the class-props patch, since he already had that in his local
tree.  I'll try to get a rebased series posted today / tomorrow.


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] [PATCH] seccomp: loosen library version dependency

[dann frazier]

Drop the libseccomp required version back to 2.1.0, restoring the ability
to build w/ --enable-seccomp on Ubuntu 14.04.

Commit 4cc47f8b3cc4f32586ba2f7fce1dc267da774a69 tightened the dependency
on libseccomp from version 2.1.0 to 2.1.1. This broke building on Ubuntu
14.04, the current Ubuntu LTS release. The commit message didn't mention
any specific functional need for 2.1.1, just that it was the most recent
stable version at the time. I reviewed the changes between 2.1.0 and 2.1.1,
but it looks like that update just contained minor fixes and cleanups - no
obvious (to me) new interfaces or critical bug fixes.

Signed-off-by: dann frazier 
---
 configure | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index 913ae4a..b6f4694 100755
--- a/configure
+++ b/configure
@@ -1873,13 +1873,13 @@ fi
 
 if test "$seccomp" != "no" ; then
 if test "$cpu" = "i386" || test "$cpu" = "x86_64" &&
-$pkg_config --atleast-version=2.1.1 libseccomp; then
+$pkg_config --atleast-version=2.1.0 libseccomp; then
 libs_softmmu="$libs_softmmu `$pkg_config --libs libseccomp`"
 QEMU_CFLAGS="$QEMU_CFLAGS `$pkg_config --cflags libseccomp`"
seccomp="yes"
 else
if test "$seccomp" = "yes"; then
-feature_not_found "libseccomp" "Install libseccomp devel >= 2.1.1"
+feature_not_found "libseccomp" "Install libseccomp devel >= 2.1.0"
fi
seccomp="no"
 fi
-- 
2.6.1

[Qemu-devel] [RFC PATCH v2 2/5] kernel: Add vGICv3 ITS definitions

[Pavel Fedin]

This temporary patch adds kernel API definitions. Use proper header update
procedure after these features are released.

Signed-off-by: Pavel Fedin 
---
 linux-headers/asm-arm64/kvm.h | 1 +
 linux-headers/linux/kvm.h | 9 +++--
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/linux-headers/asm-arm64/kvm.h b/linux-headers/asm-arm64/kvm.h
index d3714c0..a4f3230 100644
--- a/linux-headers/asm-arm64/kvm.h
+++ b/linux-headers/asm-arm64/kvm.h
@@ -87,6 +87,7 @@ struct kvm_regs {
 /* Supported VGICv3 address types  */
 #define KVM_VGIC_V3_ADDR_TYPE_DIST 2
 #define KVM_VGIC_V3_ADDR_TYPE_REDIST   3
+#define KVM_VGIC_V3_ADDR_TYPE_ITS  4
 
 #define KVM_VGIC_V3_DIST_SIZE  SZ_64K
 #define KVM_VGIC_V3_REDIST_SIZE(2 * SZ_64K)
diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
index dcc410e..32938d7 100644
--- a/linux-headers/linux/kvm.h
+++ b/linux-headers/linux/kvm.h
@@ -843,7 +843,10 @@ struct kvm_irq_routing_msi {
__u32 address_lo;
__u32 address_hi;
__u32 data;
-   __u32 pad;
+   union {
+   __u32 pad;
+   __u32 devid;
+   };
 };
 
 struct kvm_irq_routing_s390_adapter {
@@ -982,12 +985,14 @@ struct kvm_one_reg {
__u64 addr;
 };
 
+#define KVM_MSI_VALID_DEVID(1U << 0)
 struct kvm_msi {
__u32 address_lo;
__u32 address_hi;
__u32 data;
__u32 flags;
-   __u8  pad[16];
+   __u32 devid;
+   __u8  pad[12];
 };
 
 struct kvm_arm_device_addr {
-- 
2.4.4

[Qemu-devel] [RFC PATCH v2 3/5] kvm_arm: Pass requester ID to MSI routing functions

[Pavel Fedin]

Introduce global kvm_arm_msi_use_devid flag and pass device IDs in
kvm_arch_fixup_msi_route(). Device IDs are required by the ITS.

Signed-off-by: Pavel Fedin 
---
 target-arm/kvm.c | 6 ++
 target-arm/kvm_arm.h | 3 +++
 2 files changed, 9 insertions(+)

diff --git a/target-arm/kvm.c b/target-arm/kvm.c
index 79ef4c6..aad48a5 100644
--- a/target-arm/kvm.c
+++ b/target-arm/kvm.c
@@ -23,6 +23,7 @@
 #include "cpu.h"
 #include "internals.h"
 #include "hw/arm/arm.h"
+#include "hw/pci/pci.h"
 #include "exec/memattrs.h"
 
 const KVMCapabilityInfo kvm_arch_required_capabilities[] = {
@@ -30,6 +31,7 @@ const KVMCapabilityInfo kvm_arch_required_capabilities[] = {
 };
 
 static bool cap_has_mp_state;
+bool kvm_arm_msi_use_devid = 0;
 
 int kvm_arm_vcpu_init(CPUState *cs)
 {
@@ -607,6 +609,10 @@ int kvm_arm_vgic_probe(void)
 int kvm_arch_fixup_msi_route(struct kvm_irq_routing_entry *route,
  uint64_t address, uint32_t data, PCIDevice *dev)
 {
+if (kvm_arm_msi_use_devid) {
+route->flags = KVM_MSI_VALID_DEVID;
+route->u.msi.devid = pci_requester_id(dev);
+}
 return 0;
 }
 
diff --git a/target-arm/kvm_arm.h b/target-arm/kvm_arm.h
index 0ec221b..181ff37 100644
--- a/target-arm/kvm_arm.h
+++ b/target-arm/kvm_arm.h
@@ -120,6 +120,9 @@ bool write_kvmstate_to_list(ARMCPU *cpu);
 void kvm_arm_reset_vcpu(ARMCPU *cpu);
 
 #ifdef CONFIG_KVM
+
+extern bool kvm_arm_msi_use_devid;
+
 /**
  * kvm_arm_create_scratch_host_vcpu:
  * @cpus_to_try: array of QEMU_KVM_ARM_TARGET_* values (terminated with
-- 
2.4.4

Re: [Qemu-devel] [PATCH] net: Remove duplicate data from query-rx-filter on multiqueue net devices

[Jason Wang]

On 10/19/2015 09:04 PM, Vladislav Yasevich wrote:
> When responding to a query-rx-filter command on a multiqueue
> netdev, qemu reports the data for each queue.  The data, however,
> is not per-queue, but per device and the same data is reported
> multiple times.  This causes confusion and may also cause extra
> unnecessary processing when looking at the data.
>
> Commit 638fb14169 (net: Make qmp_query_rx_filter() with name argument
> more obvious) partially addresses this issue, by limiting the output
> when the name is specified.  However, when the name is not specified,
> the issue still persists.
>
> Signed-off-by: Vladislav Yasevich 
> ---
>  net/net.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/net/net.c b/net/net.c
> index 39af893..a8cfeba 100644
> --- a/net/net.c
> +++ b/net/net.c
> @@ -1219,6 +1219,12 @@ RxFilterInfoList *qmp_query_rx_filter(bool has_name, 
> const char *name,
>  continue;
>  }
>  
> +/* only query information on queue 0 since the info is per nic,
> + * not per queue
> + */
> +if (nc->queue_index != 0)
> +continue;
> +
>  if (nc->info->query_rx_filter) {
>  info = nc->info->query_rx_filter(nc);
>  entry = g_malloc0(sizeof(*entry));

Applied in https://github.com/jasowang/qemu/commits/net

Thanks

Re: [Qemu-devel] PING: [PATCH v4 0/7] qom: more efficient object property handling

[Andreas Färber]

Am 20.10.2015 um 14:15 schrieb Paolo Bonzini:
> On 20/10/2015 13:38, Pavel Fedin wrote:
>>  Hello! Is there any progress on this?
>>  6/7 significantly improves startup performance, i'd like to have it 
>> accepted.
> 
> Me too. :)
> 
> I am waiting for Andreas, since he's the maintainer for QOM.

Pavel, adding a Tested-by does not automagically make the patch accepted.

Two problems apart from time: 1) Discussions about iterator design, 2)
lack of test cases, and that applies to iterator-less v2, too. Circles
back to me (or someone) looking into qom-proplist test.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg)

[Qemu-devel] [PATCH] qxl: lock current_async update in qxl_soft_reset

[Gerd Hoffmann]

Cc: Paolo Bonzini 
Signed-off-by: Gerd Hoffmann 
---
 hw/display/qxl.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/hw/display/qxl.c b/hw/display/qxl.c
index 9c961da..20dc72e 100644
--- a/hw/display/qxl.c
+++ b/hw/display/qxl.c
@@ -1156,7 +1156,9 @@ static void qxl_soft_reset(PCIQXLDevice *d)
 trace_qxl_soft_reset(d->id);
 qxl_check_state(d);
 qxl_clear_guest_bug(d);
+qemu_mutex_lock(&d->async_lock);
 d->current_async = QXL_UNDEFINED_IO;
+qemu_mutex_unlock(&d->async_lock);
 
 if (d->id == 0) {
 qxl_enter_vga_mode(d);
-- 
1.8.3.1

Re: [Qemu-devel] [PULL 0/1] virtio-input: ignore events until the guest driver is ready

[Peter Maydell]

On 20 October 2015 at 08:11, Gerd Hoffmann  wrote:
>   Hi,
>
> One more pretty small queue, input with a single bugfix.
>
> please pull,
>   Gerd
>
> The following changes since commit 26c7be842637ee65a79cd77f96a99c23ddcd90ad:
>
>   Merge remote-tracking branch 'remotes/sstabellini/tags/2015-10-19-tag' into 
> staging (2015-10-19 12:13:27 +0100)
>
> are available in the git repository at:
>
>
>   git://git.kraxel.org/qemu tags/pull-input-20151020-1
>
> for you to fetch changes up to d9460a7557672af9c4d9d4f153200d1075ed5a78:
>
>   virtio-input: ignore events until the guest driver is ready (2015-10-20 
> 08:53:40 +0200)
>
> 
> virtio-input: ignore events until the guest driver is ready
>

Applied, thanks.

-- PMM

Re: [Qemu-devel] [PATCH v3 3/5] virtio-9p: block hot-unplug when device is active

[Michael S. Tsirkin]

On Tue, Oct 20, 2015 at 11:17:00AM +0200, Greg Kurz wrote:
> Hot-unplug of an active virtio-9p device is not currently supported. Until
> we have that, let's block hot-unplugging when the 9p share is mounted in
> the guest.
> 
> This patch implements a hot-unplug blocker feature like we already have for
> migration. Both virtio-9p-pci and virtio-9p-ccw were adapted accordingly.
> 
> Signed-off-by: Greg Kurz 

I'm not sure that's right.
This isn't what we do for other devices.
Why doesn't unplug request cause filesystem to be unmounted?
Isn't this just a guest bug?
And if yes, why do we need a blocker in qemu?

> ---
>  hw/9pfs/virtio-9p.c|   14 ++
>  hw/9pfs/virtio-9p.h|2 ++
>  hw/s390x/virtio-ccw.c  |8 
>  hw/virtio/virtio-pci.c |8 
>  4 files changed, 32 insertions(+)
> 
> diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9p.c
> index f972731f5a8d..bbf39ed33983 100644
> --- a/hw/9pfs/virtio-9p.c
> +++ b/hw/9pfs/virtio-9p.c
> @@ -345,6 +345,7 @@ static int put_fid(V9fsPDU *pdu, V9fsFidState *fidp)
>  migrate_del_blocker(pdu->s->migration_blocker);
>  error_free(pdu->s->migration_blocker);
>  pdu->s->migration_blocker = NULL;
> +pdu->s->unplug_is_blocked = false;
>  }
>  }
>  return free_fid(pdu, fidp);
> @@ -991,6 +992,7 @@ static void v9fs_attach(void *opaque)
> "Migration is disabled when VirtFS export path '%s' is 
> mounted in the guest using mount_tag '%s'",
> s->ctx.fs_root ? s->ctx.fs_root : "NULL", s->tag);
>  migrate_add_blocker(s->migration_blocker);
> +s->unplug_is_blocked = true;
>  }
>  out:
>  put_fid(pdu, fidp);
> @@ -3288,6 +3290,18 @@ void handle_9p_output(VirtIODevice *vdev, VirtQueue 
> *vq)
>  free_pdu(s, pdu);
>  }
>  
> +bool v9fs_unplug_is_blocked(V9fsState *s, Error **errp)
> +{
> +if (s->unplug_is_blocked) {
> +error_setg(errp,
> +   "Unplug is disabled when VirtFS export path '%s' is 
> mounted"
> +   " in the guest using mount_tag '%s'",
> +   s->ctx.fs_root ? s->ctx.fs_root : "NULL", s->tag);
> +return false;
> +}
> +return true;
> +}
> +
>  static void __attribute__((__constructor__)) virtio_9p_set_fd_limit(void)
>  {
>  struct rlimit rlim;
> diff --git a/hw/9pfs/virtio-9p.h b/hw/9pfs/virtio-9p.h
> index 2e7d48857083..8d4cbed2a5c4 100644
> --- a/hw/9pfs/virtio-9p.h
> +++ b/hw/9pfs/virtio-9p.h
> @@ -218,6 +218,7 @@ typedef struct V9fsState
>  CoRwlock rename_lock;
>  int32_t root_fid;
>  Error *migration_blocker;
> +bool unplug_is_blocked;
>  V9fsConf fsconf;
>  } V9fsState;
>  
> @@ -381,6 +382,7 @@ extern void v9fs_path_free(V9fsPath *path);
>  extern void v9fs_path_copy(V9fsPath *lhs, V9fsPath *rhs);
>  extern int v9fs_name_to_path(V9fsState *s, V9fsPath *dirpath,
>   const char *name, V9fsPath *path);
> +extern bool v9fs_unplug_is_blocked(V9fsState *s, Error **errp);
>  
>  #define pdu_marshal(pdu, offset, fmt, args...)  \
>  v9fs_marshal(pdu->elem.in_sg, pdu->elem.in_num, offset, 1, fmt, ##args)
> diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c
> index fb103b78ac28..5c13072ec96e 100644
> --- a/hw/s390x/virtio-ccw.c
> +++ b/hw/s390x/virtio-ccw.c
> @@ -1924,6 +1924,13 @@ static void virtio_ccw_9p_realize(VirtioCcwDevice 
> *ccw_dev, Error **errp)
>  }
>  }
>  
> +static bool virtio_ccw_9p_unplug_is_blocked(DeviceState *dev, Error **errp)
> +{
> +V9fsCCWState *v9fs_ccw_dev = VIRTIO_9P_CCW(dev);
> +
> +return v9fs_unplug_is_blocked(&v9fs_ccw_dev->vdev, errp);
> +}
> +
>  static void virtio_ccw_9p_class_init(ObjectClass *klass, void *data)
>  {
>  DeviceClass *dc = DEVICE_CLASS(klass);
> @@ -1931,6 +1938,7 @@ static void virtio_ccw_9p_class_init(ObjectClass 
> *klass, void *data)
>  
>  k->exit = virtio_ccw_exit;
>  k->realize = virtio_ccw_9p_realize;
> +dc->unplug_is_blocked = virtio_ccw_9p_unplug_is_blocked;
>  dc->reset = virtio_ccw_reset;
>  dc->props = virtio_ccw_9p_properties;
>  set_bit(DEVICE_CATEGORY_STORAGE, dc->categories);
> diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
> index e5c406d1d255..bf0d516528ee 100644
> --- a/hw/virtio/virtio-pci.c
> +++ b/hw/virtio/virtio-pci.c
> @@ -1015,6 +1015,13 @@ static void virtio_9p_pci_realize(VirtIOPCIProxy 
> *vpci_dev, Error **errp)
>  object_property_set_bool(OBJECT(vdev), true, "realized", errp);
>  }
>  
> +static bool virtio_9p_pci_unplug_is_blocked(DeviceState *dev, Error **errp)
> +{
> +V9fsPCIState *v9fs_pci_dev = VIRTIO_9P_PCI(dev);
> +
> +return v9fs_unplug_is_blocked(&v9fs_pci_dev->vdev, errp);
> +}
> +
>  static Property virtio_9p_pci_properties[] = {
>  DEFINE_PROP_BIT("ioeventfd", VirtIOPCIProxy, flags,
>  VIRTIO_PCI_FLAG_USE_IOEVENTFD_BIT, true),
> @@ -1035,6 +1042,7 @@ static vo

Re: [Qemu-devel] [PULL v2 0/7] fw_cfg: add dma interface, add strings via cmdline.

[Peter Maydell]

On 20 October 2015 at 07:11, Gerd Hoffmann  wrote:
>   Hi,
>
> Updated fw_cfg pull, with both old gcc build failure and make check
> error fixed.
>
> please pull,
>   Gerd
>
> The following changes since commit 526d5809a0714edc7f19196f14ec2e607dbd9753:
>
>   Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into 
> staging (2015-10-19 10:52:39 +0100)
>
> are available in the git repository at:
>
>
>   git://git.kraxel.org/qemu tags/pull-fw_cfg-20151020-1
>
> for you to fetch changes up to 2cc06a8843ace3d03464032eb3c74bc6e2b07579:
>
>   fw_cfg: Define a static signature to be returned on DMA port reads 
> (2015-10-19 15:26:54 +0200)
>
> 
> fw_cfg: add dma interface, add strings via cmdline.
>
> 

Applied, thanks.

-- PMM

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Laszlo Ersek]

On 10/20/15 13:59, Stefano Stabellini wrote:
> On Mon, 19 Oct 2015, Laszlo Ersek wrote:
>> On 10/16/15 21:09, Laszlo Ersek wrote:
>>> On 10/16/15 13:34, Fabio Fantoni wrote:
 Il 16/10/2015 12:47, Stefano Stabellini ha scritto:
> On Fri, 16 Oct 2015, Fabio Fantoni wrote:
>> Il 16/10/2015 12:13, Anthony PERARD ha scritto:
>>> On Fri, Oct 16, 2015 at 10:32:44AM +0200, Fabio Fantoni wrote:
 Il 15/10/2015 20:02, Anthony PERARD ha scritto:
> On Thu, Oct 15, 2015 at 06:27:17PM +0200, Fabio Fantoni wrote:
>> Il 14/10/2015 13:06, Stefano Stabellini ha scritto:
>>> I would suggest Fabio to avoid AHCI disks altogether and just use
>>> OVMF
>>> with PV disks only and Anthony's patch to libxl to avoid creating
>>> any
>>> IDE disks: http://marc.info/?l=xen-devel&m=144482080812353.
>>>
>>> Would that work for you?
>> Thanks for the advice, I tried it:
>> https://github.com/Fantu/Xen/commits/rebase/m2r-testing-4.6
>>
>> I installed W10 pro 64 bit with ide disk, installed the win pv
>> drivers
>> and
>> after changed to xvdX instead hdX, is the only change needed, right?
>> Initial boot is ok (ovmf part about pv disks seems ok) but windows
>> boot
>> fails with problem with pv drivers.
>> In attachment full qemu log with xen_platform trace and domU's xl
>> cfg.
>>
>> Someone have windows domUs with ovmf and pv disks only working?
>> If yes
>> can
>> tell me the difference to understand what can be the problem please?
> When I worked on the PV disk implementation in OVMF, I was able to
> boot
> a Windows 8 with pv disk only.
>
> I don't have access to the guest configuration I was using, but I
> think
> one
> difference would be the viridian setting, I'm pretty sure I did
> not set
> it.
>
 I tried with viridian disabled but did the same thing, looking
 cdrom as
 latest thing before xenbug trace in qemu log I tried also to remove
 it but
 also in this case don't boot correctly, full qemu log in attachment.
 I don't know if is a ovmf thing to improve (like what seems in
 Laszlo and
 Kevin mails) or xen winpv drivers unexpected case, have you tried also
 with
 latest winpv builds? (for exclude regression)
>>> No, I did not tried the latest winpv drivers.
>>>
>>> Sorry I can help much more that that. When I install this win8 guest
>>> tried
>>> to boot it with pv drivers only, that was more than a year ago. I
>>> have not
>>> check if it's still working. (Also I can not try anything more recent,
>>> right now.)
>>>
>> I did many other tests, retrying with ide first boot working but show pv
>> devices not working, I did another reboot (with ide) and pv devices was
>> working, after I retried with pv (xvdX) and boot correctly.
>> After other tests I found that with empty cdrom device (required for xl
>> cd-insert/cd-eject) boot stop at start (tianocore image), same result
>> with ide
>> instead.
>>  From xl cfg:
>> disk=['/mnt/vm/disks/W10UEFI.disk1.cow-sn1,qcow2,xvda,rw',',raw,xvdb,ro,cdrom']
>>
>> With seabios domU boot also with empty cdrom.
>> In qemu log I found only these that can be related:
>>> xen be: qdisk-51728: error: Could not open image: No such file or
>>> directory
>>> xen be: qdisk-51728: initialise() failed
>> And latest xl dmesg line is:
>>> (d1) Invoking OVMF ...
>> If you need more informations/test tell me and I'll post them.
> Are you saying that without any cdrom drives, it works correctly?
 Yes, I did also another test to be sure, starting with ide, installing
 windows, the pv drivers, rebooting 2 times (with one at boot of time
 boot with ide only and without net and disks pv drivers working) and
 after rebooting with pv disks (xvdX) works.
 With cdrom not empty (with iso) works, with empty not, tried with both
 ide (hdX) and pv (xvdX).
 Empty cdrom not working with ovmf I suppose is ovmf bug or inexpected case.
 About major of winpv drivers problem at boot I suppose can be solved
 improving ovmf and winpv driver removing bad hybrid thing actually, but
 I have too low knowledge to be sure.
 About the problem of pv start after install that requiring at least 2
 reboot can be also a windows 10 problem (only a suppose).

 About empty cdrom with ovmf can be solved please?

>>>
>>> Sorry, I find your problem report impenetrable. :( Please slow down and
>>> try to spend time on punctuation at least.
>>>
>>> For me to make heads or tails of this, I'll need the following:
>>>
>>> - The debug output of an OVMF binary built with the DEBUG_VERBOSE bit

Re: [Qemu-devel] x86 amd64 singlestepping bug through syscall instruction

[Rudolf Marek]

Hi all,

It seems this problem was not picked by anyone from QEMU community. Is there 
other way to report this bug?


Thanks
Rudolf

--
S přátelským pozdravem / Best regards / Mit freundlichen Grüßen

Ing. Rudolf Marek
SYSGO s.r.o.
Zelený pruh 99
CZ-14800 Praha 4
Phone: +420 222138 111, +49 6136 9948 111
Fax: +420 296374890, +49 6136 9948 1 111
rudolf.ma...@sysgo.com

http://www.sysgo.com | http://www.elinos.com | http://www.pikeos.com

[Qemu-devel] [PATCH v2 2/3] target-i386: calculate vcpu's TSC rate to be migrated

[Haozhong Zhang]

If vcpu's TSC rate is not specified by the cpu option 'tsc-freq', we
will use the value returned by KVM_GET_TSC_KHZ; otherwise, we use the
user-specified value.

Signed-off-by: Haozhong Zhang 
---
 target-i386/kvm.c | 33 +
 1 file changed, 33 insertions(+)

diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 80d1a7e..698524a 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -2213,6 +2213,35 @@ static int kvm_get_debugregs(X86CPU *cpu)
 return 0;
 }
 
+static int kvm_setup_tsc_khz(X86CPU *cpu, int level)
+{
+CPUState *cs = CPU(cpu);
+CPUX86State *env = &cpu->env;
+int r;
+
+if (level < KVM_PUT_FULL_STATE)
+return 0;
+
+/*
+ * Prepare the vcpu's TSC rate (ie. env->tsc_khz_incoming) to be migrated.
+ * 1. If no user-specified value is provided, we will use the value from
+ *KVM;
+ * 2. Otherwise, we just use the user-specified value.
+ */
+if (!env->tsc_khz) {
+r = kvm_vcpu_ioctl(cs, KVM_GET_TSC_KHZ);
+if (r < 0) {
+fprintf(stderr, "KVM_GET_TSC_KHZ failed\n");
+return r;
+}
+env->tsc_khz_incoming = r;
+} else {
+env->tsc_khz_incoming = env->tsc_khz;
+}
+
+return 0;
+}
+
 int kvm_arch_put_registers(CPUState *cpu, int level)
 {
 X86CPU *x86_cpu = X86_CPU(cpu);
@@ -2248,6 +2277,10 @@ int kvm_arch_put_registers(CPUState *cpu, int level)
 if (ret < 0) {
 return ret;
 }
+ret = kvm_setup_tsc_khz(x86_cpu, level);
+if (ret < 0) {
+return ret;
+}
 ret = kvm_put_msrs(x86_cpu, level);
 if (ret < 0) {
 return ret;
-- 
2.4.8

[Qemu-devel] [PATCH v2 3/3] target-i386: load the migrated vcpu's TSC rate

[Haozhong Zhang]

Set vcpu's TSC rate to the migrated value (if any). If KVM supports TSC
scaling, guest programs will observe TSC increasing in the migrated rate
other than the host TSC rate.

The loading is controlled by a new cpu option 'load-tsc-freq'. If it is
present, then the loading will be enabled and the migrated vcpu's TSC
rate will override the value specified by the cpu option
'tsc-freq'. Otherwise, the loading will be disabled.

The setting of vcpu's TSC rate in this patch duplicates the code in
kvm_arch_init_vcpu(), so we remove the latter one.

Signed-off-by: Haozhong Zhang 
---
 target-i386/cpu.c |  1 +
 target-i386/cpu.h |  1 +
 target-i386/kvm.c | 28 +++-
 3 files changed, 21 insertions(+), 9 deletions(-)

diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index b6bb457..763ba4b 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -3144,6 +3144,7 @@ static Property x86_cpu_properties[] = {
 DEFINE_PROP_BOOL("enforce", X86CPU, enforce_cpuid, false),
 DEFINE_PROP_BOOL("kvm", X86CPU, expose_kvm, true),
 DEFINE_PROP_BOOL("save-tsc-freq", X86CPU, env.save_tsc_khz, true),
+DEFINE_PROP_BOOL("load-tsc-freq", X86CPU, env.load_tsc_khz, false),
 DEFINE_PROP_UINT32("level", X86CPU, env.cpuid_level, 0),
 DEFINE_PROP_UINT32("xlevel", X86CPU, env.cpuid_xlevel, 0),
 DEFINE_PROP_UINT32("xlevel2", X86CPU, env.cpuid_xlevel2, 0),
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index ba1a289..353f5fb 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -968,6 +968,7 @@ typedef struct CPUX86State {
 int64_t tsc_khz;
 int64_t tsc_khz_incoming;
 bool save_tsc_khz;
+bool load_tsc_khz;
 void *kvm_xsave_buf;
 
 uint64_t mcg_cap;
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 698524a..34616f5 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -743,15 +743,6 @@ int kvm_arch_init_vcpu(CPUState *cs)
 return r;
 }
 
-r = kvm_check_extension(cs->kvm_state, KVM_CAP_TSC_CONTROL);
-if (r && env->tsc_khz) {
-r = kvm_vcpu_ioctl(cs, KVM_SET_TSC_KHZ, env->tsc_khz);
-if (r < 0) {
-fprintf(stderr, "KVM_SET_TSC_KHZ failed\n");
-return r;
-}
-}
-
 if (kvm_has_xsave()) {
 env->kvm_xsave_buf = qemu_memalign(4096, sizeof(struct kvm_xsave));
 }
@@ -2223,6 +2214,25 @@ static int kvm_setup_tsc_khz(X86CPU *cpu, int level)
 return 0;
 
 /*
+ * If the cpu option 'load-tsc-freq' is present, the vcpu's TSC rate in the
+ * migrated state will be used and the overrides the user-specified vcpu's
+ * TSC rate (if any).
+ */
+if (runstate_check(RUN_STATE_INMIGRATE) &&
+env->load_tsc_khz && env->tsc_khz_incoming) {
+env->tsc_khz = env->tsc_khz_incoming;
+}
+
+r = kvm_check_extension(cs->kvm_state, KVM_CAP_TSC_CONTROL);
+if (r && env->tsc_khz) {
+r = kvm_vcpu_ioctl(cs, KVM_SET_TSC_KHZ, env->tsc_khz);
+if (r < 0) {
+fprintf(stderr, "KVM_SET_TSC_KHZ failed\n");
+return r;
+}
+}
+
+/*
  * Prepare the vcpu's TSC rate (ie. env->tsc_khz_incoming) to be migrated.
  * 1. If no user-specified value is provided, we will use the value from
  *KVM;
-- 
2.4.8

Re: [Qemu-devel] [PATCH v3 0/5] virtio-9p: hotplug and migration support

[Michael S. Tsirkin]

On Tue, Oct 20, 2015 at 11:16:40AM +0200, Greg Kurz wrote:
> We already have a blocker to prevent migration of an active virtio-9p device.
> But in fact, there is no migration support at all for 9p, even if the device
> is considered to be quiescent (when the VirtFS share is not mounted): 
> migration
> succeeds but the device is lost in the restarted guest.
> Hotunplug of a virtio-9p device is not supported either (no unrealize handler)
> and leads to a QEMU crash on the source node, if one unplugs and migrates.
> 
> This series tries to fix that and brings hotplug and migration support of
> *quiescent* virtio-9p devices.
> 
> v2->v3:
>  - renamed QDEV handler @unpluggable to @unplug_is_blocked (patches 2/5
>and 3/5)
> 
> v1->v2:
>  - introduced unplug blocker (patches 2/5 and 3/5)
>  - moved fixes to separate patches (see individual changelogs)

I have some doubts about how hotunplug is handled, but migration
looks ok.
Is there a dependency, or can I just pick savevm things meanwhile?

> ---
> 
> Greg Kurz (5):
>   virtio-9p-coth: fix init function
>   qdev: add the @unplug_is_blocked handler
>   virtio-9p: block hot-unplug when device is active
>   virtio-9p: add unrealize handler
>   virtio-9p: add savem handlers
> 
> 
>  hw/9pfs/virtio-9p-coth.c   |   22 ++
>  hw/9pfs/virtio-9p-coth.h   |2 ++
>  hw/9pfs/virtio-9p-device.c |   24 
>  hw/9pfs/virtio-9p.c|   14 ++
>  hw/9pfs/virtio-9p.h|2 ++
>  hw/core/qdev.c |4 
>  hw/s390x/virtio-ccw.c  |8 
>  hw/virtio/virtio-pci.c |8 
>  include/hw/qdev-core.h |4 
>  9 files changed, 84 insertions(+), 4 deletions(-)

Re: [Qemu-devel] PING: [PATCH v4 0/7] qom: more efficient object property handling

[Daniel P. Berrange]

On Tue, Oct 20, 2015 at 02:38:43PM +0200, Andreas Färber wrote:
> Am 20.10.2015 um 14:15 schrieb Paolo Bonzini:
> > On 20/10/2015 13:38, Pavel Fedin wrote:
> >>  Hello! Is there any progress on this?
> >>  6/7 significantly improves startup performance, i'd like to have it 
> >> accepted.
> > 
> > Me too. :)
> > 
> > I am waiting for Andreas, since he's the maintainer for QOM.
> 
> Pavel, adding a Tested-by does not automagically make the patch accepted.
> 
> Two problems apart from time: 1) Discussions about iterator design, 2)
> lack of test cases, and that applies to iterator-less v2, too. Circles
> back to me (or someone) looking into qom-proplist test.

FYI in the v4 posting, I added to the check-qom-proplist.c test case
to cover the new iterator APIs. I further added to it in the later
patches to cover the iteration of properties against classes. The v4
also has the alternative iterator design that Markus / Paolo preferred,
that avoids use of callback functions.

I can further test cases to do more coverage of object proprty handling
wrt to classes, if you want me to.

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] What's the intended use of log.h logging?

[Kevin Wolf]

Am 19.10.2015 um 16:29 hat Markus Armbruster geschrieben:
> Points I'd like to make:
> 
> 1. Logging is not tracing.  Logging logs events interesting for the
> user.  Tracing logs code execution.  It's a debugging aid.  The two
> overlap to a degree, but they're not the same.

It's hard to draw a line here because qemu is a tool for debugging
guests. So yes, we're logging code execution, which you call tracing.
It's still output meant for the user. I've been using -d often enough,
and you can easily check that I'm not a regular TCG developer. My goal
was debugging the guest, not qemu.

(By the way, it's a shame that -d int doesn't work with KVM.)

> 2. The current use of log.h seems closer to tracing than to logging.
> 
> 3. I figure our tracing needs could be served by the tracing subsystem
> with a few improvements.  The few things log.h can do that tracing can't
> yet do should be easy enough to add.  Why have two separate subsystems
> then?

I'm not objecting to this as long as the currently supported logging
doesn't get worse.

One important point for me is that our logging gives me nicely formatted
messages, for example register dumps. I'm trying to imagine this being
printed through our existing tracing functions - the horror. It would be
like using QMP query-* commands instead of HMP info, simply not made for
human readers.

Kevin

Re: [Qemu-devel] PING: [PATCH v4 0/7] qom: more efficient object property handling

[Andreas Färber]

Am 20.10.2015 um 14:54 schrieb Daniel P. Berrange:
> On Tue, Oct 20, 2015 at 02:38:43PM +0200, Andreas Färber wrote:
>> Two problems apart from time: 1) Discussions about iterator design, 2)
>> lack of test cases, and that applies to iterator-less v2, too. Circles
>> back to me (or someone) looking into qom-proplist test.
> 
> FYI in the v4 posting, I added to the check-qom-proplist.c test case
> to cover the new iterator APIs. I further added to it in the later
> patches to cover the iteration of properties against classes. The v4
> also has the alternative iterator design that Markus / Paolo preferred,
> that avoids use of callback functions.
> 
> I can further test cases to do more coverage of object proprty handling
> wrt to classes, if you want me to.

No, if that is sorted out now, I'll drop v2 and need to review v4.

Cheers,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg)

Re: [Qemu-devel] [PATCH v2 03/16] sockets: allow port to be NULL when listening on IP address

[Daniel P. Berrange]

On Mon, Oct 19, 2015 at 04:12:00PM -0600, Eric Blake wrote:
> On 10/12/2015 05:14 AM, Daniel P. Berrange wrote:
> > If the port in the SocketAddress struct is NULL, it can allow
> > the kernel to automatically select a free port. This is useful
> > in particular in unit tests to avoid a race trying to find a
> > free port to run a test case on.
> > 
> > Signed-off-by: Daniel P. Berrange 
> > ---
> >  util/qemu-sockets.c | 18 +-
> >  1 file changed, 13 insertions(+), 5 deletions(-)
> > 
> 
> Right now, the qapi documents InetSocketAddress.port as mandatory.
> Should we relax it to be optional, rather than special-casing the empty
> string "" to mean no port?

Yep, I can change qapi-schema.json to mark it optional.


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 v2 01/16] sockets: add helpers for creating SocketAddress from a socket

[Daniel P. Berrange]

On Mon, Oct 19, 2015 at 03:43:27PM -0600, Eric Blake wrote:
> On 10/12/2015 05:14 AM, Daniel P. Berrange wrote:
> > Add two helper methods that, given a socket file descriptor,
> > can return a populated SocketAddress struct containing either
> > the local or remote address information.
> > 
> > Signed-off-by: Daniel P. Berrange 
> > ---
> >  include/qemu/sockets.h |  30 ++
> >  util/qemu-sockets.c| 110 
> > +
> >  2 files changed, 140 insertions(+)
> > 
> 
> > +static SocketAddress *
> > +socket_sockaddr_to_address_inet(struct sockaddr_storage *sa,
> > +socklen_t salen,
> > +Error **errp)
> > +{
> > +char host[NI_MAXHOST];
> > +char serv[NI_MAXSERV];
> > +SocketAddress *addr;
> > +int ret;
> > +
> > +ret = getnameinfo((struct sockaddr *)sa, salen,
> > +  host, sizeof(host),
> > +  serv, sizeof(serv),
> > +  NI_NUMERICHOST | NI_NUMERICSERV);
> > +if (ret != 0) {
> > +error_setg(errp, "Cannot format numeric socket address: %s\n",
> > +   gai_strerror(ret));
> 
> No trailing \n with error_setg(), please.
> 
> > +return NULL;
> > +}
> > +
> > +addr = g_new0(SocketAddress, 1);
> > +addr->kind = SOCKET_ADDRESS_KIND_INET;
> 
> I've got pending qapi patches that rename this to addr->type,
> 
> > +addr->inet = g_new0(InetSocketAddress, 1);
> 
> and this to addr->u.inet.  Whoever merges first gets to watch the other
> guy rebase :)
> 
> > +addr->inet->host = g_strdup(host);
> > +addr->inet->port = g_strdup(serv);
> > +if (sa->ss_family == AF_INET) {
> > +addr->inet->ipv4 = true;
> > +} else {
> > +addr->inet->ipv6 = true;
> > +}
> 
> Don't we also need to set has_ipv4 and has_ipv6 appropriately?

Yes, we do.


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 v8 13/54] Move dirty page search state into separate structure

[Juan Quintela]

Juan Quintela  wrote:

Post proper list

Remove cc'd


> "Dr. David Alan Gilbert (git)"  wrote:
>> From: "Dr. David Alan Gilbert" 
>>
>> Pull the search state for one iteration of the dirty page
>> search into a structure.
>>
>> Signed-off-by: Dr. David Alan Gilbert 
>> Reviewed-by: Amit Shah 

Reviewed-by: Juan Quintela 

[Qemu-devel] [PATCH v2 1/3] target-i386: add a subsection for migrating vcpu's TSC rate

[Haozhong Zhang]

The newly added subsection 'vmstate_tsc_khz' is used by following
patches to migrate vcpu's TSC rate. For the back migration
compatibility, this subsection is not migrated on pc-*-2.4 and older
machine types by default. If users do want to migrate this subsection on
older machine types, they can enable it by giving a new cpu option
'save-tsc-freq'.

Signed-off-by: Haozhong Zhang 
---
 include/hw/i386/pc.h  |  5 +
 target-i386/cpu.c |  1 +
 target-i386/cpu.h |  2 ++
 target-i386/machine.c | 19 +++
 4 files changed, 27 insertions(+)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 0503485..7fde50f 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -300,6 +300,11 @@ bool e820_get_entry(int, uint32_t, uint64_t *, uint64_t *);
 #define PC_COMPAT_2_4 \
 HW_COMPAT_2_4 \
 {\
+.driver   = TYPE_X86_CPU,\
+.property = "save-tsc-freq",\
+.value= "off",\
+},\
+{\
 .driver   = "Haswell-" TYPE_X86_CPU,\
 .property = "abm",\
 .value= "off",\
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 05d7f26..b6bb457 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -3143,6 +3143,7 @@ static Property x86_cpu_properties[] = {
 DEFINE_PROP_BOOL("check", X86CPU, check_cpuid, false),
 DEFINE_PROP_BOOL("enforce", X86CPU, enforce_cpuid, false),
 DEFINE_PROP_BOOL("kvm", X86CPU, expose_kvm, true),
+DEFINE_PROP_BOOL("save-tsc-freq", X86CPU, env.save_tsc_khz, true),
 DEFINE_PROP_UINT32("level", X86CPU, env.cpuid_level, 0),
 DEFINE_PROP_UINT32("xlevel", X86CPU, env.cpuid_xlevel, 0),
 DEFINE_PROP_UINT32("xlevel2", X86CPU, env.cpuid_xlevel2, 0),
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index 54d9d50..ba1a289 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -966,6 +966,8 @@ typedef struct CPUX86State {
 uint32_t sipi_vector;
 bool tsc_valid;
 int64_t tsc_khz;
+int64_t tsc_khz_incoming;
+bool save_tsc_khz;
 void *kvm_xsave_buf;
 
 uint64_t mcg_cap;
diff --git a/target-i386/machine.c b/target-i386/machine.c
index 9fa0563..7d68d63 100644
--- a/target-i386/machine.c
+++ b/target-i386/machine.c
@@ -752,6 +752,24 @@ static const VMStateDescription vmstate_xss = {
 }
 };
 
+static bool tsc_khz_needed(void *opaque)
+{
+X86CPU *cpu = opaque;
+CPUX86State *env = &cpu->env;
+return env->tsc_khz_incoming && env->save_tsc_khz;
+}
+
+static const VMStateDescription vmstate_tsc_khz = {
+.name = "cpu/tsc_khz",
+.version_id = 1,
+.minimum_version_id = 1,
+.needed = tsc_khz_needed,
+.fields = (VMStateField[]) {
+VMSTATE_INT64(env.tsc_khz_incoming, X86CPU),
+VMSTATE_END_OF_LIST()
+}
+};
+
 VMStateDescription vmstate_x86_cpu = {
 .name = "cpu",
 .version_id = 12,
@@ -871,6 +889,7 @@ VMStateDescription vmstate_x86_cpu = {
 &vmstate_msr_hyperv_crash,
 &vmstate_avx512,
 &vmstate_xss,
+&vmstate_tsc_khz,
 NULL
 }
 };
-- 
2.4.8

Re: [Qemu-devel] [PATCH 1/1] vhost: set the correct queue index in case of migration with multiqueue

[Michael S. Tsirkin]

On Mon, Oct 19, 2015 at 06:41:38PM +0200, Thibaut Collet wrote:
> On Mon, Oct 19, 2015 at 5:41 PM, Michael S. Tsirkin  wrote:
> > On Mon, Oct 19, 2015 at 02:59:27PM +0200, Thibaut Collet wrote:
> >> When a live migration is started the log address to mark dirty pages is 
> >> provided
> >> to the vhost backend through the vhost_dev_set_log function.
> >> This function is called for each queue pairs but the queue index is 
> >> wrongly set:
> >> always set to the first queue pair. Then vhost backend lost descriptor 
> >> addresses
> >> of the queue pairs greater than 1 and behaviour of the vhost backend is
> >> unpredictable.
> >>
> >> The queue index is computed by taking account of the vq_index (to retrieve 
> >> the
> >> queue pair index) and calling the vhost_get_vq_index method of the backend.
> >>
> >> Signed-off-by: Thibaut Collet 
> >
> > This needs some thought to make sure we don't break the kernel vhost.
> 
> For kernel vhost my patch does nothing has vhost_get_vq_index method
> for vhost kernel subtract dev->vq_index (that was just added before)
> and idx is still equal to i.
> 
> >
> > I queued this temporarily to enable your testing but I think it would be
> > preferable to make vhost_virtqueue_set_addr for vhost_user call
> > vhost_get_vq_index internally.
> >
> 
> If I call the vhost_get_vq_index internally by vhost_user when
> vhost_virtqueue_set_addr is called I will break the
> vhost_virtqueue_start: this function calls the vhost_get_vq_index
> function for vhost user and vhost kernel to initializes the queue.

So drop vhost_get_vq_index from there as well then?


> >
> >
> >> ---
> >>  hw/virtio/vhost.c | 8 +---
> >>  1 file changed, 5 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
> >> index feeaaa4..de29968 100644
> >> --- a/hw/virtio/vhost.c
> >> +++ b/hw/virtio/vhost.c
> >> @@ -656,13 +656,14 @@ static int vhost_dev_set_features(struct vhost_dev 
> >> *dev, bool enable_log)
> >>
> >>  static int vhost_dev_set_log(struct vhost_dev *dev, bool enable_log)
> >>  {
> >> -int r, t, i;
> >> +int r, t, i, idx;
> >>  r = vhost_dev_set_features(dev, enable_log);
> >>  if (r < 0) {
> >>  goto err_features;
> >>  }
> >>  for (i = 0; i < dev->nvqs; ++i) {
> >> -r = vhost_virtqueue_set_addr(dev, dev->vqs + i, i,
> >> +idx = dev->vhost_ops->vhost_get_vq_index(dev, dev->vq_index + i);
> >> +r = vhost_virtqueue_set_addr(dev, dev->vqs + i, idx,
> >>   enable_log);
> >>  if (r < 0) {
> >>  goto err_vq;
> >> @@ -671,7 +672,8 @@ static int vhost_dev_set_log(struct vhost_dev *dev, 
> >> bool enable_log)
> >>  return 0;
> >>  err_vq:
> >>  for (; i >= 0; --i) {
> >> -t = vhost_virtqueue_set_addr(dev, dev->vqs + i, i,
> >> +idx = dev->vhost_ops->vhost_get_vq_index(dev, dev->vq_index + i);
> >> +t = vhost_virtqueue_set_addr(dev, dev->vqs + i, idx,
> >>   dev->log_enabled);
> >>  assert(t >= 0);
> >>  }
> >> --
> >> 2.1.4

Re: [Qemu-devel] [PATCH v8 27/54] postcopy: OS support test

[Juan Quintela]

"Dr. David Alan Gilbert (git)"  wrote:
> From: "Dr. David Alan Gilbert" 
>
> Provide a check to see if the OS we're running on has all the bits
> needed for postcopy.
>
> Creates postcopy-ram.c which will get most of the other helpers we need.
>
> Signed-off-by: Dr. David Alan Gilbert 
> Reviewed-by: Amit Shah 

Reviewed-by: Juan Quintela 

I still think that this bit should be in utils/*

Obvious candidates are

utils/osdep.c?


> +/*
> + * Postcopy migration for RAM
> + *
> + * Copyright 2013 Red Hat, Inc. and/or its affiliates


Ouch  it has taken some time ...

Re: [Qemu-devel] [PATCH v8 28/54] migrate_start_postcopy: Command to trigger transition to postcopy

[Juan Quintela]

"Dr. David Alan Gilbert (git)"  wrote:
> From: "Dr. David Alan Gilbert" 
>
> Once postcopy is enabled (with migrate_set_capability), the migration
> will still start on precopy mode.  To cause a transition into postcopy
> the:
>
>   migrate_start_postcopy
>
> command must be issued.  Postcopy will start sometime after this
> (when it's next checked in the migration loop).
>
> Issuing the command before migration has started will error,
> and issuing after it has finished is ignored.
>
> Signed-off-by: Dr. David Alan Gilbert 
> Reviewed-by: Eric Blake 

Reviewed-by: Juan Quintela 

Re: [Qemu-devel] [PATCH 1/1] vhost: set the correct queue index in case of migration with multiqueue

[Michael S. Tsirkin]

On Mon, Oct 19, 2015 at 02:59:27PM +0200, Thibaut Collet wrote:
> When a live migration is started the log address to mark dirty pages is 
> provided
> to the vhost backend through the vhost_dev_set_log function.
> This function is called for each queue pairs but the queue index is wrongly 
> set:
> always set to the first queue pair. Then vhost backend lost descriptor 
> addresses
> of the queue pairs greater than 1 and behaviour of the vhost backend is
> unpredictable.
> 
> The queue index is computed by taking account of the vq_index (to retrieve the
> queue pair index) and calling the vhost_get_vq_index method of the backend.
> 
> Signed-off-by: Thibaut Collet 

Thanks!
The code in question was added by:
commit a9f98bb5ebe6fb1869321dcc58e72041ae626ad8
Author: Jason Wang 
Date:   Wed Jan 30 19:12:35 2013 +0800

vhost: multiqueue support

Jason, could you comment on whether this makes sense please?
If yes - this is an old bug, and we need this on stable,
do we not?

Maybe we should refactor vhost_virtqueue_set_addr to
make it call vhost_get_vq_index internally automatically.
All callers do this anyway.
This can be a patch on top.

> ---
>  hw/virtio/vhost.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
> index feeaaa4..de29968 100644
> --- a/hw/virtio/vhost.c
> +++ b/hw/virtio/vhost.c
> @@ -656,13 +656,14 @@ static int vhost_dev_set_features(struct vhost_dev 
> *dev, bool enable_log)
>  
>  static int vhost_dev_set_log(struct vhost_dev *dev, bool enable_log)
>  {
> -int r, t, i;
> +int r, t, i, idx;
>  r = vhost_dev_set_features(dev, enable_log);
>  if (r < 0) {
>  goto err_features;
>  }
>  for (i = 0; i < dev->nvqs; ++i) {
> -r = vhost_virtqueue_set_addr(dev, dev->vqs + i, i,
> +idx = dev->vhost_ops->vhost_get_vq_index(dev, dev->vq_index + i);
> +r = vhost_virtqueue_set_addr(dev, dev->vqs + i, idx,
>   enable_log);
>  if (r < 0) {
>  goto err_vq;
> @@ -671,7 +672,8 @@ static int vhost_dev_set_log(struct vhost_dev *dev, bool 
> enable_log)
>  return 0;
>  err_vq:
>  for (; i >= 0; --i) {
> -t = vhost_virtqueue_set_addr(dev, dev->vqs + i, i,
> +idx = dev->vhost_ops->vhost_get_vq_index(dev, dev->vq_index + i);
> +t = vhost_virtqueue_set_addr(dev, dev->vqs + i, idx,
>   dev->log_enabled);
>  assert(t >= 0);
>  }
> -- 
> 2.1.4

Re: [Qemu-devel] [PATCH v8 29/54] MIGRATION_STATUS_POSTCOPY_ACTIVE: Add new migration state

[Juan Quintela]

"Dr. David Alan Gilbert (git)"  wrote:
> From: "Dr. David Alan Gilbert" 
>
> 'MIGRATION_STATUS_POSTCOPY_ACTIVE' is entered after migrate_start_postcopy
>
> 'migration_in_postcopy' is provided for other sections to know if
> they're in postcopy.
>
> Signed-off-by: Dr. David Alan Gilbert 
> Reviewed-by: David Gibson 
> Reviewed-by: Eric Blake 
> Reviewed-by: Juan Quintela 
> Reviewed-by: Amit Shah 

Just wondering


> diff --git a/migration/migration.c b/migration/migration.c
> index 5ee2c11..2ae5909 100644
> --- a/migration/migration.c
> +++ b/migration/migration.c
> @@ -439,6 +439,7 @@ static bool migration_is_active(MigrationState *ms)
>  {
>  switch (ms->state) {
>  case MIGRATION_STATUS_ACTIVE:
> +case MIGRATION_STATUS_POSTCOPY_ACTIVE:
>  case MIGRATION_STATUS_SETUP:
>  return true;
>  
> @@ -509,6 +510,39 @@ MigrationInfo *qmp_query_migrate(Error **errp)
>  
>  get_xbzrle_cache_stats(info);
>  break;
> +case MIGRATION_STATUS_POSTCOPY_ACTIVE:
> +/* Mostly the same as active; TODO add some postcopy stats */
> +info->has_status = true;
> +info->has_total_time = true;
> +info->total_time = qemu_clock_get_ms(QEMU_CLOCK_REALTIME)
> +- s->total_time;
> +info->has_expected_downtime = true;
> +info->expected_downtime = s->expected_downtime;
> +info->has_setup_time = true;
> +info->setup_time = s->setup_time;
> +
> +info->has_ram = true;
> +info->ram = g_malloc0(sizeof(*info->ram));
> +info->ram->transferred = ram_bytes_transferred();
> +info->ram->remaining = ram_bytes_remaining();
> +info->ram->total = ram_bytes_total();
> +info->ram->duplicate = dup_mig_pages_transferred();
> +info->ram->skipped = skipped_mig_pages_transferred();
> +info->ram->normal = norm_mig_pages_transferred();
> +info->ram->normal_bytes = norm_mig_bytes_transferred();
> +info->ram->dirty_pages_rate = s->dirty_pages_rate;
> +info->ram->mbps = s->mbps;
> +
> +if (blk_mig_active()) {
> +info->has_disk = true;
> +info->disk = g_malloc0(sizeof(*info->disk));
> +info->disk->transferred = blk_mig_bytes_transferred();
> +info->disk->remaining = blk_mig_bytes_remaining();
> +info->disk->total = blk_mig_bytes_total();
> +}

Are we sure that disk migration works with postcopy?  I would expect no ...

[Qemu-devel] [PATCH v2 0/3] target-i386: save/restore vcpu's TSC rate during migration

[Haozhong Zhang]

This patchset enables QEMU to save/restore vcpu's TSC rate during the
migration. When cooperating with KVM which supports TSC scaling, guest
programs can observe a consistent guest TSC rate even though they are
migrated among machines with different host TSC rates.

A pair of cpu options 'save-tsc-freq' and 'load-tsc-freq' are added to
control the migration of vcpu's TSC rate.
 * By default, the migration of vcpu's TSC rate is enabled only on
   pc-*-2.5 and newer machine types. If the cpu option 'save-tsc-freq'
   is present, the vcpu's TSC rate will be migrated from older machine
   types as well.
 * Another cpu option 'load-tsc-freq' controls whether the migrated
   vcpu's TSC rate is used. By default, QEMU will not use the migrated
   TSC rate if this option is not present. Otherwise, QEMU will use
   the migrated TSC rate and override the TSC rate given by the cpu
   option 'tsc-freq'.

Changes in v2:
 * Add a pair of cpu options 'save-tsc-freq' and 'load-tsc-freq' to
   control the migration of vcpu's TSC rate.
 * Move all logic of setting TSC rate to target-i386.
 * Remove the duplicated TSC setup in kvm_arch_init_vcpu().

Haozhong Zhang (3):
  target-i386: add a subsection for migrating vcpu's TSC rate
  target-i386: calculate vcpu's TSC rate to be migrated
  target-i386: load the migrated vcpu's TSC rate

 include/hw/i386/pc.h  |  5 +
 target-i386/cpu.c |  2 ++
 target-i386/cpu.h |  3 +++
 target-i386/kvm.c | 61 +++
 target-i386/machine.c | 19 
 5 files changed, 81 insertions(+), 9 deletions(-)

-- 
2.4.8

Re: [Qemu-devel] [PATCH v8 30/54] Avoid sending vmdescription during postcopy

[Juan Quintela]

"Dr. David Alan Gilbert (git)"  wrote:
> From: "Dr. David Alan Gilbert" 
>
> VMDescription is normally sent at the end, after all
> of the devices; however that's not the end for postcopy,
> so just don't send it when in postcopy.
>
> Signed-off-by: Dr. David Alan Gilbert 

Reviewed-by: Juan Quintela