[Qemu-devel] [PATCH] colo-compare: remove unused struct CompareChardevProps and 'props' variable

[zhanghailiang]

After commit 0a73336d, 'props' variable in find_and_check_chardev()
is unused. Remove it, togther with struct CompareChardevProps.

Signed-off-by: zhanghailiang 
---
 net/colo-compare.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/net/colo-compare.c b/net/colo-compare.c
index 47703c5..4be6fc3 100644
--- a/net/colo-compare.c
+++ b/net/colo-compare.c
@@ -92,10 +92,6 @@ typedef struct CompareClass {
 ObjectClass parent_class;
 } CompareClass;
 
-typedef struct CompareChardevProps {
-bool is_socket;
-} CompareChardevProps;
-
 enum {
 PRIMARY_IN = 0,
 SECONDARY_IN,
@@ -573,8 +569,6 @@ static int find_and_check_chardev(CharDriverState **chr,
   char *chr_name,
   Error **errp)
 {
-CompareChardevProps props;
-
 *chr = qemu_chr_find(chr_name);
 if (*chr == NULL) {
 error_setg(errp, "Device '%s' not found",
@@ -582,8 +576,6 @@ static int find_and_check_chardev(CharDriverState **chr,
 return 1;
 }
 
-memset(&props, 0, sizeof(props));
-
 if (!qemu_chr_has_feature(*chr, QEMU_CHAR_FEATURE_RECONNECTABLE)) {
 error_setg(errp, "chardev \"%s\" is not reconnectable",
chr_name);
-- 
1.8.3.1

Re: [Qemu-devel] [PATCH] colo-compare: remove unused struct CompareChardevProps and 'props' variable

[Zhang Chen]

On 10/13/2016 02:57 PM, zhanghailiang wrote:

After commit 0a73336d, 'props' variable in find_and_check_chardev()
is unused. Remove it, togther with struct CompareChardevProps.

Signed-off-by: zhanghailiang 


Reviewed-by: Zhang Chen 

Thanks
Zhang Chen


---
  net/colo-compare.c | 8 
  1 file changed, 8 deletions(-)

diff --git a/net/colo-compare.c b/net/colo-compare.c
index 47703c5..4be6fc3 100644
--- a/net/colo-compare.c
+++ b/net/colo-compare.c
@@ -92,10 +92,6 @@ typedef struct CompareClass {
  ObjectClass parent_class;
  } CompareClass;
  
-typedef struct CompareChardevProps {

-bool is_socket;
-} CompareChardevProps;
-
  enum {
  PRIMARY_IN = 0,
  SECONDARY_IN,
@@ -573,8 +569,6 @@ static int find_and_check_chardev(CharDriverState **chr,
char *chr_name,
Error **errp)
  {
-CompareChardevProps props;
-
  *chr = qemu_chr_find(chr_name);
  if (*chr == NULL) {
  error_setg(errp, "Device '%s' not found",
@@ -582,8 +576,6 @@ static int find_and_check_chardev(CharDriverState **chr,
  return 1;
  }
  
-memset(&props, 0, sizeof(props));

-
  if (!qemu_chr_has_feature(*chr, QEMU_CHAR_FEATURE_RECONNECTABLE)) {
  error_setg(errp, "chardev \"%s\" is not reconnectable",
 chr_name);


--
Thanks
zhangchen

[Qemu-devel] [PATCH 1/2] target-mips: Fix Loongson multimedia 'or' instruction.

[Heiher]

From: Heiher 

Signed-off-by: Heiher 
Signed-off-by: Fuxin Zhang 
---
 target-mips/translate.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target-mips/translate.c b/target-mips/translate.c
index ed67180..139f249 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -3947,7 +3947,7 @@ static void gen_loongson_multimedia(DisasContext *ctx, 
int rd, int rs, int rt)
 LMI_DIRECT(XOR_CP2, xor, xor);
 LMI_DIRECT(NOR_CP2, nor, nor);
 LMI_DIRECT(AND_CP2, and, and);
-LMI_DIRECT(OR, or, or);
+LMI_DIRECT(OR_CP2, or, or);
 LMI_DIRECT_SWAP(PANDN, pandn, andc);
 
 case OPC_PINSRH_0:
-- 
2.10.0

[Qemu-devel] [PATCH 2/2] target-mips: Fix Loongson multimedia instructions.

[Heiher]

From: Heiher 

Needed to emit FPU exception on Loongson multimedia instructions
executing if Status:CU1 is clear. or FPR changes may be missed
on Linux.

Signed-off-by: Heiher 
Signed-off-by: Fuxin Zhang 
---
 target-mips/translate.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target-mips/translate.c b/target-mips/translate.c
index 139f249..b87a09b 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -3871,6 +3871,7 @@ static void gen_loongson_multimedia(DisasContext *ctx, 
int rd, int rs, int rt)
 break;
 }
 
+check_cp1_enabled(ctx);
 gen_load_fpr64(ctx, t0, rs);
 gen_load_fpr64(ctx, t1, rt);
 
-- 
2.10.0

[Qemu-devel] [PATCH v7 09/12] virtio-crypto: add data queue processing handler

[Gonglei]

Introduces VirtIOCryptoReq structure to store
crypto request so that we can support sync and async
crypto operation in the future.

At present, we only support cipher and algorithm
chainning.

Signed-off-by: Gonglei 
---
 hw/virtio/virtio-crypto.c | 338 +-
 include/hw/virtio/virtio-crypto.h |  10 +-
 2 files changed, 345 insertions(+), 3 deletions(-)

diff --git a/hw/virtio/virtio-crypto.c b/hw/virtio/virtio-crypto.c
index db86796..094bc48 100644
--- a/hw/virtio/virtio-crypto.c
+++ b/hw/virtio/virtio-crypto.c
@@ -306,6 +306,342 @@ static void virtio_crypto_handle_ctrl(VirtIODevice *vdev, 
VirtQueue *vq)
 } /* end for loop */
 }
 
+static void virtio_crypto_init_request(VirtIOCrypto *vcrypto, VirtQueue *vq,
+VirtIOCryptoReq *req)
+{
+req->vcrypto = vcrypto;
+req->vq = vq;
+req->in = NULL;
+req->in_iov = NULL;
+req->in_num = 0;
+req->in_len = 0;
+req->flags = CRYPTODEV_BACKEND_ALG__MAX;
+req->u.sym_op_info = NULL;
+}
+
+static void virtio_crypto_free_request(VirtIOCryptoReq *req)
+{
+if (req) {
+if (req->flags == CRYPTODEV_BACKEND_ALG_SYM) {
+g_free(req->u.sym_op_info);
+}
+g_free(req);
+}
+}
+
+static void
+virtio_crypto_sym_input_data_helper(VirtIODevice *vdev,
+VirtIOCryptoReq *req,
+uint32_t status,
+CryptoDevBackendSymOpInfo *sym_op_info)
+{
+size_t s, len;
+
+if (status != VIRTIO_CRYPTO_OK) {
+return;
+}
+
+len = sym_op_info->dst_len;
+/* Save the cipher result */
+s = iov_from_buf(req->in_iov, req->in_num, 0, sym_op_info->dst, len);
+if (s != len) {
+virtio_error(vdev, "virtio-crypto dest data incorrect");
+return;
+}
+
+iov_discard_front(&req->in_iov, &req->in_num, len);
+
+if (sym_op_info->op_type ==
+  VIRTIO_CRYPTO_SYM_OP_ALGORITHM_CHAINING) {
+/* Save the digest result */
+s = iov_from_buf(req->in_iov, req->in_num, 0,
+ sym_op_info->digest_result,
+ sym_op_info->digest_result_len);
+if (s != sym_op_info->digest_result_len) {
+virtio_error(vdev, "virtio-crypto digest result incorrect");
+}
+}
+}
+
+static void virtio_crypto_req_complete(VirtIOCryptoReq *req, uint32_t status)
+{
+VirtIOCrypto *vcrypto = req->vcrypto;
+VirtIODevice *vdev = VIRTIO_DEVICE(vcrypto);
+
+if (req->flags == CRYPTODEV_BACKEND_ALG_SYM) {
+virtio_crypto_sym_input_data_helper(vdev, req, status,
+req->u.sym_op_info);
+}
+stl_he_p(&req->in->status, status);
+virtqueue_push(req->vq, &req->elem, req->in_len);
+virtio_notify(vdev, req->vq);
+}
+
+static VirtIOCryptoReq *
+virtio_crypto_get_request(VirtIOCrypto *s, VirtQueue *vq)
+{
+VirtIOCryptoReq *req = virtqueue_pop(vq, sizeof(VirtIOCryptoReq));
+
+if (req) {
+virtio_crypto_init_request(s, vq, req);
+}
+return req;
+}
+
+static CryptoDevBackendSymOpInfo *
+virtio_crypto_sym_op_helper(VirtIODevice *vdev,
+   struct virtio_crypto_cipher_para *para,
+   uint32_t aad_len,
+   struct iovec *iov, unsigned int out_num,
+   uint32_t hash_result_len,
+   uint32_t hash_start_src_offset)
+{
+CryptoDevBackendSymOpInfo *op_info;
+uint32_t src_len, dst_len;
+uint32_t iv_len;
+size_t max_len, curr_size = 0;
+size_t s;
+
+iv_len = virtio_ldl_p(vdev, ¶->iv_len);
+src_len = virtio_ldl_p(vdev, ¶->src_data_len);
+dst_len = virtio_ldl_p(vdev, ¶->dst_data_len);
+
+max_len = iv_len + aad_len + src_len + dst_len + hash_result_len;
+op_info = g_malloc0(sizeof(CryptoDevBackendSymOpInfo) + max_len);
+op_info->iv_len = iv_len;
+op_info->src_len = src_len;
+op_info->dst_len = dst_len;
+op_info->aad_len = aad_len;
+op_info->digest_result_len = hash_result_len;
+op_info->hash_start_src_offset = hash_start_src_offset;
+/* Handle the initilization vector */
+if (op_info->iv_len > 0) {
+DPRINTF("iv_len=%" PRIu32 "\n", op_info->iv_len);
+op_info->iv = op_info->data + curr_size;
+
+s = iov_to_buf(iov, out_num, 0, op_info->iv, op_info->iv_len);
+if (unlikely(s != op_info->iv_len)) {
+virtio_error(vdev, "virtio-crypto iv incorrect");
+goto err;
+}
+iov_discard_front(&iov, &out_num, op_info->iv_len);
+curr_size += op_info->iv_len;
+}
+
+/* Handle additional authentication data if exist */
+if (op_info->aad_len > 0) {
+DPRINTF("aad_len=%" PRIu32 "\n", op_info->aad_len);
+op_info->aad_data = op_info->data + curr_size;
+
+s = iov_to_buf(iov, out_num, 0, op_info->aad_data, op_info->aad_len);
+if (unlikely(s != op_info->aad_len)) {
+virtio_error(vdev, "virtio-crypto additional auth data incorrect");

[Qemu-devel] [PATCH v7 00/12] virtio-crypto: introduce framework and device emulation

[Gonglei]

Hi,

The virtio crypto is a virtual crypto device as well as a kind
of virtual hardware accelerator for virtual machines. The
encryption and decryption requests are placed in the data
queue and handled by the real crypto accelerators finally.
The second queue is the control queue used to create or
destroy sessions for symmetric algorithms and control
some advanced features in the future. The virtio crypto
device provides the following crypto services: CIPHER,
MAC, HASH, AEAD etc.

TODO:
 - add vhost-user as a high performance cryptodev backend.
 - more crypto services support.
 - mirgration support.

Changes since v6:
 - add copyright and license for virtio_crypto.h [Eric]
 - add/remove (bracket pair for macro definition in virtio_crypto.h  [Eric]
 - add missing dc->vmsd and fix a typo in patch 5
 - fix a checkpatch.pl complaint
 - rebase on the QEMU master branch

Changes since v5:
 - rebase the patch 14 in v5, using the correct at the beginning of whole patch 
series. [Eric]
 - perfect algorithm chain support in patch 12.
 - more friendly error handler in both controlq and dataq.
 - drop patch "virtio-crypto: emulate virtio crypto as a legacy device by 
default" because
  we shouldn't support transitional virtio devices any more. [Michael] 
 - drop patch "virtio-crypto-test: add qtest case for virtio-crypto" because
  libqtest doesn't support virtio-1.0 device yet.
 - rebase the patch set based on Michael's pull request:
[PULL 00/33] virtio, pc: fixes and features

Changes since v4: (Thanks to Stefan)
 - drop scatter-gather I/O identification in virtio crypto spec and 
corresponding code [Stefan]
 - remove qcrypto perfix for cryptdov stuff [Stefan]
 - use virtio_error() in virtio-crypto device's functions. [Stefan]
 - fix endianness handling. [Stefan]
 - use VMSTATE_VIRTIO_DEVICE() instead of calling register_savevm(). [Stefan]
 - redefine DPRINTF in virtio-crypto.h [Stefan]
 - fix some typos [Stefan]
 - fix other farraginous problems suggested by Stefan.

Changes since v3:
 - rename cryptodev-gcrypt to cryptodev-buitlin. [Daniel]
 - move cryptodev stuff from crypto/ directory to backends/ directory
   in order to keep the crypto subsystem influence by syetem
   emulators. [Daniel]
 - emulate virtio-crypto device as a legacy device by default in patch 11
 - introduce virtio-crypto qtest case in patch 12
 - add myself as cryptdoev backends mainatainer and vitio-crypto
   co-maintainer in patch 13
 - add CRT support for cryptodev-builtin, it based on my previous crypto
   patch serial queued by Daniel.
   https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg06607.html
 - add queue_index for qcrypto_cryptodev_backend_sym_close_session()

Changes since v2:
 According to Daniel's comments:
 - drop cryptodev kernel module as a cryptodev backend
 - rename crypto stuff to cryptodev stuff
 - change some files' license to GPLv2+
 - remove cryptodev command line instead of QOM to define the cryptodev backend
 - rename all functions and structures in crypto sub-directory.
 - add full inline documentation for cryptodev.h
 And:
 - drop crypto-queue.c [Paolo]
 - merge some patches

Great thanks to Daniel and Paolo. Please review again, thanks!

Changes since v1:
 - rmmove mixed endian-ness handler for virtio-crypto device, just
   use little-endian. [mst]
 - add sg list support according virtio-crypto spec v10 (will be posted soon).
 - fix a memory leak in session handler.
 - add a feature page link in qemu.org 
(http://qemu-project.org/Features/VirtioCrypto)
 - fix some trivial problems, sush as 's/Since 2.7/Since 2.8/g' in 
qapi-schema.json
 - rebase the latest qemu master tree.


This patch series realize the framework and emulation of a new
virtio crypto device, which is similar with virtio net device.
 
 - I introduce the cryptodev backend as the client of virtio crypto device
   which can be realized by different methods, such as cryptodev-backend-gcrypt 
in my series,
   vhost-crypto kernel module, vhost-user etc.
 - The patch set abides by the virtio crypto speccification.
 - The virtio crypto support symmetric algorithms (including CIPHER and 
algorithm chainning)
   at present, except HASH, MAC and AEAD services.
 - unsupport hot plug/unplug cryptodev backend at this moment.

Firstly build QEMU with libgcrypt cryptography support. 

QEMU can then be started using the following parameters:

qemu-system-x86_64 \
[...] \
-object cryptodev-backend-builtin,id=cryptodev0 \
-device virtio-crypto-pci,id=crypto0,cryptodev=cryptodev0 \
[...]

The front-end linux kernel driver (Experimental at present) is publicly 
accessible from:
 
   https://github.com/gongleiarei/virtio-crypto-linux-driver.git

After insmod virtio-crypto.ko, you can use cryptodev-linux test the crypto 
function
in the guest. For example:

linux-guest:/home/gonglei/cryptodev-linux/tests # ./cipher -
requested cipher CRYPTO_AES_CBC, got cbc(aes) with driver virtio_crypto_aes_cbc
AES Test passed
requested cipher CRYPTO_A

Re: [Qemu-devel] [SeaBIOS] [PATCH 5/5] [wip] sercon: initial split-output implementation

[Gerd Hoffmann]

  Hi,

> So far plan is merge it into QEMU 2.8.
> I've amended QEMU counterpart according to Radim's and Paolo's reviews
> and plan to respin it soon.

No respin yet on the list it seems.   What is the status?  Do you wait
for Radim's patches land upstream first?  Can you cc me if you post it?

> It will depend on Radim's 
> https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg08292.html
> though, so my series will be merged after that

That series is at v5 now and seems to be ready for merge, even though it
didn't land in master yet.

cheers,
  Gerd

[Qemu-devel] [PATCH v7 11/12] virtio-crypto: add myself as virtio-crypto and cryptodev backends maintainer

[Gonglei]

This patch includes two parts: Cryptodev Backends
and virtio-crypto stuff. I can maintain cryptodev backends
which introduced by myself. For virtio-crypto stuff, I can
share the work with Michael (The whole virtio supporter).

Signed-off-by: Gonglei 
---
 MAINTAINERS | 13 +
 1 file changed, 13 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index b01fec0..96fd24f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1003,6 +1003,13 @@ F: include/sysemu/rng*.h
 F: backends/rng*.c
 F: tests/virtio-rng-test.c
 
+virtio-crypto
+M: Gonglei 
+S: Supported
+F: hw/virtio/virtio-crypto.c
+F: hw/virtio/virtio-crypto-pci.c
+F: include/hw/virtio/virtio-crypto.h
+
 nvme
 M: Keith Busch 
 L: qemu-bl...@nongnu.org
@@ -1248,6 +1255,12 @@ S: Maintained
 F: backends/hostmem*.c
 F: include/sysemu/hostmem.h
 
+Cryptodev Backends
+M: Gonglei 
+S: Maintained
+F: include/sysemu/cryptodev*.h
+F: backends/cryptodev*.c
+
 QAPI
 M: Markus Armbruster 
 M: Michael Roth 
-- 
1.8.3.1

[Qemu-devel] [PATCH v7 06/12] virtio-crypto-pci: add virtio crypto pci support

[Gonglei]

This patch adds virtio-crypto-pci, which is the pci proxy for the virtio
crypto device.

Signed-off-by: Gonglei 
---
 hw/virtio/Makefile.objs   |  1 +
 hw/virtio/virtio-crypto-pci.c | 77 +++
 hw/virtio/virtio-pci.h| 15 +
 3 files changed, 93 insertions(+)
 create mode 100644 hw/virtio/virtio-crypto-pci.c

diff --git a/hw/virtio/Makefile.objs b/hw/virtio/Makefile.objs
index 968f392..95c4c30 100644
--- a/hw/virtio/Makefile.objs
+++ b/hw/virtio/Makefile.objs
@@ -8,3 +8,4 @@ obj-$(CONFIG_LINUX) += vhost.o vhost-backend.o vhost-user.o
 
 obj-$(CONFIG_VHOST_VSOCK) += vhost-vsock.o
 obj-y += virtio-crypto.o
+obj-$(CONFIG_VIRTIO_PCI) += virtio-crypto-pci.o
diff --git a/hw/virtio/virtio-crypto-pci.c b/hw/virtio/virtio-crypto-pci.c
new file mode 100644
index 000..21d9984
--- /dev/null
+++ b/hw/virtio/virtio-crypto-pci.c
@@ -0,0 +1,77 @@
+/*
+ * Virtio crypto device
+ *
+ * Copyright (c) 2016 HUAWEI TECHNOLOGIES CO., LTD.
+ *
+ * Authors:
+ *Gonglei 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or
+ * (at your option) any later version.  See the COPYING file in the
+ * top-level directory.
+ *
+ */
+#include "qemu/osdep.h"
+#include "hw/pci/pci.h"
+#include "hw/virtio/virtio.h"
+#include "hw/virtio/virtio-bus.h"
+#include "hw/virtio/virtio-pci.h"
+#include "hw/virtio/virtio-crypto.h"
+#include "qapi/error.h"
+
+static Property virtio_crypto_pci_properties[] = {
+DEFINE_PROP_BIT("ioeventfd", VirtIOPCIProxy, flags,
+VIRTIO_PCI_FLAG_USE_IOEVENTFD_BIT, true),
+DEFINE_PROP_UINT32("vectors", VirtIOPCIProxy, nvectors, 2),
+DEFINE_PROP_END_OF_LIST(),
+};
+
+static void virtio_crypto_pci_realize(VirtIOPCIProxy *vpci_dev, Error **errp)
+{
+VirtIOCryptoPCI *vcrypto = VIRTIO_CRYPTO_PCI(vpci_dev);
+DeviceState *vdev = DEVICE(&vcrypto->vdev);
+
+qdev_set_parent_bus(vdev, BUS(&vpci_dev->bus));
+virtio_pci_force_virtio_1(vpci_dev);
+object_property_set_bool(OBJECT(vdev), true, "realized", errp);
+object_property_set_link(OBJECT(vcrypto),
+ OBJECT(vcrypto->vdev.conf.cryptodev), "cryptodev",
+ NULL);
+}
+
+static void virtio_crypto_pci_class_init(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+VirtioPCIClass *k = VIRTIO_PCI_CLASS(klass);
+PCIDeviceClass *pcidev_k = PCI_DEVICE_CLASS(klass);
+
+k->realize = virtio_crypto_pci_realize;
+set_bit(DEVICE_CATEGORY_MISC, dc->categories);
+dc->props = virtio_crypto_pci_properties;
+
+pcidev_k->class_id = PCI_CLASS_OTHERS;
+}
+
+static void virtio_crypto_initfn(Object *obj)
+{
+VirtIOCryptoPCI *dev = VIRTIO_CRYPTO_PCI(obj);
+
+virtio_instance_init_common(obj, &dev->vdev, sizeof(dev->vdev),
+TYPE_VIRTIO_CRYPTO);
+object_property_add_alias(obj, "cryptodev", OBJECT(&dev->vdev),
+  "cryptodev", &error_abort);
+}
+
+static const TypeInfo virtio_crypto_pci_info = {
+.name  = TYPE_VIRTIO_CRYPTO_PCI,
+.parent= TYPE_VIRTIO_PCI,
+.instance_size = sizeof(VirtIOCryptoPCI),
+.instance_init = virtio_crypto_initfn,
+.class_init= virtio_crypto_pci_class_init,
+};
+
+static void virtio_crypto_pci_register_types(void)
+{
+type_register_static(&virtio_crypto_pci_info);
+}
+type_init(virtio_crypto_pci_register_types)
diff --git a/hw/virtio/virtio-pci.h b/hw/virtio/virtio-pci.h
index b4edea6..27801f0 100644
--- a/hw/virtio/virtio-pci.h
+++ b/hw/virtio/virtio-pci.h
@@ -25,6 +25,8 @@
 #include "hw/virtio/virtio-bus.h"
 #include "hw/virtio/virtio-input.h"
 #include "hw/virtio/virtio-gpu.h"
+#include "hw/virtio/virtio-crypto.h"
+
 #ifdef CONFIG_VIRTFS
 #include "hw/9pfs/virtio-9p.h"
 #endif
@@ -48,6 +50,7 @@ typedef struct VirtIOInputHIDPCI VirtIOInputHIDPCI;
 typedef struct VirtIOInputHostPCI VirtIOInputHostPCI;
 typedef struct VirtIOGPUPCI VirtIOGPUPCI;
 typedef struct VHostVSockPCI VHostVSockPCI;
+typedef struct VirtIOCryptoPCI VirtIOCryptoPCI;
 
 /* virtio-pci-bus */
 
@@ -352,6 +355,18 @@ struct VHostVSockPCI {
 };
 #endif
 
+/*
+ * virtio-crypto-pci: This extends VirtioPCIProxy.
+ */
+#define TYPE_VIRTIO_CRYPTO_PCI "virtio-crypto-pci"
+#define VIRTIO_CRYPTO_PCI(obj) \
+OBJECT_CHECK(VirtIOCryptoPCI, (obj), TYPE_VIRTIO_CRYPTO_PCI)
+
+struct VirtIOCryptoPCI {
+VirtIOPCIProxy parent_obj;
+VirtIOCrypto vdev;
+};
+
 /* Virtio ABI version, if we increment this, we break the guest driver. */
 #define VIRTIO_PCI_ABI_VERSION  0
 
-- 
1.8.3.1

[Qemu-devel] [PATCH v7 05/12] virtio-crypto: add virtio crypto device emulation

[Gonglei]

Introduce the virtio crypto realization, I'll
finish the core code in the following patches. The
thoughts came from virtio net realization.

For more information see:
http://qemu-project.org/Features/VirtioCrypto

Signed-off-by: Gonglei 
---
 hw/virtio/Makefile.objs |   1 +
 hw/virtio/virtio-crypto.c   | 151 
 include/hw/virtio/virtio-crypto.h   |  75 ++
 include/standard-headers/linux/virtio_ids.h |   2 +-
 4 files changed, 228 insertions(+), 1 deletion(-)
 create mode 100644 hw/virtio/virtio-crypto.c
 create mode 100644 include/hw/virtio/virtio-crypto.h

diff --git a/hw/virtio/Makefile.objs b/hw/virtio/Makefile.objs
index e716308..968f392 100644
--- a/hw/virtio/Makefile.objs
+++ b/hw/virtio/Makefile.objs
@@ -7,3 +7,4 @@ obj-y += virtio.o virtio-balloon.o
 obj-$(CONFIG_LINUX) += vhost.o vhost-backend.o vhost-user.o
 
 obj-$(CONFIG_VHOST_VSOCK) += vhost-vsock.o
+obj-y += virtio-crypto.o
diff --git a/hw/virtio/virtio-crypto.c b/hw/virtio/virtio-crypto.c
new file mode 100644
index 000..109a504
--- /dev/null
+++ b/hw/virtio/virtio-crypto.c
@@ -0,0 +1,151 @@
+/*
+ * Virtio crypto Support
+ *
+ * Copyright (c) 2016 HUAWEI TECHNOLOGIES CO., LTD.
+ *
+ * Authors:
+ *Gonglei 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or
+ * (at your option) any later version.  See the COPYING file in the
+ * top-level directory.
+ */
+#include "qemu/osdep.h"
+#include "qemu/iov.h"
+#include "hw/qdev.h"
+#include "qapi/error.h"
+#include "qemu/error-report.h"
+
+#include "hw/virtio/virtio.h"
+#include "hw/virtio/virtio-crypto.h"
+#include "hw/virtio/virtio-access.h"
+#include "standard-headers/linux/virtio_ids.h"
+
+#define VIRTIO_CRYPTO_VM_VERSION 1
+
+static uint64_t virtio_crypto_get_features(VirtIODevice *vdev,
+   uint64_t features,
+   Error **errp)
+{
+return features;
+}
+
+static void virtio_crypto_reset(VirtIODevice *vdev)
+{
+VirtIOCrypto *vcrypto = VIRTIO_CRYPTO(vdev);
+/* multiqueue is disabled by default */
+vcrypto->curr_queues = 1;
+if (!vcrypto->cryptodev->ready) {
+vcrypto->status &= ~VIRTIO_CRYPTO_S_HW_READY;
+} else {
+vcrypto->status |= VIRTIO_CRYPTO_S_HW_READY;
+}
+}
+
+static void virtio_crypto_device_realize(DeviceState *dev, Error **errp)
+{
+VirtIODevice *vdev = VIRTIO_DEVICE(dev);
+VirtIOCrypto *vcrypto = VIRTIO_CRYPTO(dev);
+int i;
+
+vcrypto->cryptodev = vcrypto->conf.cryptodev;
+if (vcrypto->cryptodev == NULL) {
+error_setg(errp, "'cryptodev' parameter expects a valid object");
+return;
+}
+
+vcrypto->max_queues = MAX(vcrypto->cryptodev->conf.peers.queues, 1);
+if (vcrypto->max_queues + 1 > VIRTIO_QUEUE_MAX) {
+error_setg(errp, "Invalid number of queues (= %" PRIu16 "), "
+   "must be a postive integer less than %d.",
+   vcrypto->max_queues, VIRTIO_QUEUE_MAX);
+return;
+}
+
+virtio_init(vdev, "virtio-crypto", VIRTIO_ID_CRYPTO, vcrypto->config_size);
+vcrypto->curr_queues = 1;
+
+for (i = 0; i < vcrypto->max_queues; i++) {
+virtio_add_queue(vdev, 1024, NULL);
+}
+
+vcrypto->ctrl_vq = virtio_add_queue(vdev, 64, NULL);
+if (!vcrypto->cryptodev->ready) {
+vcrypto->status &= ~VIRTIO_CRYPTO_S_HW_READY;
+} else {
+vcrypto->status |= VIRTIO_CRYPTO_S_HW_READY;
+}
+}
+
+static void virtio_crypto_device_unrealize(DeviceState *dev, Error **errp)
+{
+VirtIODevice *vdev = VIRTIO_DEVICE(dev);
+
+virtio_cleanup(vdev);
+}
+
+static const VMStateDescription vmstate_virtio_crypto = {
+.name = "virtio-crypto",
+.minimum_version_id = VIRTIO_CRYPTO_VM_VERSION,
+.version_id = VIRTIO_CRYPTO_VM_VERSION,
+.fields = (VMStateField[]) {
+VMSTATE_VIRTIO_DEVICE,
+VMSTATE_END_OF_LIST()
+},
+};
+
+static Property virtio_crypto_properties[] = {
+DEFINE_PROP_END_OF_LIST(),
+};
+
+static void virtio_crypto_get_config(VirtIODevice *vdev, uint8_t *config)
+{
+
+}
+
+static void virtio_crypto_class_init(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+VirtioDeviceClass *vdc = VIRTIO_DEVICE_CLASS(klass);
+
+dc->props = virtio_crypto_properties;
+dc->vmsd = &vmstate_virtio_crypto;
+set_bit(DEVICE_CATEGORY_MISC, dc->categories);
+vdc->realize = virtio_crypto_device_realize;
+vdc->unrealize = virtio_crypto_device_unrealize;
+vdc->get_config = virtio_crypto_get_config;
+vdc->get_features = virtio_crypto_get_features;
+vdc->reset = virtio_crypto_reset;
+}
+
+static void virtio_crypto_instance_init(Object *obj)
+{
+VirtIOCrypto *vcrypto = VIRTIO_CRYPTO(obj);
+
+/*
+ * The default config_size is sizeof(struct virtio_crypto_config).
+ * Can be overriden with virtio_crypto_set_config_size.
+ */
+vcrypto->config_size = 

Re: [Qemu-devel] [PATCH 0/9] Misc VNC server code cleanups

[Gerd Hoffmann]

On Do, 2016-09-29 at 16:45 +0100, Daniel P. Berrange wrote:
> This patches series should have no functional change, it is
> just a series of cleanups I've accumulated for the VNC server.
> It aims to remove misleading cruft and simplify some parts
> to make future work I'm experimenting with easier.
> 
> Daniel P. Berrange (9):
>   ui: remove misleading comment from vnc_init_state
>   ui: remove 'enabled' and 'ws_enabled' fields from VncState
>   ui: remove 'ws_tls' field from VncState
>   ui: rename misleading 'VncDisplay' variables
>   ui: refactor method for setting up VncDisplay auth types
>   ui: remove bogus call to graphic_hw_update() in vnc_listen_io
>   ui: remove bogus call to reset_keys() in vnc_init_state
>   ui: move some initialization out of vnc_init_state
>   ui: rename vnc_init_state to vnc_start_protocol
> 
>  ui/vnc-ws.c |   2 +-
>  ui/vnc.c| 410 
> +++-
>  ui/vnc.h|   7 +-
>  3 files changed, 189 insertions(+), 230 deletions(-)
> 

Added to UI patch queue.

thanks,
  Gerd

[Qemu-devel] [PATCH v7 01/12] cryptodev: introduce cryptodev backend interface

[Gonglei]

cryptodev backend interface is used to realize the active work for
virtual crypto device.

This patch only add the framework, doesn't include specific operations.

Signed-off-by: Gonglei 
---
 backends/Makefile.objs |   2 +
 backends/cryptodev.c   | 176 +
 include/sysemu/cryptodev.h | 145 +
 3 files changed, 323 insertions(+)
 create mode 100644 backends/cryptodev.c
 create mode 100644 include/sysemu/cryptodev.h

diff --git a/backends/Makefile.objs b/backends/Makefile.objs
index 31a3a89..55bd43d 100644
--- a/backends/Makefile.objs
+++ b/backends/Makefile.objs
@@ -9,3 +9,5 @@ common-obj-$(CONFIG_TPM) += tpm.o
 
 common-obj-y += hostmem.o hostmem-ram.o
 common-obj-$(CONFIG_LINUX) += hostmem-file.o
+
+common-obj-y += cryptodev.o
diff --git a/backends/cryptodev.c b/backends/cryptodev.c
new file mode 100644
index 000..e8582cd
--- /dev/null
+++ b/backends/cryptodev.c
@@ -0,0 +1,176 @@
+/*
+ * QEMU Crypto Device Implementation
+ *
+ * Copyright (c) 2016 HUAWEI TECHNOLOGIES CO., LTD.
+ *
+ * Authors:
+ *Gonglei 
+ *
+ * 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 "qemu/osdep.h"
+#include "sysemu/cryptodev.h"
+#include "hw/boards.h"
+#include "qapi/error.h"
+#include "qapi/visitor.h"
+#include "qapi-types.h"
+#include "qapi-visit.h"
+#include "qemu/config-file.h"
+#include "qom/object_interfaces.h"
+
+static QTAILQ_HEAD(, CryptoDevBackendClient) crypto_clients;
+
+
+CryptoDevBackendClient *
+cryptodev_backend_new_client(const char *model,
+const char *name)
+{
+CryptoDevBackendClient *cc;
+
+cc = g_malloc0(sizeof(CryptoDevBackendClient));
+cc->model = g_strdup(model);
+if (name) {
+cc->name = g_strdup(name);
+}
+
+QTAILQ_INSERT_TAIL(&crypto_clients, cc, next);
+
+return cc;
+}
+
+void cryptodev_backend_free_client(
+  CryptoDevBackendClient *cc)
+{
+QTAILQ_REMOVE(&crypto_clients, cc, next);
+g_free(cc->name);
+g_free(cc->model);
+g_free(cc->info_str);
+g_free(cc);
+}
+
+void cryptodev_backend_cleanup(
+ CryptoDevBackend *backend,
+ Error **errp)
+{
+CryptoDevBackendClass *bc =
+  CRYPTODEV_BACKEND_GET_CLASS(backend);
+
+if (bc->cleanup) {
+bc->cleanup(backend, errp);
+}
+
+backend->ready = false;
+}
+
+static void
+cryptodev_backend_get_queues(Object *obj, Visitor *v, const char *name,
+ void *opaque, Error **errp)
+{
+CryptoDevBackend *backend = CRYPTODEV_BACKEND(obj);
+uint32_t value = backend->conf.peers.queues;
+
+visit_type_uint32(v, name, &value, errp);
+}
+
+static void
+cryptodev_backend_set_queues(Object *obj, Visitor *v, const char *name,
+ void *opaque, Error **errp)
+{
+CryptoDevBackend *backend = CRYPTODEV_BACKEND(obj);
+Error *local_err = NULL;
+uint32_t value;
+
+visit_type_uint32(v, name, &value, &local_err);
+if (local_err) {
+goto out;
+}
+if (!value) {
+error_setg(&local_err, "Property '%s.%s' doesn't take value '%"
+   PRIu32 "'", object_get_typename(obj), name, value);
+goto out;
+}
+backend->conf.peers.queues = value;
+out:
+error_propagate(errp, local_err);
+}
+
+static void
+cryptodev_backend_complete(UserCreatable *uc, Error **errp)
+{
+CryptoDevBackend *backend = CRYPTODEV_BACKEND(uc);
+CryptoDevBackendClass *bc = CRYPTODEV_BACKEND_GET_CLASS(uc);
+Error *local_err = NULL;
+
+if (bc->init) {
+bc->init(backend, &local_err);
+if (local_err) {
+goto out;
+}
+}
+backend->ready = true;
+return;
+
+out:
+backend->ready = false;
+error_propagate(errp, local_err);
+}
+
+static void cryptodev_backend_instance_init(Object *obj)
+{
+object_property_add(obj, "queues", "int",
+  cryptodev_backend_get_queues,
+  cryptodev_backend_set_queues,
+  NULL, NULL, NULL);
+/* Initialize devices' queues property to 1 */
+object_property_set_int(obj, 1, "queues", NULL);
+}
+
+static void cryptodev_backend_finalize(Object *obj)
+{
+
+}
+
+static void
+cryptodev_backend_class_init(ObjectClass *oc, void *data)
+{
+

[Qemu-devel] [PATCH v7 10/12] cryptodev: introduce an unified wrapper for crypto operation

[Gonglei]

We use an opaque point to the VirtIOCryptoReq which
can support different packets based on different
algorithms.

Signed-off-by: Gonglei 
---
 backends/cryptodev-builtin.c |  2 +-
 backends/cryptodev.c | 28 ++--
 hw/virtio/virtio-crypto.c| 10 +-
 include/sysemu/cryptodev.h   | 13 +++--
 4 files changed, 39 insertions(+), 14 deletions(-)

diff --git a/backends/cryptodev-builtin.c b/backends/cryptodev-builtin.c
index 34c45be..dc0a364 100644
--- a/backends/cryptodev-builtin.c
+++ b/backends/cryptodev-builtin.c
@@ -286,7 +286,7 @@ static int cryptodev_builtin_sym_operation(
 return -VIRTIO_CRYPTO_ERR;
 }
 }
-return 0;
+return VIRTIO_CRYPTO_OK;
 }
 
 static void cryptodev_builtin_cleanup(
diff --git a/backends/cryptodev.c b/backends/cryptodev.c
index 47521cf..4a49f97 100644
--- a/backends/cryptodev.c
+++ b/backends/cryptodev.c
@@ -30,6 +30,8 @@
 #include "qapi-visit.h"
 #include "qemu/config-file.h"
 #include "qom/object_interfaces.h"
+#include "hw/virtio/virtio-crypto.h"
+
 
 static QTAILQ_HEAD(, CryptoDevBackendClient) crypto_clients;
 
@@ -105,7 +107,7 @@ int cryptodev_backend_sym_close_session(
 return -1;
 }
 
-int cryptodev_backend_sym_operation(
+static int cryptodev_backend_sym_operation(
  CryptoDevBackend *backend,
  CryptoDevBackendSymOpInfo *op_info,
  uint32_t queue_index, Error **errp)
@@ -117,7 +119,29 @@ int cryptodev_backend_sym_operation(
 return bc->do_sym_op(backend, op_info, queue_index, errp);
 }
 
-return -1;
+return -VIRTIO_CRYPTO_ERR;
+}
+
+int cryptodev_backend_crypto_operation(
+ CryptoDevBackend *backend,
+ void *opaque,
+ uint32_t queue_index, Error **errp)
+{
+VirtIOCryptoReq *req = opaque;
+
+if (req->flags == CRYPTODEV_BACKEND_ALG_SYM) {
+CryptoDevBackendSymOpInfo *op_info;
+op_info = req->u.sym_op_info;
+
+return cryptodev_backend_sym_operation(backend,
+ op_info, queue_index, errp);
+} else {
+error_setg(errp, "Unsupported cryptodev alg type: %" PRIu32 "",
+   req->flags);
+   return -VIRTIO_CRYPTO_NOTSUPP;
+}
+
+return -VIRTIO_CRYPTO_ERR;
 }
 
 static void
diff --git a/hw/virtio/virtio-crypto.c b/hw/virtio/virtio-crypto.c
index 094bc48..fc78a86 100644
--- a/hw/virtio/virtio-crypto.c
+++ b/hw/virtio/virtio-crypto.c
@@ -600,15 +600,15 @@ virtio_crypto_handle_request(VirtIOCryptoReq *request)
 /* Set request's parameter */
 request->flags = CRYPTODEV_BACKEND_ALG_SYM;
 request->u.sym_op_info = sym_op_info;
-ret = cryptodev_backend_sym_operation(vcrypto->cryptodev,
-sym_op_info, queue_index, &local_err);
+ret = cryptodev_backend_crypto_operation(vcrypto->cryptodev,
+request, queue_index, &local_err);
 if (ret < 0) {
-status = VIRTIO_CRYPTO_ERR;
+status = -ret;
 if (local_err) {
 error_report_err(local_err);
 }
-} else { /* ret >= 0 */
-status = VIRTIO_CRYPTO_OK;
+} else { /* ret == VIRTIO_CRYPTO_OK */
+status = ret;
 }
 virtio_crypto_req_complete(request, status);
 virtio_crypto_free_request(request);
diff --git a/include/sysemu/cryptodev.h b/include/sysemu/cryptodev.h
index 8fbf1e2..f55b79e 100644
--- a/include/sysemu/cryptodev.h
+++ b/include/sysemu/cryptodev.h
@@ -264,20 +264,21 @@ int cryptodev_backend_sym_close_session(
uint32_t queue_index, Error **errp);
 
 /**
- * cryptodev_backend_sym_operation:
+ * cryptodev_backend_crypto_operation:
  * @backend: the cryptodev backend object
- * @op_info: parameters needed by symmetric crypto operation
+ * @opaque: pointer to a VirtIOCryptoReq object
  * @queue_index: queue index of cryptodev backend client
  * @errp: pointer to a NULL-initialized error object
  *
- * Do symmetric crypto operation, such as encryption and
+ * Do crypto operation, such as encryption and
  * decryption
  *
- * Returns: 0 on success, or Negative on error
+ * Returns: VIRTIO_CRYPTO_OK on success,
+ * or -VIRTIO_CRYPTO_* on error
  */
-int cryptodev_backend_sym_operation(
+int cryptodev_backend_crypto_operation(
  CryptoDevBackend *backend,
- CryptoDevBackendSymOpInfo *op_info,
+ void *opaque,
  uint32_t queue_index, Error **errp);
 
 #endif /* CRYPTODEV_H */
-- 
1.8.3.1

Re: [Qemu-devel] [PATCH v14 08/21] qapi: allow QObjectInputVisitor to be created with QemuOpts

[Markus Armbruster]

Markus Armbruster  writes:

> "Daniel P. Berrange"  writes:
>
>> Instead of requiring all callers to go through the mutli-step
>
> multi-step
>
>> process of turning QemuOpts into a suitable QObject for visiting,
>> add a new constructor that encapsulates this logic. This will
>> allow QObjectInputVisitor to be a drop-in replacement for the
>> existing OptsVisitor with minimal code changes for callers.
>>
>> NB, at this point it is only supporting opts syntax which
>> explicitly matches the QAPI schema structure, so is not yet
>> a true drop-in replacement for OptsVisitor. The patches that
>> follow will add the special cases requird for full backwards
>> compatibility with OptsVisitor.
>>
>> Signed-off-by: Daniel P. Berrange 
[...]
>> diff --git a/qapi/qobject-input-visitor.c b/qapi/qobject-input-visitor.c
>> index cf41df6..d9269c9 100644
>> --- a/qapi/qobject-input-visitor.c
>> +++ b/qapi/qobject-input-visitor.c
>> @@ -545,3 +545,28 @@ Visitor *qobject_input_visitor_new_autocast(QObject 
>> *obj)
>>  
>>  return &v->visitor;
>>  }
>> +
>> +
>> +Visitor *qobject_input_visitor_new_opts(const QemuOpts *opts,
>> +Error **errp)
>> +{
>> +QDict *pdict;
>> +QObject *pobj = NULL;
>
> @pdict and @pobj are unusual names.  Let's stick to the more common
> @dict and @obj.
>
>> +Visitor *v = NULL;
>> +
>> +pdict = qemu_opts_to_qdict(opts, NULL);
>> +if (!pdict) {
>> +goto cleanup;

Returns null without setting an error, which is wrong.  Fortunately,
qemu_opts_to_qdict() cannot fail.  Please drop the broken error
handling.

>> +}
>> +
>> +pobj = qdict_crumple(pdict, true, errp);
>> +if (!pobj) {
>> +goto cleanup;
>> +}
>> +
>> +v = qobject_input_visitor_new_autocast(pobj);
>> + cleanup:
>> +qobject_decref(pobj);
>> +QDECREF(pdict);
>> +return v;
>> +}
[...]

Re: [Qemu-devel] [PATCH V2] docs: add PCIe devices placement guidelines

[Marcel Apfelbaum]

On 10/12/2016 06:28 PM, Laszlo Ersek wrote:

Marcel,

On 10/11/16 15:45, Marcel Apfelbaum wrote:

Proposes best practices on how to use PCI Express/PCI device
in PCI Express based machines and explain the reasoning behind them.

Signed-off-by: Marcel Apfelbaum 
---

Hi,

RFC->v2:
 - Addressed a lot of comments from the reviewers (many thanks to all, 
especially to Laszlo)

Since the RFC mail-thread was relatively long and already
has passed a lot of time from the RFC, I post this version
even if is very possible that I left some of the comments out,
my apologies if so.

I will go over the comments again, in the meantime please
feel free to comment on this version, even if on something
you've already pointed out.

It may take a day or two until I'll be able to respond, but I
will do my best to address all comments.

Thanks,
Marcel


 docs/pcie.txt | 273 ++
 1 file changed, 273 insertions(+)
 create mode 100644 docs/pcie.txt


Your patch doesn't seem to have reached qemu-devel. I got one copy from
you directly, and no copy reflected by the qemu-devel list server. I
also checked the mailing list archive:
- searched for the subject with google -- only the RFC version was found,
- checked mail-archive.com by message-id
- checked the primary archive for October
(http://lists.nongnu.org/archive/html/qemu-devel/2016-10/threads.html)
-- I found only messages in the RFC thread.

So, before I start reading this version and commenting on it, can you
please repost version 2, and verify that the list reflects it?



Hi,

That is very strange, I tried sending it again but I received the same error:

Undelivered Mail Returned to Sender
...
: host eggs.gnu.org[208.118.235.92] said: 550 Invalid
address in message header (in reply to end of DATA command)

Reporting-MTA: dns; <>.redhat.com
X-Postfix-Queue-ID: <>
X-Postfix-Sender: rfc822; mar...@redhat.com
Arrival-Date: Thu, 13 Oct 2016 07:20:49 + (UTC)

Final-Recipient: rfc822; qemu-devel@nongnu.org
Original-Recipient: rfc822;qemu-devel@nongnu.org
Action: failed
Status: 5.0.0
Remote-MTA: dns; eggs.gnu.org
Diagnostic-Code: smtp; 550 Invalid address in message header


I'll try sending the mail with another mail server.

Thanks,
Marcel



Thanks!
Laszlo

[Qemu-devel] [PATCH v7 02/12] cryptodev: add symmetric algorithm operation stuff

[Gonglei]

This patch adds session operation and crypto operation
stuff in the cryptodev backend, including function
pointers and corresponding structures.

Signed-off-by: Gonglei 
---
 backends/cryptodev.c   |  45 +++
 include/sysemu/cryptodev.h | 138 +
 2 files changed, 183 insertions(+)

diff --git a/backends/cryptodev.c b/backends/cryptodev.c
index e8582cd..47521cf 100644
--- a/backends/cryptodev.c
+++ b/backends/cryptodev.c
@@ -75,6 +75,51 @@ void cryptodev_backend_cleanup(
 backend->ready = false;
 }
 
+int64_t cryptodev_backend_sym_create_session(
+   CryptoDevBackend *backend,
+   CryptoDevBackendSymSessionInfo *sess_info,
+   uint32_t queue_index, Error **errp)
+{
+CryptoDevBackendClass *bc =
+  CRYPTODEV_BACKEND_GET_CLASS(backend);
+
+if (bc->create_session) {
+return bc->create_session(backend, sess_info, queue_index, errp);
+}
+
+return -1;
+}
+
+int cryptodev_backend_sym_close_session(
+   CryptoDevBackend *backend,
+   uint64_t session_id,
+   uint32_t queue_index, Error **errp)
+{
+CryptoDevBackendClass *bc =
+  CRYPTODEV_BACKEND_GET_CLASS(backend);
+
+if (bc->close_session) {
+return bc->close_session(backend, session_id, queue_index, errp);
+}
+
+return -1;
+}
+
+int cryptodev_backend_sym_operation(
+ CryptoDevBackend *backend,
+ CryptoDevBackendSymOpInfo *op_info,
+ uint32_t queue_index, Error **errp)
+{
+CryptoDevBackendClass *bc =
+  CRYPTODEV_BACKEND_GET_CLASS(backend);
+
+if (bc->do_sym_op) {
+return bc->do_sym_op(backend, op_info, queue_index, errp);
+}
+
+return -1;
+}
+
 static void
 cryptodev_backend_get_queues(Object *obj, Visitor *v, const char *name,
  void *opaque, Error **errp)
diff --git a/include/sysemu/cryptodev.h b/include/sysemu/cryptodev.h
index de9d3e3..8fbf1e2 100644
--- a/include/sysemu/cryptodev.h
+++ b/include/sysemu/cryptodev.h
@@ -56,12 +56,100 @@ typedef struct CryptoDevBackendClient
  CryptoDevBackendClient;
 typedef struct CryptoDevBackend CryptoDevBackend;
 
+enum CryptoDevBackendAlgType {
+CRYPTODEV_BACKEND_ALG_SYM,
+CRYPTODEV_BACKEND_ALG__MAX,
+};
+
+/**
+ * CryptoDevBackendSymSessionInfo:
+ *
+ * @op_code: operation code (refer to virtio_crypto.h)
+ * @cipher_alg: algorithm type of CIPHER
+ * @key_len: byte length of cipher key
+ * @hash_alg: algorithm type of HASH/MAC
+ * @hash_result_len: byte length of HASH operation result
+ * @auth_key_len: byte length of authenticated key
+ * @add_len: byte length of additional authenticated data
+ * @op_type: operation type (refer to virtio_crypto.h)
+ * @direction: encryption or direction for CIPHER
+ * @hash_mode: HASH mode for HASH operation (refer to virtio_crypto.h)
+ * @alg_chain_order: order of algorithm chaining (CIPHER then HASH,
+ *   or HASH then CIPHER)
+ * @cipher_key: point to a key of CIPHER
+ * @auth_key: point to an authenticated key of MAC
+ *
+ */
+typedef struct CryptoDevBackendSymSessionInfo {
+/* corresponding with virtio crypto spec */
+uint32_t op_code;
+uint32_t cipher_alg;
+uint32_t key_len;
+uint32_t hash_alg;
+uint32_t hash_result_len;
+uint32_t auth_key_len;
+uint32_t add_len;
+uint8_t op_type;
+uint8_t direction;
+uint8_t hash_mode;
+uint8_t alg_chain_order;
+uint8_t *cipher_key;
+uint8_t *auth_key;
+} CryptoDevBackendSymSessionInfo;
+
+/**
+ * CryptoDevBackendSymOpInfo:
+ *
+ * @session_id: session index which was previously
+ *  created by cryptodev_backend_sym_create_session()
+ * @aad_len: byte length of additional authenticated data
+ * @iv_len: byte length of initialization vector or counter
+ * @src_len: byte length of source data
+ * @dst_len: byte length of destination data
+ * @digest_result_len: byte length of hash digest result
+ * @hash_start_src_offset: Starting point for hash processing, specified
+ * as number of bytes from start of packet in source data
+ * @op_type: operation type (refer to virtio_crypto.h)
+ * @iv: point to the initialization vector or counter
+ * @src: point to the source data
+ * @dst: point to the destination data
+ * @aad_data: point to the additional authenticated data
+ * @digest_result: point to the digest result data
+ * @data[0]: point to the extensional memory by one memory allocation
+ *
+ */
+typedef struct CryptoDevBackendSymOpInfo {
+uint64_t session_id;
+uint32_t aad_len;
+uint32_t iv_len;
+uint32_t src_len;
+uint32_t dst_len;
+uint32_t digest_result_len;
+uint32_t hash_start_src_offset;
+uint8_t op_type;
+uint8_t *iv;
+uint8_t *src;
+uint8_t *dst;
+uint8_t *aad_data;
+uint8_t *digest_result;
+uint8_t data[0];
+} CryptoDevBackendSymOpInfo;
 
 typedef st

[Qemu-devel] [PATCH v7 12/12] virtio-crypto: perfect algorithms chainning support

[Gonglei]

For one source buffer, we can do cipher and hash operations
partly in algorithms chainning mode. We updated the
corresponding part in virtio crypto specification firstly.

The cryptodev-builtin backend doesn't support algorithm
chainning, so let's add a check for it.

Signed-off-by: Gonglei 
---
 backends/cryptodev-builtin.c   |  6 +++
 hw/virtio/virtio-crypto.c  | 62 --
 include/standard-headers/linux/virtio_crypto.h | 11 -
 include/sysemu/cryptodev.h | 13 +-
 4 files changed, 66 insertions(+), 26 deletions(-)

diff --git a/backends/cryptodev-builtin.c b/backends/cryptodev-builtin.c
index dc0a364..9ad79ad 100644
--- a/backends/cryptodev-builtin.c
+++ b/backends/cryptodev-builtin.c
@@ -265,6 +265,12 @@ static int cryptodev_builtin_sym_operation(
 return -VIRTIO_CRYPTO_INVSESS;
 }
 
+if (op_info->op_type == VIRTIO_CRYPTO_SYM_OP_ALGORITHM_CHAINING) {
+error_setg(errp,
+   "Algorithm chain is unsupported for cryptdoev-builtin");
+return -VIRTIO_CRYPTO_NOTSUPP;
+}
+
 sess = builtin->sessions[op_info->session_id];
 
 ret = qcrypto_cipher_setiv(sess->cipher, op_info->iv,
diff --git a/hw/virtio/virtio-crypto.c b/hw/virtio/virtio-crypto.c
index fc78a86..2455ebb 100644
--- a/hw/virtio/virtio-crypto.c
+++ b/hw/virtio/virtio-crypto.c
@@ -390,21 +390,42 @@ virtio_crypto_get_request(VirtIOCrypto *s, VirtQueue *vq)
 
 static CryptoDevBackendSymOpInfo *
 virtio_crypto_sym_op_helper(VirtIODevice *vdev,
-   struct virtio_crypto_cipher_para *para,
-   uint32_t aad_len,
-   struct iovec *iov, unsigned int out_num,
-   uint32_t hash_result_len,
-   uint32_t hash_start_src_offset)
+   struct virtio_crypto_cipher_para *cipher_para,
+   struct virtio_crypto_alg_chain_data_para *alg_chain_para,
+   struct iovec *iov, unsigned int out_num)
 {
 CryptoDevBackendSymOpInfo *op_info;
-uint32_t src_len, dst_len;
-uint32_t iv_len;
+uint32_t src_len = 0, dst_len = 0;
+uint32_t iv_len = 0;
+uint32_t aad_len = 0, hash_result_len = 0;
+uint32_t hash_start_src_offset = 0, len_to_hash = 0;
+uint32_t cipher_start_src_offset = 0, len_to_cipher = 0;
+
 size_t max_len, curr_size = 0;
 size_t s;
 
-iv_len = virtio_ldl_p(vdev, ¶->iv_len);
-src_len = virtio_ldl_p(vdev, ¶->src_data_len);
-dst_len = virtio_ldl_p(vdev, ¶->dst_data_len);
+/* Plain cipher */
+if (cipher_para) {
+iv_len = virtio_ldl_p(vdev, &cipher_para->iv_len);
+src_len = virtio_ldl_p(vdev, &cipher_para->src_data_len);
+dst_len = virtio_ldl_p(vdev, &cipher_para->dst_data_len);
+} else if (alg_chain_para) { /* Algorithm chain */
+iv_len = virtio_ldl_p(vdev, &alg_chain_para->iv_len);
+src_len = virtio_ldl_p(vdev, &alg_chain_para->src_data_len);
+dst_len = virtio_ldl_p(vdev, &alg_chain_para->dst_data_len);
+
+aad_len = virtio_ldl_p(vdev, &alg_chain_para->aad_len);
+hash_result_len = virtio_ldl_p(vdev,
+  &alg_chain_para->hash_result_len);
+hash_start_src_offset = virtio_ldl_p(vdev,
+ &alg_chain_para->hash_start_src_offset);
+cipher_start_src_offset = virtio_ldl_p(vdev,
+ &alg_chain_para->cipher_start_src_offset);
+len_to_cipher = virtio_ldl_p(vdev, &alg_chain_para->len_to_cipher);
+len_to_hash = virtio_ldl_p(vdev, &alg_chain_para->len_to_hash);
+} else {
+return NULL;
+}
 
 max_len = iv_len + aad_len + src_len + dst_len + hash_result_len;
 op_info = g_malloc0(sizeof(CryptoDevBackendSymOpInfo) + max_len);
@@ -414,6 +435,9 @@ virtio_crypto_sym_op_helper(VirtIODevice *vdev,
 op_info->aad_len = aad_len;
 op_info->digest_result_len = hash_result_len;
 op_info->hash_start_src_offset = hash_start_src_offset;
+op_info->len_to_hash = len_to_hash;
+op_info->cipher_start_src_offset = cipher_start_src_offset;
+op_info->len_to_cipher = len_to_cipher;
 /* Handle the initilization vector */
 if (op_info->iv_len > 0) {
 DPRINTF("iv_len=%" PRIu32 "\n", op_info->iv_len);
@@ -491,25 +515,15 @@ virtio_crypto_handle_sym_req(VirtIOCrypto *vcrypto,
 
 if (op_type == VIRTIO_CRYPTO_SYM_OP_CIPHER) {
 op_info = virtio_crypto_sym_op_helper(vdev, &req->u.cipher.para,
-  0, iov, out_num, 0, 0);
+  NULL, iov, out_num);
 if (!op_info) {
 return -EFAULT;
 }
 op_info->op_type = op_type;
 } else if (op_type == VIRTIO_CRYPTO_SYM_OP_ALGORITHM_CHAINING) {
-uint32_t aad_len, hash_result_len;
-uint32_t hash_start_src_offset;
-
-aad_len = virtio_ldl_p(vdev, &req->u.chain.para.aad_len);
-hash_result_len = virtio_ldl_p(vdev,
-  &req->u.ch

Re: [Qemu-devel] [PATCHv3 4/7] spapr_pci: Delegate placement of PCI host bridges to machine type

[Laurent Vivier]

On 13/10/2016 01:57, David Gibson wrote:
> The 'spapr-pci-host-bridge' represents the virtual PCI host bridge (PHB)
> for a PAPR guest.  Unlike on x86, it's routine on Power (both bare metal
> and PAPR guests) to have numerous independent PHBs, each controlling a
> separate PCI domain.
> 
> There are two ways of configuring the spapr-pci-host-bridge device: first
> it can be done fully manually, specifying the locations and sizes of all
> the IO windows.  This gives the most control, but is very awkward with 6
> mandatory parameters.  Alternatively just an "index" can be specified
> which essentially selects from an array of predefined PHB locations.
> The PHB at index 0 is automatically created as the default PHB.
> 
> The current set of default locations causes some problems for guests with
> large RAM (> 1 TiB) or PCI devices with very large BARs (e.g. big nVidia
> GPGPU cards via VFIO).  Obviously, for migration we can only change the
> locations on a new machine type, however.
> 
> This is awkward, because the placement is currently decided within the
> spapr-pci-host-bridge code, so it breaks abstraction to look inside the
> machine type version.
> 
> So, this patch delegates the "default mode" PHB placement from the
> spapr-pci-host-bridge device back to the machine type via a public method
> in sPAPRMachineClass.  It's still a bit ugly, but it's about the best we
> can do.
> 
> For now, this just changes where the calculation is done.  It doesn't
> change the actual location of the host bridges, or any other behaviour.
> 
> Signed-off-by: David Gibson 

Reviewed-by: Laurent Vivier 

> ---
>  hw/ppc/spapr.c  | 31 +++
>  hw/ppc/spapr_pci.c  | 21 +++--
>  include/hw/pci-host/spapr.h | 11 +--
>  include/hw/ppc/spapr.h  |  3 +++
>  4 files changed, 42 insertions(+), 24 deletions(-)
> 
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index 03e3803..cb9da96 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -2370,6 +2370,36 @@ static HotpluggableCPUList 
> *spapr_query_hotpluggable_cpus(MachineState *machine)
>  return head;
>  }
>  
> +static void spapr_phb_placement(sPAPRMachineState *spapr, uint32_t index,
> +uint64_t *buid, hwaddr *pio, hwaddr *mmio,
> +unsigned n_dma, uint32_t *liobns, Error 
> **errp)
> +{
> +const uint64_t base_buid = 0x8002000ULL;
> +const hwaddr phb0_base = 0x100ULL; /* 1 TiB */
> +const hwaddr phb_spacing = 0x10ULL; /* 64 GiB */
> +const hwaddr mmio_offset = 0xa000; /* 2 GiB + 512 MiB */
> +const hwaddr pio_offset = 0x8000; /* 2 GiB */
> +const uint32_t max_index = 255;
> +
> +hwaddr phb_base;
> +int i;
> +
> +if (index > max_index) {
> +error_setg(errp, "\"index\" for PAPR PHB is too large (max %u)",
> +   max_index);
> +return;
> +}
> +
> +*buid = base_buid + index;
> +for (i = 0; i < n_dma; ++i) {
> +liobns[i] = SPAPR_PCI_LIOBN(index, i);
> +}
> +
> +phb_base = phb0_base + index * phb_spacing;
> +*pio = phb_base + pio_offset;
> +*mmio = phb_base + mmio_offset;
> +}
> +
>  static void spapr_machine_class_init(ObjectClass *oc, void *data)
>  {
>  MachineClass *mc = MACHINE_CLASS(oc);
> @@ -2406,6 +2436,7 @@ static void spapr_machine_class_init(ObjectClass *oc, 
> void *data)
>  mc->query_hotpluggable_cpus = spapr_query_hotpluggable_cpus;
>  fwc->get_dev_path = spapr_get_fw_dev_path;
>  nc->nmi_monitor_handler = spapr_nmi;
> +smc->phb_placement = spapr_phb_placement;
>  }
>  
>  static const TypeInfo spapr_machine_info = {
> diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c
> index 4f00865..0e6cf4d 100644
> --- a/hw/ppc/spapr_pci.c
> +++ b/hw/ppc/spapr_pci.c
> @@ -1311,7 +1311,8 @@ static void spapr_phb_realize(DeviceState *dev, Error 
> **errp)
>  sphb->ddw_enabled ? SPAPR_PCI_DMA_MAX_WINDOWS : 1;
>  
>  if (sphb->index != (uint32_t)-1) {
> -hwaddr windows_base;
> +sPAPRMachineClass *smc = SPAPR_MACHINE_GET_CLASS(spapr);
> +Error *local_err = NULL;
>  
>  if ((sphb->buid != (uint64_t)-1) || (sphb->dma_liobn[0] != 
> (uint32_t)-1)
>  || (sphb->dma_liobn[1] != (uint32_t)-1 && windows_supported == 2)
> @@ -1322,21 +1323,13 @@ static void spapr_phb_realize(DeviceState *dev, Error 
> **errp)
>  return;
>  }
>  
> -if (sphb->index > SPAPR_PCI_MAX_INDEX) {
> -error_setg(errp, "\"index\" for PAPR PHB is too large (max %u)",
> -   SPAPR_PCI_MAX_INDEX);
> +smc->phb_placement(spapr, sphb->index, &sphb->buid,
> +   &sphb->io_win_addr, &sphb->mem_win_addr,
> +   windows_supported, sphb->dma_liobn, &local_err);
> +if (local_err) {
> +error_propagate(errp, local_err);
>  return;
>  

[Qemu-devel] [PATCH v7 04/12] cryptodev: introduce a new cryptodev backend

[Gonglei]

The new cryptodev backend named cryptodev-builtin,
which realized by QEMU cipher APIs. These APIs can
be backed by either nettle or gcrypt.

Signed-off-by: Gonglei 
---
 backends/Makefile.objs   |   1 +
 backends/cryptodev-builtin.c | 345 +++
 qemu-options.hx  |  18 +++
 3 files changed, 364 insertions(+)
 create mode 100644 backends/cryptodev-builtin.c

diff --git a/backends/Makefile.objs b/backends/Makefile.objs
index 55bd43d..1846998 100644
--- a/backends/Makefile.objs
+++ b/backends/Makefile.objs
@@ -11,3 +11,4 @@ common-obj-y += hostmem.o hostmem-ram.o
 common-obj-$(CONFIG_LINUX) += hostmem-file.o
 
 common-obj-y += cryptodev.o
+common-obj-y += cryptodev-builtin.o
diff --git a/backends/cryptodev-builtin.c b/backends/cryptodev-builtin.c
new file mode 100644
index 000..34c45be
--- /dev/null
+++ b/backends/cryptodev-builtin.c
@@ -0,0 +1,345 @@
+/*
+ * QEMU Cryptodev backend for QEMU cipher APIs
+ *
+ * Copyright (c) 2016 HUAWEI TECHNOLOGIES CO., LTD.
+ *
+ * Authors:
+ *Gonglei 
+ *
+ * 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 "qemu/osdep.h"
+#include "sysemu/cryptodev.h"
+#include "hw/boards.h"
+#include "qapi/error.h"
+#include "standard-headers/linux/virtio_crypto.h"
+#include "crypto/cipher.h"
+
+
+/**
+ * @TYPE_CRYPTODEV_BACKEND_BUILTIN:
+ * name of backend that uses QEMU cipher API
+ */
+#define TYPE_CRYPTODEV_BACKEND_BUILTIN "cryptodev-backend-builtin"
+
+#define CRYPTODEV_BACKEND_BUILTIN(obj) \
+OBJECT_CHECK(CryptoDevBackendBuiltin, \
+ (obj), TYPE_CRYPTODEV_BACKEND_BUILTIN)
+
+typedef struct CryptoDevBackendBuiltin
+ CryptoDevBackendBuiltin;
+
+typedef struct CryptoDevBackendBuiltinSession {
+QCryptoCipher *cipher;
+uint8_t direction; /* encryption or decryption */
+uint8_t type; /* cipher? hash? aead? */
+QTAILQ_ENTRY(CryptoDevBackendBuiltinSession) next;
+} CryptoDevBackendBuiltinSession;
+
+/* Max number of symmetric sessions */
+#define MAX_NUM_SESSIONS 256
+
+
+struct CryptoDevBackendBuiltin {
+CryptoDevBackend parent_obj;
+
+CryptoDevBackendBuiltinSession *sessions[MAX_NUM_SESSIONS];
+};
+
+static void cryptodev_builtin_init(
+ CryptoDevBackend *backend, Error **errp)
+{
+/* Only support one queue */
+int queues = backend->conf.peers.queues;
+CryptoDevBackendClient *cc;
+
+if (queues != 1) {
+error_setg(errp,
+  "Only support one queue in cryptdov-builtin backend");
+return;
+}
+
+cc = cryptodev_backend_new_client(
+  "cryptodev-builtin", NULL);
+cc->info_str = g_strdup_printf("cryptodev-builtin0");
+cc->queue_index = 0;
+backend->conf.peers.ccs[0] = cc;
+
+backend->conf.crypto_services =
+ 1u << VIRTIO_CRYPTO_SERVICE_CIPHER |
+ 1u << VIRTIO_CRYPTO_SERVICE_HASH |
+ 1u << VIRTIO_CRYPTO_SERVICE_MAC;
+backend->conf.cipher_algo_l = 1u << VIRTIO_CRYPTO_CIPHER_AES_CBC;
+backend->conf.hash_algo = 1u << VIRTIO_CRYPTO_HASH_SHA1;
+}
+
+static int
+cryptodev_builtin_get_unused_session_index(
+ CryptoDevBackendBuiltin *builtin)
+{
+size_t i;
+
+for (i = 0; i < MAX_NUM_SESSIONS; i++) {
+if (builtin->sessions[i] == NULL) {
+return i;
+}
+}
+
+return -1;
+}
+
+static int
+cryptodev_builtin_get_aes_algo(uint32_t key_len, Error **errp)
+{
+int algo;
+
+if (key_len == 128 / 8) {
+algo = QCRYPTO_CIPHER_ALG_AES_128;
+} else if (key_len == 192 / 8) {
+algo = QCRYPTO_CIPHER_ALG_AES_192;
+} else if (key_len == 256 / 8) {
+algo = QCRYPTO_CIPHER_ALG_AES_256;
+} else {
+error_setg(errp, "Unsupported key length :%u", key_len);
+return -1;
+}
+
+return algo;
+}
+
+static int cryptodev_builtin_create_cipher_session(
+CryptoDevBackendBuiltin *builtin,
+CryptoDevBackendSymSessionInfo *sess_info,
+Error **errp)
+{
+int algo;
+int mode;
+QCryptoCipher *cipher;
+int index;
+CryptoDevBackendBuiltinSession *sess;
+
+if (sess_info->op_type != VIRTIO_CRYPTO_SYM_OP_CIPHER) {
+error_setg(errp, "Unsupported optype :%u", sess_info->op_type);
+return -1;
+}
+
+

Re: [Qemu-devel] [PATCHv3 5/7] spapr: Adjust placement of PCI host bridge to allow > 1TiB RAM

[Laurent Vivier]

On 13/10/2016 01:57, David Gibson wrote:
> Currently the default PCI host bridge for the 'pseries' machine type is
> constructed with its IO windows in the 1TiB..(1TiB + 64GiB) range in
> guest memory space.  This means that if > 1TiB of guest RAM is specified,
> the RAM will collide with the PCI IO windows, causing serious problems.
> 
> Problems won't be obvious until guest RAM goes a bit beyond 1TiB, because
> there's a little unused space at the bottom of the area reserved for PCI,
> but essentially this means that > 1TiB of RAM has never worked with the
> pseries machine type.
> 
> This patch fixes this by altering the placement of PHBs on large-RAM VMs.
> Instead of always placing the first PHB at 1TiB, it is placed at the next
> 1 TiB boundary after the maximum RAM address.
> 
> Technically, this changes behaviour in a migration-breaking way for
> existing machines with > 1TiB maximum memory, but since having > 1 TiB
> memory was broken anyway, this seems like a reasonable trade-off.
> 
> Signed-off-by: David Gibson 

Reviewed-by: Laurent Vivier 

> ---
>  hw/ppc/spapr.c | 16 ++--
>  1 file changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index cb9da96..e6b110d 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -2375,15 +2375,27 @@ static void spapr_phb_placement(sPAPRMachineState 
> *spapr, uint32_t index,
>  unsigned n_dma, uint32_t *liobns, Error 
> **errp)
>  {
>  const uint64_t base_buid = 0x8002000ULL;
> -const hwaddr phb0_base = 0x100ULL; /* 1 TiB */
>  const hwaddr phb_spacing = 0x10ULL; /* 64 GiB */
>  const hwaddr mmio_offset = 0xa000; /* 2 GiB + 512 MiB */
>  const hwaddr pio_offset = 0x8000; /* 2 GiB */
>  const uint32_t max_index = 255;
> +const hwaddr phb0_alignment = 0x100ULL; /* 1 TiB */
>  
> -hwaddr phb_base;
> +uint64_t ram_top = MACHINE(spapr)->ram_size;
> +hwaddr phb0_base, phb_base;
>  int i;
>  
> +/* Do we have hotpluggable memory? */
> +if (MACHINE(spapr)->maxram_size > ram_top) {
> +/* Can't just use maxram_size, because there may be an
> + * alignment gap between normal and hotpluggable memory
> + * regions */
> +ram_top = spapr->hotplug_memory.base +
> +memory_region_size(&spapr->hotplug_memory.mr);
> +}
> +
> +phb0_base = QEMU_ALIGN_UP(ram_top, phb0_alignment);
> +
>  if (index > max_index) {
>  error_setg(errp, "\"index\" for PAPR PHB is too large (max %u)",
> max_index);
> 

[Qemu-devel] [PATCH v7 07/12] virtio-crypto: set capacity of algorithms supported

[Gonglei]

Expose the capacity of algorithms supported by
virtio crypto device to the frontend driver using
pci configuration space.

Signed-off-by: Gonglei 
---
 hw/virtio/virtio-crypto.c | 40 ++-
 include/hw/virtio/virtio-crypto.h | 14 ++
 2 files changed, 53 insertions(+), 1 deletion(-)

diff --git a/hw/virtio/virtio-crypto.c b/hw/virtio/virtio-crypto.c
index 109a504..2032d31 100644
--- a/hw/virtio/virtio-crypto.c
+++ b/hw/virtio/virtio-crypto.c
@@ -42,6 +42,22 @@ static void virtio_crypto_reset(VirtIODevice *vdev)
 }
 }
 
+static void virtio_crypto_init_config(VirtIODevice *vdev)
+{
+VirtIOCrypto *vcrypto = VIRTIO_CRYPTO(vdev);
+
+vcrypto->conf.crypto_services =
+ vcrypto->conf.cryptodev->conf.crypto_services;
+vcrypto->conf.cipher_algo_l =
+ vcrypto->conf.cryptodev->conf.cipher_algo_l;
+vcrypto->conf.cipher_algo_h =
+ vcrypto->conf.cryptodev->conf.cipher_algo_h;
+vcrypto->conf.hash_algo = vcrypto->conf.cryptodev->conf.hash_algo;
+vcrypto->conf.mac_algo_l = vcrypto->conf.cryptodev->conf.mac_algo_l;
+vcrypto->conf.mac_algo_h = vcrypto->conf.cryptodev->conf.mac_algo_h;
+vcrypto->conf.aead_algo = vcrypto->conf.cryptodev->conf.aead_algo;
+}
+
 static void virtio_crypto_device_realize(DeviceState *dev, Error **errp)
 {
 VirtIODevice *vdev = VIRTIO_DEVICE(dev);
@@ -75,6 +91,8 @@ static void virtio_crypto_device_realize(DeviceState *dev, 
Error **errp)
 } else {
 vcrypto->status |= VIRTIO_CRYPTO_S_HW_READY;
 }
+
+virtio_crypto_init_config(vdev);
 }
 
 static void virtio_crypto_device_unrealize(DeviceState *dev, Error **errp)
@@ -100,7 +118,27 @@ static Property virtio_crypto_properties[] = {
 
 static void virtio_crypto_get_config(VirtIODevice *vdev, uint8_t *config)
 {
-
+VirtIOCrypto *c = VIRTIO_CRYPTO(vdev);
+struct virtio_crypto_config crypto_cfg;
+
+virtio_stl_p(vdev, &crypto_cfg.status, c->status);
+virtio_stl_p(vdev, &crypto_cfg.max_dataqueues, c->max_queues);
+virtio_stl_p(vdev, &crypto_cfg.crypto_services,
+   c->conf.crypto_services);
+virtio_stl_p(vdev, &crypto_cfg.cipher_algo_l,
+   c->conf.cipher_algo_l);
+virtio_stl_p(vdev, &crypto_cfg.cipher_algo_h,
+   c->conf.cipher_algo_h);
+virtio_stl_p(vdev, &crypto_cfg.hash_algo,
+   c->conf.hash_algo);
+virtio_stl_p(vdev, &crypto_cfg.mac_algo_l,
+   c->conf.mac_algo_l);
+virtio_stl_p(vdev, &crypto_cfg.mac_algo_h,
+   c->conf.mac_algo_h);
+virtio_stl_p(vdev, &crypto_cfg.aead_algo,
+   c->conf.aead_algo);
+
+memcpy(config, &crypto_cfg, c->config_size);
 }
 
 static void virtio_crypto_class_init(ObjectClass *klass, void *data)
diff --git a/include/hw/virtio/virtio-crypto.h 
b/include/hw/virtio/virtio-crypto.h
index 9bf2b74..a5e826c 100644
--- a/include/hw/virtio/virtio-crypto.h
+++ b/include/hw/virtio/virtio-crypto.h
@@ -39,6 +39,20 @@ do { \
 
 typedef struct VirtIOCryptoConf {
 CryptoDevBackend *cryptodev;
+
+/* Supported service mask */
+uint32_t crypto_services;
+
+/* Detailed algorithms mask */
+uint32_t cipher_algo_l;
+uint32_t cipher_algo_h;
+uint32_t hash_algo;
+uint32_t mac_algo_l;
+uint32_t mac_algo_h;
+uint32_t asym_algo;
+uint32_t kdf_algo;
+uint32_t aead_algo;
+uint32_t primitive_algo;
 } VirtIOCryptoConf;
 
 struct VirtIOCrypto;
-- 
1.8.3.1

Re: [Qemu-devel] [PATCH v3 6/7] target-arm: Make page size a runtime setting

[Andrew Jones]

On Wed, Oct 12, 2016 at 02:40:30PM +0100, Peter Maydell wrote:
> On 12 October 2016 at 14:33, Andrew Jones  wrote:
> > On Tue, Oct 11, 2016 at 06:08:18PM +0100, Peter Maydell wrote:
> >> Rather than defining TARGET_PAGE_BITS to always be 10,
> >> switch to using a value picked at runtime. This allows us
> >> to use 4K pages for modern ARM CPUs (and in particular all
> >> 64-bit CPUs) without having to drop support for the old
> >> ARMv5 CPUs which had 1K pages.
> >>
> >> Signed-off-by: Peter Maydell 
> 
> >> +if (!set_preferred_target_page_bits(pagebits)) {
> >> +/* This can only ever happen for hotplugging a CPU, or if
> >> + * the board code incorrectly creates a CPU which it has
> >> + * promised via minimum_page_size that it will not.
> >> + */
> >> +error_setg(errp, "This CPU requires a smaller page size than the "
> >> +   "system is using");
> >
> > I'm not sure about this. IIUC, then with this it won't be possible to
> > create a board that sets up its cpus with the preferred target page bits
> > greater than the cpu's default set above, even when the cpu supports it.
> > For example, I may want a board that will only use AArch64 cpus with 64K
> > pages. In that case I'd like to set the minimum to 16 bits, but then that
> > would result in this error. I think we should only set the default when a
> > preference hasn't already been given. And, maybe we should also provide
> > a maximum to sanity check against? (side note: if we provide a maximum,
> > then we could use it in arch_dump.c for the dump info's block size,
> > which must be the maximum page size the cpu supports.)
> 
> If we had a CPU which supported only 64K pages then we would
> make this if-ladder set pagebits appropriately. But we don't
> have any of those, so it's a bit moot. If the CPU can be
> configured by the guest to use 4K pages then the board
> must not have set the preferred-page-size to something
> larger, or the guest will fall over when it tries it.
> That's what this check is protecting against.

Fair enough and understood, but there is a case where we can know
what page size to use. When booting with -kernel we can probe the
kernel image's header (see Documentation/arm64/booting.txt) If the
magic number matches, then we can check the header flags to see
what the kernel page size is.

An API like the one in this series would be useful for setting
the page size to match the guest kernel's, but only if the API
doesn't override the selection.

> 
> The CPU's maximum page size isn't very interesting for this
> patchset, because we only care about the minimum (which is
> what the TLB needs to use). If the board code was somehow
> buggy and requested a page size greater than the CPU's
> maximum, then it will also be greater than the CPU's
> minimum, and be caught by this error message.

Agreed we don't need a maximum as it is now. I think we may
if we allow preferences to be greater than the minimum though.

Thanks,
drew

Re: [Qemu-devel] [PATCH 0/5] More thread sanitizer fixes and atomic.h improvements

[Paolo Bonzini]

> On Mon, Oct 10, 2016 at 15:59:02 +0200, Paolo Bonzini wrote:
> > See each patch.  My attempt at fixing whatever I did when I obviously
> > didn't know enough^W about the C11 memory model, and at setting a
> > better example for future generations...
> 
> Just for context. Building on this patchset, is it now time to
> phase out smp_(rw)mb in favour or C11's acq/rel, as you laid
> out in your KVM Forum talk [*]?

Yes, this would be the start of it.  However I'm a bit undecided
because ARMv8 doesn't have acq/rel memory barriers, and its STLR
opcode is stronger than a store release.

> What is the plan with smp_mb_(sg)et? It's not clear to me from
> the slides, but given patch 5 I don't see a reason to keep them.

No plan for now.  It makes sense to phase out at least atomic_mb_read.
atomic_mb_set is more efficient on x86 than store+mfence, so there's
that too.

Paolo

[Qemu-devel] [PATCH v7 03/12] virtio-crypto: introduce virtio_crypto.h

[Gonglei]

Introduce the virtio_crypto.h which follows
virtio-crypto specification.

Signed-off-by: Gonglei 
---
 include/standard-headers/linux/virtio_crypto.h | 406 +
 1 file changed, 406 insertions(+)
 create mode 100644 include/standard-headers/linux/virtio_crypto.h

diff --git a/include/standard-headers/linux/virtio_crypto.h 
b/include/standard-headers/linux/virtio_crypto.h
new file mode 100644
index 000..f2a059e
--- /dev/null
+++ b/include/standard-headers/linux/virtio_crypto.h
@@ -0,0 +1,406 @@
+#ifndef _LINUX_VIRTIO_CRYPTO_H
+#define _LINUX_VIRTIO_CRYPTO_H
+/* This header is BSD licensed so anyone can use the definitions to implement
+ * compatible drivers/servers.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of IBM nor the names of its contributors
+ *may be used to endorse or promote products derived from this software
+ *without specific prior written permission.
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS 
IS''
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL IBM OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE. */
+
+#include "standard-headers/linux/types.h"
+#include "standard-headers/linux/virtio_config.h"
+#include "standard-headers/linux/virtio_types.h"
+
+
+#define VIRTIO_CRYPTO_SERVICE_CIPHER 0
+#define VIRTIO_CRYPTO_SERVICE_HASH 1
+#define VIRTIO_CRYPTO_SERVICE_MAC  2
+#define VIRTIO_CRYPTO_SERVICE_AEAD 3
+
+#define VIRTIO_CRYPTO_OPCODE(service, op)   (((service) << 8) | (op))
+
+struct virtio_crypto_ctrl_header {
+#define VIRTIO_CRYPTO_CIPHER_CREATE_SESSION \
+   VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_CIPHER, 0x02)
+#define VIRTIO_CRYPTO_CIPHER_DESTROY_SESSION \
+   VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_CIPHER, 0x03)
+#define VIRTIO_CRYPTO_HASH_CREATE_SESSION \
+   VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_HASH, 0x02)
+#define VIRTIO_CRYPTO_HASH_DESTROY_SESSION \
+   VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_HASH, 0x03)
+#define VIRTIO_CRYPTO_MAC_CREATE_SESSION \
+   VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_MAC, 0x02)
+#define VIRTIO_CRYPTO_MAC_DESTROY_SESSION \
+   VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_MAC, 0x03)
+#define VIRTIO_CRYPTO_AEAD_CREATE_SESSION \
+   VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x02)
+#define VIRTIO_CRYPTO_AEAD_DESTROY_SESSION \
+   VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x03)
+__virtio32 opcode;
+__virtio32 algo;
+__virtio32 flag;
+/* data virtqueue id */
+__virtio32 queue_id;
+};
+
+struct virtio_crypto_cipher_session_para {
+#define VIRTIO_CRYPTO_NO_CIPHER 0
+#define VIRTIO_CRYPTO_CIPHER_ARC4   1
+#define VIRTIO_CRYPTO_CIPHER_AES_ECB2
+#define VIRTIO_CRYPTO_CIPHER_AES_CBC3
+#define VIRTIO_CRYPTO_CIPHER_AES_CTR4
+#define VIRTIO_CRYPTO_CIPHER_DES_ECB5
+#define VIRTIO_CRYPTO_CIPHER_DES_CBC6
+#define VIRTIO_CRYPTO_CIPHER_3DES_ECB   7
+#define VIRTIO_CRYPTO_CIPHER_3DES_CBC   8
+#define VIRTIO_CRYPTO_CIPHER_3DES_CTR   9
+#define VIRTIO_CRYPTO_CIPHER_KASUMI_F8  10
+#define VIRTIO_CRYPTO_CIPHER_SNOW3G_UEA211
+#define VIRTIO_CRYPTO_CIPHER_AES_F8 12
+#define VIRTIO_CRYPTO_CIPHER_AES_XTS13
+#define VIRTIO_CRYPTO_CIPHER_ZUC_EEA3   14
+__virtio32 algo;
+/* length of key */
+__virtio32 keylen;
+
+#define VIRTIO_CRYPTO_OP_ENCRYPT  1
+#define VIRTIO_CRYPTO_OP_DECRYPT  2
+/* encrypt or decrypt */
+__virtio32 op;
+__virtio32 padding;
+};
+
+struct virtio_crypto_session_input {
+/* Device-writable part */
+__virtio64 session_id;
+__virtio32 status;
+__virtio32 padding;
+};
+
+struct virtio_crypto_cipher_session_req {
+struct virtio_crypto_cipher_session_para para;
+};
+
+struct virtio_crypto_hash_session_para {
+#define VIRTIO_CRYPTO_NO_HASH

Re: [Qemu-devel] [PATCH v1 2/2] gdbstub: Fix vCont behaviour

[Paolo Bonzini]

- Original Message -
> From: "David Hildenbrand" 
> To: "Claudio Imbrenda" 
> Cc: "David Hildenbrand" , "Paolo Bonzini" 
> , qemu-devel@nongnu.org
> Sent: Wednesday, October 12, 2016 8:38:15 PM
> Subject: Re: [Qemu-devel] [PATCH v1 2/2] gdbstub: Fix vCont behaviour
> 
> On Wed, Oct 12, 2016 at 03:55:18PM +0200, Claudio Imbrenda wrote:
> > On 12/10/16 15:15, David Hildenbrand wrote:
> > >>> +for (cx = 0; ccpus && ccpus[cx]; cx++) {
> > >>> +cpu_single_step(cpu, 0);
> > > 
> > > This looks suspicious
> > 
> > why? we set all cpus to single step, since that is the default, and then
> > we clear the single-step property from all CPUs that should be restarted
> > in normal mode, then we restart all CPUs. Those in single-step will
> > indeed only perform one single step, the others will run freely (at
> > least until the first single-step CPU stops again).
> 
> actually I was more concerned about calling it on "cpu" in a loop.

And we all missed that it should have been ccpus[cx], not cpu. :)

Paolo

Re: [Qemu-devel] [PATCH 1/2] 9pfs: fix information leak in xattr read

[Greg Kurz]

On Wed, 12 Oct 2016 15:49:46 -0500
Eric Blake  wrote:

> On 10/12/2016 08:23 AM, Greg Kurz wrote:
> > 
> > But in fact, I'm afraid we have a more serious problem here... size
> > comes from the guest and could cause g_malloc() to abort if QEMU has
> > reached some RLIMIT... we need to call g_try_malloc0() and return
> > ENOMEM if the allocation fails.  
> 
> Even if it does not cause an ENOMEM failure right away, the guest can
> also use this to chew up lots of host resources. It may also be worth
> putting a reasonable cap at the maximum the guest can allocate, rather
> than just trying to malloc every possible size.
> 

In the case of v9fs_xattrcreate(), the allocation of the xattr value only
happens if a fid with a specific id was created. This function alone cannot
be used to chew up memory, but it can certainly be used to crash QEMU if the
guest passes an insanely great value.

I fully agree that guest triggered allocations should be capped though,
and the more I look the more I realize the 9p code is fragile on this
matter... This will require more analysis and fixing, which goes far
beyond the scope of preventing an immediate crash.

Cheers.

--
Greg




pgpUPo0OeukPa.pgp
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v2] 9pfs: fix integer overflow issue in xattr read/write

[Greg Kurz]

On Wed, 12 Oct 2016 19:53:39 -0700
Li Qiang  wrote:

> From: Li Qiang 
> 
> In 9pfs xattr read/write function, it mix to use unsigned/signed
> ,32/64 bits integers. This will causes oob read/write issues. This patch
> fix this.
> 

I suggested a more detailed changelog.

> Signed-off-by: Li Qiang 
> ---
>  hw/9pfs/9p.c | 34 +-
>  hw/9pfs/9p.h |  4 ++--
>  2 files changed, 15 insertions(+), 23 deletions(-)
> 
> diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
> index e4040dc..8c7488f 100644
> --- a/hw/9pfs/9p.c
> +++ b/hw/9pfs/9p.c
> @@ -1642,20 +1642,17 @@ static int v9fs_xattr_read(V9fsState *s, V9fsPDU 
> *pdu, V9fsFidState *fidp,
>  {
>  ssize_t err;
>  size_t offset = 7;
> -int read_count;
> -int64_t xattr_len;
> +uint64_t read_count;
>  V9fsVirtioState *v = container_of(s, V9fsVirtioState, state);
>  VirtQueueElement *elem = v->elems[pdu->idx];
>  
> -xattr_len = fidp->fs.xattr.len;
> -read_count = xattr_len - off;
> +if (fidp->fs.xattr.len < off) {
> +read_count = 0;
> +} else {
> +   read_count = fidp->fs.xattr.len - off;
> +}
>  if (read_count > max_count) {
>  read_count = max_count;
> -} else if (read_count < 0) {
> -/*
> - * read beyond XATTR value
> - */
> -read_count = 0;
>  }
>  err = pdu_marshal(pdu, offset, "d", read_count);
>  if (err < 0) {
> @@ -1982,23 +1979,18 @@ static int v9fs_xattr_write(V9fsState *s, V9fsPDU 
> *pdu, V9fsFidState *fidp,
>  {
>  int i, to_copy;
>  ssize_t err = 0;
> -int write_count;
> -int64_t xattr_len;
> +uint64_t write_count;
>  size_t offset = 7;
>  
>  
> -xattr_len = fidp->fs.xattr.len;
> -write_count = xattr_len - off;
> -if (write_count > count) {
> -write_count = count;
> -} else if (write_count < 0) {
> -/*
> - * write beyond XATTR value len specified in
> - * xattrcreate
> - */
> +if (fidp->fs.xattr.len < off) {
>  err = -ENOSPC;
>  goto out;
>  }
> +write_count = fidp->fs.xattr.len - off;
> +if (write_count > count) {
> +write_count = count;
> +}
>  err = pdu_marshal(pdu, offset, "d", write_count);
>  if (err < 0) {
>  return err;
> @@ -3254,7 +3246,7 @@ static void v9fs_xattrcreate(void *opaque)
>  {
>  int flags;
>  int32_t fid;
> -int64_t size;
> +uint64_t size;
>  ssize_t err = 0;
>  V9fsString name;
>  size_t offset = 7;
> diff --git a/hw/9pfs/9p.h b/hw/9pfs/9p.h
> index d539d2e..22198f6 100644
> --- a/hw/9pfs/9p.h
> +++ b/hw/9pfs/9p.h
> @@ -159,8 +159,8 @@ typedef struct V9fsConf
>  
>  typedef struct V9fsXattr
>  {
> -int64_t copied_len;
> -int64_t len;
> +uint64_t copied_len;
> +uint64_t len;

I had asked this to go to a separate patch... with the appropriate
justifications that these are byte counts and size_t/u64 in the guest.

>  void *value;
>  V9fsString name;
>  int flags;

[Qemu-devel] [PATCH v7 08/12] virtio-crypto: add control queue handler

[Gonglei]

Realize the symmetric algorithm control queue handler,
including plain cipher and chainning algorithms.

Currently the control queue is used to create and
close session for symmetric algorithm.

Signed-off-by: Gonglei 
---
 hw/virtio/virtio-crypto.c | 285 +-
 1 file changed, 284 insertions(+), 1 deletion(-)

diff --git a/hw/virtio/virtio-crypto.c b/hw/virtio/virtio-crypto.c
index 2032d31..db86796 100644
--- a/hw/virtio/virtio-crypto.c
+++ b/hw/virtio/virtio-crypto.c
@@ -23,6 +23,289 @@
 
 #define VIRTIO_CRYPTO_VM_VERSION 1
 
+/*
+ * Transfer virtqueue index to crypto queue index.
+ * The control virtqueue is after the data virtqueues
+ * so the input value doesn't need to be adjusted
+ */
+static inline int virtio_crypto_vq2q(int queue_index)
+{
+return queue_index;
+}
+
+static int
+virtio_crypto_cipher_session_helper(VirtIODevice *vdev,
+   CryptoDevBackendSymSessionInfo *info,
+   struct virtio_crypto_cipher_session_para *cipher_para,
+   struct iovec **iov, unsigned int *out_num)
+{
+unsigned int num = *out_num;
+
+info->cipher_alg = virtio_ldl_p(vdev, &cipher_para->algo);
+info->key_len = virtio_ldl_p(vdev, &cipher_para->keylen);
+info->direction = virtio_ldl_p(vdev, &cipher_para->op);
+DPRINTF("cipher_alg=%" PRIu32 ", info->direction=%" PRIu32 "\n",
+ info->cipher_alg, info->direction);
+/* Get cipher key */
+if (info->key_len > 0) {
+size_t s;
+DPRINTF("keylen=%" PRIu32 "\n", info->key_len);
+
+info->cipher_key = g_malloc(info->key_len);
+s = iov_to_buf(*iov, num, 0, info->cipher_key, info->key_len);
+if (unlikely(s != info->key_len)) {
+virtio_error(vdev, "virtio-crypto cipher key incorrect");
+return -EFAULT;
+}
+iov_discard_front(iov, &num, info->key_len);
+*out_num = num;
+}
+
+return 0;
+}
+
+static int64_t
+virtio_crypto_create_sym_session(VirtIOCrypto *vcrypto,
+   struct virtio_crypto_sym_create_session_req *sess_req,
+   uint32_t queue_id,
+   uint32_t opcode,
+   struct iovec *iov, unsigned int out_num)
+{
+VirtIODevice *vdev = VIRTIO_DEVICE(vcrypto);
+CryptoDevBackendSymSessionInfo info;
+int64_t session_id;
+int queue_index;
+uint32_t op_type;
+Error *local_err = NULL;
+int ret;
+
+memset(&info, 0, sizeof(info));
+op_type = virtio_ldl_p(vdev, &sess_req->op_type);
+info.op_type = op_type;
+info.op_code = opcode;
+
+if (op_type == VIRTIO_CRYPTO_SYM_OP_CIPHER) {
+ret = virtio_crypto_cipher_session_helper(vdev, &info,
+   &sess_req->u.cipher.para,
+   &iov, &out_num);
+if (ret < 0) {
+return -EFAULT;
+}
+} else if (op_type == VIRTIO_CRYPTO_SYM_OP_ALGORITHM_CHAINING) {
+size_t s;
+/* cipher part */
+ret = virtio_crypto_cipher_session_helper(vdev, &info,
+   &sess_req->u.chain.para.cipher_param,
+   &iov, &out_num);
+if (ret < 0) {
+return -EFAULT;
+}
+/* hash part */
+info.alg_chain_order = virtio_ldl_p(vdev,
+   
&sess_req->u.chain.para.alg_chain_order);
+info.add_len = virtio_ldl_p(vdev, &sess_req->u.chain.para.aad_len);
+info.hash_mode = virtio_ldl_p(vdev, &sess_req->u.chain.para.hash_mode);
+if (info.hash_mode == VIRTIO_CRYPTO_SYM_HASH_MODE_AUTH) {
+info.hash_alg = virtio_ldl_p(vdev,
+   &sess_req->u.chain.para.u.mac_param.algo);
+info.auth_key_len = virtio_ldl_p(vdev,
+ &sess_req->u.chain.para.u.mac_param.auth_key_len);
+info.hash_result_len = virtio_ldl_p(vdev,
+   
&sess_req->u.chain.para.u.mac_param.hash_result_len);
+/* get auth key */
+if (info.auth_key_len > 0) {
+DPRINTF("auth_keylen=%" PRIu32 "\n", info.auth_key_len);
+info.auth_key = g_malloc(info.auth_key_len);
+s = iov_to_buf(iov, out_num, 0, info.auth_key,
+   info.auth_key_len);
+if (unlikely(s != info.auth_key_len)) {
+virtio_error(vdev,
+  "virtio-crypto authenticated key incorrect");
+ret = -EFAULT;
+goto err;
+}
+iov_discard_front(&iov, &out_num, info.auth_key_len);
+}
+} else if (info.hash_mode == VIRTIO_CRYPTO_SYM_HASH_MODE_PLAIN) {
+info.hash_alg = virtio_ldl_p(vdev,
+ &sess_req->u.chain.para.u.hash_param.algo);
+info.hash_result_len = virtio_ldl_p(vdev,
+&sess_req->u.chain.para.u.hash_param.hash_result_len);
+} else 

Re: [Qemu-devel] [PATCH v4 1/8] record/replay: add network support

[Pavel Dovgalyuk]

Jason, what about v5 of this patch?

Pavel Dovgalyuk

> -Original Message-
> From: Jason Wang [mailto:jasow...@redhat.com]
> Sent: Friday, September 23, 2016 9:07 AM
> To: Pavel Dovgalyuk; qemu-devel@nongnu.org
> Cc: peter.mayd...@linaro.org; quint...@redhat.com; pbonz...@redhat.com; 
> m...@redhat.com
> Subject: Re: [PATCH v4 1/8] record/replay: add network support
> 
> 
> 
> On 2016年09月21日 19:33, Pavel Dovgalyuk wrote:
> > This patch adds support of recording and replaying network packets in
> > irount rr mode.
> >
> > Record and replay for network interactions is performed with the network 
> > filter.
> > Each backend must have its own instance of the replay filter as follows:
> >   -netdev user,id=net1 -device rtl8139,netdev=net1
> >   -object filter-replay,id=replay,netdev=net1
> >
> > Replay network filter is used to record and replay network packets. While
> > recording the virtual machine this filter puts all packets coming from
> > the outer world into the log. In replay mode packets from the log are
> > injected into the network device. All interactions with network backend
> > in replay mode are disabled.
> >
> > Signed-off-by: Pavel Dovgalyuk 
> 
> Looks good, just few nits, see below.
> 
> Thanks
> 
> > ---
> >   docs/replay.txt  |   14 ++
> >   include/sysemu/replay.h  |   12 +
> >   net/Makefile.objs|1
> >   net/filter-replay.c  |   92 ++
> >   replay/Makefile.objs |1
> >   replay/replay-events.c   |   11 +
> >   replay/replay-internal.h |   10 
> >   replay/replay-net.c  |  111 
> > ++
> >   replay/replay.c  |2 -
> >   vl.c |3 +
> >   10 files changed, 255 insertions(+), 2 deletions(-)
> >   create mode 100644 net/filter-replay.c
> >   create mode 100644 replay/replay-net.c
> >
> > diff --git a/docs/replay.txt b/docs/replay.txt
> > index 779c6c0..347b2ff 100644
> > --- a/docs/replay.txt
> > +++ b/docs/replay.txt
> > @@ -195,3 +195,17 @@ Queue is flushed at checkpoints and information about 
> > processed
> requests
> >   is recorded to the log. In replay phase the queue is matched with
> >   events read from the log. Therefore block devices requests are processed
> >   deterministically.
> > +
> > +Network devices
> > +---
> > +
> > +Record and replay for network interactions is performed with the network 
> > filter.
> > +Each backend must have its own instance of the replay filter as follows:
> > + -netdev user,id=net1 -device rtl8139,netdev=net1
> > + -object filter-replay,id=replay,netdev=net1
> > +
> > +Replay network filter is used to record and replay network packets. While
> > +recording the virtual machine this filter puts all packets coming from
> > +the outer world into the log. In replay mode packets from the log are
> > +injected into the network device. All interactions with network backend
> > +in replay mode are disabled.
> > diff --git a/include/sysemu/replay.h b/include/sysemu/replay.h
> > index 0a88393..a408633 100644
> > --- a/include/sysemu/replay.h
> > +++ b/include/sysemu/replay.h
> > @@ -39,6 +39,8 @@ enum ReplayCheckpoint {
> >   };
> >   typedef enum ReplayCheckpoint ReplayCheckpoint;
> >
> > +typedef struct ReplayNetState ReplayNetState;
> > +
> >   extern ReplayMode replay_mode;
> >
> >   /* Replay process control functions */
> > @@ -133,4 +135,14 @@ void replay_char_read_all_save_error(int res);
> >   /*! Writes character read_all execution result into the replay log. */
> >   void replay_char_read_all_save_buf(uint8_t *buf, int offset);
> >
> > +/* Network */
> > +
> > +/*! Registers replay network filter attached to some backend. */
> > +ReplayNetState *replay_register_net(NetFilterState *nfs);
> > +/*! Unregisters replay network filter. */
> > +void replay_unregister_net(ReplayNetState *rns);
> > +/*! Called to write network packet to the replay log. */
> > +void replay_net_packet_event(ReplayNetState *rns, unsigned flags,
> > + const struct iovec *iov, int iovcnt);
> > +
> >   #endif
> > diff --git a/net/Makefile.objs b/net/Makefile.objs
> > index b7c22fd..f787ba4 100644
> > --- a/net/Makefile.objs
> > +++ b/net/Makefile.objs
> > @@ -16,3 +16,4 @@ common-obj-$(CONFIG_NETMAP) += netmap.o
> >   common-obj-y += filter.o
> >   common-obj-y += filter-buffer.o
> >   common-obj-y += filter-mirror.o
> > +common-obj-y += filter-replay.o
> > diff --git a/net/filter-replay.c b/net/filter-replay.c
> > new file mode 100644
> > index 000..cff65f8
> > --- /dev/null
> > +++ b/net/filter-replay.c
> > @@ -0,0 +1,92 @@
> > +/*
> > + * filter-replay.c
> > + *
> > + * Copyright (c) 2010-2016 Institute for System Programming
> > + * of the Russian Academy of Sciences.
> > + *
> > + * This work is licensed under the terms of the GNU GPL, version 2 or 
> > later.
> > + * See the COPYING file in the top-level directory.
> > + *
> > + */
> > 

Re: [Qemu-devel] [PATCH] 9pfs: add xattrwalk_fid field in V9fsFidState struct

[Greg Kurz]

On Wed, 12 Oct 2016 19:55:42 -0700
Li Qiang  wrote:

> From: Li Qiang 
> 
> Currently, 9pfs sets the fs.xattr.copied_len field in V9fsFidState
> to -1 to indicate a xattr walk fid. As the fs.xattr.copied_len is also
> used to account for copied bytes, this may cause confusion. This patch
> add a bool variable to represent the xattr walk fid.
> 
> Signed-off-by: Li Qiang 
> ---

Please send a patchset instead of individual patches... it makes reviewing
difficult.

For example, this patch and the "9pfs: fix integer overflow issue in xattr
read/write" one are about fixing how xattr.copied_len and xattr.len are
being used. They definitely should be sent together.

I suggest you send a new patchset with a cover letter and 3 patches:
- the cover letter and the patches should be tagged v3, since this will be
  your third post on the same topic
- the cover letter should describe the overall problem: wrong types, unsafe
  computations, copied_len used both to account bytes and to tag the xattr
  fid.
- patch 1/3: this patch, with changes since the previous version below the ---
- patch 2/3: conversion of copied_len/len to uint64_t
- patch 3/3: "9pfs: fix integer overflow...", with changes since the previous
  version below the ---

>  hw/9pfs/9p.c | 7 ---
>  hw/9pfs/9p.h | 1 +
>  2 files changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
> index 8c7488f..9625296 100644
> --- a/hw/9pfs/9p.c
> +++ b/hw/9pfs/9p.c
> @@ -325,7 +325,7 @@ static int v9fs_xattr_fid_clunk(V9fsPDU *pdu, 
> V9fsFidState *fidp)
>  {
>  int retval = 0;
>  
> -if (fidp->fs.xattr.copied_len == -1) {
> +if (fidp->xattrwalk_fid) {
>  /* getxattr/listxattr fid */
>  goto free_value;
>  }
> @@ -3181,7 +3181,7 @@ static void v9fs_xattrwalk(void *opaque)
>   */
>  xattr_fidp->fs.xattr.len = size;
>  xattr_fidp->fid_type = P9_FID_XATTR;
> -xattr_fidp->fs.xattr.copied_len = -1;
> +xattr_fidp->xattrwalk_fid  = true;
>  if (size) {
>  xattr_fidp->fs.xattr.value = g_malloc(size);
>  err = v9fs_co_llistxattr(pdu, &xattr_fidp->path,
> @@ -3214,7 +3214,7 @@ static void v9fs_xattrwalk(void *opaque)
>   */
>  xattr_fidp->fs.xattr.len = size;
>  xattr_fidp->fid_type = P9_FID_XATTR;
> -xattr_fidp->fs.xattr.copied_len = -1;
> +xattr_fidp->xattrwalk_fid  = true;
>  if (size) {
>  xattr_fidp->fs.xattr.value = g_malloc(size);
>  err = v9fs_co_lgetxattr(pdu, &xattr_fidp->path,
> @@ -3269,6 +3269,7 @@ static void v9fs_xattrcreate(void *opaque)
>  /* Make the file fid point to xattr */
>  xattr_fidp = file_fidp;
>  xattr_fidp->fid_type = P9_FID_XATTR;
> +xattr_fidp->xattrwalk_fid  = false;
>  xattr_fidp->fs.xattr.copied_len = 0;
>  xattr_fidp->fs.xattr.len = size;
>  xattr_fidp->fs.xattr.flags = flags;
> diff --git a/hw/9pfs/9p.h b/hw/9pfs/9p.h
> index 22198f6..7e1e70b 100644
> --- a/hw/9pfs/9p.h
> +++ b/hw/9pfs/9p.h
> @@ -214,6 +214,7 @@ struct V9fsFidState
>  uid_t uid;
>  int ref;
>  int clunked;
> +bool xattrwalk_fid;

This belongs to the V9fsXattr type.

>  V9fsFidState *next;
>  V9fsFidState *rclm_lst;
>  };

Cheers.

--
Greg

Re: [Qemu-devel] [PATCHv3 6/7] spapr_pci: Add a 64-bit MMIO window

[Laurent Vivier]

On 13/10/2016 01:57, David Gibson wrote:
> On real hardware, and under pHyp, the PCI host bridges on Power machines
> typically advertise two outbound MMIO windows from the guest's physical
> memory space to PCI memory space:
>   - A 32-bit window which maps onto 2GiB..4GiB in the PCI address space
>   - A 64-bit window which maps onto a large region somewhere high in PCI
> address space (traditionally this used an identity mapping from guest
> physical address to PCI address, but that's not always the case)
> 
> The qemu implementation in spapr-pci-host-bridge, however, only supports a
> single outbound MMIO window, however.  At least some Linux versions expect
> the two windows however, so we arranged this window to map onto the PCI
> memory space from 2 GiB..~64 GiB, then advertised it as two contiguous
> windows, the "32-bit" window from 2G..4G and the "64-bit" window from
> 4G..~64G.
> 
> This approach means, however, that the 64G window is not naturally aligned.
> In turn this limits the size of the largest BAR we can map (which does have
> to be naturally aligned) to roughly half of the total window.  With some
> large nVidia GPGPU cards which have huge memory BARs, this is starting to
> be a problem.
> 
> This patch adds true support for separate 32-bit and 64-bit outbound MMIO
> windows to the spapr-pci-host-bridge implementation, each of which can
> be independently configured.  The 32-bit window always maps to 2G.. in PCI
> space, but the PCI address of the 64-bit window can be configured (it
> defaults to the same as the guest physical address).
> 
> So as not to break possible existing configurations, as long as a 64-bit
> window is not specified, a large single window can be specified.  This
> will appear the same way to the guest as the old approach, although it's
> now implemented by two contiguous memory regions rather than a single one.
> 
> For now, this only adds the possibility of 64-bit windows.  The default
> configuration still uses the legacy mode.
> 
> Signed-off-by: David Gibson 

Reviewed-by: Laurent Vivier 

> ---
>  hw/ppc/spapr.c  | 10 +--
>  hw/ppc/spapr_pci.c  | 70 
> -
>  include/hw/pci-host/spapr.h |  8 --
>  include/hw/ppc/spapr.h  |  3 +-
>  4 files changed, 72 insertions(+), 19 deletions(-)
> 
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index e6b110d..8db3657 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -2371,7 +2371,8 @@ static HotpluggableCPUList 
> *spapr_query_hotpluggable_cpus(MachineState *machine)
>  }
>  
>  static void spapr_phb_placement(sPAPRMachineState *spapr, uint32_t index,
> -uint64_t *buid, hwaddr *pio, hwaddr *mmio,
> +uint64_t *buid, hwaddr *pio,
> +hwaddr *mmio32, hwaddr *mmio64,
>  unsigned n_dma, uint32_t *liobns, Error 
> **errp)
>  {
>  const uint64_t base_buid = 0x8002000ULL;
> @@ -2409,7 +2410,12 @@ static void spapr_phb_placement(sPAPRMachineState 
> *spapr, uint32_t index,
>  
>  phb_base = phb0_base + index * phb_spacing;
>  *pio = phb_base + pio_offset;
> -*mmio = phb_base + mmio_offset;
> +*mmio32 = phb_base + mmio_offset;
> +/*
> + * We don't set the 64-bit MMIO window, relying on the PHB's
> + * fallback behaviour of automatically splitting a large "32-bit"
> + * window into contiguous 32-bit and 64-bit windows
> + */
>  }
>  
>  static void spapr_machine_class_init(ObjectClass *oc, void *data)
> diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c
> index 0e6cf4d..31ca6fa 100644
> --- a/hw/ppc/spapr_pci.c
> +++ b/hw/ppc/spapr_pci.c
> @@ -1317,14 +1317,16 @@ static void spapr_phb_realize(DeviceState *dev, Error 
> **errp)
>  if ((sphb->buid != (uint64_t)-1) || (sphb->dma_liobn[0] != 
> (uint32_t)-1)
>  || (sphb->dma_liobn[1] != (uint32_t)-1 && windows_supported == 2)
>  || (sphb->mem_win_addr != (hwaddr)-1)
> +|| (sphb->mem64_win_addr != (hwaddr)-1)
>  || (sphb->io_win_addr != (hwaddr)-1)) {
>  error_setg(errp, "Either \"index\" or other parameters must"
> " be specified for PAPR PHB, not both");
>  return;
>  }
>  
> -smc->phb_placement(spapr, sphb->index, &sphb->buid,
> -   &sphb->io_win_addr, &sphb->mem_win_addr,
> +smc->phb_placement(spapr, sphb->index,
> +   &sphb->buid, &sphb->io_win_addr,
> +   &sphb->mem_win_addr, &sphb->mem64_win_addr,
> windows_supported, sphb->dma_liobn, &local_err);
>  if (local_err) {
>  error_propagate(errp, local_err);
> @@ -1353,6 +1355,38 @@ static void spapr_phb_realize(DeviceState *dev, Error 
> **errp)
>  return;
>  }
>  
> +if (sphb->mem64_win_size != 0) {
> +  

Re: [Qemu-devel] [PATCH 1/2] 9pfs: fix information leak in xattr read

[Greg Kurz]

On Thu, 13 Oct 2016 11:30:08 +0800
Li Qiang  wrote:

> Yes, I think the limit to apply to xattr size in 9pfs is the same as the
> Linux xattr size limit, I will try to find this limit.
> 

/usr/include/linux/limits.h:#define XATTR_SIZE_MAX 65536/* size of an 
extended attribute value (64k) */

> Thanks.
> 
> On 2016-10-13 4:49 GMT+08:00 Eric Blake  wrote:
> 
> > On 10/12/2016 08:23 AM, Greg Kurz wrote:
> > >
> > > But in fact, I'm afraid we have a more serious problem here... size
> > > comes from the guest and could cause g_malloc() to abort if QEMU has
> > > reached some RLIMIT... we need to call g_try_malloc0() and return
> > > ENOMEM if the allocation fails.
> >
> > Even if it does not cause an ENOMEM failure right away, the guest can
> > also use this to chew up lots of host resources. It may also be worth
> > putting a reasonable cap at the maximum the guest can allocate, rather
> > than just trying to malloc every possible size.
> >
> > --
> > Eric Blake   eblake redhat com+1-919-301-3266
> > Libvirt virtualization library http://libvirt.org
> >
> >

Re: [Qemu-devel] [SeaBIOS] [PATCH 5/5] [wip] sercon: initial split-output implementation

[Igor Mammedov]

On Thu, 13 Oct 2016 09:17:51 +0200
Gerd Hoffmann  wrote:

>   Hi,
> 
> > So far plan is merge it into QEMU 2.8.
> > I've amended QEMU counterpart according to Radim's and Paolo's reviews
> > and plan to respin it soon.  
> 
> No respin yet on the list it seems.   What is the status?  Do you wait
> for Radim's patches land upstream first?
yep, I'm was waiting on Radim's patches to be ready first.
By now they all have been reviewed and I don't expect to any changes in them.
So I'll respin v3 todayish as well as v6 of this series.

>  Can you cc me if you post it?
sure

> 
> > It will depend on Radim's 
> > https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg08292.html
> > though, so my series will be merged after that  
> 
> That series is at v5 now and seems to be ready for merge, even though it
> didn't land in master yet.
> 
> cheers,
>   Gerd
> 

Re: [Qemu-devel] [PATCH v7 00/12] virtio-crypto: introduce framework and device emulation

[no-reply]

Hi,

Your series failed automatic build test. Please find the testing commands and
their output below. If you have docker installed, you can probably reproduce it
locally.

Message-id: 1476342726-104488-1-git-send-email-arei.gong...@huawei.com
Type: series
Subject: [Qemu-devel] [PATCH v7 00/12] virtio-crypto: introduce framework and 
device emulation

=== TEST SCRIPT BEGIN ===
#!/bin/bash
set -e
git submodule update --init dtc
# Let docker tests dump environment info
export SHOW_ENV=1
export J=16
make docker-test-quick@centos6
make docker-test-mingw@fedora
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 - [tag update]  
patchew/1476316647-9433-1-git-send-email-da...@gibson.dropbear.id.au -> 
patchew/1476316647-9433-1-git-send-email-da...@gibson.dropbear.id.au
 - [tag update]  
patchew/1476341848-1940-1-git-send-email-zhang.zhanghaili...@huawei.com -> 
patchew/1476341848-1940-1-git-send-email-zhang.zhanghaili...@huawei.com
 * [new tag] 
patchew/1476342726-104488-1-git-send-email-arei.gong...@huawei.com -> 
patchew/1476342726-104488-1-git-send-email-arei.gong...@huawei.com
Switched to a new branch 'test'
1ca577d virtio-crypto: perfect algorithms chainning support
4376900 virtio-crypto: add myself as virtio-crypto and cryptodev backends 
maintainer
ef22b20 cryptodev: introduce an unified wrapper for crypto operation
22fabe0 virtio-crypto: add data queue processing handler
1641b14 virtio-crypto: add control queue handler
049c407 virtio-crypto: set capacity of algorithms supported
a17c1d6 virtio-crypto-pci: add virtio crypto pci support
af04236 virtio-crypto: add virtio crypto device emulation
b0a320b cryptodev: introduce a new cryptodev backend
e1b908f virtio-crypto: introduce virtio_crypto.h
971ca64 cryptodev: add symmetric algorithm operation stuff
b97bca9 cryptodev: introduce cryptodev backend interface

=== OUTPUT BEGIN ===
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into 'dtc'...
Submodule path 'dtc': checked out '65cc4d2748a2c2e6f27f1cf39e07a5dbabd80ebf'
  BUILD   centos6
  ARCHIVE qemu.tgz
  ARCHIVE dtc.tgz
  COPYRUNNER
  RUN test-quick in centos6
Packages installed:
SDL-devel-1.2.14-7.el6_7.1.x86_64
ccache-3.1.6-2.el6.x86_64
epel-release-6-8.noarch
gcc-4.4.7-17.el6.x86_64
git-1.7.1-4.el6_7.1.x86_64
glib2-devel-2.28.8-5.el6.x86_64
libfdt-devel-1.4.0-1.el6.x86_64
make-3.81-23.el6.x86_64
package g++ is not installed
pixman-devel-0.32.8-1.el6.x86_64
tar-1.23-15.el6_8.x86_64
zlib-devel-1.2.3-29.el6.x86_64

Environment variables:
PACKAGES=libfdt-devel ccache tar git make gcc g++ zlib-devel 
glib2-devel SDL-devel pixman-devel epel-release
HOSTNAME=39f0095507bd
TERM=xterm
MAKEFLAGS= -j16
HISTSIZE=1000
J=16
USER=root
CCACHE_DIR=/var/tmp/ccache
EXTRA_CONFIGURE_OPTS=
V=
SHOW_ENV=1
MAIL=/var/spool/mail/root
PATH=/usr/lib/ccache:/usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/
LANG=en_US.UTF-8
TARGET_LIST=
HISTCONTROL=ignoredups
SHLVL=1
HOME=/root
TEST_DIR=/tmp/qemu-test
LOGNAME=root
LESSOPEN=||/usr/bin/lesspipe.sh %s
FEATURES= dtc
DEBUG=
G_BROKEN_FILENAMES=1
CCACHE_HASHDIR=
_=/usr/bin/env

Configure options:
--enable-werror --target-list=x86_64-softmmu,aarch64-softmmu 
--prefix=/var/tmp/qemu-build/install
No C++ compiler available; disabling C++ specific optional code
Install prefix/var/tmp/qemu-build/install
BIOS directory/var/tmp/qemu-build/install/share/qemu
binary directory  /var/tmp/qemu-build/install/bin
library directory /var/tmp/qemu-build/install/lib
module directory  /var/tmp/qemu-build/install/lib/qemu
libexec directory /var/tmp/qemu-build/install/libexec
include directory /var/tmp/qemu-build/install/include
config directory  /var/tmp/qemu-build/install/etc
local state directory   /var/tmp/qemu-build/install/var
Manual directory  /var/tmp/qemu-build/install/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path   /tmp/qemu-test/src
C compilercc
Host C compiler   cc
C++ compiler  
Objective-C compiler cc
ARFLAGS   rv
CFLAGS-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g 
QEMU_CFLAGS   -I/usr/include/pixman-1-pthread -I/usr/include/glib-2.0 
-I/usr/lib64/glib-2.0/include   -fPIE -DPIE -m64 -D_GNU_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes 
-Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes 
-fno-strict-aliasing -fno-common -fwrapv  -Wendif-labels -Wmissing-include-dirs 
-Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self 
-Wignored-qualifiers -Wold-style-declaration -Wold-style-definition 
-Wtype-limits -fstack-protector-all
LDFLAGS   -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g 
make  make
install   install
pythonpython -B
smbd  /usr/sbin/smbd
module supportno
host CPU  x86_64
host big endian   no
target list   x86_64-softmm

Re: [Qemu-devel] [Qemu-ppc] [QEMU PATCH v5 3/6] migration: extend VMStateInfo

[Paolo Bonzini]

> > No, I disagree.  We shouldn't be worried about making intrusive changes
> > to all invocations or declarations, if that leads to a simpler API.
> 
> If VMStateInfo was meant for complete customization, then it was missing
> some parts. I think the API is indeed simpler. Just like
> definition for VMStateField. Not all of its fields are used all time.

Code moves.  We can decide how much customization to allow of VMStateInfo.

You said it: "Not all of its fields are used all time".  Likewise, not
all arguments are used all time for get/put, but it's not an issue if they
are still there!  So this patch is good, but at the same time VMS_LINKED is
pointless.

Paolo

> > I agree that overloading .start can be a bit ugly but you can choose to
> > overload .num_offset instead, which is already better.
> >
> I did considered num_offset. But it is associated with an actual field.
> On the other hand, start means the start position of the q in the
> structure. So it is not that far stretched.
> 
> >> I would also suggest unit tests in test/test-vmstate.c. Maybe with
> >> that the vmstate migration of QTAILQ could be factored out as a separate
> >> patch series.
> > 
> > Yes, definitely.
> > 
> This sounds a good idea. Will do it.
> 
> > Paolo
> > 
> Thanks,
> Jianjun
> 
> 

Re: [Qemu-devel] [PATCH 15/15] xen: Rename xen_be_frontend_changed

[Paolo Bonzini]

> So we are better leave it as is. Maybe we need to rename some functions in
> that file.
>  __iirc__ adding xen_frontend.c is one of Stefano's comments in previous v6
>  or v7..

I agree; it's quite possible that code can be shared between backend and
frontend (renaming functions as needed), and it's good to have a generic
xen frontend mechanism instead of something specific to TPM.

Paolo

Re: [Qemu-devel] Async savevm using userfaultfd(2)

[Dr. David Alan Gilbert]

* Stefan Hajnoczi (stefa...@gmail.com) wrote:
> On Wed, Oct 12, 2016 at 4:04 PM, Stefan Hajnoczi  wrote:
> > Perhaps this approach can be prototyped with mprotect and a SIGSEGV
> > handler if anyone wants to get async savevm going.  I don't know if
> > there are any disadvantages to mprotecting guest RAM that the kvm kernel
> > module is using.  Hopefully in-kernel devices and vhost will continue to
> > work.
> 
> I woke up this morning with a strong feeling that a SIGSEGV handler
> won't work with vhost.

YKYBHTLW you wake up with strong feelings about SIGSEGV handlers.

>  The problem is that the QEMU process' SIGSEGV
> handler won't be called when the vhost kernel thread faults.  Now I'm
> wondering whether userfaultfd will work together with vhost.

I think it should, or at least I think all other kernel things end up being
caught by userfaultfd during postcopy.

Dave

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

Re: [Qemu-devel] [PATCH v14 12/21] option: allow qemu_opts_to_qdict to merge repeated options

[Markus Armbruster]

"Daniel P. Berrange"  writes:

> If given an option string such as
>
>   size=1024,nodes=10,nodes=4-5,nodes=1-2,policy=bind
>
> the qemu_opts_to_qdict() method will currently overwrite
> the values for repeated option keys, so only the last
> value is in the returned dict:
>
> size=QString("1024")
> nodes=QString("1-2")
> policy=QString("bind")
>
> With this change the caller can optionally ask for all
> the repeated values to be stored in a QList. In the
> above example that would result in 'nodes' being a
> QList, so the returned dict would contain
>
> size=QString("1024")
> nodes=QList([QString("10"),
>  QString("4-5"),
>  QString("1-2")])
> policy=QString("bind")
>
> Note that the conversion has no way of knowing whether
> any given key is expected to be a list upfront - it can
> only figure that out when seeing the first duplicated
> key. Thus the caller has to be prepared to deal with the
> fact that if a key 'foo' is a list, then the returned
> qdict may contain either a QString or a QList for the
> key 'foo'.

Actually three cases, not two:

0. qdict does not contain the key means empty list.

1. qdict contains the key with a QString value means list of one
element.

2. qdict contains the key with a QList value means list of more than one
element.

I consider this weird.  However, it's usefully weird with at least your
QObject input visitor.

> In a third mode, it is possible to ask for repeated
> options to be reported as an error, rather than silently
> dropping all but the last one.

Got users for this policy in the pipeline?

> All existing callers are all converted to explicitly
> request the historical behaviour of only reporting the
> last key. Later patches will make use of the new modes.
>
> Signed-off-by: Daniel P. Berrange 
> ---
>  blockdev.c   |   7 ++-
>  include/qemu/option.h|  13 -
>  monitor.c|   3 +-
>  qapi/qobject-input-visitor.c |   4 +-
>  qemu-img.c   |   4 +-
>  qemu-io-cmds.c   |   3 +-
>  qemu-io.c|   6 +-
>  qemu-nbd.c   |   3 +-
>  qom/object_interfaces.c  |   3 +-
>  tests/test-qemu-opts.c   | 132 
> +++
>  tests/test-replication.c |   9 ++-
>  util/qemu-option.c   |  64 ++---
>  12 files changed, 229 insertions(+), 22 deletions(-)
>
> diff --git a/blockdev.c b/blockdev.c
> index 814d49f..a999d46 100644
> --- a/blockdev.c
> +++ b/blockdev.c
> @@ -914,7 +914,8 @@ DriveInfo *drive_new(QemuOpts *all_opts, 
> BlockInterfaceType block_default_type)
>  
>  /* Get a QDict for processing the options */
>  bs_opts = qdict_new();
> -qemu_opts_to_qdict(all_opts, bs_opts);
> +qemu_opts_to_qdict(all_opts, bs_opts, QEMU_OPTS_REPEAT_POLICY_LAST,
> +   &error_abort);
>  
>  legacy_opts = qemu_opts_create(&qemu_legacy_drive_opts, NULL, 0,
> &error_abort);
> @@ -3804,8 +3805,8 @@ void hmp_drive_add_node(Monitor *mon, const char 
> *optstr)
>  return;
>  }
>  
> -qdict = qemu_opts_to_qdict(opts, NULL);
> -
> +qdict = qemu_opts_to_qdict(opts, NULL, QEMU_OPTS_REPEAT_POLICY_LAST,
> +   &error_abort);
>  if (!qdict_get_try_str(qdict, "node-name")) {
>  QDECREF(qdict);
>  error_report("'node-name' needs to be specified");
> diff --git a/include/qemu/option.h b/include/qemu/option.h
> index 29f3f18..ffd841d 100644
> --- a/include/qemu/option.h
> +++ b/include/qemu/option.h
> @@ -125,7 +125,18 @@ void qemu_opts_set_defaults(QemuOptsList *list, const 
> char *params,
>  int permit_abbrev);
>  QemuOpts *qemu_opts_from_qdict(QemuOptsList *list, const QDict *qdict,
> Error **errp);
> -QDict *qemu_opts_to_qdict(const QemuOpts *opts, QDict *qdict);

Blank line here, please.

> +typedef enum {
> +/* Last occurrence of a duplicate option silently replaces earlier */
> +QEMU_OPTS_REPEAT_POLICY_LAST,
> +/* Each occurrence of a duplicate option converts value to a QList */
> +QEMU_OPTS_REPEAT_POLICY_ALL,
> +/* First occurrence of a duplicate option causes an error */
> +QEMU_OPTS_REPEAT_POLICY_ERROR,
> +} QemuOptsRepeatPolicy;
> +
> +QDict *qemu_opts_to_qdict(const QemuOpts *opts, QDict *qdict,
> +  QemuOptsRepeatPolicy repeatPolicy,
> +  Error **errp);
>  void qemu_opts_absorb_qdict(QemuOpts *opts, QDict *qdict, Error **errp);
>  
>  typedef int (*qemu_opts_loopfunc)(void *opaque, QemuOpts *opts, Error 
> **errp);
> diff --git a/monitor.c b/monitor.c
> index 14089cc..84e79d4 100644
> --- a/monitor.c
> +++ b/monitor.c
> @@ -2642,7 +2642,8 @@ static QDict *monitor_parse_arguments(Monitor *mon,
>  if (!opts) {
>  goto fail;
>  }
> -   

Re: [Qemu-devel] [PATCHv3 7/7] spapr: Improved placement of PCI host bridges in guest memory map

[Laurent Vivier]

On 13/10/2016 01:57, David Gibson wrote:
> Currently, the MMIO space for accessing PCI on pseries guests begins at
> 1 TiB in guest address space.  Each PCI host bridge (PHB) has a 64 GiB
> chunk of address space in which it places its outbound PIO and 32-bit and
> 64-bit MMIO windows.
> 
> This scheme as several problems:
>   - It limits guest RAM to 1 TiB (though we have a limited fix for this
> now)
>   - It limits the total MMIO window to 64 GiB.  This is not always enough
> for some of the large nVidia GPGPU cards
>   - Putting all the windows into a single 64 GiB area means that naturally
> aligning things within there will waste more address space.
> In addition there was a miscalculation in some of the defaults, which meant
> that the MMIO windows for each PHB actually slightly overran the 64 GiB
> region for that PHB.  We got away without nasty consequences because
> the overrun fit within an unused area at the beginning of the next PHB's
> region, but it's not pretty.
> 
> This patch implements a new scheme which addresses those problems, and is
> also closer to what bare metal hardware and pHyp guests generally use.
> 
> Because some guest versions (including most current distro kernels) can't
> access PCI MMIO above 64 TiB, we put all the PCI windows between 32 TiB and
> 64 TiB.  This is broken into 1 TiB chunks.  The 1 TiB contains the PIO
> (64 kiB) and 32-bit MMIO (2 GiB) windows for all of the PHBs.  Each
> subsequent TiB chunk contains a naturally aligned 64-bit MMIO window for
> one PHB each.
> 
> This reduces the number of allowed PHBs (without full manual configuration
> of all the windows) from 256 to 31, but this should still be plenty in
> practice.
> 
> We also change some of the default window sizes for manually configured
> PHBs to saner values.
> 
> Finally we adjust some tests and libqos so that it correctly uses the new
> default locations.  Ideally it would parse the device tree given to the
> guest, but that's a more complex problem for another time.
> 
> Signed-off-by: David Gibson 
> ---
>  hw/ppc/spapr.c  | 126 
> +---
>  hw/ppc/spapr_pci.c  |   5 +-
>  include/hw/pci-host/spapr.h |   8 ++-
>  tests/endianness-test.c |   3 +-
>  tests/libqos/pci-spapr.c|   9 ++--
>  tests/spapr-phb-test.c  |   2 +-
>  6 files changed, 113 insertions(+), 40 deletions(-)
> 
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index 8db3657..2d952a8 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -2375,31 +2375,42 @@ static void spapr_phb_placement(sPAPRMachineState 
> *spapr, uint32_t index,
>  hwaddr *mmio32, hwaddr *mmio64,
>  unsigned n_dma, uint32_t *liobns, Error 
> **errp)
>  {
> +/*
> + * New-style PHB window placement.
> + *
> + * Goals: Gives large (1TiB), naturally aligned 64-bit MMIO window
> + * for each PHB, in addition to 2GiB 32-bit MMIO and 64kiB PIO
> + * windows.
> + *
> + * Some guest kernels can't work with MMIO windows above 1<<46
> + * (64TiB), so we place up to 31 PHBs in the area 32TiB..64TiB
> + *
> + * 32TiB..33TiB contains the PIO and 32-bit MMIO windows for all
> + * PHBs.  33..34TiB has the 64-bit MMIO window for PHB0, 34..35
> + * has the 64-bit window for PHB1 and so forth.
> + */
>  const uint64_t base_buid = 0x8002000ULL;
> -const hwaddr phb_spacing = 0x10ULL; /* 64 GiB */
> -const hwaddr mmio_offset = 0xa000; /* 2 GiB + 512 MiB */
> -const hwaddr pio_offset = 0x8000; /* 2 GiB */
> -const uint32_t max_index = 255;
> -const hwaddr phb0_alignment = 0x100ULL; /* 1 TiB */
>  
> -uint64_t ram_top = MACHINE(spapr)->ram_size;
> -hwaddr phb0_base, phb_base;
> +int max_phbs =
> +(SPAPR_PCI_LIMIT - SPAPR_PCI_BASE) / SPAPR_PCI_MEM64_WIN_SIZE - 1;
> +hwaddr mmio32_base = SPAPR_PCI_BASE + SPAPR_PCI_MEM32_WIN_SIZE;

The result is the same but I would add SPAPR_PCI_MEM_WIN_BUS_OFFSET
instead of SPAPR_PCI_MEM32_WIN_SIZE.

As SPAPR_PCI_MEM32_WIN_SIZE is defined as "((1ULL << 32) -
SPAPR_PCI_MEM_WIN_BUS_OFFSET)", I guess 0..SPAPR_PCI_MEM_WIN_BUS_OFFSET
is for PIO and SPAPR_PCI_MEM_WIN_BUS_OFFSET..(1<<32) is for MMIO.

This is what we have below with:

*pio = SPAPR_PCI_BASE + index * SPAPR_PCI_IO_WIN_SIZE;
*mmio32 = mmio32_base + index * SPAPR_PCI_MEM32_WIN_SIZE;

Perhaps we can see *mmio32 as

SPAPR_PCI_BASE + (index + 1) * SPAPR_PCI_MEM32_WIN_SIZE

But in this case you should directly defined SPAPR_PCI_MEM32_WIN_SIZE as
0x8000, not as "SIZE - OFFSET". It's confusing...

If it is only a misunderstanding from my side, you can add my:

Reviewed-by: Laurent Vivier 

Thanks,
Laurent

Re: [Qemu-devel] Windows 7 guest not starting with HyperV features enabled

[Denis V. Lunev]

On 10/11/2016 03:44 PM, Aleksei wrote:
> Hi,
> I'm using libvirt, but folks on libvirt mailing list said it makes
> more sense to post here.
>
> I have a Windows 7 SP1 Pro 64-bit VM which works fine on libvirt 2.3.0
> and Qemu 2.7.0.
>
> If I enable HyperV features
> (https://libvirt.org/formatdomain.html#elementsFeatures) like
> "relaxed", "spinlocks" etc - VM doesn't boot. "Starting Windows" text
> appears for ~2 seconds (no flying dots, no logo) and then it just goes
> to black screen. If I switch HyperV features back off, it boots
> normally again.
>
> There are no logs for that attempted boot in the guest - apparently it
> doesn't get to the point when Windows starts logging. No errors logged
> in libvirt's win7.log either.
>
> Attaching VM xml definition and libvirt-generated Qemu command line -
> only "relaxed" feature is enabled. VM fails with any feature in
>  block enabled. Platform-specific values (smbios info etc) are
> replaced.
Win7 + EFI + HyperV will not work.
In short words Windows has bug the HAL.
(Win2k8 and Win7 have the same kernels).

You can find details here:
https://bugs.launchpad.net/qemu/+bug/1593605

Den

Re: [Qemu-devel] [PATCH V2] docs: add PCIe devices placement guidelines

[Laszlo Ersek]

On 10/13/16 09:25, Marcel Apfelbaum wrote:
> On 10/12/2016 06:28 PM, Laszlo Ersek wrote:
>> Marcel,
>>
>> On 10/11/16 15:45, Marcel Apfelbaum wrote:
>>> Proposes best practices on how to use PCI Express/PCI device
>>> in PCI Express based machines and explain the reasoning behind them.
>>>
>>> Signed-off-by: Marcel Apfelbaum 
>>> ---
>>>
>>> Hi,
>>>
>>> RFC->v2:
>>>  - Addressed a lot of comments from the reviewers (many thanks to
>>> all, especially to Laszlo)
>>>
>>> Since the RFC mail-thread was relatively long and already
>>> has passed a lot of time from the RFC, I post this version
>>> even if is very possible that I left some of the comments out,
>>> my apologies if so.
>>>
>>> I will go over the comments again, in the meantime please
>>> feel free to comment on this version, even if on something
>>> you've already pointed out.
>>>
>>> It may take a day or two until I'll be able to respond, but I
>>> will do my best to address all comments.
>>>
>>> Thanks,
>>> Marcel
>>>
>>>
>>>  docs/pcie.txt | 273
>>> ++
>>>  1 file changed, 273 insertions(+)
>>>  create mode 100644 docs/pcie.txt
>>
>> Your patch doesn't seem to have reached qemu-devel. I got one copy from
>> you directly, and no copy reflected by the qemu-devel list server. I
>> also checked the mailing list archive:
>> - searched for the subject with google -- only the RFC version was found,
>> - checked mail-archive.com by message-id
>> - checked the primary archive for October
>> (http://lists.nongnu.org/archive/html/qemu-devel/2016-10/threads.html)
>> -- I found only messages in the RFC thread.
>>
>> So, before I start reading this version and commenting on it, can you
>> please repost version 2, and verify that the list reflects it?
>>
> 
> Hi,
> 
> That is very strange, I tried sending it again but I received the same
> error:
> 
> Undelivered Mail Returned to Sender
> ...
> : host eggs.gnu.org[208.118.235.92] said: 550
> Invalid
> address in message header (in reply to end of DATA command)
> 
> Reporting-MTA: dns; <>.redhat.com
> X-Postfix-Queue-ID: <>
> X-Postfix-Sender: rfc822; mar...@redhat.com
> Arrival-Date: Thu, 13 Oct 2016 07:20:49 + (UTC)
> 
> Final-Recipient: rfc822; qemu-devel@nongnu.org
> Original-Recipient: rfc822;qemu-devel@nongnu.org
> Action: failed
> Status: 5.0.0
> Remote-MTA: dns; eggs.gnu.org
> Diagnostic-Code: smtp; 550 Invalid address in message header
> 
> 
> I'll try sending the mail with another mail server.

Something remains broken; and quite strangely at that. Now I've got two copies 
of the following message in my inbox:

[Qemu-devel] [PATCH V2 RESEND] docs: add PCIe devices placement guidelines

with the following message-id's:

  <1476343236-13192-1-git-send-email-mar...@redhat.com>
  <1476345339-5355-1-git-send-email-mar...@redhat.com>

and I have zero copies of this message in my qemu-devel folder.

Interestingly, the subject *does* have the [qemu-devel] prefix, in both copies. 
So I thought, maybe these were reflected by the list server after all, and only 
their headers changed unexpectedly / inexpicably, so that my filter rules 
wouldn't apply any longer (and the messages wouldn't be moved to my qemu-devel 
folder).

However, the mailing list archive at 
 still 
does not list your message.

Here's the full list of headers from the first RESEND message:

> Return-Path: mar...@redhat.com
> Received: from zmta01.collab.prod.int.phx2.redhat.com (LHLO 
> zmta01.collab.prod.int.phx2.redhat.com) (10.5.81.8) by 
> zmail17.collab.prod.int.phx2.redhat.com with LMTP; Thu, 13 Oct 2016 03:20:49 
> -0400 (EDT)
> Received: from int-mx13.intmail.prod.int.phx2.redhat.com 
> (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by 
> zmta01.collab.prod.int.phx2.redhat.com (Postfix) with ESMTP id 399BF186479; 
> Thu, 13 Oct 2016 03:20:49 -0400 (EDT)
> Received: from work.redhat.com (vpn-200-250.tlv.redhat.com [10.35.200.250]) 
> by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id 
> u9D7KbZ4017253; Thu, 13 Oct 2016 03:20:40 -0400
> From: Marcel Apfelbaum 
> To: qemu-devel@nongnu.org
> Cc: ler...@redhat.com, kra...@redhat.com, la...@redhat.com, 
> peter.mayd...@linaro.org, drjo...@redhat.com, abolo...@redhat.com, 
> "alex.williamson@redhat.comberrange"@redhat.com, m...@redhat.com, 
> mar...@redhat.com
> Subject: [Qemu-devel] [PATCH V2 RESEND] docs: add PCIe devices placement 
> guidelines
> Date: Thu, 13 Oct 2016 10:20:36 +0300
> Message-Id: <1476343236-13192-1-git-send-email-mar...@redhat.com>
> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26

Same from the second RESEND message:

> Return-Path: marcel.apfelb...@gmail.com
> Received: from zmta05.collab.prod.int.phx2.redhat.com (LHLO 
> zmta05.collab.prod.int.phx2.redhat.com) (10.5.81.12) by 
> zmail17.collab.prod.int.phx2.redhat.com with LMTP; Thu, 13 Oct 2016 03:55:48 
> -0400 (EDT)
> Received: from int-mx09.intmail.pro

Re: [Qemu-devel] [PATCH v2 04/11] blockjobs: Always use block_job_get_aio_context

[Paolo Bonzini]

On 13/10/2016 02:49, John Snow wrote:
> As context to everyone else as to why I'm going down the rabbit hole of
> trying to remove external references to AioContext at all, see
> https://lists.gnu.org/archive/html/qemu-devel/2016-10/msg00795.html
> 
> On 10/07/2016 03:49 AM, Paolo Bonzini wrote:
>>
>>
>> On 06/10/2016 22:22, John Snow wrote:
>>> Calls .complete(), for which the only implementation is
>>> mirror_complete. Uh, this actually seems messy. Looks like there's
>>> nothing to prevent us from calling this after we've already told it to
>>> complete once.
>>
>> Yeah, it should have an
>>
>> if (s->should_complete) {
>> return;
>> }
>>
>> at the beginning.  I have other mirror.c patches in my queue so I can
>> take care of that.
>>
> 
> Or something up the stack at block_job_complete so it's not up to job
> implementations? What if the next implementer "forgets."

Yeah, that would require moving s->should_complete up to BlockJob.

>>> block_job_cancel and block_job_complete are different.
>>>
>>> block_job_cancel is called in many places, but we can just add a similar
>>> block_job_user_cancel if we wanted a version which takes care to acquire
>>> context and one that does not. (Or we could just acquire the context
>>> regardless, but Paolo warned me ominously that recursive locks are EVIL.
>>> He sounded serious.)
>>
>> Not that many places:
>>
>> - block_job_finish_sync calls it, and you can just release/reacquire
>> around the call to "finish(job, &local_err)".
> 
> This makes me a little nervous because we went through the trouble of
> creating this callback, but we're going to assume we know that it's a
> public interface that will take the lock for itself (or otherwise does
> not require a lock.)
> 
> In practice it works, but it seems needlessly mystifying in terms of
> proving correctness.

It's _much_ easier to assume that all callbacks take the lock
themselves.  It's counterintuitive (just like the idea that recursive
locks are bad :)), but the point is that if you second guess the
callbacks and invoke them you might get the locking order wrong.  This
ends up with ugly AB-BA deadlocks.

>> - replication_stop is not acquiring s->secondary_disk->bs's AioContext.
> 
> Seems like a bug on their part. Would be fixed by having cancel acquire
> context for itself.

Yep.

> Yeah, I should be reffing it anyway.
> 
> The rest of this... What I think you mean is acquiring and releasing the
> context as needed for EACH of prepare, commit, abort, and clean as
> necessary, right?
> 
> And then in this case, it simply wouldn't be necessary for abort, as the
> sync cancel would do it for us.

Right.

> Alright.
> 
> Say I *do* push the acquisitions down into blockjob.c. What benefit does
> that provide? Won't I still need the block_job_get_aio_context()
> function (At least internally) to know which context to acquire? This
> would preclude you from deleting it.
> 
> Plus... we remove some fairly simple locking mechanisms and then inflate
> it tenfold. I'm not convinced this is an improvement.

The improvement is that you can now replace the huge lock with a smaller
one (you don't have to do it now, but you could).  Furthermore, the
small lock is a) non-recursive b) a leaf lock.  This means that you've
removed a lot of opportunities for deadlock, and generally made things
easier to reason about.

Furthermore, with large locks you never know what they actually protect;
cue the confusion between aio_context_acquire/release and
bdrv_drained_begin/end.  And it's easier to forget them if you force the
caller to do it; and we have an example with replication.

Again, it can be counterintuitive that it's better, but it is. :)

> (1) QMP interface for job management
> (2) bdrv_drain_all, in block/io.c
> 
> (1) AFAICT, the QMP interface is concerned with assuring itself it has
> unique access to the BlockJob structure itself, and it doesn't really
> authentically care about the AIOContext itself -- just race-free access
> to the Job.

Yes.  The protection you need here is mostly against concurrent
completion of the job (and concurrent manipulation of fields such as
job->busy, job->paused, etc.

> This is not necessarily buggy today because, even though we grab the
> BlockBackend's context unconditionally, we already know the main/monitor
> thread is not accessing the blockjob. It's still silly, though.
> 
> (2) bdrv_drain_all appears to be worried about the same thing; we just
> need to safely deliver pause/resume messages.
> 
> I'm less sure about where this can run from, and suspect that if the job
> has deferred to main that this could be buggy. If bdrv_drain_all is
> called from context A and the job is running on context M having
> deferred from B, we may lock against context B (from A) and have racey
> access from between A/M. (Maybe?)

bdrv_drain_all is BQL-only (because it acquires more than one AioContext).

> Would you be terribly offended if I left this patch as-is for now and we
> can 

Re: [Qemu-devel] [PATCH V2] docs: add PCIe devices placement guidelines

[Marcel Apfelbaum]

On 10/13/2016 11:53 AM, Laszlo Ersek wrote:

On 10/13/16 09:25, Marcel Apfelbaum wrote:

On 10/12/2016 06:28 PM, Laszlo Ersek wrote:

Marcel,

On 10/11/16 15:45, Marcel Apfelbaum wrote:

Proposes best practices on how to use PCI Express/PCI device
in PCI Express based machines and explain the reasoning behind them.

Signed-off-by: Marcel Apfelbaum 
---

Hi,

RFC->v2:
 - Addressed a lot of comments from the reviewers (many thanks to
all, especially to Laszlo)

Since the RFC mail-thread was relatively long and already
has passed a lot of time from the RFC, I post this version
even if is very possible that I left some of the comments out,
my apologies if so.

I will go over the comments again, in the meantime please
feel free to comment on this version, even if on something
you've already pointed out.

It may take a day or two until I'll be able to respond, but I
will do my best to address all comments.

Thanks,
Marcel


 docs/pcie.txt | 273
++
 1 file changed, 273 insertions(+)
 create mode 100644 docs/pcie.txt


Your patch doesn't seem to have reached qemu-devel. I got one copy from
you directly, and no copy reflected by the qemu-devel list server. I
also checked the mailing list archive:
- searched for the subject with google -- only the RFC version was found,
- checked mail-archive.com by message-id
- checked the primary archive for October
(http://lists.nongnu.org/archive/html/qemu-devel/2016-10/threads.html)
-- I found only messages in the RFC thread.

So, before I start reading this version and commenting on it, can you
please repost version 2, and verify that the list reflects it?



Hi,

That is very strange, I tried sending it again but I received the same
error:

Undelivered Mail Returned to Sender
...
: host eggs.gnu.org[208.118.235.92] said: 550
Invalid
address in message header (in reply to end of DATA command)

Reporting-MTA: dns; <>.redhat.com
X-Postfix-Queue-ID: <>
X-Postfix-Sender: rfc822; mar...@redhat.com
Arrival-Date: Thu, 13 Oct 2016 07:20:49 + (UTC)

Final-Recipient: rfc822; qemu-devel@nongnu.org
Original-Recipient: rfc822;qemu-devel@nongnu.org
Action: failed
Status: 5.0.0
Remote-MTA: dns; eggs.gnu.org
Diagnostic-Code: smtp; 550 Invalid address in message header


I'll try sending the mail with another mail server.




Hi Laszlo, thanks for the help


Something remains broken; and quite strangely at that. Now I've got two copies 
of the following message in my inbox:

[Qemu-devel] [PATCH V2 RESEND] docs: add PCIe devices placement guidelines

with the following message-id's:

  <1476343236-13192-1-git-send-email-mar...@redhat.com>
  <1476345339-5355-1-git-send-email-mar...@redhat.com>

and I have zero copies of this message in my qemu-devel folder.

Interestingly, the subject *does* have the [qemu-devel] prefix, in both copies.


This is because I have a script adding the [qemu-devel] prefix, maybe I should 
drop it.


So I thought, maybe these were reflected by the list server after all, and only their headers changed unexpectedly / inexpicably, so that my filter rules wouldn't apply any longer (and the messages 
wouldn't be moved to my qemu-devel folder).


However, the mailing list archive at 
 still 
does not list your message.

Here's the full list of headers from the first RESEND message:


Return-Path: mar...@redhat.com
Received: from zmta01.collab.prod.int.phx2.redhat.com (LHLO 
zmta01.collab.prod.int.phx2.redhat.com) (10.5.81.8) by 
zmail17.collab.prod.int.phx2.redhat.com with LMTP; Thu, 13 Oct 2016 03:20:49 
-0400 (EDT)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com 
(int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by 
zmta01.collab.prod.int.phx2.redhat.com (Postfix) with ESMTP id 399BF186479; 
Thu, 13 Oct 2016 03:20:49 -0400 (EDT)
Received: from work.redhat.com (vpn-200-250.tlv.redhat.com [10.35.200.250]) by 
int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id 
u9D7KbZ4017253; Thu, 13 Oct 2016 03:20:40 -0400
From: Marcel Apfelbaum 
To: qemu-devel@nongnu.org
Cc: ler...@redhat.com, kra...@redhat.com, la...@redhat.com, peter.mayd...@linaro.org, 
drjo...@redhat.com, abolo...@redhat.com, 
"alex.williamson@redhat.comberrange"@redhat.com, m...@redhat.com, 
mar...@redhat.com
Subject: [Qemu-devel] [PATCH V2 RESEND] docs: add PCIe devices placement 
guidelines
Date: Thu, 13 Oct 2016 10:20:36 +0300
Message-Id: <1476343236-13192-1-git-send-email-mar...@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26


Same from the second RESEND message:


Return-Path: marcel.apfelb...@gmail.com
Received: from zmta05.collab.prod.int.phx2.redhat.com (LHLO 
zmta05.collab.prod.int.phx2.redhat.com) (10.5.81.12) by 
zmail17.collab.prod.int.phx2.redhat.com with LMTP; Thu, 13 Oct 2016 03:55:48 
-0400 (EDT)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com 
(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by 
zmta05.col

Re: [Qemu-devel] [PATCH v14 12/21] option: allow qemu_opts_to_qdict to merge repeated options

[Markus Armbruster]

Markus Armbruster  writes:

> "Daniel P. Berrange"  writes:
>
>> If given an option string such as
>>
>>   size=1024,nodes=10,nodes=4-5,nodes=1-2,policy=bind
>>
>> the qemu_opts_to_qdict() method will currently overwrite
>> the values for repeated option keys, so only the last
>> value is in the returned dict:
>>
>> size=QString("1024")
>> nodes=QString("1-2")
>> policy=QString("bind")
>>
>> With this change the caller can optionally ask for all
>> the repeated values to be stored in a QList. In the
>> above example that would result in 'nodes' being a
>> QList, so the returned dict would contain
>>
>> size=QString("1024")
>> nodes=QList([QString("10"),
>>  QString("4-5"),
>>  QString("1-2")])
>> policy=QString("bind")
>>
>> Note that the conversion has no way of knowing whether
>> any given key is expected to be a list upfront - it can
>> only figure that out when seeing the first duplicated
>> key. Thus the caller has to be prepared to deal with the
>> fact that if a key 'foo' is a list, then the returned
>> qdict may contain either a QString or a QList for the
>> key 'foo'.
>>
>> In a third mode, it is possible to ask for repeated
>> options to be reported as an error, rather than silently
>> dropping all but the last one.
>
> To serve as a replacement for the options visitor, this needs to be able
> to behave exactly the same together with a suitably hacked up QObject
> input visitor.  Before I dive into the actual patch, let me summarize
> QemuOpts and options visitor behavior.
>
> Warning, this is going to get ugly.
>
> QemuOpts faithfully represents a key=value,... string as a list of
> QemuOpt.  Each QemuOpt represents one key=value.  They are in the same
> order.  If key occurs multiple times in the string, it occurs just the
> same in the list.
>
> *Except* key "id" is special: it's stored outside the list, and all but
> the first one are silently ignored.
>
> Most users only ever get the last value of a key.  Any non-last
> key=value are silently ignored.
>
> We actually exploit this behavior to do defaults, by *prepending* them
> to the list.  See the use of qemu_opts_set_defaults() in main().

This prepending of defaults assumes all users ignore values other than
the last.  It breaks if any user gets non-last values.

> A few users get all values of keys (other than key "id"):
>
> * -device, in qdev_device_add() with callback set_property().
>
>   We first get "driver" and "bus" normally (silently ignoring non-last
>   values, as usual).  All other keys are device properties.  To set
>   them, we get all (key, value), ignore keys "driver" and "bus", and set
>   the rest.  If a key occurs multiple times, it gets set multiple times.
>   This effectively ignores all but the last one, silently.
>
> * -semihosting-config, in main() with callback add_semihosting_arg().
>
>   We first get a bunch of keys normally.  Key "arg" is special: it may
>   be repeated to build a list.  To implement that, we get all (key,
>   value), ignore keys other than "arg", and accumulate the values.
>
> * -machine & friends, in main() with callback machine_set_property()
>
>   Similar to -device, only for machines, with "type" instead of "driver"
>   and "bus".
>
> * -spice, in qemu_spice_init() with callback add_channel()
>
>   Keys "tls-channel" and "plaintext-channel" may be used repeated to
>   specify multiple channels.  To implement that, we get all (key,
>   value), ignore keys other than "tls-channel" and "plaintext-channel",
>   and set up a channel for each of the others.
>
> * -writeconfig, in config_write_opts() with callback config_write_opt()
>
>   We write out all keys in order.
>
> * The options visitor, in opts_start_struct()
>
>   We convert the list of (key, value) to a hash table of (key, list of
>   values).  Most of the time, the list of values has exactly one
>   element.
>
>   When the visitor's user asks for a scalar, we return the last element
>   of the list of values, in lookup_scalar().
>
>   When the user asks for list elements, we return the elements of the
>   list of values in order, in opts_next_list(), or if there are none,
>   the empty list in opts_start_list().

Note that the only way to get non-last values is to iterate over all
(key, value).  The combination of "getting a specific key's value gets
the last one" and "iterating over all keys gets all values" is poor
interface design.  The latter feature got pressed into service to do
list-valued keys.  When qemu_opts_set_defaults() got added (commit
4f6dd9a), the bad interaction with the list-valued keys hack wasn't
considered, probably because the whole thing had become too byzantine to
fully understand.

> Unlike the options visitor, this patch (judging from your description)
> makes a list only when keys are repeated.  The QObject visitor will have
> to cope with finding both scalars and lists.  When it finds a scalar,
> but needs a list, it'll have to wrap it in a list (PAT

Re: [Qemu-devel] [PATCH v8 4/6] docs: Add Documentation for Mediated devices

[Kirti Wankhede]

On 10/13/2016 3:14 AM, Alex Williamson wrote:
> On Thu, 13 Oct 2016 00:32:48 +0530
> Kirti Wankhede  wrote:
> 
>> On 10/12/2016 9:29 PM, Alex Williamson wrote:
>>> On Wed, 12 Oct 2016 20:43:48 +0530
>>> Kirti Wankhede  wrote:
>>>   
 On 10/12/2016 7:22 AM, Tian, Kevin wrote:  
>> From: Kirti Wankhede [mailto:kwankh...@nvidia.com]
>> Sent: Wednesday, October 12, 2016 4:45 AM
 +* mdev_supported_types:
 +List of current supported mediated device types and its details 
 are added
 +in this directory in following format:
 +
 +|- 
 +|--- Vendor-specific-attributes [optional]
 +|--- mdev_supported_types
 +| |--- 
 +| |   |--- create
 +| |   |--- name
 +| |   |--- available_instances
 +| |   |--- description /class
 +| |   |--- [devices]
 +| |--- 
 +| |   |--- create
 +| |   |--- name
 +| |   |--- available_instances
 +| |   |--- description /class
 +| |   |--- [devices]
 +| |--- 
 +|  |--- create
 +|  |--- name
 +|  |--- available_instances
 +|  |--- description /class
 +|  |--- [devices]
 +
 +[TBD : description or class is yet to be decided. This will change.]  
   
>>>
>>> I thought that in previous discussions we had agreed to drop
>>> the  concept and use the name as the unique identifier.
>>> When reporting these types in libvirt we won't want to report
>>> the type id values - we'll want the name strings to be unique.
>>>
>>
>> The 'name' might not be unique but type_id will be. For example that Neo
>> pointed out in earlier discussion, virtual devices can come from two
>> different physical devices, end user would be presented with what they
>> had selected but there will be internal implementation differences. In
>> that case 'type_id' will be unique.
>>
>
> Hi, Kirti, my understanding is that Neo agreed to use an unique type
> string (if you still called it ), and then no need of additional
> 'name' field which can be put inside 'description' field. See below quote:
> 

 We had internal discussions about this within NVIDIA and found that
 'name' might not be unique where as 'type_id' would be unique. I'm
 refering to Neo's mail after that, where Neo do pointed that out.

 https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg07714.html  
>>>
>>> Everyone not privy to those internal discussions, including me, seems to
>>> think we dropped type_id and that if a vendor does not have a stable
>>> name, they can compose some sort of stable type description based on the
>>> name+id, or even vendor+id, ex. NVIDIA-11.  So please share why we
>>> haven't managed to kill off type_id yet.  No matter what internal
>>> representation each vendor driver has of "type_id" it seems possible
>>> for it to come up with stable string to define a given configuration.  
>>
>>
>> The 'type_id' is unique and the 'name' are not, the name is just a
>> virtual device name/ human readable name. Because at this moment Intel
>> can't define a proper GPU class, we have to add a 'description' field
>> there as well to represent the features of this virtual device, once we
>> have all agreed with the GPU class and its mandatory attributes, the
>> 'description' field can be removed. Here is an example,
>> type_id/type_name = NVIDIA_11,
>> name=M60-M0Q,
>> description=2560x1600, 2 displays, 512MB"
>>
>> Neo's previous comment only applies to the situation where we will have
>> the GPU class or optional attributes defined and recognized by libvirt,
>> since that is not going to happen any time soon, we will have to have
>> the new 'description' field, and we don't want to have it mixed up with
>> 'name' field.
>>
>> We can definitely have something like name+id as Alex recommended to
>> remove the 'name' field, but it will just require libvirt to have more
>> logic to parse that string.
> 
> Let's use the mtty example driver provided in patch 5 so we can all
> more clearly see how the interfaces work.  I'll start from the
> beginning of my experience and work my way to the type/name thing.
> 

Thanks for looking into it and getting feel of it. And I hope this helps
to understand that 'name' and 'type_id' are different.


> (please add a modules_install target to the Makefile)
>

This is an example and I feel it should not be installed in
/lib/modules/../build path. This should be used to understand the
interface and the flow of mdev device management life cycle. User can
use insmod to load driver:

# insmod mtty.ko

> # modprobe mtty
> 
> Now what?  It seems like I need to have prior knowledge that this
> drivers supports mdev devices and I need to go hunt for them.  We need
> to create a cl

[Qemu-devel] [PULL 10/10] input-linux: initialize key state

[Gerd Hoffmann]

Query input device keys, initialize state accordingly, so the correct
state is reflected in case any key is pressed at initialization time.
There is a high chance for this to actually happen for the 'enter' key
in case you start qemu with a terminal command (directly or virsh).

When finding any pressed keys the input grab is delayed until all keys
are lifted, to avoid confusing guest and host with appearently stuck
keys.

Reported-by: Muted Bytes 
Signed-off-by: Gerd Hoffmann 
Message-id: 1476277384-30365-1-git-send-email-kra...@redhat.com
---
 ui/input-linux.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/ui/input-linux.c b/ui/input-linux.c
index 0e230ce..f345317 100644
--- a/ui/input-linux.c
+++ b/ui/input-linux.c
@@ -347,7 +347,8 @@ static void input_linux_event(void *opaque)
 static void input_linux_complete(UserCreatable *uc, Error **errp)
 {
 InputLinux *il = INPUT_LINUX(uc);
-uint8_t evtmap, relmap, absmap, keymap[KEY_CNT / 8];
+uint8_t evtmap, relmap, absmap;
+uint8_t keymap[KEY_CNT / 8], keystate[KEY_CNT / 8];
 unsigned int i;
 int rc, ver;
 
@@ -394,6 +395,7 @@ static void input_linux_complete(UserCreatable *uc, Error 
**errp)
 if (evtmap & (1 << EV_KEY)) {
 memset(keymap, 0, sizeof(keymap));
 rc = ioctl(il->fd, EVIOCGBIT(EV_KEY, sizeof(keymap)), keymap);
+rc = ioctl(il->fd, EVIOCGKEY(sizeof(keystate)), keystate);
 for (i = 0; i < KEY_CNT; i++) {
 if (keymap[i / 8] & (1 << (i % 8))) {
 if (linux_is_button(i)) {
@@ -401,12 +403,21 @@ static void input_linux_complete(UserCreatable *uc, Error 
**errp)
 } else {
 il->num_keys++;
 }
+if (keystate[i / 8] & (1 << (i % 8))) {
+il->keydown[i] = true;
+il->keycount++;
+}
 }
 }
 }
 
 qemu_set_fd_handler(il->fd, input_linux_event, NULL, il);
-input_linux_toggle_grab(il);
+if (il->keycount) {
+/* delay grab until all keys are released */
+il->grab_request = true;
+} else {
+input_linux_toggle_grab(il);
+}
 QTAILQ_INSERT_TAIL(&inputs, il, next);
 il->initialized = true;
 return;
-- 
1.8.3.1

[Qemu-devel] [PULL 00/10] ui: vnc cleanups, input-linux kbd fix.

[Gerd Hoffmann]

  Hi,

Here is the ui patch queue, shipping mostly vnc cleanups, also a input-linux 
kbd fix.

please pull,
  Gerd

The following changes since commit c264a8807299852fc45562768ae60ccc886cea91:

  Merge remote-tracking branch 'remotes/kraxel/tags/pull-usb-20161012-1' into 
staging (2016-10-12 14:05:23 +0100)

are available in the git repository at:


  git://git.kraxel.org/qemu tags/pull-ui-20161013-1

for you to fetch changes up to 2a57c55f26f7ba6dcea6d01ef74bae7069150f6f:

  input-linux: initialize key state (2016-10-13 09:25:24 +0200)


ui: vnc cleanups, input-linux kbd fix.


Daniel P. Berrange (9):
  ui: remove misleading comment from vnc_init_state
  ui: remove 'enabled' and 'ws_enabled' fields from VncState
  ui: remove 'ws_tls' field from VncState
  ui: rename misleading 'VncDisplay' variables
  ui: refactor method for setting up VncDisplay auth types
  ui: remove bogus call to graphic_hw_update() in vnc_listen_io
  ui: remove bogus call to reset_keys() in vnc_init_state
  ui: move some initialization out of vnc_init_state
  ui: rename vnc_init_state to vnc_start_protocol

Gerd Hoffmann (1):
  input-linux: initialize key state

 ui/input-linux.c |  15 +-
 ui/vnc-ws.c  |   2 +-
 ui/vnc.c | 412 +--
 ui/vnc.h |   7 +-
 4 files changed, 203 insertions(+), 233 deletions(-)

[Qemu-devel] [PULL 09/10] ui: rename vnc_init_state to vnc_start_protocol

[Gerd Hoffmann]

From: "Daniel P. Berrange" 

Rename the vnc_init_state method to reflect what its actual
purpose is, to discourage future devs from using it for more
general state initialization.

Signed-off-by: Daniel P. Berrange 
Message-id: 1475163940-26094-10-git-send-email-berra...@redhat.com
Signed-off-by: Gerd Hoffmann 
---
 ui/vnc-ws.c | 2 +-
 ui/vnc.c| 4 ++--
 ui/vnc.h| 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/ui/vnc-ws.c b/ui/vnc-ws.c
index 3bac46e..42a8e7b 100644
--- a/ui/vnc-ws.c
+++ b/ui/vnc-ws.c
@@ -92,7 +92,7 @@ static void vncws_handshake_done(Object *source,
 vnc_client_error(vs);
 } else {
 VNC_DEBUG("Websock handshake complete, starting VNC protocol\n");
-vnc_init_state(vs);
+vnc_start_protocol(vs);
 vs->ioc_tag = qio_channel_add_watch(
 vs->ioc, G_IO_IN, vnc_client_io, vs, NULL);
 }
diff --git a/ui/vnc.c b/ui/vnc.c
index c10a003..c1e98fb 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -3065,7 +3065,7 @@ static void vnc_connect(VncDisplay *vd, QIOChannelSocket 
*sioc,
 graphic_hw_update(vd->dcl.con);
 
 if (!vs->websocket) {
-vnc_init_state(vs);
+vnc_start_protocol(vs);
 }
 
 if (vd->num_connecting > vd->connections_limit) {
@@ -3078,7 +3078,7 @@ static void vnc_connect(VncDisplay *vd, QIOChannelSocket 
*sioc,
 }
 }
 
-void vnc_init_state(VncState *vs)
+void vnc_start_protocol(VncState *vs)
 {
 vnc_write(vs, "RFB 003.008\n", 12);
 vnc_flush(vs);
diff --git a/ui/vnc.h b/ui/vnc.h
index e48e155..d20b154 100644
--- a/ui/vnc.h
+++ b/ui/vnc.h
@@ -515,7 +515,7 @@ void vnc_write_u8(VncState *vs, uint8_t value);
 void vnc_flush(VncState *vs);
 void vnc_read_when(VncState *vs, VncReadEvent *func, size_t expecting);
 void vnc_disconnect_finish(VncState *vs);
-void vnc_init_state(VncState *vs);
+void vnc_start_protocol(VncState *vs);
 
 
 /* Buffer I/O functions */
-- 
1.8.3.1

[Qemu-devel] [PULL 01/10] ui: remove misleading comment from vnc_init_state

[Gerd Hoffmann]

From: "Daniel P. Berrange" 

The last line in vnc_init_state() says

 /* vs might be free()ed here */

This was added in

  commit 198a0039c5fca224a77e9761e2350dd9cc102ad0
  Author: Gerd Hoffmann 
  Date:   Tue Jun 16 14:19:48 2009 +0200

vnc: rework VncState release workflow.

because the preceeding 'vnc_update_client()' could indeed
release the VncState instance.

The call to vnc_update_client() was removed not long after
though in

  commit 1fc624122fb923c7fc4c1f426541d953e7df13c9
  Author: Stefano Stabellini 
  Date:   Mon Aug 3 10:54:32 2009 +0100

single vnc server surface

and so the comment has been wrong ever since

Signed-off-by: Daniel P. Berrange 
Message-id: 1475163940-26094-2-git-send-email-berra...@redhat.com
Signed-off-by: Gerd Hoffmann 
---
 ui/vnc.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/ui/vnc.c b/ui/vnc.c
index 76a3273..5faf79b 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -3092,8 +3092,6 @@ void vnc_init_state(VncState *vs)
 
 vs->mouse_mode_notifier.notify = check_pointer_type_change;
 qemu_add_mouse_mode_change_notifier(&vs->mouse_mode_notifier);
-
-/* vs might be free()ed here */
 }
 
 static gboolean vnc_listen_io(QIOChannel *ioc,
-- 
1.8.3.1

[Qemu-devel] [PULL 07/10] ui: remove bogus call to reset_keys() in vnc_init_state

[Gerd Hoffmann]

From: "Daniel P. Berrange" 

The vnc_init_state method calls reset_keys() to reset the
modifier key state. This was originally added in

  commit 53762ddb277c690e486d0e17b10591774248c8cf
  Author: malc 
  Date:   Mon Dec 1 20:57:52 2008 +

Reset the key modifiers upon client connect

This was valid at this time because there was only the
single VncState object which was persistent across client
connections and so needed resetting.

The persistent data was later split off into VncDisplay
and VncState was allocated at time of client connection:

  commit 753b4053311ff1437d99726970b1e7e6bf38249b
  Author: aliguori 
  Date:   Mon Feb 16 14:59:30 2009 +

Support multiple VNC clients (Brian Kress)

at which point the modifier state is always 0 due to
use of g_new0. As such the reset_keys() call has been
a no-op ever since.

Signed-off-by: Daniel P. Berrange 
Message-id: 1475163940-26094-8-git-send-email-berra...@redhat.com
Signed-off-by: Gerd Hoffmann 
---
 ui/vnc.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/ui/vnc.c b/ui/vnc.c
index d1f33d3..7c8f07d 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -3086,7 +3086,6 @@ void vnc_init_state(VncState *vs)
 vnc_write(vs, "RFB 003.008\n", 12);
 vnc_flush(vs);
 vnc_read_when(vs, protocol_version, 12);
-reset_keys(vs);
 if (vs->vd->lock_key_sync)
 vs->led = qemu_add_led_event_handler(kbd_leds, vs);
 
-- 
1.8.3.1

[Qemu-devel] [PULL 03/10] ui: remove 'ws_tls' field from VncState

[Gerd Hoffmann]

From: "Daniel P. Berrange" 

The 'ws_tls' field in VncState is only ever representing
the result of 'tlscreds != NULL' and is thus pointless.
Replace use of 'ws_tls' with a direct check against
'tlscreds'

Signed-off-by: Daniel P. Berrange 
Message-id: 1475163940-26094-4-git-send-email-berra...@redhat.com
Signed-off-by: Gerd Hoffmann 
---
 ui/vnc.c | 11 +--
 ui/vnc.h |  1 -
 2 files changed, 1 insertion(+), 11 deletions(-)

diff --git a/ui/vnc.c b/ui/vnc.c
index 45a23d3..83a608b 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -3029,7 +3029,7 @@ static void vnc_connect(VncDisplay *vd, QIOChannelSocket 
*sioc,
 qio_channel_set_blocking(vs->ioc, false, NULL);
 if (websocket) {
 vs->websocket = 1;
-if (vd->ws_tls) {
+if (vd->tlscreds) {
 vs->ioc_tag = qio_channel_add_watch(
 vs->ioc, G_IO_IN, vncws_tls_handshake_io, vs, NULL);
 } else {
@@ -3379,9 +3379,6 @@ vnc_display_setup_auth(VncDisplay *vs,
 if (password) {
 if (vs->tlscreds) {
 vs->auth = VNC_AUTH_VENCRYPT;
-if (websocket) {
-vs->ws_tls = true;
-}
 if (object_dynamic_cast(OBJECT(vs->tlscreds),
 TYPE_QCRYPTO_TLS_CREDS_X509)) {
 VNC_DEBUG("Initializing VNC server with x509 password auth\n");
@@ -3409,9 +3406,6 @@ vnc_display_setup_auth(VncDisplay *vs,
 } else if (sasl) {
 if (vs->tlscreds) {
 vs->auth = VNC_AUTH_VENCRYPT;
-if (websocket) {
-vs->ws_tls = true;
-}
 if (object_dynamic_cast(OBJECT(vs->tlscreds),
 TYPE_QCRYPTO_TLS_CREDS_X509)) {
 VNC_DEBUG("Initializing VNC server with x509 SASL auth\n");
@@ -3439,9 +3433,6 @@ vnc_display_setup_auth(VncDisplay *vs,
 } else {
 if (vs->tlscreds) {
 vs->auth = VNC_AUTH_VENCRYPT;
-if (websocket) {
-vs->ws_tls = true;
-}
 if (object_dynamic_cast(OBJECT(vs->tlscreds),
 TYPE_QCRYPTO_TLS_CREDS_X509)) {
 VNC_DEBUG("Initializing VNC server with x509 no auth\n");
diff --git a/ui/vnc.h b/ui/vnc.h
index a0519cc..223af38 100644
--- a/ui/vnc.h
+++ b/ui/vnc.h
@@ -172,7 +172,6 @@ struct VncDisplay
 int auth;
 int subauth; /* Used by VeNCrypt */
 int ws_auth; /* Used by websockets */
-bool ws_tls; /* Used by websockets */
 bool lossy;
 bool non_adaptive;
 QCryptoTLSCreds *tlscreds;
-- 
1.8.3.1

Re: [Qemu-devel] [PATCH V2] docs: add PCIe devices placement guidelines

[Paolo Bonzini]

On 13/10/2016 11:11, Marcel Apfelbaum wrote:
> Agreed, I sent the patch with both Red Hat and Google SMTP and each time
> was rejected by the server for the recipient domain nongnu.org by
> eggs.gnu.org. [2001:4830:134:3::10].
> 
> The error that the other server returned was: 550 Invalid address in
> message header

You have an "alex.williamson@redhat.comberrange"@redhat.com address that
looks seriously invalid. :)

Paolo

[Qemu-devel] [PULL 06/10] ui: remove bogus call to graphic_hw_update() in vnc_listen_io

[Gerd Hoffmann]

From: "Daniel P. Berrange" 

Just before accepting a new client connection the vnc_listen_io
method calls graphic_hw_update(). This is bogus because there
is a call to this method already in vnc_state_init() and the
client doesn't need up2date graphics console before reaching
that.

Signed-off-by: Daniel P. Berrange 
Message-id: 1475163940-26094-7-git-send-email-berra...@redhat.com
Signed-off-by: Gerd Hoffmann 
---
 ui/vnc.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/ui/vnc.c b/ui/vnc.c
index 2f3ebdc..d1f33d3 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -3102,8 +3102,6 @@ static gboolean vnc_listen_io(QIOChannel *ioc,
 QIOChannelSocket *sioc = NULL;
 Error *err = NULL;
 
-/* Catch-up */
-graphic_hw_update(vd->dcl.con);
 sioc = qio_channel_socket_accept(QIO_CHANNEL_SOCKET(ioc), &err);
 if (sioc != NULL) {
 qio_channel_set_delay(QIO_CHANNEL(sioc), false);
-- 
1.8.3.1

[Qemu-devel] [PULL 05/10] ui: refactor method for setting up VncDisplay auth types

[Gerd Hoffmann]

From: "Daniel P. Berrange" 

There is a lot of repeated code in the auth type setup method,
particularly around checking TLS credential types. Refactor
it to reduce duplication and instead of having one method
do both plain and websockets at once, call it separately
for each.

Signed-off-by: Daniel P. Berrange 
Message-id: 1475163940-26094-6-git-send-email-berra...@redhat.com
Signed-off-by: Gerd Hoffmann 
---
 ui/vnc.c | 124 +++
 ui/vnc.h |   1 +
 2 files changed, 53 insertions(+), 72 deletions(-)

diff --git a/ui/vnc.c b/ui/vnc.c
index 1104697..2f3ebdc 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -3325,7 +3325,9 @@ static QemuOptsList qemu_vnc_opts = {
 
 
 static int
-vnc_display_setup_auth(VncDisplay *vd,
+vnc_display_setup_auth(int *auth,
+   int *subauth,
+   QCryptoTLSCreds *tlscreds,
bool password,
bool sasl,
bool websocket,
@@ -3378,86 +3380,56 @@ vnc_display_setup_auth(VncDisplay *vd,
  * VNC auth mechs for plain VNC vs websockets VNC, the end
  * result has the same security characteristics.
  */
-if (password) {
-if (vd->tlscreds) {
-vd->auth = VNC_AUTH_VENCRYPT;
-if (object_dynamic_cast(OBJECT(vd->tlscreds),
-TYPE_QCRYPTO_TLS_CREDS_X509)) {
+if (websocket || !tlscreds) {
+if (password) {
+VNC_DEBUG("Initializing VNC server with password auth\n");
+*auth = VNC_AUTH_VNC;
+} else if (sasl) {
+VNC_DEBUG("Initializing VNC server with SASL auth\n");
+*auth = VNC_AUTH_SASL;
+} else {
+VNC_DEBUG("Initializing VNC server with no auth\n");
+*auth = VNC_AUTH_NONE;
+}
+*subauth = VNC_AUTH_INVALID;
+} else {
+bool is_x509 = object_dynamic_cast(OBJECT(tlscreds),
+   TYPE_QCRYPTO_TLS_CREDS_X509) != 
NULL;
+bool is_anon = object_dynamic_cast(OBJECT(tlscreds),
+   TYPE_QCRYPTO_TLS_CREDS_ANON) != 
NULL;
+
+if (!is_x509 && !is_anon) {
+error_setg(errp,
+   "Unsupported TLS cred type %s",
+   object_get_typename(OBJECT(tlscreds)));
+return -1;
+}
+*auth = VNC_AUTH_VENCRYPT;
+if (password) {
+if (is_x509) {
 VNC_DEBUG("Initializing VNC server with x509 password auth\n");
-vd->subauth = VNC_AUTH_VENCRYPT_X509VNC;
-} else if (object_dynamic_cast(OBJECT(vd->tlscreds),
-   TYPE_QCRYPTO_TLS_CREDS_ANON)) {
+*subauth = VNC_AUTH_VENCRYPT_X509VNC;
+} else {
 VNC_DEBUG("Initializing VNC server with TLS password auth\n");
-vd->subauth = VNC_AUTH_VENCRYPT_TLSVNC;
-} else {
-error_setg(errp,
-   "Unsupported TLS cred type %s",
-   object_get_typename(OBJECT(vd->tlscreds)));
-return -1;
+*subauth = VNC_AUTH_VENCRYPT_TLSVNC;
 }
-} else {
-VNC_DEBUG("Initializing VNC server with password auth\n");
-vd->auth = VNC_AUTH_VNC;
-vd->subauth = VNC_AUTH_INVALID;
-}
-if (websocket) {
-vd->ws_auth = VNC_AUTH_VNC;
-} else {
-vd->ws_auth = VNC_AUTH_INVALID;
-}
-} else if (sasl) {
-if (vd->tlscreds) {
-vd->auth = VNC_AUTH_VENCRYPT;
-if (object_dynamic_cast(OBJECT(vd->tlscreds),
-TYPE_QCRYPTO_TLS_CREDS_X509)) {
+
+} else if (sasl) {
+if (is_x509) {
 VNC_DEBUG("Initializing VNC server with x509 SASL auth\n");
-vd->subauth = VNC_AUTH_VENCRYPT_X509SASL;
-} else if (object_dynamic_cast(OBJECT(vd->tlscreds),
-   TYPE_QCRYPTO_TLS_CREDS_ANON)) {
+*subauth = VNC_AUTH_VENCRYPT_X509SASL;
+} else {
 VNC_DEBUG("Initializing VNC server with TLS SASL auth\n");
-vd->subauth = VNC_AUTH_VENCRYPT_TLSSASL;
-} else {
-error_setg(errp,
-   "Unsupported TLS cred type %s",
-   object_get_typename(OBJECT(vd->tlscreds)));
-return -1;
+*subauth = VNC_AUTH_VENCRYPT_TLSSASL;
 }
 } else {
-VNC_DEBUG("Initializing VNC server with SASL auth\n");
-vd->auth = VNC_AUTH_SASL;
-vd->subauth = VNC_AUTH_INVALID;
-}
-if (websocket) {
-vd->ws_auth = VNC_AUTH_SASL;
-} else {
-vd->ws_auth = VNC_AUTH_INVALID;
-}
-}

[Qemu-devel] [PULL 08/10] ui: move some initialization out of vnc_init_state

[Gerd Hoffmann]

From: "Daniel P. Berrange" 

Most of the fields in VncState are initialized in the
vnc_connect() method, but some are done in vnc_init_state()
instead.

The purpose of having vnc_init_state() is to delay starting
of the VNC wire protocol until after the websockets handshake
has completed. As such the vnc_init_state() method only needs
to be used for initialization that is dependant on the wire
protocol running.

This also lets us get rid of the initialized boolean flag
from the VncState struct.

Signed-off-by: Daniel P. Berrange 
Message-id: 1475163940-26094-9-git-send-email-berra...@redhat.com
Signed-off-by: Gerd Hoffmann 
---
 ui/vnc.c | 49 +++--
 ui/vnc.h |  1 -
 2 files changed, 23 insertions(+), 27 deletions(-)

diff --git a/ui/vnc.c b/ui/vnc.c
index 7c8f07d..c10a003 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -1222,13 +1222,13 @@ void vnc_disconnect_finish(VncState *vs)
 audio_del(vs);
 vnc_release_modifiers(vs);
 
-if (vs->initialized) {
-QTAILQ_REMOVE(&vs->vd->clients, vs, next);
+if (vs->mouse_mode_notifier.notify != NULL) {
 qemu_remove_mouse_mode_change_notifier(&vs->mouse_mode_notifier);
-if (QTAILQ_EMPTY(&vs->vd->clients)) {
-/* last client gone */
-vnc_update_server_surface(vs->vd);
-}
+}
+QTAILQ_REMOVE(&vs->vd->clients, vs, next);
+if (QTAILQ_EMPTY(&vs->vd->clients)) {
+/* last client gone */
+vnc_update_server_surface(vs->vd);
 }
 
 if (vs->vd->lock_key_sync)
@@ -2978,6 +2978,7 @@ static void vnc_connect(VncDisplay *vd, QIOChannelSocket 
*sioc,
 bool skipauth, bool websocket)
 {
 VncState *vs = g_new0(VncState, 1);
+bool first_client = QTAILQ_EMPTY(&vd->clients);
 int i;
 
 vs->sioc = sioc;
@@ -3045,26 +3046,6 @@ static void vnc_connect(VncDisplay *vd, QIOChannelSocket 
*sioc,
 vnc_qmp_event(vs, QAPI_EVENT_VNC_CONNECTED);
 vnc_set_share_mode(vs, VNC_SHARE_MODE_CONNECTING);
 
-if (!vs->websocket) {
-vnc_init_state(vs);
-}
-
-if (vd->num_connecting > vd->connections_limit) {
-QTAILQ_FOREACH(vs, &vd->clients, next) {
-if (vs->share_mode == VNC_SHARE_MODE_CONNECTING) {
-vnc_disconnect_start(vs);
-return;
-}
-}
-}
-}
-
-void vnc_init_state(VncState *vs)
-{
-vs->initialized = true;
-VncDisplay *vd = vs->vd;
-bool first_client = QTAILQ_EMPTY(&vd->clients);
-
 vs->last_x = -1;
 vs->last_y = -1;
 
@@ -3083,6 +3064,22 @@ void vnc_init_state(VncState *vs)
 
 graphic_hw_update(vd->dcl.con);
 
+if (!vs->websocket) {
+vnc_init_state(vs);
+}
+
+if (vd->num_connecting > vd->connections_limit) {
+QTAILQ_FOREACH(vs, &vd->clients, next) {
+if (vs->share_mode == VNC_SHARE_MODE_CONNECTING) {
+vnc_disconnect_start(vs);
+return;
+}
+}
+}
+}
+
+void vnc_init_state(VncState *vs)
+{
 vnc_write(vs, "RFB 003.008\n", 12);
 vnc_flush(vs);
 vnc_read_when(vs, protocol_version, 12);
diff --git a/ui/vnc.h b/ui/vnc.h
index d191d88..e48e155 100644
--- a/ui/vnc.h
+++ b/ui/vnc.h
@@ -307,7 +307,6 @@ struct VncState
 QEMUPutLEDEntry *led;
 
 bool abort;
-bool initialized;
 QemuMutex output_mutex;
 QEMUBH *bh;
 Buffer jobs_buffer;
-- 
1.8.3.1

[Qemu-devel] [PULL 04/10] ui: rename misleading 'VncDisplay' variables

[Gerd Hoffmann]

From: "Daniel P. Berrange" 

Normally code declares 'VncDisplay *vd' or 'VncState *vs'
but there are a bunch of places which misleadingly declare
'VncDisplay *vs'.

Signed-off-by: Daniel P. Berrange 
Message-id: 1475163940-26094-5-git-send-email-berra...@redhat.com
Signed-off-by: Gerd Hoffmann 
---
 ui/vnc.c | 274 ---
 1 file changed, 138 insertions(+), 136 deletions(-)

diff --git a/ui/vnc.c b/ui/vnc.c
index 83a608b..1104697 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -3098,17 +3098,17 @@ static gboolean vnc_listen_io(QIOChannel *ioc,
   GIOCondition condition,
   void *opaque)
 {
-VncDisplay *vs = opaque;
+VncDisplay *vd = opaque;
 QIOChannelSocket *sioc = NULL;
 Error *err = NULL;
 
 /* Catch-up */
-graphic_hw_update(vs->dcl.con);
+graphic_hw_update(vd->dcl.con);
 sioc = qio_channel_socket_accept(QIO_CHANNEL_SOCKET(ioc), &err);
 if (sioc != NULL) {
 qio_channel_set_delay(QIO_CHANNEL(sioc), false);
-vnc_connect(vs, sioc, false,
-ioc != QIO_CHANNEL(vs->lsock));
+vnc_connect(vd, sioc, false,
+ioc != QIO_CHANNEL(vd->lsock));
 object_unref(OBJECT(sioc));
 } else {
 /* client probably closed connection before we got there */
@@ -3131,106 +3131,108 @@ static const DisplayChangeListenerOps dcl_ops = {
 
 void vnc_display_init(const char *id)
 {
-VncDisplay *vs;
+VncDisplay *vd;
 
 if (vnc_display_find(id) != NULL) {
 return;
 }
-vs = g_malloc0(sizeof(*vs));
+vd = g_malloc0(sizeof(*vd));
 
-vs->id = strdup(id);
-QTAILQ_INSERT_TAIL(&vnc_displays, vs, next);
+vd->id = strdup(id);
+QTAILQ_INSERT_TAIL(&vnc_displays, vd, next);
 
-QTAILQ_INIT(&vs->clients);
-vs->expires = TIME_MAX;
+QTAILQ_INIT(&vd->clients);
+vd->expires = TIME_MAX;
 
 if (keyboard_layout) {
 trace_vnc_key_map_init(keyboard_layout);
-vs->kbd_layout = init_keyboard_layout(name2keysym, keyboard_layout);
+vd->kbd_layout = init_keyboard_layout(name2keysym, keyboard_layout);
 } else {
-vs->kbd_layout = init_keyboard_layout(name2keysym, "en-us");
+vd->kbd_layout = init_keyboard_layout(name2keysym, "en-us");
 }
 
-if (!vs->kbd_layout)
+if (!vd->kbd_layout) {
 exit(1);
+}
 
-vs->share_policy = VNC_SHARE_POLICY_ALLOW_EXCLUSIVE;
-vs->connections_limit = 32;
+vd->share_policy = VNC_SHARE_POLICY_ALLOW_EXCLUSIVE;
+vd->connections_limit = 32;
 
-qemu_mutex_init(&vs->mutex);
+qemu_mutex_init(&vd->mutex);
 vnc_start_worker_thread();
 
-vs->dcl.ops = &dcl_ops;
-register_displaychangelistener(&vs->dcl);
+vd->dcl.ops = &dcl_ops;
+register_displaychangelistener(&vd->dcl);
 }
 
 
-static void vnc_display_close(VncDisplay *vs)
+static void vnc_display_close(VncDisplay *vd)
 {
-if (!vs)
+if (!vd) {
 return;
-vs->is_unix = false;
-if (vs->lsock != NULL) {
-if (vs->lsock_tag) {
-g_source_remove(vs->lsock_tag);
+}
+vd->is_unix = false;
+if (vd->lsock != NULL) {
+if (vd->lsock_tag) {
+g_source_remove(vd->lsock_tag);
 }
-object_unref(OBJECT(vs->lsock));
-vs->lsock = NULL;
+object_unref(OBJECT(vd->lsock));
+vd->lsock = NULL;
 }
-if (vs->lwebsock != NULL) {
-if (vs->lwebsock_tag) {
-g_source_remove(vs->lwebsock_tag);
+if (vd->lwebsock != NULL) {
+if (vd->lwebsock_tag) {
+g_source_remove(vd->lwebsock_tag);
 }
-object_unref(OBJECT(vs->lwebsock));
-vs->lwebsock = NULL;
+object_unref(OBJECT(vd->lwebsock));
+vd->lwebsock = NULL;
 }
-vs->auth = VNC_AUTH_INVALID;
-vs->subauth = VNC_AUTH_INVALID;
-if (vs->tlscreds) {
-object_unparent(OBJECT(vs->tlscreds));
-vs->tlscreds = NULL;
+vd->auth = VNC_AUTH_INVALID;
+vd->subauth = VNC_AUTH_INVALID;
+if (vd->tlscreds) {
+object_unparent(OBJECT(vd->tlscreds));
+vd->tlscreds = NULL;
 }
-g_free(vs->tlsaclname);
-vs->tlsaclname = NULL;
+g_free(vd->tlsaclname);
+vd->tlsaclname = NULL;
 }
 
 int vnc_display_password(const char *id, const char *password)
 {
-VncDisplay *vs = vnc_display_find(id);
+VncDisplay *vd = vnc_display_find(id);
 
-if (!vs) {
+if (!vd) {
 return -EINVAL;
 }
-if (vs->auth == VNC_AUTH_NONE) {
+if (vd->auth == VNC_AUTH_NONE) {
 error_printf_unless_qmp("If you want use passwords please enable "
 "password auth using '-vnc 
${dpy},password'.\n");
 return -EINVAL;
 }
 
-g_free(vs->password);
-vs->password = g_strdup(password);
+g_free(vd->password);
+vd->password = g_strdup(password);
 
 return 0;
 }
 
 int vnc_display_pw_expire(const char *id

[Qemu-devel] [PATCH] pxa2xx: Auto-assign name for i2c bus in i2c_init_bus.

[Vijay Kumar B]

If a name is provided, the same name is assigned to both the I2C
controllers. Leaving it NULL, causes names to be automatically
assigned with an ID suffix, giving unique names to each
controller. This helps us to uniquely identify each controller in the
device tree, for example when adding an I2C device.

Signed-off-by: Vijay Kumar B. 
Reviewed-by: Deepak S. 
---
 hw/arm/pxa2xx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/arm/pxa2xx.c b/hw/arm/pxa2xx.c
index 0241e07..9898287 100644
--- a/hw/arm/pxa2xx.c
+++ b/hw/arm/pxa2xx.c
@@ -1505,7 +1505,7 @@ static void pxa2xx_i2c_initfn(Object *obj)
 PXA2xxI2CState *s = PXA2XX_I2C(obj);
 SysBusDevice *sbd = SYS_BUS_DEVICE(obj);
 
-s->bus = i2c_init_bus(dev, "i2c");
+s->bus = i2c_init_bus(dev, NULL);
 
 memory_region_init_io(&s->iomem, obj, &pxa2xx_i2c_ops, s,
   "pxa2xx-i2c", s->region_size);
-- 
2.1.4

[Qemu-devel] [PULL 02/10] ui: remove 'enabled' and 'ws_enabled' fields from VncState

[Gerd Hoffmann]

From: "Daniel P. Berrange" 

The 'ws_enabled' field is never used outside of the
vnc_display_open method, so can be a local variable.

The 'enabled' field is easily replaced by a check
for whether 'lsock' is non-NULL.

Signed-off-by: Daniel P. Berrange 
Message-id: 1475163940-26094-3-git-send-email-berra...@redhat.com
Signed-off-by: Gerd Hoffmann 
---
 ui/vnc.c | 23 ++-
 ui/vnc.h |  2 --
 2 files changed, 10 insertions(+), 15 deletions(-)

diff --git a/ui/vnc.c b/ui/vnc.c
index 5faf79b..45a23d3 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -371,7 +371,7 @@ VncInfo *qmp_query_vnc(Error **errp)
 VncDisplay *vd = vnc_display_find(NULL);
 SocketAddress *addr = NULL;
 
-if (vd == NULL || !vd->enabled) {
+if (vd == NULL || !vd->lsock) {
 info->enabled = false;
 } else {
 info->enabled = true;
@@ -3169,7 +3169,6 @@ static void vnc_display_close(VncDisplay *vs)
 {
 if (!vs)
 return;
-vs->enabled = false;
 vs->is_unix = false;
 if (vs->lsock != NULL) {
 if (vs->lsock_tag) {
@@ -3178,7 +3177,6 @@ static void vnc_display_close(VncDisplay *vs)
 object_unref(OBJECT(vs->lsock));
 vs->lsock = NULL;
 }
-vs->ws_enabled = false;
 if (vs->lwebsock != NULL) {
 if (vs->lwebsock_tag) {
 g_source_remove(vs->lwebsock_tag);
@@ -3538,6 +3536,7 @@ void vnc_display_open(const char *id, Error **errp)
 int acl = 0;
 int lock_key_sync = 1;
 int key_delay_ms;
+bool ws_enabled = false;
 
 if (!vs) {
 error_setg(errp, "VNC display not active");
@@ -3573,7 +3572,7 @@ void vnc_display_open(const char *id, Error **errp)
 }
 
 wsaddr = g_new0(SocketAddress, 1);
-vs->ws_enabled = true;
+ws_enabled = true;
 }
 
 if (strncmp(vnc, "unix:", 5) == 0) {
@@ -3581,7 +3580,7 @@ void vnc_display_open(const char *id, Error **errp)
 saddr->u.q_unix.data = g_new0(UnixSocketAddress, 1);
 saddr->u.q_unix.data->path = g_strdup(vnc + 5);
 
-if (vs->ws_enabled) {
+if (ws_enabled) {
 error_setg(errp, "UNIX sockets not supported with websock");
 goto fail;
 }
@@ -3617,7 +3616,7 @@ void vnc_display_open(const char *id, Error **errp)
 inet->ipv6 = ipv6;
 inet->has_ipv6 = has_ipv6;
 
-if (vs->ws_enabled) {
+if (ws_enabled) {
 wsaddr->type = SOCKET_ADDRESS_KIND_INET;
 inet = wsaddr->u.inet.data = g_new0(InetSocketAddress, 1);
 inet->host = g_strdup(saddr->u.inet.data->host);
@@ -3777,7 +3776,7 @@ void vnc_display_open(const char *id, Error **errp)
 }
 #endif
 
-if (vnc_display_setup_auth(vs, password, sasl, vs->ws_enabled, errp) < 0) {
+if (vnc_display_setup_auth(vs, password, sasl, ws_enabled, errp) < 0) {
 goto fail;
 }
 
@@ -3816,7 +3815,7 @@ void vnc_display_open(const char *id, Error **errp)
 QIOChannelSocket *sioc = NULL;
 vs->lsock = NULL;
 vs->lwebsock = NULL;
-if (vs->ws_enabled) {
+if (ws_enabled) {
 error_setg(errp, "Cannot use websockets in reverse mode");
 goto fail;
 }
@@ -3833,9 +3832,8 @@ void vnc_display_open(const char *id, Error **errp)
 goto fail;
 }
 vs->is_unix = saddr->type == SOCKET_ADDRESS_KIND_UNIX;
-vs->enabled = true;
 
-if (vs->ws_enabled) {
+if (ws_enabled) {
 vs->lwebsock = qio_channel_socket_new();
 if (qio_channel_socket_listen_sync(vs->lwebsock,
wsaddr, errp) < 0) {
@@ -3848,7 +3846,7 @@ void vnc_display_open(const char *id, Error **errp)
 vs->lsock_tag = qio_channel_add_watch(
 QIO_CHANNEL(vs->lsock),
 G_IO_IN, vnc_listen_io, vs, NULL);
-if (vs->ws_enabled) {
+if (ws_enabled) {
 vs->lwebsock_tag = qio_channel_add_watch(
 QIO_CHANNEL(vs->lwebsock),
 G_IO_IN, vnc_listen_io, vs, NULL);
@@ -3866,8 +3864,7 @@ void vnc_display_open(const char *id, Error **errp)
 fail:
 qapi_free_SocketAddress(saddr);
 qapi_free_SocketAddress(wsaddr);
-vs->enabled = false;
-vs->ws_enabled = false;
+ws_enabled = false;
 }
 
 void vnc_display_add_client(const char *id, int csock, bool skipauth)
diff --git a/ui/vnc.h b/ui/vnc.h
index ab5f244..a0519cc 100644
--- a/ui/vnc.h
+++ b/ui/vnc.h
@@ -150,7 +150,6 @@ struct VncDisplay
 guint lsock_tag;
 QIOChannelSocket *lwebsock;
 guint lwebsock_tag;
-bool ws_enabled;
 DisplaySurface *ds;
 DisplayChangeListener dcl;
 kbd_layout_t *kbd_layout;
@@ -167,7 +166,6 @@ struct VncDisplay
 
 const char *id;
 QTAILQ_ENTRY(VncDisplay) next;
-bool enabled;
 bool is_unix;
 char *password;
 time_t expires;
-- 
1.8.3.1

[Qemu-devel] [PATCH v3 05/13] pc: leave max apic_id_limit only in legacy cpu hotplug code

[Igor Mammedov]

that's enough to make old code that depends on it
to prevent QEMU starting with more than 255 CPUs.

Signed-off-by: Igor Mammedov 
---
 hw/acpi/cpu_hotplug.c | 7 ++-
 hw/i386/pc.c  | 7 ---
 2 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/hw/acpi/cpu_hotplug.c b/hw/acpi/cpu_hotplug.c
index c2ab9b8..f15a240 100644
--- a/hw/acpi/cpu_hotplug.c
+++ b/hw/acpi/cpu_hotplug.c
@@ -15,6 +15,7 @@
 #include "qapi/error.h"
 #include "qom/cpu.h"
 #include "hw/i386/pc.h"
+#include "qemu/error-report.h"
 
 #define CPU_EJECT_METHOD "CPEJ"
 #define CPU_MAT_METHOD "CPMA"
@@ -236,7 +237,11 @@ void build_legacy_cpu_hotplug_aml(Aml *ctx, MachineState 
*machine,
 /* The current AML generator can cover the APIC ID range [0..255],
  * inclusive, for VCPU hotplug. */
 QEMU_BUILD_BUG_ON(ACPI_CPU_HOTPLUG_ID_LIMIT > 256);
-g_assert(pcms->apic_id_limit <= ACPI_CPU_HOTPLUG_ID_LIMIT);
+if (pcms->apic_id_limit > ACPI_CPU_HOTPLUG_ID_LIMIT) {
+error_report("max_cpus is too large. APIC ID of last CPU is %u",
+ pcms->apic_id_limit - 1);
+exit(1);
+}
 
 /* create PCI0.PRES device and its _CRS to reserve CPU hotplug MMIO */
 dev = aml_device("PCI0." stringify(CPU_HOTPLUG_RESOURCE_DEVICE));
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 93ff49c..f1c1013 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -778,7 +778,6 @@ static FWCfgState *bochs_bios_init(AddressSpace *as, 
PCMachineState *pcms)
 numa_fw_cfg[0] = cpu_to_le64(nb_numa_nodes);
 for (i = 0; i < max_cpus; i++) {
 unsigned int apic_id = x86_cpu_apic_id_from_index(i);
-assert(apic_id < pcms->apic_id_limit);
 j = numa_get_node_for_cpu(i);
 if (j < nb_numa_nodes) {
 numa_fw_cfg[apic_id + 1] = cpu_to_le64(j);
@@ -1190,12 +1189,6 @@ void pc_cpus_init(PCMachineState *pcms)
  * This is used for FW_CFG_MAX_CPUS. See comments on bochs_bios_init().
  */
 pcms->apic_id_limit = x86_cpu_apic_id_from_index(max_cpus - 1) + 1;
-if (pcms->apic_id_limit > ACPI_CPU_HOTPLUG_ID_LIMIT) {
-error_report("max_cpus is too large. APIC ID of last CPU is %u",
- pcms->apic_id_limit - 1);
-exit(1);
-}
-
 pcms->possible_cpus = g_malloc0(sizeof(CPUArchIdList) +
 sizeof(CPUArchId) * max_cpus);
 for (i = 0; i < max_cpus; i++) {
-- 
2.7.4

[Qemu-devel] [PATCH v3 02/13] pc: acpi: x2APIC support for SRAT table

[Igor Mammedov]

Signed-off-by: Igor Mammedov 
---
rebase on top in 2.7 + updated cpu PXM patches
---
 include/hw/acpi/acpi-defs.h | 11 +++
 hw/i386/acpi-build.c| 34 --
 2 files changed, 35 insertions(+), 10 deletions(-)

diff --git a/include/hw/acpi/acpi-defs.h b/include/hw/acpi/acpi-defs.h
index e94123c..fa89abc 100644
--- a/include/hw/acpi/acpi-defs.h
+++ b/include/hw/acpi/acpi-defs.h
@@ -503,6 +503,17 @@ struct AcpiSratProcessorAffinity
 } QEMU_PACKED;
 typedef struct AcpiSratProcessorAffinity AcpiSratProcessorAffinity;
 
+struct AcpiSratProcessorX2ApicAffinity {
+ACPI_SUB_HEADER_DEF
+uint16_treserved;
+uint32_tproximity_domain;
+uint32_tx2apic_id;
+uint32_tflags;
+uint32_tclk_domain;
+uint32_treserved2;
+} QEMU_PACKED;
+typedef struct AcpiSratProcessorX2ApicAffinity AcpiSratProcessorX2ApicAffinity;
+
 struct AcpiSratMemoryAffinity
 {
 ACPI_SUB_HEADER_DEF
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 702d254..b9819f4 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -2421,7 +2421,6 @@ static void
 build_srat(GArray *table_data, BIOSLinker *linker, MachineState *machine)
 {
 AcpiSystemResourceAffinityTable *srat;
-AcpiSratProcessorAffinity *core;
 AcpiSratMemoryAffinity *numamem;
 
 int i;
@@ -2441,18 +2440,33 @@ build_srat(GArray *table_data, BIOSLinker *linker, 
MachineState *machine)
 
 for (i = 0; i < apic_ids->len; i++) {
 int j = numa_get_node_for_cpu(i);
-int apic_id = apic_ids->cpus[i].arch_id;
+uint32_t apic_id = apic_ids->cpus[i].arch_id;
 
-core = acpi_data_push(table_data, sizeof *core);
-core->type = ACPI_SRAT_PROCESSOR_APIC;
-core->length = sizeof(*core);
-core->local_apic_id = apic_id;
-if (j < nb_numa_nodes) {
+if (apic_id < 255) {
+AcpiSratProcessorAffinity *core;
+
+core = acpi_data_push(table_data, sizeof *core);
+core->type = ACPI_SRAT_PROCESSOR_APIC;
+core->length = sizeof(*core);
+core->local_apic_id = apic_id;
+if (j < nb_numa_nodes) {
 core->proximity_lo = j;
+}
+memset(core->proximity_hi, 0, 3);
+core->local_sapic_eid = 0;
+core->flags = cpu_to_le32(1);
+} else {
+AcpiSratProcessorX2ApicAffinity *core;
+
+core = acpi_data_push(table_data, sizeof *core);
+core->type = ACPI_SRAT_PROCESSOR_x2APIC;
+core->length = sizeof(*core);
+core->x2apic_id = apic_id;
+if (j < nb_numa_nodes) {
+core->proximity_domain = cpu_to_le32(j);
+}
+core->flags = cpu_to_le32(1);
 }
-memset(core->proximity_hi, 0, 3);
-core->local_sapic_eid = 0;
-core->flags = cpu_to_le32(1);
 }
 
 
-- 
2.7.4

[Qemu-devel] [PATCH v3 01/13] pc: acpi: x2APIC support for MADT table

[Igor Mammedov]

Signed-off-by: Igor Mammedov 
---
 include/hw/acpi/acpi-defs.h | 18 +++
 hw/i386/acpi-build.c| 78 +++--
 2 files changed, 72 insertions(+), 24 deletions(-)

diff --git a/include/hw/acpi/acpi-defs.h b/include/hw/acpi/acpi-defs.h
index 9c1b7cb..e94123c 100644
--- a/include/hw/acpi/acpi-defs.h
+++ b/include/hw/acpi/acpi-defs.h
@@ -343,6 +343,24 @@ struct AcpiMadtLocalNmi {
 } QEMU_PACKED;
 typedef struct AcpiMadtLocalNmi AcpiMadtLocalNmi;
 
+struct AcpiMadtProcessorX2Apic {
+ACPI_SUB_HEADER_DEF
+uint16_t reserved;
+uint32_t x2apic_id;  /* Processor's local x2APIC ID */
+uint32_t flags;
+uint32_t uid;/* Processor object _UID */
+} QEMU_PACKED;
+typedef struct AcpiMadtProcessorX2Apic AcpiMadtProcessorX2Apic;
+
+struct AcpiMadtLocalX2ApicNmi {
+ACPI_SUB_HEADER_DEF
+uint16_t flags;  /* MPS INTI flags */
+uint32_t uid;/* Processor object _UID */
+uint8_t  lint;   /* Local APIC LINT# */
+uint8_t  reserved[3];/* Local APIC LINT# */
+} QEMU_PACKED;
+typedef struct AcpiMadtLocalX2ApicNmi AcpiMadtLocalX2ApicNmi;
+
 struct AcpiMadtGenericInterrupt {
 ACPI_SUB_HEADER_DEF
 uint16_t reserved;
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index e999654..702d254 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -340,24 +340,38 @@ build_fadt(GArray *table_data, BIOSLinker *linker, 
AcpiPmInfo *pm,
 void pc_madt_cpu_entry(AcpiDeviceIf *adev, int uid,
CPUArchIdList *apic_ids, GArray *entry)
 {
-int apic_id;
-AcpiMadtProcessorApic *apic = acpi_data_push(entry, sizeof *apic);
-
-apic_id = apic_ids->cpus[uid].arch_id;
-apic->type = ACPI_APIC_PROCESSOR;
-apic->length = sizeof(*apic);
-apic->processor_id = uid;
-apic->local_apic_id = apic_id;
-if (apic_ids->cpus[uid].cpu != NULL) {
-apic->flags = cpu_to_le32(1);
+uint32_t apic_id = apic_ids->cpus[uid].arch_id;
+
+/* ACPI spec says that LAPIC entry for non present
+ * CPU may be omitted from MADT or it must be marked
+ * as disabled. However omitting non present CPU from
+ * MADT breaks hotplug on linux. So possible CPUs
+ * should be put in MADT but kept disabled.
+ */
+if (apic_id < 255) {
+AcpiMadtProcessorApic *apic = acpi_data_push(entry, sizeof *apic);
+
+apic->type = ACPI_APIC_PROCESSOR;
+apic->length = sizeof(*apic);
+apic->processor_id = uid;
+apic->local_apic_id = apic_id;
+if (apic_ids->cpus[uid].cpu != NULL) {
+apic->flags = cpu_to_le32(1);
+} else {
+apic->flags = cpu_to_le32(0);
+}
 } else {
-/* ACPI spec says that LAPIC entry for non present
- * CPU may be omitted from MADT or it must be marked
- * as disabled. However omitting non present CPU from
- * MADT breaks hotplug on linux. So possible CPUs
- * should be put in MADT but kept disabled.
- */
-apic->flags = cpu_to_le32(0);
+AcpiMadtProcessorX2Apic *apic = acpi_data_push(entry, sizeof *apic);
+
+apic->type = ACPI_APIC_LOCAL_X2APIC;
+apic->length = sizeof(*apic);
+apic->uid = uid;
+apic->x2apic_id = apic_id;
+if (apic_ids->cpus[uid].cpu != NULL) {
+apic->flags = cpu_to_le32(1);
+} else {
+apic->flags = cpu_to_le32(0);
+}
 }
 }
 
@@ -369,11 +383,11 @@ build_madt(GArray *table_data, BIOSLinker *linker, 
PCMachineState *pcms)
 int madt_start = table_data->len;
 AcpiDeviceIfClass *adevc = ACPI_DEVICE_IF_GET_CLASS(pcms->acpi_dev);
 AcpiDeviceIf *adev = ACPI_DEVICE_IF(pcms->acpi_dev);
+bool x2apic_mode = false;
 
 AcpiMultipleApicTable *madt;
 AcpiMadtIoApic *io_apic;
 AcpiMadtIntsrcovr *intsrcovr;
-AcpiMadtLocalNmi *local_nmi;
 int i;
 
 madt = acpi_data_push(table_data, sizeof *madt);
@@ -382,6 +396,9 @@ build_madt(GArray *table_data, BIOSLinker *linker, 
PCMachineState *pcms)
 
 for (i = 0; i < apic_ids->len; i++) {
 adevc->madt_cpu(adev, i, apic_ids, table_data);
+if (apic_ids->cpus[i].arch_id > 254) {
+x2apic_mode = true;
+}
 }
 g_free(apic_ids);
 
@@ -414,12 +431,25 @@ build_madt(GArray *table_data, BIOSLinker *linker, 
PCMachineState *pcms)
 intsrcovr->flags  = cpu_to_le16(0xd); /* active high, level triggered 
*/
 }
 
-local_nmi = acpi_data_push(table_data, sizeof *local_nmi);
-local_nmi->type = ACPI_APIC_LOCAL_NMI;
-local_nmi->length   = sizeof(*local_nmi);
-local_nmi->processor_id = 0xff; /* all processors */
-local_nmi->flags= cpu_to_le16(0);
-local_nmi->lint = 1; /* ACPI_LINT1 */
+if (x2apic_mode) {
+AcpiMadtLocalX2ApicNmi *local_nmi;
+
+local_nmi = acpi_data_push(table_data, sizeof *local_n

[Qemu-devel] [PATCH v3 09/13] pc: kvm_apic: pass APIC ID depending on xAPIC/x2APIC mode

[Igor Mammedov]

Signed-off-by: Igor Mammedov 
---
v4:
 - drop kvm_has_x2apic_api() and reuse kvm_enable_x2apic() instead
---
 hw/i386/kvm/apic.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/hw/i386/kvm/apic.c b/hw/i386/kvm/apic.c
index be55102..9a7dd03 100644
--- a/hw/i386/kvm/apic.c
+++ b/hw/i386/kvm/apic.c
@@ -34,7 +34,11 @@ static void kvm_put_apic_state(APICCommonState *s, struct 
kvm_lapic_state *kapic
 int i;
 
 memset(kapic, 0, sizeof(*kapic));
-kvm_apic_set_reg(kapic, 0x2, s->id << 24);
+if (kvm_enable_x2apic() && s->apicbase & MSR_IA32_APICBASE_EXTD) {
+kvm_apic_set_reg(kapic, 0x2, s->initial_apic_id);
+} else {
+kvm_apic_set_reg(kapic, 0x2, s->id << 24);
+}
 kvm_apic_set_reg(kapic, 0x8, s->tpr);
 kvm_apic_set_reg(kapic, 0xd, s->log_dest << 24);
 kvm_apic_set_reg(kapic, 0xe, s->dest_mode << 28 | 0x0fff);
@@ -59,7 +63,11 @@ void kvm_get_apic_state(DeviceState *dev, struct 
kvm_lapic_state *kapic)
 APICCommonState *s = APIC_COMMON(dev);
 int i, v;
 
-s->id = kvm_apic_get_reg(kapic, 0x2) >> 24;
+if (kvm_enable_x2apic() && s->apicbase & MSR_IA32_APICBASE_EXTD) {
+assert(kvm_apic_get_reg(kapic, 0x2) == s->initial_apic_id);
+} else {
+s->id = kvm_apic_get_reg(kapic, 0x2) >> 24;
+}
 s->tpr = kvm_apic_get_reg(kapic, 0x8);
 s->arb_id = kvm_apic_get_reg(kapic, 0x9);
 s->log_dest = kvm_apic_get_reg(kapic, 0xd) >> 24;
-- 
2.7.4

[Qemu-devel] [PATCH v3 00/13] pc: q35: x2APIC support in kvm_apic mode

[Igor Mammedov]

Changes since v2:
  - rebase on top of EIM fixes
  - drop kvm_has_x2apic_ids() and reuse kvm_enable_x2apic()
from Radim's EIM fixes
  - fix hang on reboot in BIOS due to not updated 'etc/boot-cpus' fwcfg file
after CPU hotplug
  - drop not used anymore pc_present_cpus_count() and incrementally count
present VCPUs as they are added/removed at (un)plug callbacks time

Changes since v1:
  - rebase on top of 2.7
  - drop add 2.8 machine and linux headers update patches
  - drop numa related patches (will post separately as unrelated)
  - change default mc->maxcpus only for q35

Changes since RFC:
  - use new KVM_CAP_X2APIC_API to detect x2APIC IDs support
  - rebase on top of 2.7-rc1, since many deps were merged
  - fix etc/boot-cpus to account for -device provided cpus
  - include not yet merged _PXM fix as prereq
  - add 2.8 machine type and bump up maxcpus count since it

Series extends current CPU/kvm_apic/Q35 machine
code to support x2APIC and upto 288 VCPUs when QEMU
is used with KVM's lapic.

Due to FW_CFG_MAX_CPUS (which is actually apic_id_limit)
being limited to uint16_t, the max possible APIC ID is
limitted to 2^16 with this series but that should
be sufficient for bumping VCPUs number for quite a while.

Not yet fixed x2APIC issues:
CPU hotplug doesn't work for CPUs where APIC ID > 254
(guest has to be rebooted to pickup hotplugged CPUs)
due to kernel_irqchip loosing directed IPIs (INIT/SIPI)
to APICs above 254 as a hotplugged CPU is in after power-on
state (i.e. not in x2APIC mode).
Radim's going to post KVM patch to fix it and on top of it
I'll post a followup QEMU sanity check patch to detect if host
supports directed IPIs to CPUs with APIC IDs above 254 in
after power-on state.


Tested with following CLI:
 QEMU -M q35 -enable-kvm \
  -device intel-iommu,intremap=on,eim=on -machine kernel_irqchip=split \
  -smp 1,sockets=9,cores=32,threads=1,maxcpus=288 \
  -device qemu64-x86_64-cpu,socket-id=8,core-id=30,thread-id=0   \
  -bios x2apic_bios.bin

v2 for reference:
[PATCH v2 00/14] pc: q35: x2APIC support in kvm_apic mode
https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg05630.html

Depends on following series:
[PATCH v5 0/7] intel_iommu: fix EIM
https://lists.gnu.org/archive/html/qemu-devel/2016-10/msg01981.html

git gree for testing:
https://github.com/imammedo/qemu.git x2apic_v3

To play with the feature, one would also need x2apic enabled
seabios counterpart:
https://github.com/imammedo/seabios.git x2apic_v4

Cc: kra...@redhat.com,
Cc: ehabk...@redhat.com,
Cc: liuxiaoji...@huawei.com,
Cc: m...@redhat.com,
Cc: rkrc...@redhat.com,
Cc: pet...@redhat.com,
Cc: ke...@koconnor.net,
Cc: pbonz...@redhat.com,
Cc: ler...@redhat.com,
Cc: chao@intel.com

Igor Mammedov (13):
  pc: acpi: x2APIC support for MADT table
  pc: acpi: x2APIC support for SRAT table
  acpi: cphp: support x2APIC entry in cpu._MAT
  acpi: cphp: force switch to modern cpu hotplug if APIC ID > 254
  pc: leave max apic_id_limit only in legacy cpu hotplug code
  pc: apic_common: extend APIC ID property to 32bit
  pc: apic_common: restore APIC ID to initial ID on reset
  pc: apic_common: reset APIC ID to initial ID when switching into
x2APIC mode
  pc: kvm_apic: pass APIC ID depending on xAPIC/x2APIC mode
  pc: clarify FW_CFG_MAX_CPUS usage comment
  increase MAX_CPUMASK_BITS from 255 to 288
  pc: add 'etc/boot-cpus' fw_cfg file for machine with more than 255
CPUs
  pc: require IRQ remapping and EIM if there could be x2APIC CPUs

 include/hw/acpi/acpi-defs.h |  29 +++
 include/hw/i386/apic_internal.h |   3 +-
 include/hw/i386/pc.h|   2 +
 include/sysemu/sysemu.h |   2 +-
 target-i386/cpu.h   |   1 +
 hw/acpi/cpu.c   |   5 ++
 hw/acpi/cpu_hotplug.c   |  17 --
 hw/arm/virt.c   |   2 +-
 hw/i386/acpi-build.c| 112 
 hw/i386/kvm/apic.c  |  12 -
 hw/i386/pc.c|  74 ++
 hw/intc/apic_common.c   |  52 ++-
 hw/ppc/spapr.c  |   2 +-
 target-i386/cpu.c   |   2 +-
 14 files changed, 236 insertions(+), 79 deletions(-)

-- 
2.7.4

[Qemu-devel] [PATCH v3 07/13] pc: apic_common: restore APIC ID to initial ID on reset

[Igor Mammedov]

APIC ID should be restored to initial APIC ID
state after Reset and Power-On.

Signed-off-by: Igor Mammedov 
---
 hw/intc/apic_common.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/intc/apic_common.c b/hw/intc/apic_common.c
index 30f2af0..ea3c8ca 100644
--- a/hw/intc/apic_common.c
+++ b/hw/intc/apic_common.c
@@ -243,6 +243,7 @@ static void apic_reset_common(DeviceState *dev)
 
 bsp = s->apicbase & MSR_IA32_APICBASE_BSP;
 s->apicbase = APIC_DEFAULT_ADDRESS | bsp | MSR_IA32_APICBASE_ENABLE;
+s->id = s->initial_apic_id;
 
 s->vapic_paddr = 0;
 info->vapic_base_update(s);
-- 
2.7.4

[Qemu-devel] [PATCH v3 04/13] acpi: cphp: force switch to modern cpu hotplug if APIC ID > 254

[Igor Mammedov]

Switch to modern cpu hotplug at machine startup time if
a cpu present at boot has apic-id in range unsupported
by legacy cpu hotplug interface (i.e. > 254), to avoid
killing QEMU from legacy cpu hotplug code with error:
   "acpi: invalid cpu id: #apic-id#"

Signed-off-by: Igor Mammedov 
---
 hw/acpi/cpu_hotplug.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/hw/acpi/cpu_hotplug.c b/hw/acpi/cpu_hotplug.c
index e19d902..c2ab9b8 100644
--- a/hw/acpi/cpu_hotplug.c
+++ b/hw/acpi/cpu_hotplug.c
@@ -63,7 +63,8 @@ static void acpi_set_cpu_present_bit(AcpiCpuHotplug *g, 
CPUState *cpu,
 
 cpu_id = k->get_arch_id(cpu);
 if ((cpu_id / 8) >= ACPI_GPE_PROC_LEN) {
-error_setg(errp, "acpi: invalid cpu id: %" PRIi64, cpu_id);
+object_property_set_bool(g->device, false, "cpu-hotplug-legacy",
+ &error_abort);
 return;
 }
 
@@ -85,13 +86,14 @@ void legacy_acpi_cpu_hotplug_init(MemoryRegion *parent, 
Object *owner,
 {
 CPUState *cpu;
 
-CPU_FOREACH(cpu) {
-acpi_set_cpu_present_bit(gpe_cpu, cpu, &error_abort);
-}
 memory_region_init_io(&gpe_cpu->io, owner, &AcpiCpuHotplug_ops,
   gpe_cpu, "acpi-cpu-hotplug", ACPI_GPE_PROC_LEN);
 memory_region_add_subregion(parent, base, &gpe_cpu->io);
 gpe_cpu->device = owner;
+
+CPU_FOREACH(cpu) {
+acpi_set_cpu_present_bit(gpe_cpu, cpu, &error_abort);
+}
 }
 
 void acpi_switch_to_modern_cphp(AcpiCpuHotplug *gpe_cpu,
-- 
2.7.4

[Qemu-devel] [PATCH v3 06/13] pc: apic_common: extend APIC ID property to 32bit

[Igor Mammedov]

ACPI ID is 32 bit wide on CPUs with x2APIC support.
Extend 'id' property to support it.

Signed-off-by: Igor Mammedov 
---
v3:
   keep original behaviour where 'id' is readonly after
   object is realized (pbonzini)
---
 include/hw/i386/apic_internal.h |  3 ++-
 target-i386/cpu.h   |  1 +
 hw/intc/apic_common.c   | 46 -
 target-i386/cpu.c   |  2 +-
 4 files changed, 49 insertions(+), 3 deletions(-)

diff --git a/include/hw/i386/apic_internal.h b/include/hw/i386/apic_internal.h
index cdd11fb..1209eb4 100644
--- a/include/hw/i386/apic_internal.h
+++ b/include/hw/i386/apic_internal.h
@@ -160,7 +160,8 @@ struct APICCommonState {
 MemoryRegion io_memory;
 X86CPU *cpu;
 uint32_t apicbase;
-uint8_t id;
+uint8_t id; /* legacy APIC ID */
+uint32_t initial_apic_id;
 uint8_t version;
 uint8_t arb_id;
 uint8_t tpr;
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index e645698..6303d65 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -325,6 +325,7 @@
 #define MSR_IA32_APICBASE   0x1b
 #define MSR_IA32_APICBASE_BSP   (1<<8)
 #define MSR_IA32_APICBASE_ENABLE(1<<11)
+#define MSR_IA32_APICBASE_EXTD  (1 << 10)
 #define MSR_IA32_APICBASE_BASE  (0xfU<<12)
 #define MSR_IA32_FEATURE_CONTROL0x003a
 #define MSR_TSC_ADJUST  0x003b
diff --git a/hw/intc/apic_common.c b/hw/intc/apic_common.c
index 8d01c9c..30f2af0 100644
--- a/hw/intc/apic_common.c
+++ b/hw/intc/apic_common.c
@@ -22,6 +22,7 @@
 #include "qapi/error.h"
 #include "qemu-common.h"
 #include "cpu.h"
+#include "qapi/visitor.h"
 #include "hw/i386/apic.h"
 #include "hw/i386/apic_internal.h"
 #include "trace.h"
@@ -428,7 +429,6 @@ static const VMStateDescription vmstate_apic_common = {
 };
 
 static Property apic_properties_common[] = {
-DEFINE_PROP_UINT8("id", APICCommonState, id, -1),
 DEFINE_PROP_UINT8("version", APICCommonState, version, 0x14),
 DEFINE_PROP_BIT("vapic", APICCommonState, vapic_control, VAPIC_ENABLE_BIT,
 true),
@@ -437,6 +437,49 @@ static Property apic_properties_common[] = {
 DEFINE_PROP_END_OF_LIST(),
 };
 
+static void apic_common_get_id(Object *obj, Visitor *v, const char *name,
+   void *opaque, Error **errp)
+{
+APICCommonState *s = APIC_COMMON(obj);
+int64_t value;
+
+value = s->apicbase & MSR_IA32_APICBASE_EXTD ? s->initial_apic_id : s->id;
+visit_type_int(v, name, &value, errp);
+}
+
+static void apic_common_set_id(Object *obj, Visitor *v, const char *name,
+   void *opaque, Error **errp)
+{
+APICCommonState *s = APIC_COMMON(obj);
+DeviceState *dev = DEVICE(obj);
+Error *local_err = NULL;
+int64_t value;
+
+if (dev->realized) {
+qdev_prop_set_after_realize(dev, name, errp);
+return;
+}
+
+visit_type_int(v, name, &value, &local_err);
+if (local_err) {
+error_propagate(errp, local_err);
+return;
+}
+
+s->initial_apic_id = value;
+s->id = (uint8_t)value;
+}
+
+static void apic_common_initfn(Object *obj)
+{
+APICCommonState *s = APIC_COMMON(obj);
+
+s->id = s->initial_apic_id = -1;
+object_property_add(obj, "id", "int",
+apic_common_get_id,
+apic_common_set_id, NULL, NULL, NULL);
+}
+
 static void apic_common_class_init(ObjectClass *klass, void *data)
 {
 DeviceClass *dc = DEVICE_CLASS(klass);
@@ -456,6 +499,7 @@ static const TypeInfo apic_common_type = {
 .name = TYPE_APIC_COMMON,
 .parent = TYPE_DEVICE,
 .instance_size = sizeof(APICCommonState),
+.instance_init = apic_common_initfn,
 .class_size = sizeof(APICCommonClass),
 .class_init = apic_common_class_init,
 .abstract = true,
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 13505ab..b4b4342 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -2872,7 +2872,7 @@ static void x86_cpu_apic_create(X86CPU *cpu, Error **errp)
   OBJECT(cpu->apic_state), &error_abort);
 object_unref(OBJECT(cpu->apic_state));
 
-qdev_prop_set_uint8(cpu->apic_state, "id", cpu->apic_id);
+qdev_prop_set_uint32(cpu->apic_state, "id", cpu->apic_id);
 /* TODO: convert to link<> */
 apic = APIC_COMMON(cpu->apic_state);
 apic->cpu = cpu;
-- 
2.7.4

[Qemu-devel] [PATCH v3 03/13] acpi: cphp: support x2APIC entry in cpu._MAT

[Igor Mammedov]

Signed-off-by: Igor Mammedov 
---
 hw/acpi/cpu.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/hw/acpi/cpu.c b/hw/acpi/cpu.c
index 902f5c9..5ac89fe 100644
--- a/hw/acpi/cpu.c
+++ b/hw/acpi/cpu.c
@@ -531,6 +531,11 @@ void build_cpus_aml(Aml *table, MachineState *machine, 
CPUHotplugFeatures opts,
 apic->flags = cpu_to_le32(1);
 break;
 }
+case ACPI_APIC_LOCAL_X2APIC: {
+AcpiMadtProcessorX2Apic *apic = (void *)madt_buf->data;
+apic->flags = cpu_to_le32(1);
+break;
+}
 default:
 assert(0);
 }
-- 
2.7.4

[Qemu-devel] [PATCH v3 11/13] increase MAX_CPUMASK_BITS from 255 to 288

[Igor Mammedov]

so that it would be possible to increase maxcpus limit
for x86 target. Keep spapr/virt_arm at limit they used
to have 255.

Signed-off-by: Igor Mammedov 
---
CC: da...@gibson.dropbear.id.au
CC: peter.mayd...@linaro.org
CC: drjo...@redhat.com

 include/sysemu/sysemu.h | 2 +-
 hw/arm/virt.c   | 2 +-
 hw/ppc/spapr.c  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index b668833..66c6f15 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -173,7 +173,7 @@ extern int mem_prealloc;
  *
  * Note that cpu->get_arch_id() may be larger than MAX_CPUMASK_BITS.
  */
-#define MAX_CPUMASK_BITS 255
+#define MAX_CPUMASK_BITS 288
 
 #define MAX_OPTION_ROMS 16
 typedef struct QEMUOptionRom {
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 795740d..186b5bd 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -1491,7 +1491,7 @@ static void virt_machine_class_init(ObjectClass *oc, void 
*data)
  * it later in machvirt_init, where we have more information about the
  * configuration of the particular instance.
  */
-mc->max_cpus = MAX_CPUMASK_BITS;
+mc->max_cpus = 255;
 mc->has_dynamic_sysbus = true;
 mc->block_default_type = IF_VIRTIO;
 mc->no_cdrom = 1;
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 03e3803..fb3b498 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -2388,7 +2388,7 @@ static void spapr_machine_class_init(ObjectClass *oc, 
void *data)
 mc->init = ppc_spapr_init;
 mc->reset = ppc_spapr_reset;
 mc->block_default_type = IF_SCSI;
-mc->max_cpus = MAX_CPUMASK_BITS;
+mc->max_cpus = 255;
 mc->no_parallel = 1;
 mc->default_boot_order = "";
 mc->default_ram_size = 512 * M_BYTE;
-- 
2.7.4

Re: [Qemu-devel] [PATCH v3 00/13] pc: q35: x2APIC support in kvm_apic mode

[Paolo Bonzini]

On 13/10/2016 11:52, Igor Mammedov wrote:
> To play with the feature, one would also need x2apic enabled
> seabios counterpart:
> https://github.com/imammedo/seabios.git x2apic_v4

Is this going to make it into seabios 1.10?

Paolo

[Qemu-devel] [PATCH v3 08/13] pc: apic_common: reset APIC ID to initial ID when switching into x2APIC mode

[Igor Mammedov]

SDM: x2APIC State Transitions:
 State Changes From xAPIC Mode to x2APIC Mode
"
Any APIC ID value written to the memory-mapped
local APIC ID register is not preserved
"

Signed-off-by: Igor Mammedov 
---
 hw/intc/apic_common.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/hw/intc/apic_common.c b/hw/intc/apic_common.c
index ea3c8ca..d78c885 100644
--- a/hw/intc/apic_common.c
+++ b/hw/intc/apic_common.c
@@ -40,6 +40,11 @@ void cpu_set_apic_base(DeviceState *dev, uint64_t val)
 if (dev) {
 APICCommonState *s = APIC_COMMON(dev);
 APICCommonClass *info = APIC_COMMON_GET_CLASS(s);
+/* switching to x2APIC, reset possibly modified xAPIC ID */
+if (!(s->apicbase & MSR_IA32_APICBASE_EXTD) &&
+(val & MSR_IA32_APICBASE_EXTD)) {
+s->id = s->initial_apic_id;
+}
 info->set_base(s, val);
 }
 }
-- 
2.7.4

[Qemu-devel] [PATCH v3 10/13] pc: clarify FW_CFG_MAX_CPUS usage comment

[Igor Mammedov]

Signed-off-by: Igor Mammedov 
---
 hw/i386/pc.c | 18 --
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index f1c1013..f807932 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -746,17 +746,15 @@ static FWCfgState *bochs_bios_init(AddressSpace *as, 
PCMachineState *pcms)
 
 /* FW_CFG_MAX_CPUS is a bit confusing/problematic on x86:
  *
- * SeaBIOS needs FW_CFG_MAX_CPUS for CPU hotplug, but the CPU hotplug
- * QEMU<->SeaBIOS interface is not based on the "CPU index", but on the 
APIC
- * ID of hotplugged CPUs[1]. This means that FW_CFG_MAX_CPUS is not the
- * "maximum number of CPUs", but the "limit to the APIC ID values SeaBIOS
- * may see".
+ * For machine types prior to 1.8, SeaBIOS needs FW_CFG_MAX_CPUS for
+ * building MPTable, ACPI MADT, ACPI CPU hotplug and ACPI SRAT table,
+ * that tables are based on xAPIC ID and QEMU<->SeaBIOS interface
+ * for CPU hotplug also uses APIC ID and not "CPU index".
+ * This means that FW_CFG_MAX_CPUS is not the "maximum number of CPUs",
+ * but the "limit to the APIC ID values SeaBIOS may see".
  *
- * So, this means we must not use max_cpus, here, but the maximum possible
- * APIC ID value, plus one.
- *
- * [1] The only kind of "CPU identifier" used between SeaBIOS and QEMU is
- * the APIC ID, not the "CPU index"
+ * So for compatibility reasons with old BIOSes we are stuck with
+ * "etc/max-cpus" actually being apic_id_limit
  */
 fw_cfg_add_i16(fw_cfg, FW_CFG_MAX_CPUS, (uint16_t)pcms->apic_id_limit);
 fw_cfg_add_i64(fw_cfg, FW_CFG_RAM_SIZE, (uint64_t)ram_size);
-- 
2.7.4

[Qemu-devel] [Bug 1593605] Re: windows2008r2 boot failed with uefi

[Aleksei Kovura]

I had the same problem and it took me some time to get to this bug
report.

Since this behaviour will not change in future versions of Qemu/OVMF,
maybe Qemu should recognize this configuration as invalid and print
error message instead of failing silently?

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

Title:
  windows2008r2 boot failed with uefi

Status in QEMU:
  Invalid

Bug description:
  I want to run my win2008r2 with uefi. Hypervisor is ubuntu16.04 and my
  qemu command line show below:

  qemu-system-x86_64 -enable-kvm -name win2008r2 -S -machine pc-
  i440fx-2.5,accel=kvm,usb=off -cpu
  host,hv_time,hv_relaxed,hv_spinlocks=0x2000 -drive
  file=/usr/share/qemu/OVMF.fd,if=pflash,format=raw,unit=0,readonly=on
  -drive
  file=/var/lib/libvirt/qemu/nvram/win2008r2_VARS.fd,if=pflash,format=raw,unit=1
  -m size=8388608k,slots=10,maxmem=1073741824k -realtime mlock=off -smp
  8,maxcpus=96,sockets=24,cores=4,threads=1 -numa
  node,nodeid=0,cpus=0-7,mem=8192 -uuid 030638c5-c6aa-
  4f06-82f8-dd2d04fd5705 -no-user-config -nodefaults -chardev
  socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-
  win2008r2/monitor.sock,server,nowait -mon
  chardev=charmonitor,id=monitor,mode=control -rtc
  base=localtime,clock=vm,driftfix=slew -no-hpet -no-shutdown -boot
  strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device
  usb-ehci,id=usb1,bus=pci.0,addr=0x4 -device nec-usb-
  xhci,id=usb2,bus=pci.0,addr=0x5 -device
  lsi,id=scsi0,bus=pci.0,addr=0x6 -device virtio-scsi-
  pci,id=scsi1,bus=pci.0,addr=0x7 -device virtio-serial-pci,id=virtio-
  serial0,bus=pci.0,addr=0x8 -drive
  file=/vms/images/win2008r2,format=qcow2,if=none,id=drive-
  ide0-0-0,cache=directsync -device ide-hd,bus=ide.0,unit=0,drive=drive-
  ide0-0-0,id=ide0-0-0,bootindex=1 -drive
  
file=/vms/isos/cn_windows_server_2008_r2_standard_enterprise_datacenter_and_web_with_sp1_x64_dvd_617598.iso,format=raw,if=none,id
  =drive-ide0-1-1,readonly=on -device ide-cd,bus=ide.1,unit=1,drive
  =drive-ide0-1-1,id=ide0-1-1,bootindex=2 -chardev pty,id=charserial0
  -device isa-serial,chardev=charserial0,id=serial0 -chardev
  
socket,id=charchannel0,path=/var/lib/libvirt/qemu/win2008r2.agent,server,nowait
  -device virtserialport,bus=virtio-
  serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0
  -device usb-tablet,id=input0 -vnc 0.0.0.0:0 -device
  VGA,id=video0,vgamem_mb=16,bus=pci.0,addr=0x2 -device virtio-balloon-
  pci,id=balloon0,bus=pci.0,addr=0xa -msg timestamp=on

  
  OVMF.fd is download from http://sourceforge.net/projects/edk2/files/OVMF/ 
OVMF-X64-r15214.zip.

  When I boot my domain with windows2008 iso, the kvm was caught in
  endless interrupt. I enable trace on my host and I got this.


  1. echo 1 > /sys/kernel/debug/tracing/events/kvm/enable
  2. cat /sys/kernel/debug/tracing/trace_pipe 
  qemu-system-x86-1969  [006]   2093.019588: kvm_exit: reason 
EXTERNAL_INTERRUPT rip 0xf8001080ae8e info 0 80fd
   qemu-system-x86-1969  [006] d...  2093.019590: kvm_entry: vcpu 0
   qemu-system-x86-1966  [017]   2093.021424: kvm_set_irq: gsi 8 level 1 
source 0
   qemu-system-x86-1966  [017]   2093.021429: kvm_pic_set_irq: chip 1 pin 0 
(edge|masked)
   qemu-system-x86-1966  [017]   2093.021430: kvm_ioapic_set_irq: pin 8 dst 
1 vec=209 (Fixed|logical|edge) (coalesced)
   qemu-system-x86-1969  [006]   2093.021683: kvm_exit: reason 
EXTERNAL_INTERRUPT rip 0xf8001080ae78 info 0 80fd
   qemu-system-x86-1969  [006] d...  2093.021686: kvm_entry: vcpu 0
   qemu-system-x86-1969  [006]   2093.022592: kvm_exit: reason 
EXTERNAL_INTERRUPT rip 0xf8001080ae8e info 0 80ef
   qemu-system-x86-1969  [006] d...  2093.022595: kvm_entry: vcpu 0
   qemu-system-x86-1969  [006]   2093.022746: kvm_exit: reason 
EXTERNAL_INTERRUPT rip 0xf8001080ae8e info 0 80fd
   qemu-system-x86-1969  [006] d...  2093.022749: kvm_entry: vcpu 0
   qemu-system-x86-1966  [017]   2093.023434: kvm_set_irq: gsi 8 level 1 
source 0
   qemu-system-x86-1966  [017]   2093.023444: kvm_pic_set_irq: chip 1 pin 0 
(edge|masked)
   qemu-system-x86-1966  [017]   2093.023446: kvm_ioapic_set_irq: pin 8 dst 
1 vec=209 (Fixed|logical|edge) (coalesced)
   qemu-system-x86-1969  [006]   2093.023610: kvm_exit: reason 
EXTERNAL_INTERRUPT rip 0xf8001080ae78 info 0 80fd
   qemu-system-x86-1969  [006] d...  2093.023612: kvm_entry: vcpu 0
   qemu-system-x86-1966  [017]   2093.025430: kvm_set_irq: gsi 8 level 1 
source 0
   qemu-system-x86-1966  [017]   2093.025435: kvm_pic_set_irq: chip 1 pin 0 
(edge|masked)
   qemu-system-x86-1966  [017]   2093.025436: kvm_ioapic_set_irq: pin 8 dst 
1 vec=209 (Fixed|logical|edge) (coalesced)
   qemu-system-x86-1969  [006]   2093.025599: kvm_exit: reason 
EXTERNAL_INTERRUPT rip 0xf8001080ae78 info 0 80fd
   qemu-system-x86-1969  [006] d...  2093.02

[Qemu-devel] [PATCH v3 13/13] pc: require IRQ remapping and EIM if there could be x2APIC CPUs

[Igor Mammedov]

it would prevent starting guest with incorrect configs
where interrupts couldn't be delivered to CPUs with
APIC IDs > 254.

Signed-off-by: Igor Mammedov 
---
 hw/i386/pc.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 40eb43b..f7070e0 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -68,6 +68,7 @@
 #include "qapi-visit.h"
 #include "qom/cpu.h"
 #include "hw/nmi.h"
+#include "hw/i386/intel_iommu.h"
 
 /* debug PC/ISA interrupts */
 //#define DEBUG_IRQ
@@ -1264,6 +1265,18 @@ void pc_machine_done(Notifier *notifier, void *data)
 sizeof(pcms->boot_cpus_le));
 }
 }
+
+if (pcms->apic_id_limit > 255) {
+IntelIOMMUState *iommu = INTEL_IOMMU_DEVICE(x86_iommu_get_default());
+
+if (!iommu || !iommu->x86_iommu.intr_supported ||
+iommu->intr_eim != ON_OFF_AUTO_ON) {
+error_report("current -smp configuration requires "
+ "Extended Interrupt Mode enabled. "
+ "IOMMU should have eim=on option set");
+exit(EXIT_FAILURE);
+}
+}
 }
 
 void pc_guest_info_init(PCMachineState *pcms)
-- 
2.7.4

[Qemu-devel] [PATCH v3 2/3] 9pfs: convert 'len/copied_len' field in V9fsXattr to the type of uint64_t

[Li Qiang]

From: Li Qiang 

The 'len' in V9fsXattr comes from the 'size' argument in setxattr()
function in guest. The setxattr() function's declaration is this:

int setxattr(const char *path, const char *name,
 const void *value, size_t size, int flags);

and 'size' is treated as u64 in linux kernel client code:

int p9_client_xattrcreate(struct p9_fid *fid, const char *name,
  u64 attr_size, int flags)

So the 'len' should have an type of 'uint64_t'.
The 'copied_len' in V9fsXattr is used to account for copied bytes, it
should also have an type of 'uint64_t'.

Suggested-by: Greg Kurz 
Signed-off-by: Li Qiang 
---
 hw/9pfs/9p.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/9pfs/9p.h b/hw/9pfs/9p.h
index aa18da1..7fb075f 100644
--- a/hw/9pfs/9p.h
+++ b/hw/9pfs/9p.h
@@ -159,8 +159,8 @@ typedef struct V9fsConf
 
 typedef struct V9fsXattr
 {
-int64_t copied_len;
-int64_t len;
+uint64_t copied_len;
+uint64_t len;
 void *value;
 V9fsString name;
 int flags;
-- 
1.8.3.1

[Qemu-devel] [PATCH v3 3/3] 9pfs: fix integer overflow issue in xattr read/write

[Li Qiang]

From: Li Qiang 

The v9fs_xattr_read() and v9fs_xattr_write() are passed a guest
originated offset: they must ensure this offset does not go beyond
the size of the extended attribute that was set in v9fs_xattrcreate().
Unfortunately, the current code implement these checks with unsafe
calculations on 32 and 64 bit values, which may allow a malicious
guest to cause OOB access anyway.

Fix this by comparing the offset and the xattr size, which are
both uint64_t, before trying to compute the effective number of bytes
to read or write.

Suggested-by: Greg Kurz 
Signed-off-by: Li Qiang 
---

Changes since v2:
-make the solution of 'copied_len/len' in V9fsXattr type issue to a separate 
patch.
-add detailed changelog.

Changes since v1:
-delete 'xattr_len'.

 hw/9pfs/9p.c | 32 
 1 file changed, 12 insertions(+), 20 deletions(-)

diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
index e902eed..6df85b8 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -1642,20 +1642,17 @@ static int v9fs_xattr_read(V9fsState *s, V9fsPDU *pdu, 
V9fsFidState *fidp,
 {
 ssize_t err;
 size_t offset = 7;
-int read_count;
-int64_t xattr_len;
+uint64_t read_count;
 V9fsVirtioState *v = container_of(s, V9fsVirtioState, state);
 VirtQueueElement *elem = v->elems[pdu->idx];
 
-xattr_len = fidp->fs.xattr.len;
-read_count = xattr_len - off;
+if (fidp->fs.xattr.len < off) {
+read_count = 0;
+} else {
+read_count = fidp->fs.xattr.len - off;
+}
 if (read_count > max_count) {
 read_count = max_count;
-} else if (read_count < 0) {
-/*
- * read beyond XATTR value
- */
-read_count = 0;
 }
 err = pdu_marshal(pdu, offset, "d", read_count);
 if (err < 0) {
@@ -1982,23 +1979,18 @@ static int v9fs_xattr_write(V9fsState *s, V9fsPDU *pdu, 
V9fsFidState *fidp,
 {
 int i, to_copy;
 ssize_t err = 0;
-int write_count;
-int64_t xattr_len;
+uint64_t write_count;
 size_t offset = 7;
 
 
-xattr_len = fidp->fs.xattr.len;
-write_count = xattr_len - off;
-if (write_count > count) {
-write_count = count;
-} else if (write_count < 0) {
-/*
- * write beyond XATTR value len specified in
- * xattrcreate
- */
+if (fidp->fs.xattr.len < off) {
 err = -ENOSPC;
 goto out;
 }
+write_count = fidp->fs.xattr.len - off;
+if (write_count > count) {
+write_count = count;
+}
 err = pdu_marshal(pdu, offset, "d", write_count);
 if (err < 0) {
 return err;
-- 
1.8.3.1

Re: [Qemu-devel] 答复： Re: [PATCH v3 2/3] qapi: auto generate enum value strings

[Lin Ma]

>>> Markus Armbruster  2016/10/11 星期二 下午 2:56 >>>
>Eric Blake  writes:
>
>> On 10/10/2016 10:09 AM, Lin Ma wrote:
>>> 
>>> 
>> Eric Blake  2016/9/27 星期二 上午 4:17 >>>
 On 09/26/2016 05:38 AM, Daniel P. Berrange wrote:
> On Mon, Sep 26, 2016 at 06:16:26PM +0800, Lin Ma wrote:
>> Automatically generate enum value strings that containing the acceptable 
>> values.
>> (Borrowwed Daniel's code.)

 s/Borrowwed/Borrowed/
>>> Sorry for the late reply, I was on vacation.
>>> Thanks for the review.

>>
>> Signed-off-by: Lin Ma 
>> ---
>>  scripts/qapi-types.py | 2 ++
>>  scripts/qapi.py   | 9 +
>>  2 files changed, 11 insertions(+)
>
> This will need some test case coverage in tests/ somewhere, but I'm
> not sure exactly which place is best - Eric/Markus can probably advise

 tests/test-qmp-commands.c is the first one that comes to mind, for
 adding another test case to an existing program.
>
>Yes, that's the closest we got.
>
>>> I'm not familiar with how to write qapi generator code and related test
>>> code at all. I'll start to dig, Any guidance is appreciated.
>>> For adding test case, Only this tests/test-qmp-commands.c needs to be
>>> modified, right? 
>>
>> Yes, I think the easiest approach is to add a new line in the main()
>> file that calls out to a new function, and the new function tests that
>> an existing QAPI enum (from tests/qapi-schema/qapi-schema-test.json) has
>> a sane conversion to a string listing all its members.  Markus may have
>> better ideas on where to place a new test, though.
>
>I think tests/test-qmp-commands.c should be split.  See
>Message-ID: <8760p7yv8n@dusky.pond.sub.org>
>http://lists.gnu.org/archive/html/qemu-devel/2016-10/msg00664.html
>
>However, splitting it out of scope of Lin Ma's work.  Go ahead and add
>to tests/test-qmp-commands.c.
>
Thanks for your information.
 
How about these changes in tests/test-qmp-commands.c ?
@@ -262,6 +262,23 @@ static void test_dealloc_partial(void)
 qapi_free_UserDefTwo(ud2);
 }
 
+/* test generated enum value str */
+static void test_enum_value_str(void)
+{
+EnumOne i;
+char *expected_str = NULL;
+
+for (i = 0; i < ENUM_ONE__MAX; i++) {
+   if (i == 0) {
+   expected_str = g_strdup_printf("\'%s\'", EnumOne_lookup[i]);
+   } else {
+   expected_str = g_strdup_printf("%s, \'%s\'",
+   
expected_str, EnumOne_lookup[i]);
+   }
+}
+g_assert_cmpstr(EnumOne_value_str, ==, expected_str);
+}
+
 
 int main(int argc, char **argv)
 {
@@ -272,6 +289,7 @@ int main(int argc, char **argv)
 g_test_add_func("/0.15/dispatch_cmd_io", test_dispatch_cmd_io);
 g_test_add_func("/0.15/dealloc_types", test_dealloc_types);
 g_test_add_func("/0.15/dealloc_partial", test_dealloc_partial);
+g_test_add_func("/0.15/enum_value_str", test_enum_value_str);
 
 module_call_init(MODULE_INIT_QAPI);
 g_test_run();
 
 
Thanks,
Lin

[Qemu-devel] [PATCH v3 12/13] pc: add 'etc/boot-cpus' fw_cfg file for machine with more than 255 CPUs

[Igor Mammedov]

Currently firmware uses 1 byte at 0x5F offset in RTC CMOS
to get number of CPUs present at boot. However 1 byte is
not enough to handle more than 255 CPUs.  So add a new
fw_cfg file that would allow QEMU to tell it.
For compat reasons add file only for machine types that
support more than 255 CPUs.

Signed-off-by: Igor Mammedov 
---
v3:
  * make boot_cpus to PCMachineState so it could be kept uptodate
when a cpu is added/removed and BIOS would read current value
on system reset
---
 include/hw/i386/pc.h |  2 ++
 hw/i386/pc.c | 36 +---
 2 files changed, 23 insertions(+), 15 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index b16c448..17fff80 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -37,6 +37,7 @@
 /**
  * PCMachineState:
  * @acpi_dev: link to ACPI PM device that performs ACPI hotplug handling
+ * @boot_cpus_le: number of present VCPUs, referenced by 'etc/boot-cpus' fw_cfg
  */
 struct PCMachineState {
 /*< private >*/
@@ -69,6 +70,7 @@ struct PCMachineState {
 bool apic_xrupt_override;
 unsigned apic_id_limit;
 CPUArchIdList *possible_cpus;
+uint16_t boot_cpus_le;
 
 /* NUMA information: */
 uint64_t numa_nodes;
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index f807932..40eb43b 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1084,17 +1084,6 @@ void pc_acpi_smi_interrupt(void *opaque, int irq, int 
level)
 }
 }
 
-static int pc_present_cpus_count(PCMachineState *pcms)
-{
-int i, boot_cpus = 0;
-for (i = 0; i < pcms->possible_cpus->len; i++) {
-if (pcms->possible_cpus->cpus[i].cpu) {
-boot_cpus++;
-}
-}
-return boot_cpus;
-}
-
 static X86CPU *pc_new_cpu(const char *typename, int64_t apic_id,
   Error **errp)
 {
@@ -1231,6 +1220,11 @@ static void pc_build_feature_control_file(PCMachineState 
*pcms)
 fw_cfg_add_file(pcms->fw_cfg, "etc/msr_feature_control", val, 
sizeof(*val));
 }
 
+static void rtc_set_cpus_count(ISADevice *rtc, uint16_t cpus_count)
+{
+rtc_set_memory(rtc, 0x5f, cpus_count - 1);
+}
+
 static
 void pc_machine_done(Notifier *notifier, void *data)
 {
@@ -1239,7 +1233,7 @@ void pc_machine_done(Notifier *notifier, void *data)
 PCIBus *bus = pcms->bus;
 
 /* set the number of CPUs */
-rtc_set_memory(pcms->rtc, 0x5f, pc_present_cpus_count(pcms) - 1);
+rtc_set_cpus_count(pcms->rtc, le16_to_cpu(pcms->boot_cpus_le));
 
 if (bus) {
 int extra_hosts = 0;
@@ -1260,8 +1254,15 @@ void pc_machine_done(Notifier *notifier, void *data)
 
 acpi_setup();
 if (pcms->fw_cfg) {
+MachineClass *mc = MACHINE_GET_CLASS(pcms);
+
 pc_build_smbios(pcms->fw_cfg);
 pc_build_feature_control_file(pcms);
+
+if (mc->max_cpus > 255) {
+fw_cfg_add_file(pcms->fw_cfg, "etc/boot-cpus", &pcms->boot_cpus_le,
+sizeof(pcms->boot_cpus_le));
+}
 }
 }
 
@@ -1785,9 +1786,11 @@ static void pc_cpu_plug(HotplugHandler *hotplug_dev,
 }
 }
 
+/* increment the number of CPUs */
+pcms->boot_cpus_le = cpu_to_le16(le16_to_cpu(pcms->boot_cpus_le) + 1);
 if (dev->hotplugged) {
-/* increment the number of CPUs */
-rtc_set_memory(pcms->rtc, 0x5f, rtc_get_memory(pcms->rtc, 0x5f) + 1);
+/* Update the number of CPUs in CMOS */
+rtc_set_cpus_count(pcms->rtc, le16_to_cpu(pcms->boot_cpus_le));
 }
 
 found_cpu = pc_find_cpu_slot(pcms, CPU(dev), NULL);
@@ -1841,7 +1844,10 @@ static void pc_cpu_unplug_cb(HotplugHandler *hotplug_dev,
 found_cpu->cpu = NULL;
 object_unparent(OBJECT(dev));
 
-rtc_set_memory(pcms->rtc, 0x5f, rtc_get_memory(pcms->rtc, 0x5f) - 1);
+/* decrement the number of CPUs */
+pcms->boot_cpus_le = cpu_to_le16(le16_to_cpu(pcms->boot_cpus_le) - 1);
+/* Update the number of CPUs in CMOS */
+rtc_set_cpus_count(pcms->rtc, le16_to_cpu(pcms->boot_cpus_le));
  out:
 error_propagate(errp, local_err);
 }
-- 
2.7.4

[Qemu-devel] [PATCH v3 0/3] 9pfs: fix xattr related issues

[Li Qiang]

From: Li Qiang 

The current xattr implementation in 9pfs has several issues.

-The 'copied_len' in V9fsXattr is used both for accounting bytes and to tag the 
xattr fid.
-The 'len/copied_len' field in V9fsXattr has a wrong type.
-The read/write dispatch function of xattr uses unsafe computations.

This patchset solves these issues.

Li Qiang (3):
  9pfs: add xattrwalk_fid field in V9fsXattr struct
  9pfs: convert 'len/copied_len' field in V9fsXattr to the type of
uint64_t
  9pfs: fix integer overflow issue in xattr read/write

 hw/9pfs/9p.c | 39 ---
 hw/9pfs/9p.h |  5 +++--
 2 files changed, 19 insertions(+), 25 deletions(-)

-- 
1.8.3.1

Re: [Qemu-devel] [PATCH v3 00/13] pc: q35: x2APIC support in kvm_apic mode

[Igor Mammedov]

On Thu, 13 Oct 2016 12:01:48 +0200
Paolo Bonzini  wrote:

> On 13/10/2016 11:52, Igor Mammedov wrote:
> > To play with the feature, one would also need x2apic enabled
> > seabios counterpart:
> > https://github.com/imammedo/seabios.git x2apic_v4  
> 
> Is this going to make it into seabios 1.10?

The only dependency here is a new fwcfg file etc/boot-cpus
which so far (RFC-v2) haven't risen any questions/complains
from QEMU/SeabIOS sides, so we could assume that it won't
change and merge SeaBIOS side first.

BTW:
I'm going to respin SeaBIOS side today dropping per Kevin's suggestion
 [PATCH v4 3/5] error out if present cpus count changed during SMP bringup

> Paolo

Re: [Qemu-devel] [PATCH v3 00/13] pc: q35: x2APIC support in kvm_apic mode

[Gerd Hoffmann]

On Do, 2016-10-13 at 12:01 +0200, Paolo Bonzini wrote:
> 
> On 13/10/2016 11:52, Igor Mammedov wrote:
> > To play with the feature, one would also need x2apic enabled
> > seabios counterpart:
> > https://github.com/imammedo/seabios.git x2apic_v4
> 
> Is this going to make it into seabios 1.10?

seabios patches are basically ready and are waiting for the qemu patches
being merged.  So, yes, if this series gets reviewed and merged quickly
it should be able to make 1.10

cheers,
  Gerd

Re: [Qemu-devel] [QEMU PATCH v5 3/6] migration: extend VMStateInfo

[Halil Pasic]

On 10/12/2016 04:59 PM, Dr. David Alan Gilbert wrote:
>> Paolo I agree on a theoretical level. It's just I do not see why this
>> > particular change makes the API simpler. In my opinion this complicates
>> > things because now all VMStateInfo's can do funky stuff. Having additional
>> > state you can poke is rarely a simplification. Same goes for lots
>> > of arguments especially if some of them are barely ever used. These
>> > additional parameters contribute nothing for the large majority
>> > of the cases (except maybe some head scratching when reading
>> > the code).
> I think it might depend how many VMStateInfo's we have.
> My ideal rule would be there are no .get/.put implementations outside
> of migration/ and we can trust that they would never do anything silly 
> (right?);

Your statement about ideally no .get/.put implementations outside
of migration/ is consistent with my initial understanding of VMStateInfo:
It's there to take care of the marshaling between the on wire representation
and the in memory representation of a single and preferably primitive
vmstate field (not consisting of further fields). Complex stuff like
arrays, structs, indirection via pointers and possibly allocation is
preferably handled elsewhere. So VMStateInfo is the basic building stones,
and the only place which should write to/read from the stream (in
ideal vmstate).

So in a perfect vmstate world complete type of VMStateInfo is not part of the
API (you do not care about how it's done outside vmstate/), but only the
(possibly pointers to) VMStateInfo's supported by the vmstate API.

Of course this is not realistic, at least at the moment.

On the other hand if VMStateInfo is meant for complete customization,
as Jianjun has put it, then it obviously has to be a full fledged member
of the API, and I think then your ideal rule makes no sense to me.

I also do think we will always need something for handling special
cases because we need to maintain compatibility -- see virtio migration
for example.

> so the extra parameters aren't going to be misused too badly.
> 

What would you consider bad misuse? I do not see this as a big concern
at the moment.

Cheers,
Halil

> However, we're probably quite a way from pulling all of the weirder
> .get/.put implementations back in.
> 
> Dave
> 



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH 1/4] target-lm32: swap operand of wcsr in LOG_DIS()

[Peter Maydell]

On 12 October 2016 at 23:35, Michael Walle  wrote:
> Be consistent with the reference manual.
>
> Signed-off-by: Michael Walle 
> ---
>  target-lm32/translate.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/target-lm32/translate.c b/target-lm32/translate.c
> index dc64cc6..fa8416a 100644
> --- a/target-lm32/translate.c
> +++ b/target-lm32/translate.c
> @@ -865,7 +865,7 @@ static void dec_wcsr(DisasContext *dc)
>  {
>  int no;
>
> -LOG_DIS("wcsr r%d, %d\n", dc->r1, dc->csr);
> +LOG_DIS("wcsr %d, r%d\n", dc->csr, dc->r1);
>
>  switch (dc->csr) {
>  case CSR_IE:
> --
> 2.1.4

Reviewed-by: Peter Maydell 

thanks
-- PMM

Re: [Qemu-devel] [PATCH 3/4] lm32: milkymist-tmu2: fix integer overflow

[Peter Maydell]

On 12 October 2016 at 23:35, Michael Walle  wrote:
> Don't truncate the multiplication and do a 64 bit one instead because
> because the result is stored in a 64 bit variable.
>
> Spotted by coverity, CID 1167561.
>
> Signed-off-by: Michael Walle 
> ---
>  hw/display/milkymist-tmu2.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/display/milkymist-tmu2.c b/hw/display/milkymist-tmu2.c
> index 9c00184..5c666f9 100644
> --- a/hw/display/milkymist-tmu2.c
> +++ b/hw/display/milkymist-tmu2.c
> @@ -213,7 +213,7 @@ static void tmu2_start(MilkymistTMU2State *s)
>  /* Read the QEMU source framebuffer into an OpenGL texture */
>  glGenTextures(1, &texture);
>  glBindTexture(GL_TEXTURE_2D, texture);
> -fb_len = 2*s->regs[R_TEXHRES]*s->regs[R_TEXVRES];
> +fb_len = 2ULL * s->regs[R_TEXHRES] * s->regs[R_TEXVRES];
>  fb = cpu_physical_memory_map(s->regs[R_TEXFBUF], &fb_len, 0);
>  if (fb == NULL) {
>  glDeleteTextures(1, &texture);
> --
> 2.1.4
>

Reviewed-by: Peter Maydell 

thanks
-- PMM

Re: [Qemu-devel] [PATCH 2/4] target-lm32: disable asm logging via LOG_DIS()

[Peter Maydell]

On 12 October 2016 at 23:35, Michael Walle  wrote:
> The lm32 target already has a disassembler which logs the assembly
> instructions with "-d in_asm". Therefore, turn of the LOG_DIS() macro to
> prevent logging the assembly instructions twice. Also turn the macro in a
> one which is always compiled to catch any errors while the macro is turned
> off.
>
> Signed-off-by: Michael Walle 
> ---
>  target-lm32/translate.c | 14 --
>  1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/target-lm32/translate.c b/target-lm32/translate.c
> index fa8416a..792637f 100644
> --- a/target-lm32/translate.c
> +++ b/target-lm32/translate.c
> @@ -33,12 +33,14 @@
>  #include "exec/log.h"
>
>
> -#define DISAS_LM32 1
> -#if DISAS_LM32
> -#  define LOG_DIS(...) qemu_log_mask(CPU_LOG_TB_IN_ASM, ## __VA_ARGS__)
> -#else
> -#  define LOG_DIS(...) do { } while (0)
> -#endif
> +#define DISAS_LM32 0
> +
> +#define LOG_DIS(...) \
> +do { \
> +if (DISAS_LM32) { \
> +qemu_log_mask(CPU_LOG_TB_IN_ASM, ## __VA_ARGS__); \
> +} \
> +} while (0)
>
>  #define EXTRACT_FIELD(src, start, end) \
>  (((src) >> start) & ((1 << (end - start + 1)) - 1))
> --
> 2.1.4

Reviewed-by: Peter Maydell 

thanks
-- PMM

Re: [Qemu-devel] [PATCH 4/4] target-lm32: rewrite gen_compare()

[Peter Maydell]

On 12 October 2016 at 23:35, Michael Walle  wrote:
> Drop the rX, rY and rZ stuff and use dc->r{0,1,2} directly. This should
> also fix the false positive in coverity CID 1005720.
>
> Signed-off-by: Michael Walle 
> ---
>  target-lm32/translate.c | 7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/target-lm32/translate.c b/target-lm32/translate.c
> index 792637f..842af63 100644
> --- a/target-lm32/translate.c
> +++ b/target-lm32/translate.c
> @@ -344,9 +344,6 @@ static void dec_calli(DisasContext *dc)
>
>  static inline void gen_compare(DisasContext *dc, int cond)
>  {
> -int rX = (dc->format == OP_FMT_RR) ? dc->r2 : dc->r1;
> -int rY = dc->r0;
> -int rZ = (dc->format == OP_FMT_RR) ? dc->r1 : -1;
>  int i;
>
>  if (dc->format == OP_FMT_RI) {
> @@ -360,9 +357,9 @@ static inline void gen_compare(DisasContext *dc, int cond)
>  break;
>  }
>
> -tcg_gen_setcondi_tl(cond, cpu_R[rX], cpu_R[rY], i);
> +tcg_gen_setcondi_tl(cond, cpu_R[dc->r1], cpu_R[dc->r0], i);
>  } else {
> -tcg_gen_setcond_tl(cond, cpu_R[rX], cpu_R[rY], cpu_R[rZ]);
> +tcg_gen_setcond_tl(cond, cpu_R[dc->r2], cpu_R[dc->r0], 
> cpu_R[dc->r1]);
>  }
>  }
>

Reviewed-by: Peter Maydell 

thanks
-- PMM

Re: [Qemu-devel] [PATCH v4] timer: a9gtimer: remove loop to auto-increment comparator

[Peter Maydell]

On 13 October 2016 at 07:42, P J P  wrote:
> +-- On Wed, 12 Oct 2016, Peter Maydell wrote --+
> | > -while (gtb->compare < update.new) {
> | > +if (gtb->compare < update.new) {
> | >
> | > +inc = update.new - gtb->compare - 1;
> |
> | Can you explain why the '- 1' here ?
>
>   I think I did that because while was running till gtb->compare < update.new.
> To contain gtb->compare under update.new.
>
> | Something still doesn't look right here. Consider the case where
> | update.new is only just bigger than gtb->compare (actually the
> | usual case, I think). In this case 'update.new - gtb->compare - 1'
> | is smaller than gtb->inc and so the QEMU_ALIGN_DOWN will produce
> | an inc value of 0. That would be wrong, because we should definitely
> | have done an auto-increment.
>
>Yes, but in those cases 'gtb->compare += inc' would exceed update.new. Is
> that okay ?

Of course, and it's what you want. The point of the autoincrement
is that when the timer fires (because the current time reaches
or exceeds the comparator) the hardware automatically advances
the compare value so that it is again ahead of the current time.
That way at some future point the timer will fire again.

You can work this out also by looking at the existing code,
which reads "while (gtb->compare < update.new) { ... }"
so if the autoincrement is enabled we can't leave the while
loop until the compare has been moved forward beyond update.new.

I suggest you try putting in some sample values for the
various variables to confirm that your new code produces the
same answers that the old code did.

thanks
-- PMM

Re: [Qemu-devel] [Qemu-ppc] [QEMU PATCH v5 3/6] migration: extend VMStateInfo

[Halil Pasic]

On 10/13/2016 10:22 AM, Paolo Bonzini wrote:
>>> No, I disagree.  We shouldn't be worried about making intrusive changes
>>> > > to all invocations or declarations, if that leads to a simpler API.
>> > 
>> > If VMStateInfo was meant for complete customization, then it was missing
>> > some parts. I think the API is indeed simpler. Just like
>> > definition for VMStateField. Not all of its fields are used all time.
> Code moves.  We can decide how much customization to allow of VMStateInfo.
> 
> You said it: "Not all of its fields are used all time".  Likewise, not
> all arguments are used all time for get/put, but it's not an issue if they
> are still there!  So this patch is good, but at the same time VMS_LINKED is
> pointless.
> 
> Paolo
> 

I'm fine with this. I just think, it would be nice if the contract between
the vmstate-core and the client code implementing VMStateInfo callbacks
could be documented, including when are certain parameters valid, what
they stand for, and how are they supposed to be used for the next version of
the patch. Just to improve readability. Would this be OK with everybody?

By the way the flag VMS_SINGLE is documented as ignored. Should we drop
it?




signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH V2] docs: add PCIe devices placement guidelines

[Marcel Apfelbaum]

On 10/13/2016 12:38 PM, Paolo Bonzini wrote:



On 13/10/2016 11:11, Marcel Apfelbaum wrote:

Agreed, I sent the patch with both Red Hat and Google SMTP and each time
was rejected by the server for the recipient domain nongnu.org by
eggs.gnu.org. [2001:4830:134:3::10].

The error that the other server returned was: 550 Invalid address in
message header


You have an "alex.williamson@redhat.comberrange"@redhat.com address that
looks seriously invalid. :)



Yes, I saw that - we have 2 lucky people not spammed (yet),
but sadly is uncorrelated with the issue in hand.

Thanks,
Marcel


Paolo

[Qemu-devel] [PATCH 1/2] ACPI: Add IORT Structure definition

[Eric Auger]

From: Prem Mallappa 

ACPI Spec 6.0 introduces IO Remapping Table Structure. This patch
introduces the definitions required to describe the IO relationship
between the PCIe root complex and the ITS.

This conforms to:
"IO Remapping Table System Software on ARM Platforms",
Document number: ARM DEN 0049B, October 2015.

Signed-off-by: Prem Mallappa 
Signed-off-by: Eric Auger 
---
 include/hw/acpi/acpi-defs.h | 91 +
 1 file changed, 91 insertions(+)

diff --git a/include/hw/acpi/acpi-defs.h b/include/hw/acpi/acpi-defs.h
index 9c1b7cb..9ad3c01 100644
--- a/include/hw/acpi/acpi-defs.h
+++ b/include/hw/acpi/acpi-defs.h
@@ -609,4 +609,95 @@ typedef struct AcpiDmarHardwareUnit AcpiDmarHardwareUnit;
 /* Masks for Flags field above */
 #define ACPI_DMAR_INCLUDE_PCI_ALL   1
 
+/*
+ * Input Output Remapping Table (IORT)
+ * Conforms to "IO Remapping Table System Software on ARM Platforms",
+ * Document number: ARM DEN 0049B, October 2015
+ */
+
+struct AcpiIortTable {
+ACPI_TABLE_HEADER_DEF /* ACPI common table header */
+uint32_t node_count;
+uint32_t node_offset;
+uint32_t reserved;
+} QEMU_PACKED;
+typedef struct AcpiIortTable AcpiIortTable;
+
+/*
+ * IORT subtables
+ */
+
+struct AcpiIortNode {
+uint8_t  type;
+uint16_t length;
+uint8_t  revision;
+uint32_t reserved;
+uint32_t mapping_count;
+uint32_t mapping_offset;
+} QEMU_PACKED;
+typedef struct AcpiIortNode AcpiIortNode;
+
+/* Values for subtable Type above */
+enum {
+ACPI_IORT_NODE_ITS_GROUP = 0x00,
+ACPI_IORT_NODE_NAMED_COMPONENT = 0x01,
+ACPI_IORT_NODE_PCI_ROOT_COMPLEX = 0x02,
+ACPI_IORT_NODE_SMMU = 0x03,
+ACPI_IORT_NODE_SMMU_V3 = 0x04
+};
+
+struct AcpiIortIdMapping {
+uint32_t input_base;
+uint32_t id_count;
+uint32_t output_base;
+uint32_t output_reference;
+uint32_t flags;
+} QEMU_PACKED;
+typedef struct AcpiIortIdMapping AcpiIortIdMapping;
+
+/* Masks for Flags field above for IORT subtable */
+#define ACPI_IORT_ID_SINGLE_MAPPING (1)
+
+struct AcpiIortMemoryAccess {
+uint32_t cache_coherency;
+uint8_t  hints;
+uint16_t reserved;
+uint8_t  memory_flags;
+} QEMU_PACKED;
+typedef struct AcpiIortMemoryAccess AcpiIortMemoryAccess;
+
+/* Values for cache_coherency field above */
+#define ACPI_IORT_NODE_COHERENT 0x0001
+#define ACPI_IORT_NODE_NOT_COHERENT 0x
+
+/* Masks for Hints field above */
+#define ACPI_IORT_HT_TRANSIENT  (1)
+#define ACPI_IORT_HT_WRITE  (1 << 1)
+#define ACPI_IORT_HT_READ   (1 << 2)
+#define ACPI_IORT_HT_OVERRIDE   (1 << 3)
+
+/* Masks for memory_flags field above */
+#define ACPI_IORT_MF_COHERENCY  (1)
+#define ACPI_IORT_MF_ATTRIBUTES (1 << 1)
+
+/*
+ * IORT node specific subtables
+ */
+
+struct AcpiIortItsGroup {
+AcpiIortNode iort_node;
+uint32_t its_count;
+uint32_t identifiers[0];
+} QEMU_PACKED;
+typedef struct AcpiIortItsGroup AcpiIortItsGroup;
+
+struct AcpiIortRC {
+AcpiIortNode iort_node;
+AcpiIortMemoryAccess memory_properties;
+uint32_t ats_attribute;
+uint32_t pci_segment_number;
+AcpiIortIdMapping id_mapping_array[0];
+} QEMU_PACKED;
+typedef struct AcpiIortRC AcpiIortRC;
+
 #endif
-- 
2.5.5

[Qemu-devel] [PATCH 0/2] ACPI IORT generation for ITS support

[Eric Auger]

This series completes the support of MSIs for ACPI guests featuring an ITS.

It generates an ACPI IORT table which describes the relationship between
the root complex and the ITS. This typically enables vhost-net support on
such guest.

The series applies on top of Drew's [PATCH 0/2] couple ITS support fixups,
which is now on target-arm.next.

Original contribution was sent by Prem Mallapa in
[PATCH v2 9/9] [optional] arm: smmu-v3: ACPI IORT initial support,
part of [PATCH v2 0/9] SMMUv3 Emulation support.
https://lists.gnu.org/archive/html/qemu-devel/2016-08/msg04350.html

Prem's 1st integration targetted Root Complex - vSMMU relationship
description whereas this series targets RC - ITS description.

This was tested with a guest featuring Tomasz' series related to ACPI ITS
and PCIe support:
- [PATCH V11 0/8] Introduce ACPI world to ITS,
  https://lkml.org/lkml/2016/9/12/926
- Support for ARM64 ACPI based PCI host controller,
  https://lwn.net/Articles/690995/

History:

Prem's version -> v1:
- split into 2 separate patches
- iort struct field names match include/acpi/actbl2.h 's ones
- added ITS node
- added ID mapping in RC node
- removed smmu mode


Prem Mallappa (2):
  ACPI: Add IORT Structure definition
  ARM: Virt: ACPI: Build an IORT table with RC and ITS nodes

 hw/arm/virt-acpi-build.c| 71 +++
 include/hw/acpi/acpi-defs.h | 91 +
 2 files changed, 162 insertions(+)

-- 
2.5.5

[Qemu-devel] [PATCH 2/2] ARM: Virt: ACPI: Build an IORT table with RC and ITS nodes

[Eric Auger]

From: Prem Mallappa 

This patch builds an IORT table that features a root complex node and
an ITS node. This complements the ITS description in the ACPI MADT
table and allows vhost-net on ACPI guest.

Signed-off-by: Prem Mallappa 
Signed-off-by: Eric Auger 
---
 hw/arm/virt-acpi-build.c | 71 
 1 file changed, 71 insertions(+)

diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
index fa0655a..373630a 100644
--- a/hw/arm/virt-acpi-build.c
+++ b/hw/arm/virt-acpi-build.c
@@ -384,6 +384,73 @@ build_rsdp(GArray *rsdp_table, BIOSLinker *linker, 
unsigned rsdt_tbl_offset)
 }
 
 static void
+build_iort(GArray *table_data, BIOSLinker *linker, VirtGuestInfo *guest_info)
+{
+int iort_start = table_data->len;
+AcpiIortTable *iort;
+AcpiIortNode *iort_node;
+AcpiIortItsGroup *its;
+AcpiIortRC *rc;
+AcpiIortIdMapping *idmap;
+size_t node_size;
+
+/* at the moment if there is no its, no need to build the IORT */
+if (!its_class_name() || guest_info->no_its) {
+return;
+}
+
+iort = acpi_data_push(table_data, sizeof(*iort));
+
+iort->length = sizeof(*iort);
+iort->node_offset = table_data->len - iort_start;
+
+/* ITS group node featuring a single ITS identifier */
+iort->node_count++;
+node_size =  sizeof(*its) + sizeof(uint32_t);
+its = acpi_data_push(table_data, node_size);
+
+iort_node = &its->iort_node;
+iort_node->type = ACPI_IORT_NODE_ITS_GROUP;
+iort_node->length = node_size;
+iort->length += iort_node->length;
+
+iort_node->mapping_count = 0;  /* ITS groups do not have IDs */
+iort_node->mapping_offset = 0; /* no ID array */
+its->its_count = 1;/* single ITS identifier */
+its->identifiers[0] = 0;   /* ID = 0 as described in the MADT */
+
+/* Root Complex Node with a single ID mapping*/
+iort->node_count++;
+node_size = sizeof(*rc) + sizeof(*idmap);
+rc = acpi_data_push(table_data, node_size);
+
+iort_node = &rc->iort_node;
+iort_node->type = ACPI_IORT_NODE_PCI_ROOT_COMPLEX;
+iort_node->length = node_size;
+iort->length += iort_node->length;
+
+iort_node->mapping_count = 1;
+iort_node->mapping_offset = sizeof(*rc);
+
+rc->memory_properties.cache_coherency = ACPI_IORT_NODE_COHERENT;
+rc->memory_properties.hints = 0;
+rc->memory_properties.memory_flags = 0;
+rc->ats_attribute = 0;  /* does not support ATS */
+rc->pci_segment_number = 0; /* MCFG _SEG */
+
+/* fill array of ID mappings */
+idmap = &rc->id_mapping_array[0];
+idmap->input_base = 0;
+idmap->id_count = 0x;
+idmap->output_base = 0;
+idmap->output_reference = iort->node_offset;
+idmap->flags = 0;
+
+build_header(linker, table_data, (void *)(table_data->data + iort_start),
+ "IORT", table_data->len - iort_start, 0, NULL, NULL);
+}
+
+static void
 build_spcr(GArray *table_data, BIOSLinker *linker, VirtGuestInfo *guest_info)
 {
 AcpiSerialPortConsoleRedirection *spcr;
@@ -676,6 +743,7 @@ void virt_acpi_build(VirtGuestInfo *guest_info, 
AcpiBuildTables *tables)
  * MADT
  * MCFG
  * DSDT
+ * IORT = ACPI 6.0
  */
 
 /* DSDT is pointed to by FADT */
@@ -703,6 +771,9 @@ void virt_acpi_build(VirtGuestInfo *guest_info, 
AcpiBuildTables *tables)
 build_srat(tables_blob, tables->linker, guest_info);
 }
 
+acpi_add_table(table_offsets, tables_blob);
+build_iort(tables_blob, tables->linker, guest_info);
+
 /* RSDT is pointed to by RSDP */
 rsdt = tables_blob->len;
 build_rsdt(tables_blob, tables->linker, table_offsets, NULL, NULL);
-- 
2.5.5

Re: [Qemu-devel] [QEMU PATCH v5 3/6] migration: extend VMStateInfo

[Dr. David Alan Gilbert]

* Halil Pasic (pa...@linux.vnet.ibm.com) wrote:
> 
> 
> On 10/12/2016 04:59 PM, Dr. David Alan Gilbert wrote:
> >> Paolo I agree on a theoretical level. It's just I do not see why this
> >> > particular change makes the API simpler. In my opinion this complicates
> >> > things because now all VMStateInfo's can do funky stuff. Having 
> >> > additional
> >> > state you can poke is rarely a simplification. Same goes for lots
> >> > of arguments especially if some of them are barely ever used. These
> >> > additional parameters contribute nothing for the large majority
> >> > of the cases (except maybe some head scratching when reading
> >> > the code).
> > I think it might depend how many VMStateInfo's we have.
> > My ideal rule would be there are no .get/.put implementations outside
> > of migration/ and we can trust that they would never do anything silly 
> > (right?);
> 
> Your statement about ideally no .get/.put implementations outside
> of migration/ is consistent with my initial understanding of VMStateInfo:
> It's there to take care of the marshaling between the on wire representation
> and the in memory representation of a single and preferably primitive
> vmstate field (not consisting of further fields). Complex stuff like
> arrays, structs, indirection via pointers and possibly allocation is
> preferably handled elsewhere. So VMStateInfo is the basic building stones,
> and the only place which should write to/read from the stream (in
> ideal vmstate).
> 
> So in a perfect vmstate world complete type of VMStateInfo is not part of the
> API (you do not care about how it's done outside vmstate/), but only the
> (possibly pointers to) VMStateInfo's supported by the vmstate API.
> 
> Of course this is not realistic, at least at the moment.
> 
> On the other hand if VMStateInfo is meant for complete customization,
> as Jianjun has put it, then it obviously has to be a full fledged member
> of the API, and I think then your ideal rule makes no sense to me.
> 
> I also do think we will always need something for handling special
> cases because we need to maintain compatibility -- see virtio migration
> for example.
> 
> > so the extra parameters aren't going to be misused too badly.
> > 
> 
> What would you consider bad misuse? I do not see this as a big concern
> at the moment.

I don't know; but the only justification for needing the VMS_LINKED flag
was that only those functions that were marked with VMS_LINKED would
be passed the new field.

Dave

> Cheers,
> Halil
> 
> > However, we're probably quite a way from pulling all of the weirder
> > .get/.put implementations back in.
> > 
> > Dave
> > 
> 



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

[Qemu-devel] [PATCH 6/9] qdev: remove call to qemu_chr_add_handlers()

[Marc-André Lureau]

chardev property is blindly trying to remove the frontend handlers, but
that doesn't work properly that way since there might be several
frontend on the same chardev. Instead, chardev frontend should use
qemu_chr_remove_handlers(). A previous commit should have fixed all
users.

Signed-off-by: Marc-André Lureau 
---
 hw/core/qdev-properties-system.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/hw/core/qdev-properties-system.c b/hw/core/qdev-properties-system.c
index e55afe6..73d4482 100644
--- a/hw/core/qdev-properties-system.c
+++ b/hw/core/qdev-properties-system.c
@@ -185,7 +185,6 @@ static void release_chr(Object *obj, const char *name, void 
*opaque)
 CharDriverState *chr = *ptr;
 
 if (chr) {
-qemu_chr_add_handlers(chr, NULL, NULL, NULL, NULL);
 qemu_chr_fe_release(chr);
 }
 }
-- 
2.10.0

[Qemu-devel] [PATCH 0/9] Fix mux regression (commit 949055a2)

[Marc-André Lureau]

Hi,

Commit 949055a2 "char: use a fixed idx for child muxed chr" introduced
a regression in mux usage, since it wrongly interpreted mux as muxing
various chr backend. Instead, it muxes frontends.

The first patch reverts the broken change, the following patches add
tracking to frontend handler, finally the last patch adds some tests
that would have helped to track the crash and the regression. There is
also a small fix for ringbuf.

Marc-André Lureau (9):
  Revert "char: use a fixed idx for child muxed chr"
  char: return a tag when adding the fe handlers
  char: add qemu_chr_remove_handlers()
  char: keep track of qemu_chr_add_handlers()
  char: warn on unused qemu_chr_add_handlers() result
  qdev: remove call to qemu_chr_add_handlers()
  char: handle qemu_chr_add_handlers() error
  ringbuf: fix chr_write return value
  tests: start chardev unit tests

 backends/rng-egd.c|  13 ++-
 gdbstub.c |  14 ++-
 hw/arm/pxa2xx.c   |  17 ++-
 hw/arm/strongarm.c|  22 +++-
 hw/char/bcm2835_aux.c |  15 ++-
 hw/char/cadence_uart.c|  18 ++-
 hw/char/debugcon.c|  33 +++---
 hw/char/digic-uart.c  |  14 ++-
 hw/char/escc.c|  20 +++-
 hw/char/etraxfs_ser.c |  18 ++-
 hw/char/exynos4210_uart.c |  21 +++-
 hw/char/grlib_apbuart.c   |  17 ++-
 hw/char/imx_serial.c  |  15 ++-
 hw/char/ipoctal232.c  |  23 +++-
 hw/char/lm32_juart.c  |  15 ++-
 hw/char/lm32_uart.c   |  15 ++-
 hw/char/mcf_uart.c|   7 +-
 hw/char/milkymist-uart.c  |  15 ++-
 hw/char/pl011.c   |  16 ++-
 hw/char/sclpconsole-lm.c  |  18 ++-
 hw/char/sclpconsole.c |  12 +-
 hw/char/serial.c  |  14 ++-
 hw/char/sh_serial.c   |   9 +-
 hw/char/spapr_vty.c   |  16 ++-
 hw/char/stm32f2xx_usart.c |  15 ++-
 hw/char/virtio-console.c  |  17 ++-
 hw/char/xen_console.c |  17 ++-
 hw/char/xilinx_uartlite.c |  18 ++-
 hw/core/qdev-properties-system.c  |   1 -
 hw/ipmi/ipmi_bmc_extern.c |  15 ++-
 hw/misc/ivshmem.c |  15 ++-
 hw/usb/ccid-card-passthru.c   |  18 ++-
 hw/usb/dev-serial.c   |  20 +++-
 hw/usb/redirect.c |  19 ++-
 monitor.c |  21 +++-
 net/colo-compare.c|  37 --
 net/filter-mirror.c   |  20 +++-
 net/slirp.c   |  12 +-
 net/vhost-user.c  |  20 ++--
 qemu-char.c   | 173 +--
 qtest.c   |   7 +-
 stubs/monitor-init.c  |   2 +-
 tests/test-char.c | 238 ++
 tests/vhost-user-test.c   |   8 +-
 vl.c  |   2 +-
 tests/Makefile.include|   4 +
 include/hw/char/bcm2835_aux.h |   1 +
 include/hw/char/cadence_uart.h|   1 +
 include/hw/char/digic-uart.h  |   1 +
 include/hw/char/imx_serial.h  |   1 +
 include/hw/char/serial.h  |   1 +
 include/hw/char/stm32f2xx_usart.h |   1 +
 include/monitor/monitor.h |   2 +-
 include/sysemu/char.h |  40 ---
 54 files changed, 954 insertions(+), 190 deletions(-)
 create mode 100644 tests/test-char.c

-- 
2.10.0

[Qemu-devel] [PATCH 1/9] Revert "char: use a fixed idx for child muxed chr"

[Marc-André Lureau]

That commit mis-used mux char: the frontend are multiplexed, not the
backend. Fix the regression preventing "c-a c" to switch the focus. The
following patches will fix the crash (when leaving or removing frontend)
by tracking frontends with handler tags.

This reverts commit 949055a2549afc4cde06b7972072c7288bb43722.

Signed-off-by: Marc-André Lureau 
---
 qemu-char.c   | 22 +++---
 include/sysemu/char.h |  1 -
 2 files changed, 7 insertions(+), 16 deletions(-)

diff --git a/qemu-char.c b/qemu-char.c
index 721ce21..d83a896 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -165,7 +165,6 @@ CharDriverState *qemu_chr_alloc(ChardevCommon *backend, 
Error **errp)
 CharDriverState *chr = g_malloc0(sizeof(CharDriverState));
 qemu_mutex_init(&chr->chr_write_lock);
 
-chr->mux_idx = -1;
 if (backend->has_logfile) {
 int flags = O_WRONLY | O_CREAT;
 if (backend->has_logappend &&
@@ -739,25 +738,17 @@ static void mux_chr_update_read_handler(CharDriverState 
*chr,
 GMainContext *context)
 {
 MuxDriver *d = chr->opaque;
-int idx;
 
 if (d->mux_cnt >= MAX_MUX) {
 fprintf(stderr, "Cannot add I/O handlers, MUX array is full\n");
 return;
 }
-
-if (chr->mux_idx == -1) {
-chr->mux_idx = d->mux_cnt++;
-}
-
-idx = chr->mux_idx;
-d->ext_opaque[idx] = chr->handler_opaque;
-d->chr_can_read[idx] = chr->chr_can_read;
-d->chr_read[idx] = chr->chr_read;
-d->chr_event[idx] = chr->chr_event;
-
+d->ext_opaque[d->mux_cnt] = chr->handler_opaque;
+d->chr_can_read[d->mux_cnt] = chr->chr_can_read;
+d->chr_read[d->mux_cnt] = chr->chr_read;
+d->chr_event[d->mux_cnt] = chr->chr_event;
 /* Fix up the real driver with mux routines */
-if (d->mux_cnt == 1) {
+if (d->mux_cnt == 0) {
 qemu_chr_add_handlers_full(d->drv, mux_chr_can_read,
mux_chr_read,
mux_chr_event,
@@ -766,7 +757,8 @@ static void mux_chr_update_read_handler(CharDriverState 
*chr,
 if (d->focus != -1) {
 mux_chr_send_event(d, d->focus, CHR_EVENT_MUX_OUT);
 }
-d->focus = idx;
+d->focus = d->mux_cnt;
+d->mux_cnt++;
 mux_chr_send_event(d, d->focus, CHR_EVENT_MUX_IN);
 }
 
diff --git a/include/sysemu/char.h b/include/sysemu/char.h
index 0d12175..19dad3f 100644
--- a/include/sysemu/char.h
+++ b/include/sysemu/char.h
@@ -107,7 +107,6 @@ struct CharDriverState {
 int explicit_be_open;
 int avail_connections;
 int is_mux;
-int mux_idx;
 guint fd_in_tag;
 bool replay;
 DECLARE_BITMAP(features, QEMU_CHAR_FEATURE_LAST);
-- 
2.10.0

[Qemu-devel] [PATCH 5/9] char: warn on unused qemu_chr_add_handlers() result

[Marc-André Lureau]

Enforce good usage of frontend handlers.

Signed-off-by: Marc-André Lureau 
---
 include/sysemu/char.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/sysemu/char.h b/include/sysemu/char.h
index 36d82b1..9632dbb 100644
--- a/include/sysemu/char.h
+++ b/include/sysemu/char.h
@@ -439,6 +439,7 @@ void qemu_chr_be_event(CharDriverState *s, int event);
  *
  * Returns: a tag associated with the handlers, or -1 on error.
  */
+G_GNUC_WARN_UNUSED_RESULT
 int qemu_chr_add_handlers(CharDriverState *s,
IOCanReadHandler *fd_can_read,
IOReadHandler *fd_read,
@@ -446,6 +447,7 @@ int qemu_chr_add_handlers(CharDriverState *s,
void *opaque);
 
 /* This API can make handler run in the context what you pass to. */
+G_GNUC_WARN_UNUSED_RESULT
 int qemu_chr_add_handlers_full(CharDriverState *s,
 IOCanReadHandler *fd_can_read,
 IOReadHandler *fd_read,
-- 
2.10.0

[Qemu-devel] [PATCH 3/9] char: add qemu_chr_remove_handlers()

[Marc-André Lureau]

Remove the handlers associated with a frontend tag.

Signed-off-by: Marc-André Lureau 
---
 qemu-char.c   | 9 +
 include/sysemu/char.h | 9 +
 2 files changed, 18 insertions(+)

diff --git a/qemu-char.c b/qemu-char.c
index 168af69..a7fec6a 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -526,6 +526,15 @@ int qemu_chr_add_handlers(CharDriverState *s,
   fd_event, opaque, NULL);
 }
 
+void qemu_chr_remove_handlers(CharDriverState *s, int tag)
+{
+if (tag < 0) {
+return;
+}
+/* FIXME: recycle mux tag */
+qemu_chr_set_handlers(s, NULL, NULL, NULL, NULL, NULL, tag);
+}
+
 static int null_chr_write(CharDriverState *chr, const uint8_t *buf, int len)
 {
 return len;
diff --git a/include/sysemu/char.h b/include/sysemu/char.h
index bdd61ea..36d82b1 100644
--- a/include/sysemu/char.h
+++ b/include/sysemu/char.h
@@ -453,6 +453,15 @@ int qemu_chr_add_handlers_full(CharDriverState *s,
 void *opaque,
 GMainContext *context);
 
+/**
+ * @qemu_chr_remove_handlers:
+ *
+ * @tag: the tag returned from qemu_chr_add_handlers()
+ *
+ * Remove the frontend callbacks.
+ */
+void qemu_chr_remove_handlers(CharDriverState *s, int tag);
+
 void qemu_chr_be_generic_open(CharDriverState *s);
 void qemu_chr_accept_input(CharDriverState *s);
 int qemu_chr_add_client(CharDriverState *s, int fd);
-- 
2.10.0

[Qemu-devel] [PATCH 2/9] char: return a tag when adding the fe handlers

[Marc-André Lureau]

The tag helps to keep track of the frontend, and will be used in a later
change for removing the associated callbacks. Once the conversion is
done, a warning will be added to not ignore the return value, since that
would likely lead to an incorrect behaviour.

Signed-off-by: Marc-André Lureau 
---
 qemu-char.c   | 149 ++
 include/sysemu/char.h |  13 -
 2 files changed, 111 insertions(+), 51 deletions(-)

diff --git a/qemu-char.c b/qemu-char.c
index d83a896..168af69 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -89,6 +89,8 @@
 #define READ_RETRIES 10
 #define TCP_MAX_FDS 16
 
+typedef struct MuxDriver MuxDriver;
+
 /***/
 /* Socket address helpers */
 
@@ -449,12 +451,14 @@ void qemu_chr_fe_printf(CharDriverState *s, const char 
*fmt, ...)
 
 static void remove_fd_in_watch(CharDriverState *chr);
 
-void qemu_chr_add_handlers_full(CharDriverState *s,
-IOCanReadHandler *fd_can_read,
-IOReadHandler *fd_read,
-IOEventHandler *fd_event,
-void *opaque,
-GMainContext *context)
+static void
+qemu_chr_set_handlers(CharDriverState *s,
+  IOCanReadHandler *fd_can_read,
+  IOReadHandler *fd_read,
+  IOEventHandler *fd_event,
+  void *opaque,
+  GMainContext *context,
+  int tag)
 {
 int fe_open;
 
@@ -469,7 +473,7 @@ void qemu_chr_add_handlers_full(CharDriverState *s,
 s->chr_event = fd_event;
 s->handler_opaque = opaque;
 if (s->chr_update_read_handler) {
-s->chr_update_read_handler(s, context);
+s->chr_update_read_handler(s, context, tag);
 }
 
 if (!s->explicit_fe_open) {
@@ -483,14 +487,43 @@ void qemu_chr_add_handlers_full(CharDriverState *s,
 }
 }
 
-void qemu_chr_add_handlers(CharDriverState *s,
-   IOCanReadHandler *fd_can_read,
-   IOReadHandler *fd_read,
-   IOEventHandler *fd_event,
-   void *opaque)
+static int mux_chr_new_handler_tag(CharDriverState *chr, GMainContext 
*context);
+static void mux_set_focus(MuxDriver *d, int focus);
+
+int qemu_chr_add_handlers_full(CharDriverState *s,
+   IOCanReadHandler *fd_can_read,
+   IOReadHandler *fd_read,
+   IOEventHandler *fd_event,
+   void *opaque,
+   GMainContext *context)
+{
+int tag = 0;
+
+if (s->is_mux) {
+tag = mux_chr_new_handler_tag(s, context);
+if (tag < 0) {
+return tag;
+}
+}
+
+qemu_chr_set_handlers(s, fd_can_read, fd_read,
+  fd_event, opaque, context, tag);
+
+if (s->is_mux) {
+mux_set_focus(s->opaque, tag);
+}
+
+return tag;
+}
+
+int qemu_chr_add_handlers(CharDriverState *s,
+  IOCanReadHandler *fd_can_read,
+  IOReadHandler *fd_read,
+  IOEventHandler *fd_event,
+  void *opaque)
 {
-qemu_chr_add_handlers_full(s, fd_can_read, fd_read,
-   fd_event, opaque, NULL);
+return qemu_chr_add_handlers_full(s, fd_can_read, fd_read,
+  fd_event, opaque, NULL);
 }
 
 static int null_chr_write(CharDriverState *chr, const uint8_t *buf, int len)
@@ -519,7 +552,7 @@ static CharDriverState *qemu_chr_open_null(const char *id,
 #define MAX_MUX 4
 #define MUX_BUFFER_SIZE 32 /* Must be a power of 2.  */
 #define MUX_BUFFER_MASK (MUX_BUFFER_SIZE - 1)
-typedef struct {
+struct MuxDriver {
 IOCanReadHandler *chr_can_read[MAX_MUX];
 IOReadHandler *chr_read[MAX_MUX];
 IOEventHandler *chr_event[MAX_MUX];
@@ -540,8 +573,7 @@ typedef struct {
 /* Protected by the CharDriverState chr_write_lock.  */
 int linestart;
 int64_t timestamps_start;
-} MuxDriver;
-
+};
 
 /* Called with chr_write_lock held.  */
 static int mux_chr_write(CharDriverState *chr, const uint8_t *buf, int len)
@@ -655,12 +687,9 @@ static int mux_proc_byte(CharDriverState *chr, MuxDriver 
*d, int ch)
 qemu_chr_be_event(chr, CHR_EVENT_BREAK);
 break;
 case 'c':
+assert(d->mux_cnt > 0); /* handler registered with first fe */
 /* Switch to the next registered device */
-mux_chr_send_event(d, d->focus, CHR_EVENT_MUX_OUT);
-d->focus++;
-if (d->focus >= d->mux_cnt)
-d->focus = 0;
-mux_chr_send_event(d, d->focus, CHR_EVENT_MUX_IN);
+mux_set_focus(d, (d->focus + 1) % d->mux_cnt);
 break;
 case 't':
 d->

[Qemu-devel] [PATCH 9/9] tests: start chardev unit tests

[Marc-André Lureau]

Signed-off-by: Marc-André Lureau 
---
 tests/test-char.c  | 238 +
 tests/Makefile.include |   4 +
 2 files changed, 242 insertions(+)
 create mode 100644 tests/test-char.c

diff --git a/tests/test-char.c b/tests/test-char.c
new file mode 100644
index 000..fe1ccf2
--- /dev/null
+++ b/tests/test-char.c
@@ -0,0 +1,238 @@
+#include "qemu/osdep.h"
+
+#include "qemu-common.h"
+#include "qemu/config-file.h"
+#include "sysemu/char.h"
+#include "sysemu/sysemu.h"
+#include "qapi/error.h"
+#include "qmp-commands.h"
+
+typedef struct FeHandler {
+char read_buf[128];
+int read_count;
+int last_event;
+} FeHandler;
+
+static int fe_can_read(void *opaque)
+{
+FeHandler *h = opaque;
+
+return sizeof(h->read_buf) - h->read_count;
+}
+
+static void fe_read(void *opaque, const uint8_t *buf, int size)
+{
+FeHandler *h = opaque;
+
+g_assert_cmpint(size, <=, fe_can_read(opaque));
+
+memcpy(h->read_buf + h->read_count, buf, size);
+h->read_count += size;
+}
+
+static void fe_event(void *opaque, int event)
+{
+FeHandler *h = opaque;
+
+h->last_event = event;
+}
+
+#ifdef CONFIG_HAS_GLIB_SUBPROCESS_TESTS
+static void char_stdio_test_subprocess(void)
+{
+CharDriverState *chr;
+int ret;
+
+chr = qemu_chr_new("label", "stdio", NULL);
+g_assert_nonnull(chr);
+
+qemu_chr_fe_set_open(chr, true);
+ret = qemu_chr_fe_write(chr, (void *)"buf", 4);
+g_assert_cmpint(ret, ==, 4);
+
+qemu_chr_delete(chr);
+}
+
+static void char_stdio_test(void)
+{
+g_test_trap_subprocess("/char/stdio/subprocess", 0, 0);
+g_test_trap_assert_passed();
+g_test_trap_assert_stdout("buf");
+}
+#endif
+
+
+static void char_ringbuf_test(void)
+{
+QemuOpts *opts;
+CharDriverState *chr;
+char *data;
+int ret;
+
+opts = qemu_opts_create(qemu_find_opts("chardev"), "ringbuf-label",
+1, &error_abort);
+qemu_opt_set(opts, "backend", "ringbuf", &error_abort);
+
+qemu_opt_set(opts, "size", "5", &error_abort);
+chr = qemu_chr_new_from_opts(opts, NULL, NULL);
+g_assert_null(chr);
+qemu_opts_del(opts);
+
+opts = qemu_opts_create(qemu_find_opts("chardev"), "ringbuf-label",
+1, &error_abort);
+qemu_opt_set(opts, "backend", "ringbuf", &error_abort);
+qemu_opt_set(opts, "size", "2", &error_abort);
+chr = qemu_chr_new_from_opts(opts, NULL, &error_abort);
+g_assert_nonnull(chr);
+qemu_opts_del(opts);
+
+ret = qemu_chr_fe_write(chr, (void *)"buff", 4);
+g_assert_cmpint(ret, ==, 4);
+
+data = qmp_ringbuf_read("ringbuf-label", 4, false, 0, &error_abort);
+g_assert_cmpstr(data, ==, "ff");
+g_free(data);
+
+data = qmp_ringbuf_read("ringbuf-label", 4, false, 0, &error_abort);
+g_assert_cmpstr(data, ==, "");
+g_free(data);
+
+qemu_chr_delete(chr);
+}
+
+static void char_mux_test(void)
+{
+QemuOpts *opts;
+CharDriverState *chr, *base;
+char *data;
+int tag1, tag2;
+FeHandler h1 = { 0, }, h2 = { 0, };
+
+opts = qemu_opts_create(qemu_find_opts("chardev"), "mux-label",
+1, &error_abort);
+qemu_opt_set(opts, "backend", "ringbuf", &error_abort);
+qemu_opt_set(opts, "size", "128", &error_abort);
+qemu_opt_set(opts, "mux", "on", &error_abort);
+chr = qemu_chr_new_from_opts(opts, NULL, &error_abort);
+g_assert_nonnull(chr);
+qemu_opts_del(opts);
+
+tag1 = qemu_chr_add_handlers(chr,
+ fe_can_read,
+ fe_read,
+ fe_event,
+ &h1,
+ NULL,
+ &error_abort);
+g_assert_cmpint(tag1, !=, -1);
+
+tag2 = qemu_chr_add_handlers(chr,
+ fe_can_read,
+ fe_read,
+ fe_event,
+ &h2,
+ NULL,
+ &error_abort);
+g_assert_cmpint(tag2, !=, -1);
+
+g_assert_cmpint(qemu_chr_be_can_write(chr), !=, 0);
+
+base = qemu_chr_find("mux-label-base");
+
+/* the last handler has the focus */
+qemu_chr_be_write(base, (void *)"hello", 6);
+g_assert_cmpint(h1.read_count, ==, 0);
+g_assert_cmpint(h2.read_count, ==, 6);
+g_assert_cmpstr(h2.read_buf, ==, "hello");
+h2.read_count = 0;
+
+/* switch focus */
+qemu_chr_be_write(base, (void *)"\1c", 2);
+
+qemu_chr_be_write(base, (void *)"hello", 6);
+g_assert_cmpint(h2.read_count, ==, 0);
+g_assert_cmpint(h1.read_count, ==, 6);
+g_assert_cmpstr(h1.read_buf, ==, "hello");
+h1.read_count = 0;
+
+/* remove first handler */
+qemu_chr_remove_handlers(chr, tag1);
+qemu_chr_be_write(base, (void *)"hello", 6);
+g_assert_cmpint(h1.read_count, ==, 0);
+g_assert_cmpint(h2

[Qemu-devel] [PATCH 4/9] char: keep track of qemu_chr_add_handlers()

[Marc-André Lureau]

Frontends should use qemu_chr_add_handlers()/qemu_chr_remove_handlers()
with the appropriate tag. This prevents from growing the mux char
frontends. A following patch will add error handling (check tag return
value and add an Error argument).

Signed-off-by: Marc-André Lureau 
---
 backends/rng-egd.c| 13 ++---
 gdbstub.c | 12 +---
 hw/arm/pxa2xx.c   | 14 +-
 hw/arm/strongarm.c| 19 ++-
 hw/char/bcm2835_aux.c | 13 -
 hw/char/cadence_uart.c| 16 +++-
 hw/char/debugcon.c| 30 --
 hw/char/digic-uart.c  | 13 -
 hw/char/escc.c| 17 -
 hw/char/etraxfs_ser.c | 14 +-
 hw/char/exynos4210_uart.c | 12 +++-
 hw/char/grlib_apbuart.c   | 14 +-
 hw/char/imx_serial.c  | 15 +--
 hw/char/ipoctal232.c  | 18 +-
 hw/char/lm32_juart.c  | 14 +-
 hw/char/lm32_uart.c   | 14 +-
 hw/char/mcf_uart.c|  4 +++-
 hw/char/milkymist-uart.c  | 14 +-
 hw/char/pl011.c   | 14 +-
 hw/char/sclpconsole-lm.c  | 11 ++-
 hw/char/sclpconsole.c |  9 -
 hw/char/serial.c  | 10 +++---
 hw/char/sh_serial.c   |  8 ++--
 hw/char/spapr_vty.c   | 14 +-
 hw/char/stm32f2xx_usart.c | 13 -
 hw/char/virtio-console.c  | 10 --
 hw/char/xen_console.c |  8 +---
 hw/char/xilinx_uartlite.c | 17 +++--
 hw/ipmi/ipmi_bmc_extern.c | 14 +-
 hw/misc/ivshmem.c | 12 ++--
 hw/usb/ccid-card-passthru.c   |  9 -
 hw/usb/dev-serial.c   | 16 ++--
 hw/usb/redirect.c | 13 -
 monitor.c | 13 -
 net/colo-compare.c| 22 ++
 net/filter-mirror.c   | 14 ++
 net/slirp.c   |  6 --
 net/vhost-user.c  |  8 +---
 qemu-char.c   |  6 --
 qtest.c   |  4 +++-
 tests/vhost-user-test.c   |  7 +--
 include/hw/char/bcm2835_aux.h |  1 +
 include/hw/char/cadence_uart.h|  1 +
 include/hw/char/digic-uart.h  |  1 +
 include/hw/char/imx_serial.h  |  1 +
 include/hw/char/serial.h  |  1 +
 include/hw/char/stm32f2xx_usart.h |  1 +
 47 files changed, 443 insertions(+), 87 deletions(-)

diff --git a/backends/rng-egd.c b/backends/rng-egd.c
index ba17c07..5d8485f 100644
--- a/backends/rng-egd.c
+++ b/backends/rng-egd.c
@@ -25,6 +25,7 @@ typedef struct RngEgd
 RngBackend parent;
 
 CharDriverState *chr;
+int chr_tag;
 char *chr_name;
 } RngEgd;
 
@@ -107,8 +108,11 @@ static void rng_egd_opened(RngBackend *b, Error **errp)
 }
 
 /* FIXME we should resubmit pending requests when the CDS reconnects. */
-qemu_chr_add_handlers(s->chr, rng_egd_chr_can_read, rng_egd_chr_read,
-  NULL, s);
+if (s->chr_tag == -1) {
+s->chr_tag =
+qemu_chr_add_handlers(s->chr, rng_egd_chr_can_read,
+  rng_egd_chr_read, NULL, s);
+}
 }
 
 static void rng_egd_set_chardev(Object *obj, const char *value, Error **errp)
@@ -137,6 +141,9 @@ static char *rng_egd_get_chardev(Object *obj, Error **errp)
 
 static void rng_egd_init(Object *obj)
 {
+RngEgd *s = RNG_EGD(obj);
+
+s->chr_tag = -1;
 object_property_add_str(obj, "chardev",
 rng_egd_get_chardev, rng_egd_set_chardev,
 NULL);
@@ -147,7 +154,7 @@ static void rng_egd_finalize(Object *obj)
 RngEgd *s = RNG_EGD(obj);
 
 if (s->chr) {
-qemu_chr_add_handlers(s->chr, NULL, NULL, NULL, NULL);
+qemu_chr_remove_handlers(s->chr, s->chr_tag);
 qemu_chr_fe_release(s->chr);
 }
 
diff --git a/gdbstub.c b/gdbstub.c
index ecea8c4..054a1d3 100644
--- a/gdbstub.c
+++ b/gdbstub.c
@@ -304,6 +304,7 @@ typedef struct GDBState {
 int running_state;
 #else
 CharDriverState *chr;
+int chr_tag;
 CharDriverState *mon_chr;
 #endif
 char syscall_buf[256];
@@ -1724,6 +1725,7 @@ int gdbserver_start(const char *device)
 GDBState *s;
 char gdbstub_device_name[128];
 CharDriverState *chr = NULL;
+int chr_tag = -1;
 CharDriverState *mon_chr;
 ChardevCommon common = { 0 };
 
@@ -1750,8 +1752,9 @@ int gdbserver_start(const char *device)
 return -1;
 
 qemu_chr_fe_claim_no_fail(chr);
-qemu_chr_add_handlers(chr, gdb_chr_can_receive, gdb_chr_receive,
-  gdb_chr_e