date:20190513

From: Marc-André Lureau 

The only caller of unix_listen() left is qga/channel-posix.c.

There is no need to deal with legacy coma-trailing options ",...".

Signed-off-by: Marc-André Lureau 
Reviewed-by: Daniel P. Berrangé 
Message-id: 20190503130034.24916-6-marcandre.lur...@redhat.com
Signed-off-by: Gerd Hoffmann 
---
 util/qemu-sockets.c | 18 ++
 1 file changed, 2 insertions(+), 16 deletions(-)

diff --git a/util/qemu-sockets.c b/util/qemu-sockets.c
index ba6335e71a95..8850a280a84b 100644
--- a/util/qemu-sockets.c
+++ b/util/qemu-sockets.c
@@ -970,26 +970,12 @@ static int unix_connect_saddr(UnixSocketAddress *saddr, 
Error **errp)
 /* compatibility wrapper */
 int unix_listen(const char *str, Error **errp)
 {
-char *path, *optstr;
-int sock, len;
 UnixSocketAddress *saddr;
+int sock;
 
 saddr = g_new0(UnixSocketAddress, 1);
-
-optstr = strchr(str, ',');
-if (optstr) {
-len = optstr - str;
-if (len) {
-path = g_malloc(len+1);
-snprintf(path, len+1, "%.*s", len, str);
-saddr->path = path;
-}
-} else {
-saddr->path = g_strdup(str);
-}
-
+saddr->path = g_strdup(str);
 sock = unix_listen_saddr(saddr, errp);
-
 qapi_free_UnixSocketAddress(saddr);
 return sock;
 }
-- 
2.18.1

[Qemu-devel] [PULL 4/7] Add vhost-user-input-pci

From: Marc-André Lureau 

Add a new virtio-input device, which connects to a vhost-user
backend.

Instead of reading configuration directly from an input device /
evdev (like virtio-input-host), it reads it over vhost-user protocol
with {SET,GET}_CONFIG messages. The vhost-user-backend handles the
queues & events setup.

Signed-off-by: Marc-André Lureau 
Message-id: 20190503130034.24916-5-marcandre.lur...@redhat.com

[ kraxel: drop -{non-,}transitional variants ]
[ kraxel: fix "make check" on !linux ]

Signed-off-by: Gerd Hoffmann 
---
 include/hw/virtio/virtio-input.h |  14 
 hw/input/vhost-user-input.c  | 129 +++
 hw/virtio/vhost-user-input-pci.c |  50 
 MAINTAINERS  |   1 +
 hw/input/Kconfig |   5 ++
 hw/input/Makefile.objs   |   1 +
 hw/virtio/Makefile.objs  |   1 +
 7 files changed, 201 insertions(+)
 create mode 100644 hw/input/vhost-user-input.c
 create mode 100644 hw/virtio/vhost-user-input-pci.c

diff --git a/include/hw/virtio/virtio-input.h b/include/hw/virtio/virtio-input.h
index 054c38836f11..4fca03e7969e 100644
--- a/include/hw/virtio/virtio-input.h
+++ b/include/hw/virtio/virtio-input.h
@@ -2,6 +2,7 @@
 #define QEMU_VIRTIO_INPUT_H
 
 #include "ui/input.h"
+#include "sysemu/vhost-user-backend.h"
 
 /* - */
 /* virtio input protocol */
@@ -42,11 +43,18 @@ typedef struct virtio_input_event virtio_input_event;
 #define VIRTIO_INPUT_HOST_GET_PARENT_CLASS(obj) \
 OBJECT_GET_PARENT_CLASS(obj, TYPE_VIRTIO_INPUT_HOST)
 
+#define TYPE_VHOST_USER_INPUT   "vhost-user-input"
+#define VHOST_USER_INPUT(obj)  \
+OBJECT_CHECK(VHostUserInput, (obj), TYPE_VHOST_USER_INPUT)
+#define VHOST_USER_INPUT_GET_PARENT_CLASS(obj) \
+OBJECT_GET_PARENT_CLASS(obj, TYPE_VHOST_USER_INPUT)
+
 typedef struct VirtIOInput VirtIOInput;
 typedef struct VirtIOInputClass VirtIOInputClass;
 typedef struct VirtIOInputConfig VirtIOInputConfig;
 typedef struct VirtIOInputHID VirtIOInputHID;
 typedef struct VirtIOInputHost VirtIOInputHost;
+typedef struct VHostUserInput VHostUserInput;
 
 struct VirtIOInputConfig {
 virtio_input_config   config;
@@ -98,6 +106,12 @@ struct VirtIOInputHost {
 int   fd;
 };
 
+struct VHostUserInput {
+VirtIOInput   parent_obj;
+
+VhostUserBackend  *vhost;
+};
+
 void virtio_input_send(VirtIOInput *vinput, virtio_input_event *event);
 void virtio_input_init_config(VirtIOInput *vinput,
   virtio_input_config *config);
diff --git a/hw/input/vhost-user-input.c b/hw/input/vhost-user-input.c
new file mode 100644
index ..6da497b1a8a9
--- /dev/null
+++ b/hw/input/vhost-user-input.c
@@ -0,0 +1,129 @@
+/*
+ * 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/error-report.h"
+#include "qapi/error.h"
+#include "qemu-common.h"
+
+#include "hw/qdev.h"
+#include "hw/virtio/virtio-input.h"
+
+static int vhost_input_config_change(struct vhost_dev *dev)
+{
+error_report("vhost-user-input: unhandled backend config change");
+return -1;
+}
+
+static const VhostDevConfigOps config_ops = {
+.vhost_dev_config_notifier = vhost_input_config_change,
+};
+
+static void vhost_input_realize(DeviceState *dev, Error **errp)
+{
+VHostUserInput *vhi = VHOST_USER_INPUT(dev);
+VirtIOInput *vinput = VIRTIO_INPUT(dev);
+VirtIODevice *vdev = VIRTIO_DEVICE(dev);
+
+vhost_dev_set_config_notifier(&vhi->vhost->dev, &config_ops);
+vinput->cfg_size = sizeof_field(virtio_input_config, u);
+if (vhost_user_backend_dev_init(vhi->vhost, vdev, 2, errp) == -1) {
+return;
+}
+}
+
+static void vhost_input_change_active(VirtIOInput *vinput)
+{
+VHostUserInput *vhi = VHOST_USER_INPUT(vinput);
+
+if (vinput->active) {
+vhost_user_backend_start(vhi->vhost);
+} else {
+vhost_user_backend_stop(vhi->vhost);
+}
+}
+
+static void vhost_input_get_config(VirtIODevice *vdev, uint8_t *config_data)
+{
+VirtIOInput *vinput = VIRTIO_INPUT(vdev);
+VHostUserInput *vhi = VHOST_USER_INPUT(vdev);
+int ret;
+
+memset(config_data, 0, vinput->cfg_size);
+
+ret = vhost_dev_get_config(&vhi->vhost->dev, config_data, 
vinput->cfg_size);
+if (ret) {
+error_report("vhost-user-input: get device config space failed");
+return;
+}
+}
+
+static void vhost_input_set_config(VirtIODevice *vdev,
+   const uint8_t *config_data)
+{
+VHostUserInput *vhi = VHOST_USER_INPUT(vdev);
+int ret;
+
+ret = vhost_dev_set_config(&vhi->vhost->dev, config_data,
+   0, sizeof(v

[Qemu-devel] [PULL 3/7] Add vhost-user-backend

From: Marc-André Lureau 

Create a vhost-user-backend object that holds a connection to a
vhost-user backend (or "slave" process) and can be referenced from
virtio devices that support it. See later patches for input & gpu
usage.

Note: a previous iteration of this object made it user-creatable, and
allowed managed sub-process spawning, but that has been dropped for
now.

Signed-off-by: Marc-André Lureau 
Message-id: 20190503130034.24916-4-marcandre.lur...@redhat.com
Signed-off-by: Gerd Hoffmann 
---
 include/sysemu/vhost-user-backend.h |  57 
 backends/vhost-user.c   | 209 
 MAINTAINERS |   2 +
 backends/Makefile.objs  |   2 +
 4 files changed, 270 insertions(+)
 create mode 100644 include/sysemu/vhost-user-backend.h
 create mode 100644 backends/vhost-user.c

diff --git a/include/sysemu/vhost-user-backend.h 
b/include/sysemu/vhost-user-backend.h
new file mode 100644
index ..9abf8f06a1b9
--- /dev/null
+++ b/include/sysemu/vhost-user-backend.h
@@ -0,0 +1,57 @@
+/*
+ * QEMU vhost-user backend
+ *
+ * Copyright (C) 2018 Red Hat Inc
+ *
+ * Authors:
+ *  Marc-André Lureau 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+#ifndef QEMU_VHOST_USER_BACKEND_H
+#define QEMU_VHOST_USER_BACKEND_H
+
+#include "qom/object.h"
+#include "exec/memory.h"
+#include "qemu/option.h"
+#include "qemu/bitmap.h"
+#include "hw/virtio/vhost.h"
+#include "hw/virtio/vhost-user.h"
+#include "chardev/char-fe.h"
+#include "io/channel.h"
+
+#define TYPE_VHOST_USER_BACKEND "vhost-user-backend"
+#define VHOST_USER_BACKEND(obj) \
+OBJECT_CHECK(VhostUserBackend, (obj), TYPE_VHOST_USER_BACKEND)
+#define VHOST_USER_BACKEND_GET_CLASS(obj) \
+OBJECT_GET_CLASS(VhostUserBackendClass, (obj), TYPE_VHOST_USER_BACKEND)
+#define VHOST_USER_BACKEND_CLASS(klass) \
+OBJECT_CLASS_CHECK(VhostUserBackendClass, (klass), TYPE_VHOST_USER_BACKEND)
+
+typedef struct VhostUserBackend VhostUserBackend;
+typedef struct VhostUserBackendClass VhostUserBackendClass;
+
+struct VhostUserBackendClass {
+ObjectClass parent_class;
+};
+
+struct VhostUserBackend {
+/* private */
+Object parent;
+
+char *chr_name;
+CharBackend chr;
+VhostUserState vhost_user;
+struct vhost_dev dev;
+VirtIODevice *vdev;
+bool started;
+bool completed;
+};
+
+int vhost_user_backend_dev_init(VhostUserBackend *b, VirtIODevice *vdev,
+unsigned nvqs, Error **errp);
+void vhost_user_backend_start(VhostUserBackend *b);
+void vhost_user_backend_stop(VhostUserBackend *b);
+
+#endif
diff --git a/backends/vhost-user.c b/backends/vhost-user.c
new file mode 100644
index ..2b055544a739
--- /dev/null
+++ b/backends/vhost-user.c
@@ -0,0 +1,209 @@
+/*
+ * QEMU vhost-user backend
+ *
+ * Copyright (C) 2018 Red Hat Inc
+ *
+ * Authors:
+ *  Marc-André Lureau 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+
+#include "qemu/osdep.h"
+#include "hw/qdev.h"
+#include "qapi/error.h"
+#include "qapi/qmp/qerror.h"
+#include "qemu/error-report.h"
+#include "qom/object_interfaces.h"
+#include "sysemu/vhost-user-backend.h"
+#include "sysemu/kvm.h"
+#include "io/channel-command.h"
+#include "hw/virtio/virtio-bus.h"
+
+static bool
+ioeventfd_enabled(void)
+{
+return kvm_enabled() && kvm_eventfds_enabled();
+}
+
+int
+vhost_user_backend_dev_init(VhostUserBackend *b, VirtIODevice *vdev,
+unsigned nvqs, Error **errp)
+{
+int ret;
+
+assert(!b->vdev && vdev);
+
+if (!ioeventfd_enabled()) {
+error_setg(errp, "vhost initialization failed: requires kvm");
+return -1;
+}
+
+if (!vhost_user_init(&b->vhost_user, &b->chr, errp)) {
+return -1;
+}
+
+b->vdev = vdev;
+b->dev.nvqs = nvqs;
+b->dev.vqs = g_new(struct vhost_virtqueue, nvqs);
+
+ret = vhost_dev_init(&b->dev, &b->vhost_user, VHOST_BACKEND_TYPE_USER, 0);
+if (ret < 0) {
+error_setg_errno(errp, -ret, "vhost initialization failed");
+return -1;
+}
+
+return 0;
+}
+
+void
+vhost_user_backend_start(VhostUserBackend *b)
+{
+BusState *qbus = BUS(qdev_get_parent_bus(DEVICE(b->vdev)));
+VirtioBusClass *k = VIRTIO_BUS_GET_CLASS(qbus);
+int ret, i ;
+
+if (b->started) {
+return;
+}
+
+if (!k->set_guest_notifiers) {
+error_report("binding does not support guest notifiers");
+return;
+}
+
+ret = vhost_dev_enable_notifiers(&b->dev, b->vdev);
+if (ret < 0) {
+return;
+}
+
+ret = k->set_guest_notifiers(qbus->parent, b->dev.nvqs, true);
+if (ret < 0) {
+error_report("Error binding guest notifier");
+goto err_host_notifiers;
+}
+
+b->dev.acked_features = b->vdev->guest_features;
+ret = vhost_dev_

[Qemu-devel] [PULL 6/7] virtio-input-host-pci: cleanup types

virtio input is virtio-1.0 only, so we don't need the -transitional and
-non-transitional variants.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Marc-André Lureau 
Message-id: 20190510105137.17481-1-kra...@redhat.com
---
 hw/virtio/virtio-input-host-pci.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/hw/virtio/virtio-input-host-pci.c 
b/hw/virtio/virtio-input-host-pci.c
index 725a51ad30b4..124c4f344742 100644
--- a/hw/virtio/virtio-input-host-pci.c
+++ b/hw/virtio/virtio-input-host-pci.c
@@ -13,7 +13,7 @@
 
 typedef struct VirtIOInputHostPCI VirtIOInputHostPCI;
 
-#define TYPE_VIRTIO_INPUT_HOST_PCI "virtio-input-host-pci-base"
+#define TYPE_VIRTIO_INPUT_HOST_PCI "virtio-input-host-pci"
 #define VIRTIO_INPUT_HOST_PCI(obj) \
 OBJECT_CHECK(VirtIOInputHostPCI, (obj), TYPE_VIRTIO_INPUT_HOST_PCI)
 
@@ -31,10 +31,7 @@ static void virtio_host_initfn(Object *obj)
 }
 
 static const VirtioPCIDeviceTypeInfo virtio_input_host_pci_info = {
-.base_name = TYPE_VIRTIO_INPUT_HOST_PCI,
-.generic_name  = "virtio-input-host-pci",
-.transitional_name = "virtio-input-host-pci-transitional",
-.non_transitional_name = "virtio-input-host-pci-non-transitional",
+.generic_name  = TYPE_VIRTIO_INPUT_HOST_PCI,
 .parent= TYPE_VIRTIO_INPUT_PCI,
 .instance_size = sizeof(VirtIOInputHostPCI),
 .instance_init = virtio_host_initfn,
-- 
2.18.1

[Qemu-devel] [PULL 2/7] libvhost-user: add PROTOCOL_F_CONFIG if {set, get}_config

From: Marc-André Lureau 

Add the config protocol feature bit if the set_config & get_config
callbacks are implemented.

Signed-off-by: Marc-André Lureau 
Message-id: 20190503130034.24916-3-marcandre.lur...@redhat.com
Signed-off-by: Gerd Hoffmann 
---
 contrib/libvhost-user/libvhost-user.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/contrib/libvhost-user/libvhost-user.c 
b/contrib/libvhost-user/libvhost-user.c
index dcf4a969f238..74d42177c5c8 100644
--- a/contrib/libvhost-user/libvhost-user.c
+++ b/contrib/libvhost-user/libvhost-user.c
@@ -1157,6 +1157,10 @@ vu_get_protocol_features_exec(VuDev *dev, VhostUserMsg 
*vmsg)
 features |= 1ULL << VHOST_USER_PROTOCOL_F_PAGEFAULT;
 }
 
+if (dev->iface->get_config && dev->iface->set_config) {
+features |= 1ULL << VHOST_USER_PROTOCOL_F_CONFIG;
+}
+
 if (dev->iface->get_protocol_features) {
 features |= dev->iface->get_protocol_features(dev);
 }
-- 
2.18.1

[Qemu-devel] [PULL 1/7] libvhost-user: fix -Waddress-of-packed-member

From: Marc-André Lureau 

/home/elmarco/src/qemu/contrib/libvhost-user/libvhost-user.c: In function 
‘vu_set_mem_table_exec_postcopy’:
/home/elmarco/src/qemu/contrib/libvhost-user/libvhost-user.c:546:31: warning: 
taking address of packed member of ‘struct VhostUserMsg’ may result in an 
unaligned pointer value [-Waddress-of-packed-member]
  546 | VhostUserMemory *memory = &vmsg->payload.memory;
  |   ^
/home/elmarco/src/qemu/contrib/libvhost-user/libvhost-user.c: In function 
‘vu_set_mem_table_exec’:
/home/elmarco/src/qemu/contrib/libvhost-user/libvhost-user.c:688:31: warning: 
taking address of packed member of ‘struct VhostUserMsg’ may result in an 
unaligned pointer value [-Waddress-of-packed-member]
  688 | VhostUserMemory *memory = &vmsg->payload.memory;
  |   ^
/home/elmarco/src/qemu/contrib/libvhost-user/libvhost-user.c: In function 
‘vu_set_vring_addr_exec’:
/home/elmarco/src/qemu/contrib/libvhost-user/libvhost-user.c:817:36: warning: 
taking address of packed member of ‘struct VhostUserMsg’ may result in an 
unaligned pointer value [-Waddress-of-packed-member]
  817 | struct vhost_vring_addr *vra = &vmsg->payload.addr;
  |^~~

Signed-off-by: Marc-André Lureau 
Message-id: 20190503130034.24916-2-marcandre.lur...@redhat.com
Signed-off-by: Gerd Hoffmann 
---
 contrib/libvhost-user/libvhost-user.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/contrib/libvhost-user/libvhost-user.c 
b/contrib/libvhost-user/libvhost-user.c
index e08d6c7b9741..dcf4a969f238 100644
--- a/contrib/libvhost-user/libvhost-user.c
+++ b/contrib/libvhost-user/libvhost-user.c
@@ -542,7 +542,7 @@ static bool
 vu_set_mem_table_exec_postcopy(VuDev *dev, VhostUserMsg *vmsg)
 {
 int i;
-VhostUserMemory *memory = &vmsg->payload.memory;
+VhostUserMemory m = vmsg->payload.memory, *memory = &m;
 dev->nregions = memory->nregions;
 
 DPRINT("Nregions: %d\n", memory->nregions);
@@ -684,7 +684,7 @@ static bool
 vu_set_mem_table_exec(VuDev *dev, VhostUserMsg *vmsg)
 {
 int i;
-VhostUserMemory *memory = &vmsg->payload.memory;
+VhostUserMemory m = vmsg->payload.memory, *memory = &m;
 
 for (i = 0; i < dev->nregions; i++) {
 VuDevRegion *r = &dev->regions[i];
@@ -813,7 +813,7 @@ vu_set_vring_num_exec(VuDev *dev, VhostUserMsg *vmsg)
 static bool
 vu_set_vring_addr_exec(VuDev *dev, VhostUserMsg *vmsg)
 {
-struct vhost_vring_addr *vra = &vmsg->payload.addr;
+struct vhost_vring_addr addr = vmsg->payload.addr, *vra = &addr;
 unsigned int index = vra->index;
 VuVirtq *vq = &dev->vq[index];
 
-- 
2.18.1

[Qemu-devel] [PULL 0/7] Input 20190513 v2 patches

The following changes since commit 812b835fb4d23dd108b2f9802158472d50b73579:

  Merge remote-tracking branch 'remotes/maxreitz/tags/pull-block-2019-05-07' 
into staging (2019-05-09 16:31:12 +0100)

are available in the Git repository at:

  git://git.kraxel.org/qemu tags/input-20190513-v2-pull-request

for you to fetch changes up to 503591cb6c28c3ddbe38ea50cab2f0dd3d6cd929:

  virtio-input: fix Kconfig dependency and Makefile (2019-05-13 08:49:30 +0200)


input: add vhost-user-input, virtio-input fixes.



Gerd Hoffmann (2):
  virtio-input-host-pci: cleanup types
  virtio-input: fix Kconfig dependency and Makefile

Marc-André Lureau (5):
  libvhost-user: fix -Waddress-of-packed-member
  libvhost-user: add PROTOCOL_F_CONFIG if {set, get}_config
  Add vhost-user-backend
  Add vhost-user-input-pci
  util: simplify unix_listen()

 include/hw/virtio/virtio-input.h  |  14 ++
 include/sysemu/vhost-user-backend.h   |  57 +++
 backends/vhost-user.c | 209 ++
 contrib/libvhost-user/libvhost-user.c |  10 +-
 hw/input/vhost-user-input.c   | 129 
 hw/virtio/vhost-user-input-pci.c  |  50 ++
 hw/virtio/virtio-input-host-pci.c |   7 +-
 util/qemu-sockets.c   |  18 +--
 MAINTAINERS   |   3 +
 backends/Makefile.objs|   2 +
 hw/input/Kconfig  |   7 +-
 hw/input/Makefile.objs|   5 +-
 hw/virtio/Makefile.objs   |   1 +
 13 files changed, 484 insertions(+), 28 deletions(-)
 create mode 100644 include/sysemu/vhost-user-backend.h
 create mode 100644 backends/vhost-user.c
 create mode 100644 hw/input/vhost-user-input.c
 create mode 100644 hw/virtio/vhost-user-input-pci.c

-- 
2.18.1

[Qemu-devel] [PULL 7/7] virtio-input: fix Kconfig dependency and Makefile

Make VIRTIO_INPUT_HOST depend on VIRTIO_INPUT.
Use CONFIG_VIRTIO_INPUT_HOST in Makefile.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Marc-André Lureau 
Message-id: 20190510105137.17481-2-kra...@redhat.com
---
 hw/input/Kconfig   | 2 +-
 hw/input/Makefile.objs | 4 +---
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/hw/input/Kconfig b/hw/input/Kconfig
index 50e55e353847..889363d8aef1 100644
--- a/hw/input/Kconfig
+++ b/hw/input/Kconfig
@@ -27,7 +27,7 @@ config VIRTIO_INPUT
 config VIRTIO_INPUT_HOST
 bool
 default y
-depends on VIRTIO && LINUX
+depends on VIRTIO_INPUT && LINUX
 
 config VHOST_USER_INPUT
 bool
diff --git a/hw/input/Makefile.objs b/hw/input/Makefile.objs
index 3eddf00f2bba..d1de30770854 100644
--- a/hw/input/Makefile.objs
+++ b/hw/input/Makefile.objs
@@ -9,9 +9,7 @@ common-obj-$(CONFIG_TSC2005) += tsc2005.o
 
 common-obj-$(CONFIG_VIRTIO_INPUT) += virtio-input.o
 common-obj-$(CONFIG_VIRTIO_INPUT) += virtio-input-hid.o
-ifeq ($(CONFIG_LINUX),y)
-common-obj-$(CONFIG_VIRTIO_INPUT) += virtio-input-host.o
-endif
+common-obj-$(CONFIG_VIRTIO_INPUT_HOST) += virtio-input-host.o
 common-obj-$(CONFIG_VHOST_USER_INPUT) += vhost-user-input.o
 
 obj-$(CONFIG_MILKYMIST) += milkymist-softusb.o
-- 
2.18.1

Re: [Qemu-devel] [PULL 0/8] Input 20190510 patches

> Hi; there are some compile failures here I'm afraid:
> 
> On ppc64:
> 
> /home/pm215/qemu/contrib/libvhost-user/libvhost-user.c: In function
> ‘vu_set_mem_table_exec_postcopy’:
> /home/pm215/qemu/contrib/libvhost-user/libvhost-user.c:666:9: error:
> format ‘%llx’ expects argument of type ‘long long unsigned int’, but
> argument 5 has type ‘__u64’ [-Werror=format=]
>  DPRINT("%s: region %d: Registered userfault for %llx + %llx\n",
>  ^
> /home/pm215/qemu/contrib/libvhost-user/libvhost-user.c:666:9: error:
> format ‘%llx’ expects argument of type ‘long long unsigned int’, but
> argument 6 has type ‘__u64’ [-Werror=format=]
> cc1: all warnings being treated as errors
> 
> On arm (and probably any 32-bit host):
> 
> /home/peter.maydell/qemu/contrib/libvhost-user/libvhost-user.c: In
> function 'vu_set_mem_table_exec_postcopy':
> /home/peter.maydell/qemu/contrib/libvhost-user/libvhost-user.c:624:23:
> error: cast to pointer from integer of different size
> [-Werror=int-to-pointer-cast]
>  ret = madvise((void *)dev_region->mmap_addr,
>^
> /home/peter.maydell/qemu/contrib/libvhost-user/libvhost-user.c:636:23:
> error: cast to pointer from integer of different size
> [-Werror=int-to-pointer-cast]
>  ret = madvise((void *)dev_region->mmap_addr,
>^
> /home/peter.maydell/qemu/contrib/libvhost-user/libvhost-user.c:669:22:
> error: cast to pointer from integer of different size
> [-Werror=int-to-pointer-cast]
>  if (mprotect((void *)dev_region->mmap_addr,
>   ^

Patch #6 dropped, v2 sent.

cheers,
  Gerd

Re: [Qemu-devel] [qemu-s390x] [PULL SUBSYSTEM s390x 2/3] s390-bios: Skip bootmap signature entries

2019-05-13 Thread Cornelia Huck

On Sat, 11 May 2019 08:15:21 +0200
Thomas Huth  wrote:

> On 10/05/2019 15.59, Christian Borntraeger wrote:
> > Shall we cc stable this?  
> 
> I think I'd rather not do it unless someone really speaks up that they
> urgently need it. If we could use the binary from the master branch, I'd
> say go for it, but in this case we'd need to build a separate
> s390-ccw.img for this (without the DASD passthrough patches), and since
> the stable branch does not get that much testing attention from all the
> s390x developers, you'd end up with a firmware binary in the stable
> branch that is not very well tested... This does not sound very
> appealing to me.

FWIW, I have rebuilt the bios for the stable tree in the past, when a
bios patch had been picked. In this case, however, I would need to rely
on someone else to sanity-check the binary.

How likely are folks to run -stable QEMU with a bootmap containing
signatures? It would be one more QEMU version with toleration for this,
but I expect distros to pick up this one anyway?

Re: [Qemu-devel] [qemu-s390x] [PULL SUBSYSTEM s390x 2/3] s390-bios: Skip bootmap signature entries




On 13.05.19 09:42, Cornelia Huck wrote:
> On Sat, 11 May 2019 08:15:21 +0200
> Thomas Huth  wrote:
> 
>> On 10/05/2019 15.59, Christian Borntraeger wrote:
>>> Shall we cc stable this?  
>>
>> I think I'd rather not do it unless someone really speaks up that they
>> urgently need it. If we could use the binary from the master branch, I'd
>> say go for it, but in this case we'd need to build a separate
>> s390-ccw.img for this (without the DASD passthrough patches), and since
>> the stable branch does not get that much testing attention from all the
>> s390x developers, you'd end up with a firmware binary in the stable
>> branch that is not very well tested... This does not sound very
>> appealing to me.
> 
> FWIW, I have rebuilt the bios for the stable tree in the past, when a
> bios patch had been picked. In this case, however, I would need to rely
> on someone else to sanity-check the binary.
> 
> How likely are folks to run -stable QEMU with a bootmap containing
> signatures? It would be one more QEMU version with toleration for this,
> but I expect distros to pick up this one anyway?

Yes, I will try to push this into distros. I usually try to push things also
to stable, but this might be more important for the kernel.

Re: [Qemu-devel] [PATCH v4] s390: diagnose 318 info reset and migration support

On 02.05.19 00:31, Collin Walling wrote:
> DIAGNOSE 0x318 (diag318) is a privileged s390x instruction that must
> be intercepted by SIE and handled via KVM. Let's introduce some
> functions to communicate between QEMU and KVM via ioctls. These
> will be used to get/set the diag318 related information (also known
> as the "Control Program Code" or "CPC"), as well as check the system
> if KVM supports handling this instruction.
> 
> The availability of this instruction is determined by byte 134, bit 0
> of the Read Info block. This coincidentally expands into the space used
> for CPU entries, which means VMs running with the diag318 capability
> will have a reduced maximum CPU count. To alleviate this, let's calculate
> the actual max CPU entry space by subtracting the size of Read Info from
> the SCCB size then dividing that number by the size of a CPU entry. If
> this value is less than the value denoted by S390_MAX_CPUS, then let's
> reduce the max cpus for s390 from 248 to 240 in an effort to anticipate
> this potentially happening again in the future.
> 
> In order to simplify the migration and system reset requirements of
> the diag318 data, let's introduce it as a device class and include
> a VMStateDescription.
> 
> Diag318 is reset on during modified clear and load normal.
> 
> Signed-off-by: Collin Walling 
> ---
>  hw/s390x/Makefile.objs   |   1 +
>  hw/s390x/diag318.c   | 100 
> +++
>  hw/s390x/diag318.h   |  39 +
>  hw/s390x/s390-virtio-ccw.c   |  23 ++
>  hw/s390x/sclp.c  |   5 +++
>  include/hw/s390x/sclp.h  |   2 +
>  linux-headers/asm-s390/kvm.h |   4 ++
>  target/s390x/kvm-stub.c  |  15 +++
>  target/s390x/kvm.c   |  32 ++
>  target/s390x/kvm_s390x.h |   3 ++
>  10 files changed, 224 insertions(+)
>  create mode 100644 hw/s390x/diag318.c
>  create mode 100644 hw/s390x/diag318.h
> 
> diff --git a/hw/s390x/Makefile.objs b/hw/s390x/Makefile.objs
> index e02ed80..93621dc 100644
> --- a/hw/s390x/Makefile.objs
> +++ b/hw/s390x/Makefile.objs
> @@ -34,3 +34,4 @@ obj-$(CONFIG_KVM) += s390-stattrib-kvm.o
>  obj-y += s390-ccw.o
>  obj-y += ap-device.o
>  obj-y += ap-bridge.o
> +obj-y += diag318.o
> diff --git a/hw/s390x/diag318.c b/hw/s390x/diag318.c
> new file mode 100644
> index 000..94b44da
> --- /dev/null
> +++ b/hw/s390x/diag318.c
> @@ -0,0 +1,100 @@
> +/*
> + * DIAGNOSE 0x318 functions for reset and migration
> + *
> + * Copyright IBM, Corp. 2019
> + *
> + * Authors:
> + *  Collin Walling 
> + *
> + * 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 "hw/s390x/diag318.h"
> +#include "qapi/error.h"
> +#include "kvm_s390x.h"
> +#include "sysemu/kvm.h"
> +
> +static int diag318_post_load(void *opaque, int version_id)
> +{
> +DIAG318State *d = opaque;
> +
> +kvm_s390_set_cpc(d->cpc);
> +
> +/* It is not necessary to retain a copy of the cpc after migration. */
> +d->cpc = 0;
> +
> +return 0;
> +}
> +
> +static int diag318_pre_save(void *opaque)
> +{
> +DIAG318State *d = opaque;
> +
> +kvm_s390_get_cpc(&d->cpc);
> +return 0;
> +}
> +
> +static bool diag318_needed(void *opaque)
> +{
> +DIAG318State *d = opaque;
> +
> +return d->enabled;
> +}
> +
> +const VMStateDescription vmstate_diag318 = {
> +.name = "vmstate_diag318",
> +.post_load = diag318_post_load,
> +.pre_save = diag318_pre_save,
> +.version_id = 1,
> +.minimum_version_id = 1,
> +.needed = diag318_needed,
> +.fields = (VMStateField[]) {
> +VMSTATE_UINT64(cpc, DIAG318State),
> +VMSTATE_END_OF_LIST()
> +}
> +};
> +
> +static void s390_diag318_realize(DeviceState *dev, Error **errp)
> +{
> +DIAG318State *d = DIAG318(dev);
> +
> +if (kvm_s390_has_diag318()) {
> +d->enabled = true;
> +}
> +}
> +
> +static void s390_diag318_reset(DeviceState *dev)
> +{
> +DIAG318State *d = DIAG318(dev);
> +
> +if (d->enabled) {
> +kvm_s390_set_cpc(0);
> +}
> +}
> +
> +static void s390_diag318_class_init(ObjectClass *klass, void *data)
> +{
> +DeviceClass *dc = DEVICE_CLASS(klass);
> +
> +dc->realize = s390_diag318_realize;
> +dc->reset = s390_diag318_reset;
> +dc->vmsd = &vmstate_diag318;
> +dc->hotpluggable = false;
> +/* Reason: Set automatically during IPL */
> +dc->user_creatable = false;
> +}
> +
> +static const TypeInfo s390_diag318_info = {
> +.class_init = s390_diag318_class_init,
> +.parent = TYPE_DEVICE,
> +.name = TYPE_S390_DIAG318,
> +.instance_size = sizeof(DIAG318State),
> +};
> +
> +static void s390_diag318_register_types(void)
> +{
> +type_register_static(&s390_diag318_info);
> +}
> +
> +type_init(s390_diag318_register_types)
> diff --git a/hw/s390x/diag318.h b/hw/s390x/diag318.h
> new file mode 100644
> inde

Re: [Qemu-devel] [qemu-s390x] [PULL SUBSYSTEM s390x 2/3] s390-bios: Skip bootmap signature entries

2019-05-13 Thread Cornelia Huck

On Mon, 13 May 2019 09:44:37 +0200
Christian Borntraeger  wrote:

> On 13.05.19 09:42, Cornelia Huck wrote:
> > On Sat, 11 May 2019 08:15:21 +0200
> > Thomas Huth  wrote:
> >   
> >> On 10/05/2019 15.59, Christian Borntraeger wrote:  
> >>> Shall we cc stable this?
> >>
> >> I think I'd rather not do it unless someone really speaks up that they
> >> urgently need it. If we could use the binary from the master branch, I'd
> >> say go for it, but in this case we'd need to build a separate
> >> s390-ccw.img for this (without the DASD passthrough patches), and since
> >> the stable branch does not get that much testing attention from all the
> >> s390x developers, you'd end up with a firmware binary in the stable
> >> branch that is not very well tested... This does not sound very
> >> appealing to me.  
> > 
> > FWIW, I have rebuilt the bios for the stable tree in the past, when a
> > bios patch had been picked. In this case, however, I would need to rely
> > on someone else to sanity-check the binary.
> > 
> > How likely are folks to run -stable QEMU with a bootmap containing
> > signatures? It would be one more QEMU version with toleration for this,
> > but I expect distros to pick up this one anyway?  
> 
> Yes, I will try to push this into distros. I usually try to push things also
> to stable, but this might be more important for the kernel.
> 

Yes, while the QEMU stable branch is useful, the kernel stable
backports cover a lot more.

Re: [Qemu-devel] [Qemu-block] [PATCH] nbd/server: Nicer spelling of max BLOCK_STATUS reply length

2019-05-13 Thread Stefano Garzarella

On Fri, May 10, 2019 at 10:17:35AM -0500, Eric Blake wrote:
> Commit 3d068aff (3.0) introduced NBD_MAX_BITMAP_EXTENTS as a limit on
> how large we would allow a reply to NBD_CMD_BLOCK_STATUS to grow when
> it is visiting a qemu:dirty-bitmap: context.  Later, commit fb7afc79
> (3.1) reused the constant to limit base:allocation context replies,
> although the name is now less appropriate in that situation.
> 
> Rename things, and improve the macro to use units.h for better
> legibility. Then reformat the comment to comply with checkpatch rules
> added in the meantime. No semantic change.
> 
> Signed-off-by: Eric Blake 
> ---
>  nbd/server.c | 13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/nbd/server.c b/nbd/server.c
> index e21bd501dc6..2c49744fc43 100644
> --- a/nbd/server.c
> +++ b/nbd/server.c
> @@ -21,15 +21,18 @@
>  #include "qapi/error.h"
>  #include "trace.h"
>  #include "nbd-internal.h"
> +#include "qemu/units.h"
> 
>  #define NBD_META_ID_BASE_ALLOCATION 0
>  #define NBD_META_ID_DIRTY_BITMAP 1
> 
> -/* NBD_MAX_BITMAP_EXTENTS: 1 mb of extents data. An empirical
> +/*
> + * NBD_MAX_BLOCK_STATUS_EXTENTS: 1 mb of extents data. An empirical

Since we are here, what about using MiB also in this comment block?

>   * constant. If an increase is needed, note that the NBD protocol
>   * recommends no larger than 32 mb, so that the client won't consider
> - * the reply as a denial of service attack. */
> -#define NBD_MAX_BITMAP_EXTENTS (0x10 / 8)
> + * the reply as a denial of service attack.
> + */
> +#define NBD_MAX_BLOCK_STATUS_EXTENTS (1 * MiB / 8)
> 
>  static int system_errno_to_nbd_errno(int err)
>  {
> @@ -1958,7 +1961,7 @@ static int nbd_co_send_block_status(NBDClient *client, 
> uint64_t handle,
>  Error **errp)
>  {
>  int ret;
> -unsigned int nb_extents = dont_fragment ? 1 : NBD_MAX_BITMAP_EXTENTS;
> +unsigned int nb_extents = dont_fragment ? 1 : 
> NBD_MAX_BLOCK_STATUS_EXTENTS;
>  NBDExtent *extents = g_new(NBDExtent, nb_extents);
>  uint64_t final_length = length;
> 
> @@ -2043,7 +2046,7 @@ static int nbd_co_send_bitmap(NBDClient *client, 
> uint64_t handle,
>uint32_t context_id, Error **errp)
>  {
>  int ret;
> -unsigned int nb_extents = dont_fragment ? 1 : NBD_MAX_BITMAP_EXTENTS;
> +unsigned int nb_extents = dont_fragment ? 1 : 
> NBD_MAX_BLOCK_STATUS_EXTENTS;
>  NBDExtent *extents = g_new(NBDExtent, nb_extents);
>  uint64_t final_length = length;

With or without changing the comment:

Reviewed-by: Stefano Garzarella

Re: [Qemu-devel] [PATCH v4] s390: diagnose 318 info reset and migration support

On 13.05.19 09:46, David Hildenbrand wrote:
> On 02.05.19 00:31, Collin Walling wrote:
>> DIAGNOSE 0x318 (diag318) is a privileged s390x instruction that must
>> be intercepted by SIE and handled via KVM. Let's introduce some
>> functions to communicate between QEMU and KVM via ioctls. These
>> will be used to get/set the diag318 related information (also known
>> as the "Control Program Code" or "CPC"), as well as check the system
>> if KVM supports handling this instruction.
>>
>> The availability of this instruction is determined by byte 134, bit 0
>> of the Read Info block. This coincidentally expands into the space used
>> for CPU entries, which means VMs running with the diag318 capability
>> will have a reduced maximum CPU count. To alleviate this, let's calculate
>> the actual max CPU entry space by subtracting the size of Read Info from
>> the SCCB size then dividing that number by the size of a CPU entry. If
>> this value is less than the value denoted by S390_MAX_CPUS, then let's
>> reduce the max cpus for s390 from 248 to 240 in an effort to anticipate
>> this potentially happening again in the future.
>>
>> In order to simplify the migration and system reset requirements of
>> the diag318 data, let's introduce it as a device class and include
>> a VMStateDescription.
>>
>> Diag318 is reset on during modified clear and load normal.
>>
>> Signed-off-by: Collin Walling 
>> ---
>>  hw/s390x/Makefile.objs   |   1 +
>>  hw/s390x/diag318.c   | 100 
>> +++
>>  hw/s390x/diag318.h   |  39 +
>>  hw/s390x/s390-virtio-ccw.c   |  23 ++
>>  hw/s390x/sclp.c  |   5 +++
>>  include/hw/s390x/sclp.h  |   2 +
>>  linux-headers/asm-s390/kvm.h |   4 ++
>>  target/s390x/kvm-stub.c  |  15 +++
>>  target/s390x/kvm.c   |  32 ++
>>  target/s390x/kvm_s390x.h |   3 ++
>>  10 files changed, 224 insertions(+)
>>  create mode 100644 hw/s390x/diag318.c
>>  create mode 100644 hw/s390x/diag318.h
>>
>> diff --git a/hw/s390x/Makefile.objs b/hw/s390x/Makefile.objs
>> index e02ed80..93621dc 100644
>> --- a/hw/s390x/Makefile.objs
>> +++ b/hw/s390x/Makefile.objs
>> @@ -34,3 +34,4 @@ obj-$(CONFIG_KVM) += s390-stattrib-kvm.o
>>  obj-y += s390-ccw.o
>>  obj-y += ap-device.o
>>  obj-y += ap-bridge.o
>> +obj-y += diag318.o
>> diff --git a/hw/s390x/diag318.c b/hw/s390x/diag318.c
>> new file mode 100644
>> index 000..94b44da
>> --- /dev/null
>> +++ b/hw/s390x/diag318.c
>> @@ -0,0 +1,100 @@
>> +/*
>> + * DIAGNOSE 0x318 functions for reset and migration
>> + *
>> + * Copyright IBM, Corp. 2019
>> + *
>> + * Authors:
>> + *  Collin Walling 
>> + *
>> + * 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 "hw/s390x/diag318.h"
>> +#include "qapi/error.h"
>> +#include "kvm_s390x.h"
>> +#include "sysemu/kvm.h"
>> +
>> +static int diag318_post_load(void *opaque, int version_id)
>> +{
>> +DIAG318State *d = opaque;
>> +
>> +kvm_s390_set_cpc(d->cpc);
>> +
>> +/* It is not necessary to retain a copy of the cpc after migration. */
>> +d->cpc = 0;
>> +
>> +return 0;
>> +}
>> +
>> +static int diag318_pre_save(void *opaque)
>> +{
>> +DIAG318State *d = opaque;
>> +
>> +kvm_s390_get_cpc(&d->cpc);
>> +return 0;
>> +}
>> +
>> +static bool diag318_needed(void *opaque)
>> +{
>> +DIAG318State *d = opaque;
>> +
>> +return d->enabled;
>> +}
>> +
>> +const VMStateDescription vmstate_diag318 = {
>> +.name = "vmstate_diag318",
>> +.post_load = diag318_post_load,
>> +.pre_save = diag318_pre_save,
>> +.version_id = 1,
>> +.minimum_version_id = 1,
>> +.needed = diag318_needed,
>> +.fields = (VMStateField[]) {
>> +VMSTATE_UINT64(cpc, DIAG318State),
>> +VMSTATE_END_OF_LIST()
>> +}
>> +};
>> +
>> +static void s390_diag318_realize(DeviceState *dev, Error **errp)
>> +{
>> +DIAG318State *d = DIAG318(dev);
>> +
>> +if (kvm_s390_has_diag318()) {
>> +d->enabled = true;
>> +}
>> +}
>> +
>> +static void s390_diag318_reset(DeviceState *dev)
>> +{
>> +DIAG318State *d = DIAG318(dev);
>> +
>> +if (d->enabled) {
>> +kvm_s390_set_cpc(0);
>> +}
>> +}
>> +
>> +static void s390_diag318_class_init(ObjectClass *klass, void *data)
>> +{
>> +DeviceClass *dc = DEVICE_CLASS(klass);
>> +
>> +dc->realize = s390_diag318_realize;
>> +dc->reset = s390_diag318_reset;
>> +dc->vmsd = &vmstate_diag318;
>> +dc->hotpluggable = false;
>> +/* Reason: Set automatically during IPL */
>> +dc->user_creatable = false;
>> +}
>> +
>> +static const TypeInfo s390_diag318_info = {
>> +.class_init = s390_diag318_class_init,
>> +.parent = TYPE_DEVICE,
>> +.name = TYPE_S390_DIAG318,
>> +.instance_size = sizeof(DIAG318State),
>> +};
>> +
>> +static void s390_diag318_register_types(vo

Re: [Qemu-devel] [PATCH v4 5/5] pci: Fold pci_get_bus_devfn() into its sole caller

On Mon, 13 May 2019 16:19:39 +1000
David Gibson  wrote:

> The only remaining caller of pci_get_bus_devfn() is pci_nic_init_nofail(),
> itself an old compatibility function.  Fold the two together to avoid
> re-using the stale interface.
> 
> While we're there replace the explicit fprintf()s with error_report().
> 
> Signed-off-by: David Gibson 
> ---

Reviewed-by: Greg Kurz 

>  hw/pci/pci.c | 60 
>  1 file changed, 28 insertions(+), 32 deletions(-)
> 
> diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> index 7e5f8d001b..d3893bdfe1 100644
> --- a/hw/pci/pci.c
> +++ b/hw/pci/pci.c
> @@ -723,37 +723,6 @@ static int pci_parse_devaddr(const char *addr, int 
> *domp, int *busp,
>  return 0;
>  }
>  
> -static PCIBus *pci_get_bus_devfn(int *devfnp, PCIBus *root,
> - const char *devaddr)
> -{
> -int dom, bus;
> -unsigned slot;
> -
> -if (!root) {
> -fprintf(stderr, "No primary PCI bus\n");
> -return NULL;
> -}
> -
> -assert(!root->parent_dev);
> -
> -if (!devaddr) {
> -*devfnp = -1;
> -return pci_find_bus_nr(root, 0);
> -}
> -
> -if (pci_parse_devaddr(devaddr, &dom, &bus, &slot, NULL) < 0) {
> -return NULL;
> -}
> -
> -if (dom != 0) {
> -fprintf(stderr, "No support for non-zero PCI domains\n");
> -return NULL;
> -}
> -
> -*devfnp = PCI_DEVFN(slot, 0);
> -return pci_find_bus_nr(root, bus);
> -}
> -
>  static void pci_init_cmask(PCIDevice *dev)
>  {
>  pci_set_word(dev->cmask + PCI_VENDOR_ID, 0x);
> @@ -1895,6 +1864,8 @@ PCIDevice *pci_nic_init_nofail(NICInfo *nd, PCIBus 
> *rootbus,
>  DeviceState *dev;
>  int devfn;
>  int i;
> +int dom, busnr;
> +unsigned slot;
>  
>  if (nd->model && !strcmp(nd->model, "virtio")) {
>  g_free(nd->model);
> @@ -1928,7 +1899,32 @@ PCIDevice *pci_nic_init_nofail(NICInfo *nd, PCIBus 
> *rootbus,
>  exit(1);
>  }
>  
> -bus = pci_get_bus_devfn(&devfn, rootbus, devaddr);
> +if (!rootbus) {
> +error_report("No primary PCI bus");
> +exit(1);
> +}
> +
> +assert(!rootbus->parent_dev);
> +
> +if (!devaddr) {
> +devfn = -1;
> +busnr = 0;
> +} else {
> +if (pci_parse_devaddr(devaddr, &dom, &busnr, &slot, NULL) < 0) {
> +error_report("Invalid PCI device address %s for device %s",
> + devaddr, nd->model);
> +exit(1);
> +}
> +
> +if (dom != 0) {
> +error_report("No support for non-zero PCI domains");
> +exit(1);
> +}
> +
> +devfn = PCI_DEVFN(slot, 0);
> +}
> +
> +bus = pci_find_bus_nr(rootbus, busnr);
>  if (!bus) {
>  error_report("Invalid PCI device address %s for device %s",
>   devaddr, nd->model);

[Qemu-devel] [PULL 5/9] target/xtensa: Clean up core-isa.h header guards

scripts/clean-header-guards.pl warns these headers use reserved
identifier _XTENSA_CORE_CONFIGURATION_H as header guard symbol.  It
additionally warns the guard doesn't match the file name.

Reuse of the same guard symbol in multiple headers is okay as long as
they cannot be included together.

Since we can avoid guard symbol reuse easily, do so: use the guard
symbol scripts/clean-header-guards.pl picks, less the TARGET_ prefix.

Signed-off-by: Markus Armbruster 
Message-Id: <20190315145123.28030-5-arm...@redhat.com>
---
 target/xtensa/core-de212/core-isa.h | 8 +++-
 target/xtensa/core-sample_controller/core-isa.h | 8 +++-
 target/xtensa/core-test_kc705_be/core-isa.h | 8 +++-
 target/xtensa/core-test_mmuhifi_c3/core-isa.h   | 8 +++-
 4 files changed, 12 insertions(+), 20 deletions(-)

diff --git a/target/xtensa/core-de212/core-isa.h 
b/target/xtensa/core-de212/core-isa.h
index 78e7f38310..90ac329230 100644
--- a/target/xtensa/core-de212/core-isa.h
+++ b/target/xtensa/core-de212/core-isa.h
@@ -28,9 +28,8 @@
TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.  */
 
-#ifndef _XTENSA_CORE_CONFIGURATION_H
-#define _XTENSA_CORE_CONFIGURATION_H
-
+#ifndef XTENSA_CORE_DE212_CORE_ISA_H
+#define XTENSA_CORE_DE212_CORE_ISA_H
 
 /
Parameters Useful for Any Code, USER or PRIVILEGED
@@ -618,5 +617,4 @@
 #endif /* !XTENSA_HAL_NON_PRIVILEGED_ONLY */
 
 
-#endif /* _XTENSA_CORE_CONFIGURATION_H */
-
+#endif /* XTENSA_CORE_DE212_CORE_ISA_H */
diff --git a/target/xtensa/core-sample_controller/core-isa.h 
b/target/xtensa/core-sample_controller/core-isa.h
index e681e43209..d53dca8665 100644
--- a/target/xtensa/core-sample_controller/core-isa.h
+++ b/target/xtensa/core-sample_controller/core-isa.h
@@ -28,9 +28,8 @@
TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.  */
 
-#ifndef _XTENSA_CORE_CONFIGURATION_H
-#define _XTENSA_CORE_CONFIGURATION_H
-
+#ifndef XTENSA_CORE_SAMPLE_CONTROLLER_CORE_ISA_H
+#define XTENSA_CORE_SAMPLE_CONTROLLER_CORE_ISA_H
 
 /
Parameters Useful for Any Code, USER or PRIVILEGED
@@ -640,5 +639,4 @@
 #endif /* !XTENSA_HAL_NON_PRIVILEGED_ONLY */
 
 
-#endif /* _XTENSA_CORE_CONFIGURATION_H */
-
+#endif /* XTENSA_CORE_SAMPLE_CONTROLLER_CORE_ISA_H */
diff --git a/target/xtensa/core-test_kc705_be/core-isa.h 
b/target/xtensa/core-test_kc705_be/core-isa.h
index a4ebdf7197..408fed871d 100644
--- a/target/xtensa/core-test_kc705_be/core-isa.h
+++ b/target/xtensa/core-test_kc705_be/core-isa.h
@@ -28,9 +28,8 @@
TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.  */
 
-#ifndef _XTENSA_CORE_CONFIGURATION_H
-#define _XTENSA_CORE_CONFIGURATION_H
-
+#ifndef XTENSA_CORE_TEST_KC705_BE_CORE_ISA_H
+#define XTENSA_CORE_TEST_KC705_BE_CORE_ISA_H
 
 /
Parameters Useful for Any Code, USER or PRIVILEGED
@@ -571,5 +570,4 @@
 #endif /* !XTENSA_HAL_NON_PRIVILEGED_ONLY */
 
 
-#endif /* _XTENSA_CORE_CONFIGURATION_H */
-
+#endif /* XTENSA_CORE_TEST_KC705_BE_CORE_ISA_H */
diff --git a/target/xtensa/core-test_mmuhifi_c3/core-isa.h 
b/target/xtensa/core-test_mmuhifi_c3/core-isa.h
index 309caa1a32..704a31f7c8 100644
--- a/target/xtensa/core-test_mmuhifi_c3/core-isa.h
+++ b/target/xtensa/core-test_mmuhifi_c3/core-isa.h
@@ -7,9 +7,8 @@
  * Copyright (c) 1999-2009 Tensilica Inc.
  */
 
-#ifndef _XTENSA_CORE_CONFIGURATION_H
-#define _XTENSA_CORE_CONFIGURATION_H
-
+#ifndef XTENSA_CORE_TEST_MMUHIFI_C3_CORE_ISA_H
+#define XTENSA_CORE_TEST_MMUHIFI_C3_CORE_ISA_H
 
 /
Parameters Useful for Any Code, USER or PRIVILEGED
@@ -380,5 +379,4 @@
 #endif /* !XTENSA_HAL_NON_PRIVILEGED_ONLY */
 
 
-#endif /* _XTENSA_CORE_CONFIGURATION_H */
-
+#endif /* XTENSA_CORE_TEST_MMUHIFI_C3_CORE_ISA_H */
-- 
2.17.2

[Qemu-devel] [PULL 4/9] linux-user/nios2 linux-user/riscv: Clean up header guards

Reuse of the same guard symbol in multiple headers is okay as long as
they cannot be included together.  scripts/clean-header-guards.pl
can't tell, so it warns.

Since we can avoid guard symbol reuse easily, do so: use guard symbol
${target^^}_${fname^^} for linux-user/$target/$fname, just like we did
in commit a9c94277f0..3500385697.

Signed-off-by: Markus Armbruster 
Message-Id: <20190315145123.28030-4-arm...@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé 
---
 linux-user/nios2/target_cpu.h | 4 ++--
 linux-user/nios2/target_signal.h  | 6 +++---
 linux-user/nios2/target_structs.h | 4 ++--
 linux-user/nios2/target_syscall.h | 6 +++---
 linux-user/riscv/target_cpu.h | 4 ++--
 linux-user/riscv/target_signal.h  | 6 +++---
 linux-user/riscv/target_structs.h | 4 ++--
 7 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/linux-user/nios2/target_cpu.h b/linux-user/nios2/target_cpu.h
index 14f63338fa..5596c05c9c 100644
--- a/linux-user/nios2/target_cpu.h
+++ b/linux-user/nios2/target_cpu.h
@@ -17,8 +17,8 @@
  * License along with this library; if not, see .
  */
 
-#ifndef TARGET_CPU_H
-#define TARGET_CPU_H
+#ifndef NIOS2_TARGET_CPU_H
+#define NIOS2_TARGET_CPU_H
 
 static inline void cpu_clone_regs(CPUNios2State *env, target_ulong newsp)
 {
diff --git a/linux-user/nios2/target_signal.h b/linux-user/nios2/target_signal.h
index 7776bcdbfd..fe48721b3d 100644
--- a/linux-user/nios2/target_signal.h
+++ b/linux-user/nios2/target_signal.h
@@ -1,5 +1,5 @@
-#ifndef TARGET_SIGNAL_H
-#define TARGET_SIGNAL_H
+#ifndef NIOS2_TARGET_SIGNAL_H
+#define NIOS2_TARGET_SIGNAL_H
 
 /* this struct defines a stack used during syscall handling */
 
@@ -18,4 +18,4 @@ typedef struct target_sigaltstack {
 
 #include "../generic/signal.h"
 
-#endif /* TARGET_SIGNAL_H */
+#endif /* NIOS2_TARGET_SIGNAL_H */
diff --git a/linux-user/nios2/target_structs.h 
b/linux-user/nios2/target_structs.h
index 8713772089..7145251706 100644
--- a/linux-user/nios2/target_structs.h
+++ b/linux-user/nios2/target_structs.h
@@ -16,8 +16,8 @@
  * You should have received a copy of the GNU Lesser General Public
  * License along with this library; if not, see .
  */
-#ifndef TARGET_STRUCTS_H
-#define TARGET_STRUCTS_H
+#ifndef NIOS2_TARGET_STRUCTS_H
+#define NIOS2_TARGET_STRUCTS_H
 
 struct target_ipc_perm {
 abi_int __key;  /* Key.  */
diff --git a/linux-user/nios2/target_syscall.h 
b/linux-user/nios2/target_syscall.h
index ca6b7e69f6..f3b2a500f4 100644
--- a/linux-user/nios2/target_syscall.h
+++ b/linux-user/nios2/target_syscall.h
@@ -1,5 +1,5 @@
-#ifndef TARGET_SYSCALL_H
-#define TARGET_SYSCALL_H
+#ifndef NIOS2_TARGET_SYSCALL_H
+#define NIOS2_TARGET_SYSCALL_H
 
 #define UNAME_MACHINE "nios2"
 #define UNAME_MINIMUM_RELEASE "3.19.0"
@@ -34,4 +34,4 @@ struct target_pt_regs {
 #define TARGET_MLOCKALL_MCL_CURRENT 1
 #define TARGET_MLOCKALL_MCL_FUTURE  2
 
-#endif  /* TARGET_SYSCALL_H */
+#endif /* NIOS2_TARGET_SYSCALL_H */
diff --git a/linux-user/riscv/target_cpu.h b/linux-user/riscv/target_cpu.h
index 7e090f376a..90f9a4171e 100644
--- a/linux-user/riscv/target_cpu.h
+++ b/linux-user/riscv/target_cpu.h
@@ -1,5 +1,5 @@
-#ifndef TARGET_CPU_H
-#define TARGET_CPU_H
+#ifndef RISCV_TARGET_CPU_H
+#define RISCV_TARGET_CPU_H
 
 static inline void cpu_clone_regs(CPURISCVState *env, target_ulong newsp)
 {
diff --git a/linux-user/riscv/target_signal.h b/linux-user/riscv/target_signal.h
index c8b1455800..f113ba9a55 100644
--- a/linux-user/riscv/target_signal.h
+++ b/linux-user/riscv/target_signal.h
@@ -1,5 +1,5 @@
-#ifndef TARGET_SIGNAL_H
-#define TARGET_SIGNAL_H
+#ifndef RISCV_TARGET_SIGNAL_H
+#define RISCV_TARGET_SIGNAL_H
 
 typedef struct target_sigaltstack {
 abi_ulong ss_sp;
@@ -15,4 +15,4 @@ typedef struct target_sigaltstack {
 
 #include "../generic/signal.h"
 
-#endif /* TARGET_SIGNAL_H */
+#endif /* RISCV_TARGET_SIGNAL_H */
diff --git a/linux-user/riscv/target_structs.h 
b/linux-user/riscv/target_structs.h
index 4f0462c497..ea3e5ed17e 100644
--- a/linux-user/riscv/target_structs.h
+++ b/linux-user/riscv/target_structs.h
@@ -4,8 +4,8 @@
  * This is a copy of ../aarch64/target_structs.h atm.
  *
  */
-#ifndef TARGET_STRUCTS_H
-#define TARGET_STRUCTS_H
+#ifndef RISCV_TARGET_STRUCTS_H
+#define RISCV_TARGET_STRUCTS_H
 
 struct target_ipc_perm {
 abi_int __key;  /* Key.  */
-- 
2.17.2

[Qemu-devel] [PULL 1/9] Clean up includes

Clean up includes so that osdep.h is included first and headers
which it implies are not included manually.

This commit was created with scripts/clean-includes, with the changes
to the following files manually reverted:

contrib/libvhost-user/libvhost-user-glib.h
contrib/libvhost-user/libvhost-user.c
contrib/libvhost-user/libvhost-user.h
linux-user/mips64/cpu_loop.c
linux-user/mips64/signal.c
linux-user/sparc64/cpu_loop.c
linux-user/sparc64/signal.c
linux-user/x86_64/cpu_loop.c
linux-user/x86_64/signal.c
slirp/src/*
target/s390x/gen-features.c
tests/fp/platform.h
tests/migration/s390x/a-b-bios.c
tests/test-rcu-simpleq.c
tests/test-rcu-tailq.c
tests/uefi-test-tools/UefiTestToolsPkg/BiosTablesTest/BiosTablesTest.c

We're in the process of spinning out slirp/.  tests/fp/platform.h is
has to include qemu/osdep.h because tests/fp/berkeley-softfloat-3/ and
tests/fp/berkeley-testfloat-3/ don't.  tests/uefi-test-tools/ is guest
software.  The remaining reverts are the same as in commit
b7d89466dde.

Signed-off-by: Markus Armbruster 
Message-Id: <20190313162812.8885-1-arm...@redhat.com>
Reviewed-by: Eric Blake 
---
 contrib/elf2dmp/main.c   | 3 +--
 contrib/elf2dmp/pdb.c| 3 +--
 hw/display/ati.c | 1 +
 hw/display/ati_2d.c  | 1 +
 hw/display/ati_dbg.c | 1 +
 hw/display/ati_int.h | 1 -
 include/hw/cpu/cluster.h | 1 -
 tests/libqos/qgraph.h| 4 
 tests/qos-test.c | 2 +-
 9 files changed, 6 insertions(+), 11 deletions(-)

diff --git a/contrib/elf2dmp/main.c b/contrib/elf2dmp/main.c
index 1bfeb89ba7..9a2dbc2902 100644
--- a/contrib/elf2dmp/main.c
+++ b/contrib/elf2dmp/main.c
@@ -5,9 +5,8 @@
  *
  */
 
-#include 
-
 #include "qemu/osdep.h"
+
 #include "err.h"
 #include "addrspace.h"
 #include "pe.h"
diff --git a/contrib/elf2dmp/pdb.c b/contrib/elf2dmp/pdb.c
index 64af20f584..a5bd40c99d 100644
--- a/contrib/elf2dmp/pdb.c
+++ b/contrib/elf2dmp/pdb.c
@@ -18,9 +18,8 @@
  * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA
  */
 
-#include 
-
 #include "qemu/osdep.h"
+
 #include "pdb.h"
 #include "err.h"
 
diff --git a/hw/display/ati.c b/hw/display/ati.c
index db409be3c9..75716dd944 100644
--- a/hw/display/ati.c
+++ b/hw/display/ati.c
@@ -16,6 +16,7 @@
  * No 3D at all yet (maybe after 2D works, but feel free to improve it)
  */
 
+#include "qemu/osdep.h"
 #include "ati_int.h"
 #include "ati_regs.h"
 #include "vga_regs.h"
diff --git a/hw/display/ati_2d.c b/hw/display/ati_2d.c
index fe3ae14864..d83c29c6d9 100644
--- a/hw/display/ati_2d.c
+++ b/hw/display/ati_2d.c
@@ -7,6 +7,7 @@
  * This work is licensed under the GNU GPL license version 2 or later.
  */
 
+#include "qemu/osdep.h"
 #include "ati_int.h"
 #include "ati_regs.h"
 #include "qemu/log.h"
diff --git a/hw/display/ati_dbg.c b/hw/display/ati_dbg.c
index 1e6c32624e..b045f81d06 100644
--- a/hw/display/ati_dbg.c
+++ b/hw/display/ati_dbg.c
@@ -1,3 +1,4 @@
+#include "qemu/osdep.h"
 #include "ati_int.h"
 
 #ifdef DEBUG_ATI
diff --git a/hw/display/ati_int.h b/hw/display/ati_int.h
index a6f3e20e63..2f426064cf 100644
--- a/hw/display/ati_int.h
+++ b/hw/display/ati_int.h
@@ -9,7 +9,6 @@
 #ifndef ATI_INT_H
 #define ATI_INT_H
 
-#include "qemu/osdep.h"
 #include "hw/pci/pci.h"
 #include "vga_int.h"
 
diff --git a/include/hw/cpu/cluster.h b/include/hw/cpu/cluster.h
index 549c2d31d4..01c1e50cd2 100644
--- a/include/hw/cpu/cluster.h
+++ b/include/hw/cpu/cluster.h
@@ -20,7 +20,6 @@
 #ifndef HW_CPU_CLUSTER_H
 #define HW_CPU_CLUSTER_H
 
-#include "qemu/osdep.h"
 #include "hw/qdev.h"
 
 /*
diff --git a/tests/libqos/qgraph.h b/tests/libqos/qgraph.h
index ef0c73837a..e799095b30 100644
--- a/tests/libqos/qgraph.h
+++ b/tests/libqos/qgraph.h
@@ -19,11 +19,7 @@
 #ifndef QGRAPH_H
 #define QGRAPH_H
 
-#include 
-#include 
-#include 
 #include 
-#include 
 #include "qemu/module.h"
 #include "malloc.h"
 
diff --git a/tests/qos-test.c b/tests/qos-test.c
index 6b1145eccc..ae2fb5de1c 100644
--- a/tests/qos-test.c
+++ b/tests/qos-test.c
@@ -16,8 +16,8 @@
  * License along with this library; if not, see 
  */
 
-#include 
 #include "qemu/osdep.h"
+#include 
 #include "libqtest.h"
 #include "qapi/qmp/qdict.h"
 #include "qapi/qmp/qbool.h"
-- 
2.17.2

[Qemu-devel] [PULL 8/9] Normalize header guard symbol definition.

We commonly define the header guard symbol without an explicit value.
Normalize the exceptions.

Done with scripts/clean-header-guards.pl.

Signed-off-by: Markus Armbruster 
Message-Id: <20190315145123.28030-8-arm...@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé 
---
 hw/timer/m48t59-internal.h| 3 ++-
 include/disas/capstone.h  | 2 +-
 include/hw/scsi/emulation.h   | 2 +-
 include/qemu/stats64.h| 2 +-
 include/qemu/sys_membarrier.h | 2 +-
 include/qemu/systemd.h| 2 +-
 include/scsi/utils.h  | 2 +-
 include/ui/kbd-state.h| 3 ++-
 scsi/pr-helper.h  | 3 ++-
 target/i386/hvf/x86.h | 2 +-
 target/i386/hvf/x86_decode.h  | 2 +-
 target/i386/hvf/x86_descr.h   | 2 +-
 12 files changed, 15 insertions(+), 12 deletions(-)

diff --git a/hw/timer/m48t59-internal.h b/hw/timer/m48t59-internal.h
index d0f0caf3c7..4d4f2a6fed 100644
--- a/hw/timer/m48t59-internal.h
+++ b/hw/timer/m48t59-internal.h
@@ -22,8 +22,9 @@
  * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
  * THE SOFTWARE.
  */
+
 #ifndef HW_M48T59_INTERNAL_H
-#define HW_M48T59_INTERNAL_H 1
+#define HW_M48T59_INTERNAL_H
 
 #define M48T59_DEBUG 0
 
diff --git a/include/disas/capstone.h b/include/disas/capstone.h
index 84e214956d..e29068dd97 100644
--- a/include/disas/capstone.h
+++ b/include/disas/capstone.h
@@ -1,5 +1,5 @@
 #ifndef QEMU_CAPSTONE_H
-#define QEMU_CAPSTONE_H 1
+#define QEMU_CAPSTONE_H
 
 #ifdef CONFIG_CAPSTONE
 
diff --git a/include/hw/scsi/emulation.h b/include/hw/scsi/emulation.h
index 09fba1ff39..9521704326 100644
--- a/include/hw/scsi/emulation.h
+++ b/include/hw/scsi/emulation.h
@@ -1,5 +1,5 @@
 #ifndef HW_SCSI_EMULATION_H
-#define HW_SCSI_EMULATION_H 1
+#define HW_SCSI_EMULATION_H
 
 typedef struct SCSIBlockLimits {
 bool wsnz;
diff --git a/include/qemu/stats64.h b/include/qemu/stats64.h
index 4a357b3e9d..19a5ac4c56 100644
--- a/include/qemu/stats64.h
+++ b/include/qemu/stats64.h
@@ -10,7 +10,7 @@
  */
 
 #ifndef QEMU_STATS64_H
-#define QEMU_STATS64_H 1
+#define QEMU_STATS64_H
 
 #include "qemu/atomic.h"
 
diff --git a/include/qemu/sys_membarrier.h b/include/qemu/sys_membarrier.h
index 316e3dc4a2..b5bfa21d52 100644
--- a/include/qemu/sys_membarrier.h
+++ b/include/qemu/sys_membarrier.h
@@ -7,7 +7,7 @@
  */
 
 #ifndef QEMU_SYS_MEMBARRIER_H
-#define QEMU_SYS_MEMBARRIER_H 1
+#define QEMU_SYS_MEMBARRIER_H
 
 #ifdef CONFIG_MEMBARRIER
 /* Only block reordering at the compiler level in the performance-critical
diff --git a/include/qemu/systemd.h b/include/qemu/systemd.h
index e6a877e5c6..f0ea1266d5 100644
--- a/include/qemu/systemd.h
+++ b/include/qemu/systemd.h
@@ -11,7 +11,7 @@
  */
 
 #ifndef QEMU_SYSTEMD_H
-#define QEMU_SYSTEMD_H 1
+#define QEMU_SYSTEMD_H
 
 #define FIRST_SOCKET_ACTIVATION_FD 3 /* defined by systemd ABI */
 
diff --git a/include/scsi/utils.h b/include/scsi/utils.h
index 4b705f5e0f..9351b21ead 100644
--- a/include/scsi/utils.h
+++ b/include/scsi/utils.h
@@ -1,5 +1,5 @@
 #ifndef SCSI_UTILS_H
-#define SCSI_UTILS_H 1
+#define SCSI_UTILS_H
 
 #ifdef CONFIG_LINUX
 #include 
diff --git a/include/ui/kbd-state.h b/include/ui/kbd-state.h
index d87833553a..eb9067dd53 100644
--- a/include/ui/kbd-state.h
+++ b/include/ui/kbd-state.h
@@ -3,8 +3,9 @@
  * (at your option) any later version.  See the COPYING file in the
  * top-level directory.
  */
+
 #ifndef QEMU_UI_KBD_STATE_H
-#define QEMU_UI_KBD_STATE_H 1
+#define QEMU_UI_KBD_STATE_H
 
 #include "qapi/qapi-types-ui.h"
 
diff --git a/scsi/pr-helper.h b/scsi/pr-helper.h
index 096d1f1df6..e26e104ec7 100644
--- a/scsi/pr-helper.h
+++ b/scsi/pr-helper.h
@@ -23,8 +23,9 @@
  * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
  * IN THE SOFTWARE.
  */
+
 #ifndef QEMU_PR_HELPER_H
-#define QEMU_PR_HELPER_H 1
+#define QEMU_PR_HELPER_H
 
 #define PR_HELPER_CDB_SIZE 16
 #define PR_HELPER_SENSE_SIZE   96
diff --git a/target/i386/hvf/x86.h b/target/i386/hvf/x86.h
index 103ec0976c..c95d5b2116 100644
--- a/target/i386/hvf/x86.h
+++ b/target/i386/hvf/x86.h
@@ -17,7 +17,7 @@
  */
 
 #ifndef HVF_X86_H
-#define HVF_X86_H 1
+#define HVF_X86_H
 
 typedef struct x86_register {
 union {
diff --git a/target/i386/hvf/x86_decode.h b/target/i386/hvf/x86_decode.h
index ef4bcab310..bc574a7a44 100644
--- a/target/i386/hvf/x86_decode.h
+++ b/target/i386/hvf/x86_decode.h
@@ -16,7 +16,7 @@
  */
 
 #ifndef HVF_X86_DECODE_H
-#define HVF_X86_DECODE_H 1
+#define HVF_X86_DECODE_H
 
 #include "cpu.h"
 #include "x86.h"
diff --git a/target/i386/hvf/x86_descr.h b/target/i386/hvf/x86_descr.h
index 25a2b1731c..049ef9a417 100644
--- a/target/i386/hvf/x86_descr.h
+++ b/target/i386/hvf/x86_descr.h
@@ -17,7 +17,7 @@
  */
 
 #ifndef HVF_X86_DESCR_H
-#define HVF_X86_DESCR_H 1
+#define HVF_X86_DESCR_H
 
 #include "x86.h"
 
-- 
2.17.2

[Qemu-devel] [PULL 0/9] Miscellaneous patches for 2019-05-13

This is actually a fixed rebase of "[PULL for-4.1 0/9] Miscellaneous
patches for 2019-04-18", but that subject has since become misleading,
so I changed it.

v2:
* Back out the change to tests/fp/platform.h that breaks big endian
* Rebase

The following changes since commit efb4f3b62c69383a7308d7b739a3193e7c0ccae8:

  Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' into 
staging (2019-05-10 14:49:36 +0100)

are available in the Git repository at:

  git://repo.or.cz/qemu/armbru.git tags/pull-misc-2019-05-13

for you to fetch changes up to 6834c3f410f6ce77dd9cad78f3a9a864e7fc8ec5:

  Clean up decorations and whitespace around header guards (2019-05-13 08:58:55 
+0200)


Miscellaneous patches for 2019-05-13


Markus Armbruster (9):
  Clean up includes
  Use #include "..." for our own headers, <...> for others
  authz: Normalize #include "authz/trace.h" to "trace.h"
  linux-user/nios2 linux-user/riscv: Clean up header guards
  target/xtensa: Clean up core-isa.h header guards
  Clean up header guards that don't match their file name
  Clean up ill-advised or unusual header guards
  Normalize header guard symbol definition.
  Clean up decorations and whitespace around header guards

 authz/base.c|  2 +-
 authz/list.c|  2 +-
 authz/listfile.c|  2 +-
 authz/pamacct.c |  2 +-
 authz/simple.c  |  2 +-
 block/crypto.h  |  6 +++---
 contrib/elf2dmp/main.c  |  3 +--
 contrib/elf2dmp/pdb.c   |  3 +--
 contrib/elf2dmp/qemu_elf.h  |  6 +++---
 contrib/rdmacm-mux/main.c   | 18 +-
 contrib/rdmacm-mux/rdmacm-mux.h |  6 +++---
 disas/nanomips.h|  4 ++--
 fsdev/qemu-fsdev-throttle.h |  7 ---
 hw/arm/smmuv3-internal.h|  4 ++--
 hw/display/ati.c|  1 +
 hw/display/ati_2d.c |  1 +
 hw/display/ati_dbg.c|  1 +
 hw/display/ati_int.h|  1 -
 hw/display/vga_regs.h   |  6 +++---
 hw/i386/amd_iommu.h |  4 ++--
 hw/ide/ahci_internal.h  |  2 +-
 hw/rdma/rdma_utils.h|  1 -
 hw/rdma/vmw/pvrdma_qp_ops.h |  4 ++--
 hw/sd/sdmmc-internal.h  |  5 +++--
 hw/timer/m48t59-internal.h  |  3 ++-
 hw/tpm/tpm_ioctl.h  |  7 ---
 hw/xtensa/xtensa_memory.h   |  4 ++--
 include/authz/base.h|  7 +++
 include/authz/list.h|  7 +++
 include/authz/listfile.h|  8 +++-
 include/authz/pamacct.h |  7 +++
 include/authz/simple.h  |  7 +++
 include/block/aio-wait.h|  2 +-
 include/chardev/spice.h |  4 ++--
 include/disas/capstone.h|  2 +-
 include/exec/translator.h   |  2 +-
 include/hw/arm/nrf51_soc.h  |  1 -
 include/hw/arm/smmu-common.h|  2 +-
 include/hw/audio/soundhw.h  |  4 ++--
 include/hw/cpu/cluster.h|  1 -
 include/hw/i386/x86-iommu.h |  4 ++--
 include/hw/intc/heathrow_pic.h  |  6 +++---
 include/hw/intc/xlnx-pmu-iomod-intc.h   |  6 +++---
 include/hw/misc/armsse-mhu.h|  4 ++--
 include/hw/misc/imx2_wdt.h  |  2 +-
 include/hw/misc/nrf51_rng.h |  3 ++-
 include/hw/net/ne2000-isa.h |  4 ++--
 include/hw/pci-host/designware.h|  2 +-
 include/hw/pci-host/sabre.h |  4 ++--
 include/hw/ppc/pnv.h|  7 ---
 include/hw/ppc/pnv_core.h   |  7 ---
 include/hw/ppc/pnv_lpc.h|  7 ---
 include/hw/ppc/pnv_occ.h|  7 ---
 include/hw/ppc/pnv_psi.h|  7 ---
 include/hw/ppc/pnv_xscom.h  |  7 ---
 include/hw/ppc/spapr_ovec.h |  7 ---
 include/hw/riscv/sifive_plic.h  |  1 -
 include/hw/scsi/emulation.h |  2 +-
 include/hw/timer/pl031.h|  4 ++--
 include/hw/virtio/vhost-vsock.h |  6 +++---
 include/hw/virtio/virtio-crypto.h   |  6 ++

[Qemu-devel] [PULL 2/9] Use #include "..." for our own headers, <...> for others

Also delete a few redundant #include.

Signed-off-by: Markus Armbruster 
Message-Id: <20190315145123.28030-2-arm...@redhat.com>
---
 contrib/rdmacm-mux/main.c   | 18 +-
 contrib/rdmacm-mux/rdmacm-mux.h |  6 +++---
 hw/rdma/rdma_utils.h|  1 -
 target/i386/whp-dispatch.h  |  2 +-
 target/i386/whpx-all.c  |  1 -
 5 files changed, 13 insertions(+), 15 deletions(-)

diff --git a/contrib/rdmacm-mux/main.c b/contrib/rdmacm-mux/main.c
index 21cc804367..30c7052651 100644
--- a/contrib/rdmacm-mux/main.c
+++ b/contrib/rdmacm-mux/main.c
@@ -14,16 +14,16 @@
  */
 
 #include "qemu/osdep.h"
-#include "sys/poll.h"
-#include "sys/ioctl.h"
-#include "pthread.h"
-#include "syslog.h"
+#include 
+#include 
+#include 
+#include 
 
-#include "infiniband/verbs.h"
-#include "infiniband/umad.h"
-#include "infiniband/umad_types.h"
-#include "infiniband/umad_sa.h"
-#include "infiniband/umad_cm.h"
+#include 
+#include 
+#include 
+#include 
+#include 
 
 #include "rdmacm-mux.h"
 
diff --git a/contrib/rdmacm-mux/rdmacm-mux.h b/contrib/rdmacm-mux/rdmacm-mux.h
index 942a802c47..07a4722913 100644
--- a/contrib/rdmacm-mux/rdmacm-mux.h
+++ b/contrib/rdmacm-mux/rdmacm-mux.h
@@ -17,9 +17,9 @@
 #define RDMACM_MUX_H
 
 #include "linux/if.h"
-#include "infiniband/verbs.h"
-#include "infiniband/umad.h"
-#include "rdma/rdma_user_cm.h"
+#include 
+#include 
+#include 
 
 typedef enum RdmaCmMuxMsgType {
 RDMACM_MUX_MSG_TYPE_REQ   = 0,
diff --git a/hw/rdma/rdma_utils.h b/hw/rdma/rdma_utils.h
index 2d42249691..e7babe96cb 100644
--- a/hw/rdma/rdma_utils.h
+++ b/hw/rdma/rdma_utils.h
@@ -20,7 +20,6 @@
 #include "qemu/error-report.h"
 #include "hw/pci/pci.h"
 #include "sysemu/dma.h"
-#include "stdio.h"
 
 #define rdma_error_report(fmt, ...) \
 error_report("%s: " fmt, "rdma", ## __VA_ARGS__)
diff --git a/target/i386/whp-dispatch.h b/target/i386/whp-dispatch.h
index 4ae3cc8fa5..a23fb33a29 100644
--- a/target/i386/whp-dispatch.h
+++ b/target/i386/whp-dispatch.h
@@ -1,4 +1,4 @@
-#include "windows.h"
+#include 
 
 #include 
 #include 
diff --git a/target/i386/whpx-all.c b/target/i386/whpx-all.c
index 57e53e1f1f..31d47320e4 100644
--- a/target/i386/whpx-all.c
+++ b/target/i386/whpx-all.c
@@ -13,7 +13,6 @@
 #include "exec/address-spaces.h"
 #include "exec/ioport.h"
 #include "qemu-common.h"
-#include "strings.h"
 #include "sysemu/accel.h"
 #include "sysemu/whpx.h"
 #include "sysemu/sysemu.h"
-- 
2.17.2

[Qemu-devel] [PULL 6/9] Clean up header guards that don't match their file name

Header guard symbols should match their file name to make guard
collisions less likely.

Cleaned up with scripts/clean-header-guards.pl, followed by some
renaming of new guard symbols picked by the script to better ones.

Signed-off-by: Markus Armbruster 
Message-Id: <20190315145123.28030-6-arm...@redhat.com>
[Rebase to master: update include/hw/net/ne2000-isa.h]
---
 contrib/elf2dmp/qemu_elf.h| 6 +++---
 disas/nanomips.h  | 4 ++--
 fsdev/qemu-fsdev-throttle.h   | 7 ---
 hw/arm/smmuv3-internal.h  | 4 ++--
 hw/display/vga_regs.h | 6 +++---
 hw/rdma/vmw/pvrdma_qp_ops.h   | 4 ++--
 hw/sd/sdmmc-internal.h| 5 +++--
 include/authz/listfile.h  | 8 +++-
 include/authz/pamacct.h   | 7 +++
 include/hw/audio/soundhw.h| 4 ++--
 include/hw/i386/x86-iommu.h   | 4 ++--
 include/hw/intc/heathrow_pic.h| 6 +++---
 include/hw/intc/xlnx-pmu-iomod-intc.h | 6 +++---
 include/hw/misc/armsse-mhu.h  | 4 ++--
 include/hw/net/ne2000-isa.h   | 4 ++--
 include/hw/pci-host/sabre.h   | 4 ++--
 include/hw/watchdog/wdt_aspeed.h  | 7 ---
 include/hw/xen/xen-legacy-backend.h   | 6 +++---
 include/hw/xtensa/xtensa-isa.h| 6 +++---
 include/migration/qemu-file-types.h   | 4 ++--
 include/qemu/filemonitor.h| 6 +++---
 include/scsi/constants.h  | 4 ++--
 net/colo.h| 6 +++---
 target/i386/hax-posix.h   | 6 +++---
 target/i386/hvf/x86_task.h| 6 --
 target/nios2/cpu.h| 7 ---
 target/nios2/mmu.h| 7 ---
 target/ppc/mmu-book3s-v3.h| 6 +++---
 tests/libqos/qgraph_internal.h| 4 ++--
 tests/migration/migration-test.h  | 7 ---
 30 files changed, 85 insertions(+), 80 deletions(-)

diff --git a/contrib/elf2dmp/qemu_elf.h b/contrib/elf2dmp/qemu_elf.h
index 2a7963821a..66ee1f0ed5 100644
--- a/contrib/elf2dmp/qemu_elf.h
+++ b/contrib/elf2dmp/qemu_elf.h
@@ -5,8 +5,8 @@
  *
  */
 
-#ifndef ELF2DMP_ELF_H
-#define ELF2DMP_ELF_H
+#ifndef EMPF2DMP_QEMU_ELF_H
+#define EMPF2DMP_QEMU_ELF_H
 
 #include "elf.h"
 
@@ -47,4 +47,4 @@ void QEMU_Elf_exit(QEMU_Elf *qe);
 Elf64_Phdr *elf64_getphdr(void *map);
 Elf64_Half elf_getphdrnum(void *map);
 
-#endif /* ELF2DMP_ELF_H */
+#endif /* ELF2DMP_QEMU_ELF_H */
diff --git a/disas/nanomips.h b/disas/nanomips.h
index 243c3e38d2..a0a2225301 100644
--- a/disas/nanomips.h
+++ b/disas/nanomips.h
@@ -20,8 +20,8 @@
  *
  */
 
-#ifndef NANOMIPS_DISASSEMBLER_H
-#define NANOMIPS_DISASSEMBLER_H
+#ifndef DISAS_NANOMIPS_H
+#define DISAS_NANOMIPS_H
 
 #include 
 
diff --git a/fsdev/qemu-fsdev-throttle.h b/fsdev/qemu-fsdev-throttle.h
index 4e83bdac25..7d6211d499 100644
--- a/fsdev/qemu-fsdev-throttle.h
+++ b/fsdev/qemu-fsdev-throttle.h
@@ -12,8 +12,8 @@
  *
  */
 
-#ifndef _FSDEV_THROTTLE_H
-#define _FSDEV_THROTTLE_H
+#ifndef QEMU_FSDEV_THROTTLE_H
+#define QEMU_FSDEV_THROTTLE_H
 
 #include "block/aio.h"
 #include "qemu/main-loop.h"
@@ -35,4 +35,5 @@ void coroutine_fn fsdev_co_throttle_request(FsThrottle *, 
bool ,
 struct iovec *, int);
 
 void fsdev_throttle_cleanup(FsThrottle *);
-#endif /* _FSDEV_THROTTLE_H */
+
+#endif /* QEMU_FSDEV_THROTTLE_H */
diff --git a/hw/arm/smmuv3-internal.h b/hw/arm/smmuv3-internal.h
index 19540f8f41..b160289cd1 100644
--- a/hw/arm/smmuv3-internal.h
+++ b/hw/arm/smmuv3-internal.h
@@ -18,8 +18,8 @@
  * with this program; if not, see .
  */
 
-#ifndef HW_ARM_SMMU_V3_INTERNAL_H
-#define HW_ARM_SMMU_V3_INTERNAL_H
+#ifndef HW_ARM_SMMUV3_INTERNAL_H
+#define HW_ARM_SMMUV3_INTERNAL_H
 
 #include "hw/arm/smmu-common.h"
 
diff --git a/hw/display/vga_regs.h b/hw/display/vga_regs.h
index 16886f5eed..30a98b8736 100644
--- a/hw/display/vga_regs.h
+++ b/hw/display/vga_regs.h
@@ -14,8 +14,8 @@
  *
  */
 
-#ifndef LINUX_VIDEO_VGA_H
-#define LINUX_VIDEO_VGA_H
+#ifndef HW_VGA_REGS_H
+#define HW_VGA_REGS_H
 
 /* Some of the code below is taken from SVGAlib.  The original,
unmodified copyright notice for that code is below. */
@@ -156,4 +156,4 @@
 /* VGA graphics controller bit masks */
 #define VGA_GR06_GRAPHICS_MODE  0x01
 
-#endif /* LINUX_VIDEO_VGA_H */
+#endif /* HW_VGA_REGS_H */
diff --git a/hw/rdma/vmw/pvrdma_qp_ops.h b/hw/rdma/vmw/pvrdma_qp_ops.h
index 82e720a76f..bf2b15c5ce 100644
--- a/hw/rdma/vmw/pvrdma_qp_ops.h
+++ b/hw/rdma/vmw/pvrdma_qp_ops.h
@@ -13,8 +13,8 @@
  *
  */
 
-#ifndef PVRDMA_QP_H
-#define PVRDMA_QP_H
+#ifndef PVRDMA_QP_OPS_H
+#define PVRDMA_QP_OPS_H
 
 #include "pvrdma.h"
 
diff --git a/hw/sd/sdmmc-internal.h b/hw/sd/sdmmc-internal.h
index 9aa04766fc..d8bf17d204 100644
--- a/hw/sd/sdmmc-internal.h
+++ b/hw/sd/sdmmc-internal.h
@@ -7,8 +7,9 @@
  * See the COPYING file in the top-level directory.
  * SPDX-License-Identifier: GPL-2.0-or-later
  */
-#ifndef SD_INTERNAL_H
-#define SD_INTERNAL_H

[Qemu-devel] [PULL 3/9] authz: Normalize #include "authz/trace.h" to "trace.h"

Include the generated trace.h the same way as we do everywhere else.

Signed-off-by: Markus Armbruster 
Message-Id: <20190315145123.28030-3-arm...@redhat.com>
Acked-by: Daniel P. Berrangé 
Reviewed-by: Philippe Mathieu-Daudé 
---
 authz/base.c | 2 +-
 authz/list.c | 2 +-
 authz/listfile.c | 2 +-
 authz/pamacct.c  | 2 +-
 authz/simple.c   | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/authz/base.c b/authz/base.c
index 110dfa4195..baf39fff25 100644
--- a/authz/base.c
+++ b/authz/base.c
@@ -20,7 +20,7 @@
 
 #include "qemu/osdep.h"
 #include "authz/base.h"
-#include "authz/trace.h"
+#include "trace.h"
 
 bool qauthz_is_allowed(QAuthZ *authz,
const char *identity,
diff --git a/authz/list.c b/authz/list.c
index dc6b0fec13..831da936fe 100644
--- a/authz/list.c
+++ b/authz/list.c
@@ -20,7 +20,7 @@
 
 #include "qemu/osdep.h"
 #include "authz/list.h"
-#include "authz/trace.h"
+#include "trace.h"
 #include "qom/object_interfaces.h"
 #include "qapi/qapi-visit-authz.h"
 
diff --git a/authz/listfile.c b/authz/listfile.c
index bc2b58ef6d..d74bbd1048 100644
--- a/authz/listfile.c
+++ b/authz/listfile.c
@@ -20,7 +20,7 @@
 
 #include "qemu/osdep.h"
 #include "authz/listfile.h"
-#include "authz/trace.h"
+#include "trace.h"
 #include "qemu/error-report.h"
 #include "qemu/main-loop.h"
 #include "qemu/sockets.h"
diff --git a/authz/pamacct.c b/authz/pamacct.c
index 5038358cdc..7539867923 100644
--- a/authz/pamacct.c
+++ b/authz/pamacct.c
@@ -20,7 +20,7 @@
 
 #include "qemu/osdep.h"
 #include "authz/pamacct.h"
-#include "authz/trace.h"
+#include "trace.h"
 #include "qom/object_interfaces.h"
 
 #include 
diff --git a/authz/simple.c b/authz/simple.c
index 8ab718803e..c409ce7efc 100644
--- a/authz/simple.c
+++ b/authz/simple.c
@@ -20,7 +20,7 @@
 
 #include "qemu/osdep.h"
 #include "authz/simple.h"
-#include "authz/trace.h"
+#include "trace.h"
 #include "qom/object_interfaces.h"
 
 static bool qauthz_simple_is_allowed(QAuthZ *authz,
-- 
2.17.2

[Qemu-devel] [Bug 1828608] Re: Chardev websocket might not support pasting more than a few chars

2019-05-13 Thread Anisse Astier

I wrote a websocket client to help reproduce the bug without a browser:
https://github.com/anisse/websocktty

You can install it to your $GOPATH/bin (defaults to ~/go/bin) with "go
get github.com/anisse/websocktty"

I can reproduce the bug with it by simply pasting a long-enough (5 to 20
characters) string.

I could not reproduce the bug with qemu's  "-serial tcp" and netcat, so
this problem might indeed be limited to the websock channel
implementation.

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

Title:
  Chardev websocket might not support pasting more than a few chars

Status in QEMU:
  New

Bug description:
  When sending more than 4-5 characters on the websocket serial console
  (with pasting for example), the guest might not receive all of them,
  or worse interpret the input as Magic SysRq keys.

  This might be due to the io loop not checking the backend readiness
  before calling the read function.

  Attached patched fixes the problem on my system. I'm not sure it's the
  proper approach, this is just to start discussion.

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

[Qemu-devel] [PULL 9/9] Clean up decorations and whitespace around header guards

Cleaned up with scripts/clean-header-guards.pl.

Signed-off-by: Markus Armbruster 
Message-Id: <20190315145123.28030-9-arm...@redhat.com>
---
 hw/ide/ahci_internal.h  | 2 +-
 include/block/aio-wait.h| 2 +-
 include/exec/translator.h   | 2 +-
 include/hw/arm/nrf51_soc.h  | 1 -
 include/hw/arm/smmu-common.h| 2 +-
 include/hw/misc/imx2_wdt.h  | 2 +-
 include/hw/misc/nrf51_rng.h | 3 ++-
 include/hw/pci-host/designware.h| 2 +-
 include/hw/riscv/sifive_plic.h  | 1 -
 include/qemu/pmem.h | 2 +-
 target/xtensa/xtensa-isa-internal.h | 2 +-
 tests/acpi-utils.h  | 2 +-
 tests/tpm-emu.h | 2 +-
 13 files changed, 12 insertions(+), 13 deletions(-)

diff --git a/hw/ide/ahci_internal.h b/hw/ide/ahci_internal.h
index 9b7fa8fc7d..95ecddcd3c 100644
--- a/hw/ide/ahci_internal.h
+++ b/hw/ide/ahci_internal.h
@@ -394,4 +394,4 @@ void ahci_reset(AHCIState *s);
 
 #define SYSBUS_AHCI(obj) OBJECT_CHECK(SysbusAHCIState, (obj), TYPE_SYSBUS_AHCI)
 
-#endif /* HW_IDE_AHCI_H */
+#endif /* HW_IDE_AHCI_INTERNAL_H */
diff --git a/include/block/aio-wait.h b/include/block/aio-wait.h
index afd0ff7eb8..afeeb18f95 100644
--- a/include/block/aio-wait.h
+++ b/include/block/aio-wait.h
@@ -124,4 +124,4 @@ void aio_wait_kick(void);
  */
 void aio_wait_bh_oneshot(AioContext *ctx, QEMUBHFunc *cb, void *opaque);
 
-#endif /* QEMU_AIO_WAIT */
+#endif /* QEMU_AIO_WAIT_H */
diff --git a/include/exec/translator.h b/include/exec/translator.h
index 66dfe906c4..180c51d509 100644
--- a/include/exec/translator.h
+++ b/include/exec/translator.h
@@ -142,4 +142,4 @@ void translator_loop(const TranslatorOps *ops, 
DisasContextBase *db,
 
 void translator_loop_temp_check(DisasContextBase *db);
 
-#endif  /* EXEC__TRANSLATOR_H */
+#endif /* EXEC__TRANSLATOR_H */
diff --git a/include/hw/arm/nrf51_soc.h b/include/hw/arm/nrf51_soc.h
index fd7fcc71a5..0cb78aafea 100644
--- a/include/hw/arm/nrf51_soc.h
+++ b/include/hw/arm/nrf51_soc.h
@@ -53,4 +53,3 @@ typedef struct NRF51State {
 } NRF51State;
 
 #endif
-
diff --git a/include/hw/arm/smmu-common.h b/include/hw/arm/smmu-common.h
index 2c7fbf4202..1f37844e5c 100644
--- a/include/hw/arm/smmu-common.h
+++ b/include/hw/arm/smmu-common.h
@@ -163,4 +163,4 @@ void smmu_inv_notifiers_all(SMMUState *s);
 /* Unmap the range of all the notifiers registered to @mr */
 void smmu_inv_notifiers_mr(IOMMUMemoryRegion *mr);
 
-#endif  /* HW_ARM_SMMU_COMMON */
+#endif /* HW_ARM_SMMU_COMMON_H */
diff --git a/include/hw/misc/imx2_wdt.h b/include/hw/misc/imx2_wdt.h
index 8afc99a10e..b91b002528 100644
--- a/include/hw/misc/imx2_wdt.h
+++ b/include/hw/misc/imx2_wdt.h
@@ -30,4 +30,4 @@ typedef struct IMX2WdtState {
 MemoryRegion mmio;
 } IMX2WdtState;
 
-#endif /* IMX7_SNVS_H */
+#endif /* IMX2_WDT_H */
diff --git a/include/hw/misc/nrf51_rng.h b/include/hw/misc/nrf51_rng.h
index 3d6bf79997..b0133bf665 100644
--- a/include/hw/misc/nrf51_rng.h
+++ b/include/hw/misc/nrf51_rng.h
@@ -30,6 +30,7 @@
  * the COPYING file in the top-level directory.
  *
  */
+
 #ifndef NRF51_RNG_H
 #define NRF51_RNG_H
 
@@ -80,4 +81,4 @@ typedef struct {
 } NRF51RNGState;
 
 
-#endif /* NRF51_RNG_H_ */
+#endif /* NRF51_RNG_H */
diff --git a/include/hw/pci-host/designware.h b/include/hw/pci-host/designware.h
index a4f2c0695b..186bb36238 100644
--- a/include/hw/pci-host/designware.h
+++ b/include/hw/pci-host/designware.h
@@ -99,4 +99,4 @@ typedef struct DesignwarePCIEHost {
 MemoryRegion mmio;
 } DesignwarePCIEHost;
 
-#endif  /* DESIGNWARE_H */
+#endif /* DESIGNWARE_H */
diff --git a/include/hw/riscv/sifive_plic.h b/include/hw/riscv/sifive_plic.h
index 688cd97f82..ce8907f6aa 100644
--- a/include/hw/riscv/sifive_plic.h
+++ b/include/hw/riscv/sifive_plic.h
@@ -80,4 +80,3 @@ DeviceState *sifive_plic_create(hwaddr addr, char 
*hart_config,
 uint32_t aperture_size);
 
 #endif
-
diff --git a/include/qemu/pmem.h b/include/qemu/pmem.h
index dfb6d0da62..d2d7ad085c 100644
--- a/include/qemu/pmem.h
+++ b/include/qemu/pmem.h
@@ -33,4 +33,4 @@ pmem_persist(const void *addr, size_t len)
 
 #endif /* CONFIG_LIBPMEM */
 
-#endif /* !QEMU_PMEM_H */
+#endif /* QEMU_PMEM_H */
diff --git a/target/xtensa/xtensa-isa-internal.h 
b/target/xtensa/xtensa-isa-internal.h
index c29295ff96..40dd8bac96 100644
--- a/target/xtensa/xtensa-isa-internal.h
+++ b/target/xtensa/xtensa-isa-internal.h
@@ -228,4 +228,4 @@ int xtensa_isa_name_compare(const void *, const void *);
 extern xtensa_isa_status xtisa_errno;
 extern char xtisa_error_msg[];
 
-#endif /* !XTENSA_ISA_INTERNAL_H */
+#endif /* XTENSA_ISA_INTERNAL_H */
diff --git a/tests/acpi-utils.h b/tests/acpi-utils.h
index ef388bbf12..73fe24f044 100644
--- a/tests/acpi-utils.h
+++ b/tests/acpi-utils.h
@@ -52,4 +52,4 @@ void acpi_fetch_table(QTestState *qts, uint8_t **aml, 
uint32_t *aml_len,
   const uint8_t *addr_ptr, const char *sig,
   bool verify_checksum);
 
-#endif  /* TEST_ACPI_U

[Qemu-devel] [PULL 7/9] Clean up ill-advised or unusual header guards

Leading underscores are ill-advised because such identifiers are
reserved.  Trailing underscores are merely ugly.  Strip both.

Our header guards commonly end in _H.  Normalize the exceptions.

Done with scripts/clean-header-guards.pl.

Signed-off-by: Markus Armbruster 
Message-Id: <20190315145123.28030-7-arm...@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé 
[Changes to slirp/ dropped, as we're about to spin it off]
---
 block/crypto.h | 6 +++---
 hw/i386/amd_iommu.h| 4 ++--
 hw/tpm/tpm_ioctl.h | 7 ---
 hw/xtensa/xtensa_memory.h  | 4 ++--
 include/authz/base.h   | 7 +++
 include/authz/list.h   | 7 +++
 include/authz/simple.h | 7 +++
 include/chardev/spice.h| 4 ++--
 include/hw/ppc/pnv.h   | 7 ---
 include/hw/ppc/pnv_core.h  | 7 ---
 include/hw/ppc/pnv_lpc.h   | 7 ---
 include/hw/ppc/pnv_occ.h   | 7 ---
 include/hw/ppc/pnv_psi.h   | 7 ---
 include/hw/ppc/pnv_xscom.h | 7 ---
 include/hw/ppc/spapr_ovec.h| 7 ---
 include/hw/timer/pl031.h   | 4 ++--
 include/hw/virtio/vhost-vsock.h| 6 +++---
 include/hw/virtio/virtio-crypto.h  | 6 +++---
 include/hw/xen/start_info.h| 6 +++---
 include/hw/xtensa/mx_pic.h | 4 ++--
 include/qemu/drm.h | 4 ++--
 include/qemu/jhash.h   | 6 +++---
 include/sysemu/hvf.h   | 5 +++--
 linux-user/xtensa/syscall_nr.h | 6 +++---
 linux-user/xtensa/target_structs.h | 4 ++--
 linux-user/xtensa/termbits.h   | 6 +++---
 qga/vss-win32/vss-handles.h| 4 ++--
 target/i386/hax-i386.h | 4 ++--
 target/i386/hax-interface.h| 4 ++--
 target/i386/hvf/hvf-i386.h | 4 ++--
 target/i386/hvf/vmcs.h | 4 ++--
 target/i386/hvf/x86_emu.h  | 5 +++--
 target/i386/hvf/x86_flags.h| 7 ---
 target/i386/hvf/x86_mmu.h  | 7 ---
 target/riscv/pmp.h | 4 ++--
 target/sparc/asi.h | 6 +++---
 tests/libqos/e1000e.h  | 4 ++--
 tests/libqos/sdhci.h   | 4 ++--
 38 files changed, 109 insertions(+), 100 deletions(-)

diff --git a/block/crypto.h b/block/crypto.h
index dd7d47903c..b935695e79 100644
--- a/block/crypto.h
+++ b/block/crypto.h
@@ -18,8 +18,8 @@
  *
  */
 
-#ifndef BLOCK_CRYPTO_H__
-#define BLOCK_CRYPTO_H__
+#ifndef BLOCK_CRYPTO_H
+#define BLOCK_CRYPTO_H
 
 #define BLOCK_CRYPTO_OPT_DEF_KEY_SECRET(prefix, helpstr)\
 {   \
@@ -94,4 +94,4 @@ block_crypto_create_opts_init(QDict *opts, Error **errp);
 QCryptoBlockOpenOptions *
 block_crypto_open_opts_init(QDict *opts, Error **errp);
 
-#endif /* BLOCK_CRYPTO_H__ */
+#endif /* BLOCK_CRYPTO_H */
diff --git a/hw/i386/amd_iommu.h b/hw/i386/amd_iommu.h
index 0ff9095f32..3a694b186b 100644
--- a/hw/i386/amd_iommu.h
+++ b/hw/i386/amd_iommu.h
@@ -18,8 +18,8 @@
  * with this program; if not, see .
  */
 
-#ifndef AMD_IOMMU_H_
-#define AMD_IOMMU_H_
+#ifndef AMD_IOMMU_H
+#define AMD_IOMMU_H
 
 #include "hw/hw.h"
 #include "hw/pci/pci.h"
diff --git a/hw/tpm/tpm_ioctl.h b/hw/tpm/tpm_ioctl.h
index 59a0b0595d..f5f5c553a9 100644
--- a/hw/tpm/tpm_ioctl.h
+++ b/hw/tpm/tpm_ioctl.h
@@ -5,8 +5,9 @@
  *
  * This file is licensed under the terms of the 3-clause BSD license
  */
-#ifndef _TPM_IOCTL_H_
-#define _TPM_IOCTL_H_
+
+#ifndef TPM_IOCTL_H
+#define TPM_IOCTL_H
 
 #include 
 #include 
@@ -267,4 +268,4 @@ enum {
 CMD_SET_BUFFERSIZE,
 };
 
-#endif /* _TPM_IOCTL_H */
+#endif /* TPM_IOCTL_H */
diff --git a/hw/xtensa/xtensa_memory.h b/hw/xtensa/xtensa_memory.h
index e9aa08749d..89125c4a0d 100644
--- a/hw/xtensa/xtensa_memory.h
+++ b/hw/xtensa/xtensa_memory.h
@@ -25,8 +25,8 @@
  * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  */
 
-#ifndef _XTENSA_MEMORY_H
-#define _XTENSA_MEMORY_H
+#ifndef XTENSA_MEMORY_H
+#define XTENSA_MEMORY_H
 
 #include "qemu-common.h"
 #include "cpu.h"
diff --git a/include/authz/base.h b/include/authz/base.h
index 55ac9581ad..14a59a0425 100644
--- a/include/authz/base.h
+++ b/include/authz/base.h
@@ -18,8 +18,8 @@
  *
  */
 
-#ifndef QAUTHZ_BASE_H__
-#define QAUTHZ_BASE_H__
+#ifndef QAUTHZ_BASE_H
+#define QAUTHZ_BASE_H
 
 #include "qemu-common.h"
 #include "qapi/error.h"
@@ -108,5 +108,4 @@ bool qauthz_is_allowed_by_id(const char *authzid,
  const char *identity,
  Error **errp);
 
-#endif /* QAUTHZ_BASE_H__ */
-
+#endif /* QAUTHZ_BASE_H */
diff --git a/include/authz/list.h b/include/authz/list.h
index 138ae7047c..a88cdbbcf8 100644
--- a/include/authz/list.h
+++ b/include/authz/list.h
@@ -18,8 +18,8 @@
  *
  */
 
-#ifndef QAUTHZ_LIST_H__
-#define QAUTHZ_LIST_H__
+#ifndef QAUTHZ_LIST_H
+#define QAUTHZ_LIST_H
 
 #include "authz/base.h"
 #include "qapi/qapi-types-authz.h"
@@

[Qemu-devel] [PULL v3 00/29] Kconfig for Arm

 Hi Peter,

the following changes since commit efb4f3b62c69383a7308d7b739a3193e7c0ccae8:

  Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' into 
staging (2019-05-10 14:49:36 +0100)

are available in the Git repository at:

  https://gitlab.com/huth/qemu.git tags/pull-request-2019-05-13

for you to fetch changes up to 704d9892561d3b7ac4728296240a1b3ccfa2045a:

  hw/arm: Remove hard-enablement of the remaining PCI devices (2019-05-13 
09:36:32 +0200)


Kconfig settings for the Arm machines
(v3: Added the config-devices.mak.d patch to fix the dependencies)


Thomas Huth (29):
  hw/pci/pci-stub: Add msi_enabled() and msi_notify() to the pci stubs
  Makefile: Fix inclusion of the config-devices.mak.d Kconfig dependencies
  hw/ide/ahci: Add a Kconfig switch for the AHCI-ICH9 device
  hw/arm: Express dependencies of the exynos machines with Kconfig
  hw/arm: Express dependencies of the highbank machines with Kconfig
  hw/arm: Express dependencies of integratorcp with Kconfig
  hw/arm: Express dependencies of the fsl-imx31 machine with Kconfig
  hw/arm: Express dependencies of musicpal with Kconfig
  hw/arm: Express dependencies of the OMAP machines with Kconfig
  hw/arm: Express dependencies of stellaris with Kconfig
  hw/arm: Express dependencies of realview, versatile and vexpress with 
Kconfig
  hw/arm: Express dependencies of the PXA2xx machines with Kconfig
  hw/arm: Express dependencies of xilinx-zynq with Kconfig
  hw/arm: Express dependencies of collie with Kconfig
  hw/arm: Express dependencies of the aspeed boards with Kconfig
  hw/arm: Express dependencies of the virt machine with Kconfig
  hw/arm: Express dependencies of netduino / stm32f2xx with Kconfig
  hw/arm: Express dependencies of allwinner / cubieboard with Kconfig
  hw/arm: Express dependencies of the MPS2 boards with Kconfig
  hw/arm: Express dependencies of the raspi machines with Kconfig
  hw/arm: Express dependencies of canon-a1100 with Kconfig
  hw/arm: Express dependencies of sabrelite with Kconfig
  hw/arm: Express dependencies of the MSF2 / EMCRAFT_SF2 machine with 
Kconfig
  hw/arm: Express dependencies of the remaining IMX boards with Kconfig
  hw/arm: Express dependencies of the microbit / nrf51 machine with Kconfig
  hw/arm: Express dependencies of the ZynqMP zcu102 machine with Kconfig
  hw/arm: Express dependencies of the xlnx-versal-virt machine with Kconfig
  hw/arm: Express dependencies of the musca machines with Kconfig
  hw/arm: Remove hard-enablement of the remaining PCI devices

 Makefile|   2 +-
 configure   |   2 +-
 default-configs/aarch64-softmmu.mak |   5 -
 default-configs/arm-softmmu.mak | 179 
 docs/devel/kconfig.rst  |   2 +-
 hw/arm/Kconfig  | 317 +++-
 hw/arm/Makefile.objs|  25 ++-
 hw/display/Kconfig  |   3 +
 hw/i2c/Kconfig  |   2 +-
 hw/i386/Kconfig |   2 +-
 hw/ide/Kconfig  |   6 +-
 hw/ide/Makefile.objs|   2 +-
 hw/misc/Kconfig |   2 +
 hw/pci/pci-stub.c   |  11 ++
 14 files changed, 387 insertions(+), 173 deletions(-)

[Qemu-devel] [PULL v3 02/29] Makefile: Fix inclusion of the config-devices.mak.d Kconfig dependencies

The Makefile tries to include device Kconfig dependencies via

 -include $(SUBDIR_DEVICES_MAK_DEP)

and thus expects files that match *-softmmu/config-devices.mak.d ...
however, the minikconf script currently generates files a la
"*-softmmu-config.devices.mak.d" instead, so the dependency files
simply got ignored so far. For example, after a "touch hw/arm/Kconfig",
the arm-softmmu/config-devices.mak file is currently not re-generated.
Fix it by putting the dependency files in the *-softmmu folders now.

Reported-by: Peter Maydell 
Signed-off-by: Thomas Huth 
---
 Makefile   | 2 +-
 configure  | 2 +-
 docs/devel/kconfig.rst | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index 4a8ae0ef95..66d5c65156 100644
--- a/Makefile
+++ b/Makefile
@@ -350,7 +350,7 @@ endif
 # This has to be kept in sync with Kconfig.host.
 MINIKCONF_ARGS = \
 $(CONFIG_MINIKCONF_MODE) \
-$@ $*-config.devices.mak.d $< $(MINIKCONF_INPUTS) \
+$@ $*/config-devices.mak.d $< $(MINIKCONF_INPUTS) \
 CONFIG_KVM=$(CONFIG_KVM) \
 CONFIG_SPICE=$(CONFIG_SPICE) \
 CONFIG_IVSHMEM=$(CONFIG_IVSHMEM) \
diff --git a/configure b/configure
index 63f312bd1f..8999698bc2 100755
--- a/configure
+++ b/configure
@@ -1832,7 +1832,7 @@ exit 0
 fi
 
 # Remove old dependency files to make sure that they get properly regenerated
-rm -f *-config-devices.mak.d
+rm -f */config-devices.mak.d
 
 if test -z "$python"
 then
diff --git a/docs/devel/kconfig.rst b/docs/devel/kconfig.rst
index cce146f87d..d6f8eb0977 100644
--- a/docs/devel/kconfig.rst
+++ b/docs/devel/kconfig.rst
@@ -299,7 +299,7 @@ and also listed as follows in the top-level Makefile's 
``MINIKCONF_ARGS``
 variable::
 
 MINIKCONF_ARGS = \
-  $@ $*-config.devices.mak.d $< $(MINIKCONF_INPUTS) \
+  $@ $*/config-devices.mak.d $< $(MINIKCONF_INPUTS) \
   CONFIG_KVM=$(CONFIG_KVM) \
   CONFIG_SPICE=$(CONFIG_SPICE) \
   CONFIG_TPM=$(CONFIG_TPM) \
-- 
2.21.0

[Qemu-devel] [PULL v3 03/29] hw/ide/ahci: Add a Kconfig switch for the AHCI-ICH9 device

Some of our machines (like the ARM cubieboard) use CONFIG_AHCI for an AHCI
sysbus device, but do not use CONFIG_PCI since they do not feature a PCI
bus. With CONFIG_AHCI but without CONFIG_PCI, currently linking fails:

../hw/ide/ich.o: In function `pci_ich9_ahci_realize':
hw/ide/ich.c:124: undefined reference to `pci_allocate_irq'
hw/ide/ich.c:126: undefined reference to `pci_register_bar'
hw/ide/ich.c:128: undefined reference to `pci_register_bar'
hw/ide/ich.c:131: undefined reference to `pci_add_capability'
hw/ide/ich.c:147: undefined reference to `msi_init'
../hw/ide/ich.o: In function `pci_ich9_uninit':
hw/ide/ich.c:158: undefined reference to `msi_uninit'
../hw/ide/ich.o:(.data.rel+0x50): undefined reference to 
`vmstate_pci_device'

We must only compile ich.c if CONFIG_PCI is available, too, so introduce a
new config switch for this device.

Reviewed-by: Philippe Mathieu-Daudé 
Tested-by: Philippe Mathieu-Daudé 
Acked-by: John Snow 
Signed-off-by: Thomas Huth 
---
 hw/i386/Kconfig  | 2 +-
 hw/ide/Kconfig   | 6 +-
 hw/ide/Makefile.objs | 2 +-
 3 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/hw/i386/Kconfig b/hw/i386/Kconfig
index a6aed7c131..9817888216 100644
--- a/hw/i386/Kconfig
+++ b/hw/i386/Kconfig
@@ -80,7 +80,7 @@ config Q35
 select PC_ACPI
 select PCI_EXPRESS_Q35
 select LPC_ICH9
-select AHCI
+select AHCI_ICH9
 select DIMM
 select SMBIOS
 select VMPORT
diff --git a/hw/ide/Kconfig b/hw/ide/Kconfig
index ab47b6a7a3..5d9106b1ac 100644
--- a/hw/ide/Kconfig
+++ b/hw/ide/Kconfig
@@ -43,10 +43,14 @@ config MICRODRIVE
 select IDE_QDEV
 
 config AHCI
+bool
+select IDE_QDEV
+
+config AHCI_ICH9
 bool
 default y if PCI_DEVICES
 depends on PCI
-select IDE_QDEV
+select AHCI
 
 config IDE_SII3112
 bool
diff --git a/hw/ide/Makefile.objs b/hw/ide/Makefile.objs
index a142add90e..faf04e0209 100644
--- a/hw/ide/Makefile.objs
+++ b/hw/ide/Makefile.objs
@@ -9,6 +9,6 @@ common-obj-$(CONFIG_IDE_MMIO) += mmio.o
 common-obj-$(CONFIG_IDE_VIA) += via.o
 common-obj-$(CONFIG_MICRODRIVE) += microdrive.o
 common-obj-$(CONFIG_AHCI) += ahci.o
-common-obj-$(CONFIG_AHCI) += ich.o
+common-obj-$(CONFIG_AHCI_ICH9) += ich.o
 common-obj-$(CONFIG_ALLWINNER_A10) += ahci-allwinner.o
 common-obj-$(CONFIG_IDE_SII3112) += sii3112.o
-- 
2.21.0

Re: [Qemu-devel] [PATCH 6/6] virtfs: Fix documentation of -fsdev and -virtfs

On 09/05/2019 15.18, Greg Kurz wrote:
> On Wed, 8 May 2019 17:54:42 +0200
> Thomas Huth  wrote:
> 
>> On 07/05/2019 10.45, Greg Kurz wrote:
>>> This fixes several things:
>>> - add "id" description to -virtfs documentation
>>> - split the description into several lines in both usage and documentation
>>>   for accurateness and clarity
>>> - add documentation and usage of the synth fsdriver
>>> - add "throttling.*" description to -fsdev local
>>> - add some missing periods
>>>
>>> Buglink: https://bugs.launchpad.net/qemu/+bug/1581976
>>> Signed-off-by: Greg Kurz 
>>> ---
>>>  qemu-options.hx |   84 
>>> +++
>>>  1 file changed, 60 insertions(+), 24 deletions(-)
>>>
>>> diff --git a/qemu-options.hx b/qemu-options.hx
>>> index 9c5cc2e6bf70..975342dfbd66 100644
>>> --- a/qemu-options.hx
>>> +++ b/qemu-options.hx
>>> @@ -1232,26 +1232,35 @@ the write back by pressing @key{C-a s} 
>>> (@pxref{disk_images}).
>>>  ETEXI
>>>  
>>>  DEF("fsdev", HAS_ARG, QEMU_OPTION_fsdev,
>>> -"-fsdev 
>>> fsdriver,id=id[,path=path,][security_model={mapped-xattr|mapped-file|passthrough|none}]\n"
>>> -" 
>>> [,writeout=immediate][,readonly][,socket=socket|sock_fd=sock_fd][,fmode=fmode][,dmode=dmode]\n"
>>> +"-fsdev 
>>> local,id=id,path=path,security_model=mapped-xattr|mapped-file|passthrough|none\n"
>>> +" [,writeout=immediate][,readonly][,fmode=fmode][,dmode=dmode]\n"
>>>  " 
>>> [[,throttling.bps-total=b]|[[,throttling.bps-read=r][,throttling.bps-write=w]]]\n"
>>>  " 
>>> [[,throttling.iops-total=i]|[[,throttling.iops-read=r][,throttling.iops-write=w]]]\n"
>>>  " 
>>> [[,throttling.bps-total-max=bm]|[[,throttling.bps-read-max=rm][,throttling.bps-write-max=wm]]]\n"
>>>  " 
>>> [[,throttling.iops-total-max=im]|[[,throttling.iops-read-max=irm][,throttling.iops-write-max=iwm]]]\n"
>>> -" [[,throttling.iops-size=is]]\n",
>>> +" [[,throttling.iops-size=is]]\n"
>>> +"-fsdev proxy,id=id,socket=socket[,writeout=immediate][,readonly]\n"
>>> +"-fsdev proxy,id=id,sock_fd=sock_fd[,writeout=immediate][,readonly]\n"
>>> +"-fsdev synth,id=id\n",
>>>  QEMU_ARCH_ALL)
>>>  
>>>  STEXI
>>>  
>>> -@item -fsdev 
>>> @var{fsdriver},id=@var{id},path=@var{path},[security_model=@var{security_model}][,writeout=@var{writeout}][,readonly][,socket=@var{socket}|sock_fd=@var{sock_fd}][,fmode=@var{fmode}][,dmode=@var{dmode}]
>>> +@item -fsdev 
>>> local,id=@var{id},path=@var{path},security_model=@var{security_model} 
>>> [,writeout=@var{writeout}][,readonly][,fmode=@var{fmode}][,dmode=@var{dmode}]
>>>  
>>> [,throttling.@var{option}=@var{value}[,throttling.@var{option}=@var{value}[,...]]]
>>> +@itemx -fsdev 
>>> proxy,id=@var{id},socket=@var{socket}[,writeout=@var{writeout}][,readonly]
>>> +@itemx -fsdev 
>>> proxy,id=@var{id},sock_fd=@var{sock_fd}[,writeout=@var{writeout}][,readonly]
>>> +@itemx -fsdev synth,id=@var{id}[,readonly]
>>>  @findex -fsdev
>>>  Define a new file system device. Valid options are:
>>>  @table @option
>>> -@item @var{fsdriver}
>>> -This option specifies the fs driver backend to use.
>>> -Currently "local" and "proxy" file system drivers are supported.
>>> +@item local
>>> +Accesses to the filesystem are done by QEMU.
>>> +@item proxy
>>> +Accesses to the filesystem are done by virtfs-proxy-helper(1).
>>> +@item synth
>>> +Synthetic filesystem, only used by QTests.
>>>  @item id=@var{id}
>>> -Specifies identifier for this device
>>> +Specifies identifier for this device.
>>>  @item path=@var{path}
>>>  Specifies the export path for the file system device. Files under
>>>  this path will be available to the 9p client on the guest.
>>> @@ -1279,17 +1288,33 @@ Enables exporting 9p share as a readonly mount for 
>>> guests. By default
>>>  read-write access is given.
>>>  @item socket=@var{socket}
>>>  Enables proxy filesystem driver to use passed socket file for communicating
>>> -with virtfs-proxy-helper
>>> +with virtfs-proxy-helper(1).  
>>
>> Why did you add a "(1)" after each virtfs-proxy-helper?
>>
> 
> Oops forgot to mention that in the changelog... We have a manual page for the
> virtfs-proxy-helper command, and IIUC this is the way for a manual page to
> reference another one. Makes sense ?

Makes sense for the man page ... but it might look a little bit strange
in the qemu-doc.html file? I've got no strong opinion, but I think I'd
rather not include the "(1)" here.

 Thomas

[Qemu-devel] [PATCH v4 00/14] spapr: add KVM support to the XIVE interrupt mode

Hello,

This is the v4 of the QEMU/KVM patchset.

The first patches introduce the XIVE KVM device, state synchronization
and migration support under KVM. The second part of the patchset
modifies the XICS and XIVE interrupt models to add KVM support to the
'dual' IRQ backend.

GitHub trees available here :
 
QEMU sPAPR:

  https://github.com/legoater/qemu/commits/xive-next
  
Linux/KVM:

  https://github.com/legoater/linux/commits/xive-5.1

Thanks,

C.

Changes since v3:

 - updates of the kvm headers are synced with commit 0caecf5b0019
   (kvm-ppc-next-5.2-1) in branch kvm-ppc-next. will conflict with
   kvm-arm.   
 - added usage of xive_end_qaddr() helper
 - removed KVM_DESTROY_DEVICE control. KVM device is destroyed when
   the fd is closed.
 - update in kvmppc_xive_source_reset_one()
 - introduced a 'init' boolean under ICSState
 - removed extra spapr_irq_init_device() in spapr_irq_init_xive() 
 - reworked slightly the code sequence in xics_kvm_init() creating the
   presenters and connecting them to the KVM XICS device.

Changes since v2:

 - update linux headers to 5.1-rc1
 - rebased on new naming scheme
 - rebased on new configuration system
 - replaced error_report_err() by warn_report_err()
 - added an assert() in spapr_xive_end_to_target()
 - moved xive_end_is_valid() check out of kvmppc_xive_set_queue_config()
 - dealt with MASKED EAS
 - reworked ESB memory operations
 - improved KVM_XIVE_EQ_ALWAYS_NOTIFY handling
 - removed the capture of the OS CAM line value from KVM
 - merged in the handling of pending interrupts while the VM is stopped.
 - did an update in ics_set_kvm_state_one()
 - removed spapr_ics_create() 
 - introduced a spapr_irq_init_device() helper
 - reworked test on single initialization of the emulated IRQ device

Changes since v1:

 - Reworked most of the KVM interface
 - Reworked *All* hcalls which are now handled at the QEMU level,
   possibly extended with a KVM device ioctl when required.
 - TIMA and ESB special mapping done on the KVM device fd.
 - Tested on nested
 - Implemented the device fallback mode when a kernel_irqchip is not
   available and not required. Useful on nested to use XIVE. 
 - Fix device hotplug when VM is stopped (Is this necessary ?)


Cédric Le Goater (14):
  linux-headers: update linux headers to kvm-ppc-next-5.2-1
  spapr/xive: add KVM support
  spapr/xive: add hcall support when under KVM
  spapr/xive: add state synchronization with KVM
  spapr/xive: introduce a VM state change handler
  spapr/xive: add migration support for KVM
  spapr/xive: activate KVM support
  sysbus: add a sysbus_mmio_unmap() helper
  spapr: introduce routines to delete the KVM IRQ device
  spapr: check for the activation of the KVM IRQ device
  spapr/irq: introduce a spapr_irq_init_device() helper
  spapr/irq: initialize the IRQ device only once
  ppc/xics: fix irq priority in ics_set_irq_type()
  spapr/irq: add KVM support to the 'dual' machine

 include/hw/ppc/spapr_irq.h  |   2 +
 include/hw/ppc/spapr_xive.h |  39 ++
 include/hw/ppc/xics.h   |   1 +
 include/hw/ppc/xics_spapr.h |   1 +
 include/hw/ppc/xive.h   |  14 +
 include/hw/sysbus.h |   1 +
 linux-headers/asm-powerpc/kvm.h |  46 ++
 linux-headers/linux/kvm.h   |   3 +
 target/ppc/kvm_ppc.h|   6 +
 hw/core/sysbus.c|  10 +
 hw/intc/spapr_xive.c| 172 ++-
 hw/intc/spapr_xive_kvm.c| 827 
 hw/intc/xics.c  |  10 +-
 hw/intc/xics_kvm.c  | 113 -
 hw/intc/xics_spapr.c|   7 +
 hw/intc/xive.c  |  44 +-
 hw/ppc/spapr_irq.c  | 140 --
 target/ppc/kvm.c|   7 +
 hw/intc/Makefile.objs   |   1 +
 hw/ppc/Kconfig  |   5 +
 20 files changed, 1384 insertions(+), 65 deletions(-)
 create mode 100644 hw/intc/spapr_xive_kvm.c

-- 
2.20.1

[Qemu-devel] [PATCH v4 01/14] linux-headers: update linux headers to kvm-ppc-next-5.2-1

This updates the kvm headers to commit 0caecf5b0019 (kvm-ppc-next-5.2-1)
in branch kvm-ppc-next from :

  https://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git/

These changes provide the interface with the KVM device implementing
the XIVE native exploitation interrupt mode.

Signed-off-by: Cédric Le Goater 
---

 The XIVE capability number will conflict with kvm-arm :
 
 555f3d03e7fb ("KVM: arm64: Add a capability to advertise SVE support")
 a243c16d18be ("KVM: arm64: Add capability to advertise ptrauth for guest")

 linux-headers/asm-powerpc/kvm.h | 46 +
 linux-headers/linux/kvm.h   |  3 +++
 2 files changed, 49 insertions(+)

diff --git a/linux-headers/asm-powerpc/kvm.h b/linux-headers/asm-powerpc/kvm.h
index 8c876c166ef2..07daf7bf6fe4 100644
--- a/linux-headers/asm-powerpc/kvm.h
+++ b/linux-headers/asm-powerpc/kvm.h
@@ -480,6 +480,8 @@ struct kvm_ppc_cpu_char {
 #define  KVM_REG_PPC_ICP_PPRI_SHIFT16  /* pending irq priority */
 #define  KVM_REG_PPC_ICP_PPRI_MASK 0xff
 
+#define KVM_REG_PPC_VP_STATE   (KVM_REG_PPC | KVM_REG_SIZE_U128 | 0x8d)
+
 /* Device control API: PPC-specific devices */
 #define KVM_DEV_MPIC_GRP_MISC  1
 #define   KVM_DEV_MPIC_BASE_ADDR   0   /* 64-bit */
@@ -675,4 +677,48 @@ struct kvm_ppc_cpu_char {
 #define  KVM_XICS_PRESENTED(1ULL << 43)
 #define  KVM_XICS_QUEUED   (1ULL << 44)
 
+/* POWER9 XIVE Native Interrupt Controller */
+#define KVM_DEV_XIVE_GRP_CTRL  1
+#define   KVM_DEV_XIVE_RESET   1
+#define   KVM_DEV_XIVE_EQ_SYNC 2
+#define KVM_DEV_XIVE_GRP_SOURCE2   /* 64-bit source 
identifier */
+#define KVM_DEV_XIVE_GRP_SOURCE_CONFIG 3   /* 64-bit source identifier */
+#define KVM_DEV_XIVE_GRP_EQ_CONFIG 4   /* 64-bit EQ identifier */
+#define KVM_DEV_XIVE_GRP_SOURCE_SYNC   5   /* 64-bit source identifier */
+
+/* Layout of 64-bit XIVE source attribute values */
+#define KVM_XIVE_LEVEL_SENSITIVE   (1ULL << 0)
+#define KVM_XIVE_LEVEL_ASSERTED(1ULL << 1)
+
+/* Layout of 64-bit XIVE source configuration attribute values */
+#define KVM_XIVE_SOURCE_PRIORITY_SHIFT 0
+#define KVM_XIVE_SOURCE_PRIORITY_MASK  0x7
+#define KVM_XIVE_SOURCE_SERVER_SHIFT   3
+#define KVM_XIVE_SOURCE_SERVER_MASK0xfff8ULL
+#define KVM_XIVE_SOURCE_MASKED_SHIFT   32
+#define KVM_XIVE_SOURCE_MASKED_MASK0x1ULL
+#define KVM_XIVE_SOURCE_EISN_SHIFT 33
+#define KVM_XIVE_SOURCE_EISN_MASK  0xfffeULL
+
+/* Layout of 64-bit EQ identifier */
+#define KVM_XIVE_EQ_PRIORITY_SHIFT 0
+#define KVM_XIVE_EQ_PRIORITY_MASK  0x7
+#define KVM_XIVE_EQ_SERVER_SHIFT   3
+#define KVM_XIVE_EQ_SERVER_MASK0xfff8ULL
+
+/* Layout of EQ configuration values (64 bytes) */
+struct kvm_ppc_xive_eq {
+   __u32 flags;
+   __u32 qshift;
+   __u64 qaddr;
+   __u32 qtoggle;
+   __u32 qindex;
+   __u8  pad[40];
+};
+
+#define KVM_XIVE_EQ_ALWAYS_NOTIFY  0x0001
+
+#define KVM_XIVE_TIMA_PAGE_OFFSET  0
+#define KVM_XIVE_ESB_PAGE_OFFSET   4
+
 #endif /* __LINUX_KVM_POWERPC_H */
diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
index b53ee5974802..f78f9e072f7b 100644
--- a/linux-headers/linux/kvm.h
+++ b/linux-headers/linux/kvm.h
@@ -988,6 +988,7 @@ struct kvm_ppc_resize_hpt {
 #define KVM_CAP_ARM_VM_IPA_SIZE 165
 #define KVM_CAP_MANUAL_DIRTY_LOG_PROTECT 166
 #define KVM_CAP_HYPERV_CPUID 167
+#define KVM_CAP_PPC_IRQ_XIVE 168
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
@@ -1211,6 +1212,8 @@ enum kvm_device_type {
 #define KVM_DEV_TYPE_ARM_VGIC_V3   KVM_DEV_TYPE_ARM_VGIC_V3
KVM_DEV_TYPE_ARM_VGIC_ITS,
 #define KVM_DEV_TYPE_ARM_VGIC_ITS  KVM_DEV_TYPE_ARM_VGIC_ITS
+   KVM_DEV_TYPE_XIVE,
+#define KVM_DEV_TYPE_XIVE  KVM_DEV_TYPE_XIVE
KVM_DEV_TYPE_MAX,
 };
 
-- 
2.20.1

[Qemu-devel] [PATCH v4 03/14] spapr/xive: add hcall support when under KVM

XIVE hcalls are all redirected to QEMU as none are on a fast path.
When necessary, QEMU invokes KVM through specific ioctls to perform
host operations. QEMU should have done the necessary checks before
calling KVM and, in case of failure, H_HARDWARE is simply returned.

H_INT_ESB is a special case that could have been handled under KVM
but the impact on performance was low when under QEMU. Here are some
figures :

kernel irqchip  OFF  ON
H_INT_ESBKVM   QEMU

rtl8139 (LSI )  1.19 1.24  1.23  Gbits/sec
virtio 31.8042.30   --   Gbits/sec

Signed-off-by: Cédric Le Goater 
Reviewed-by: David Gibson 
---

 Changes since v3:

 - added usage of xive_end_qaddr() helper

 include/hw/ppc/spapr_xive.h |  15 +++
 hw/intc/spapr_xive.c|  90 ++--
 hw/intc/spapr_xive_kvm.c| 197 
 3 files changed, 294 insertions(+), 8 deletions(-)

diff --git a/include/hw/ppc/spapr_xive.h b/include/hw/ppc/spapr_xive.h
index 0edcc762dedd..03685910e76b 100644
--- a/include/hw/ppc/spapr_xive.h
+++ b/include/hw/ppc/spapr_xive.h
@@ -55,9 +55,24 @@ void spapr_xive_set_tctx_os_cam(XiveTCTX *tctx);
 void spapr_xive_mmio_set_enabled(SpaprXive *xive, bool enable);
 void spapr_xive_map_mmio(SpaprXive *xive);
 
+int spapr_xive_end_to_target(uint8_t end_blk, uint32_t end_idx,
+ uint32_t *out_server, uint8_t *out_prio);
+
 /*
  * KVM XIVE device helpers
  */
 void kvmppc_xive_connect(SpaprXive *xive, Error **errp);
+void kvmppc_xive_reset(SpaprXive *xive, Error **errp);
+void kvmppc_xive_set_source_config(SpaprXive *xive, uint32_t lisn, XiveEAS 
*eas,
+   Error **errp);
+void kvmppc_xive_sync_source(SpaprXive *xive, uint32_t lisn, Error **errp);
+uint64_t kvmppc_xive_esb_rw(XiveSource *xsrc, int srcno, uint32_t offset,
+uint64_t data, bool write);
+void kvmppc_xive_set_queue_config(SpaprXive *xive, uint8_t end_blk,
+ uint32_t end_idx, XiveEND *end,
+ Error **errp);
+void kvmppc_xive_get_queue_config(SpaprXive *xive, uint8_t end_blk,
+ uint32_t end_idx, XiveEND *end,
+ Error **errp);
 
 #endif /* PPC_SPAPR_XIVE_H */
diff --git a/hw/intc/spapr_xive.c b/hw/intc/spapr_xive.c
index 1390fc109c80..6beda26ee440 100644
--- a/hw/intc/spapr_xive.c
+++ b/hw/intc/spapr_xive.c
@@ -86,6 +86,22 @@ static int spapr_xive_target_to_nvt(uint32_t target,
  * sPAPR END indexing uses a simple mapping of the CPU vcpu_id, 8
  * priorities per CPU
  */
+int spapr_xive_end_to_target(uint8_t end_blk, uint32_t end_idx,
+ uint32_t *out_server, uint8_t *out_prio)
+{
+
+assert(end_blk == SPAPR_XIVE_BLOCK_ID);
+
+if (out_server) {
+*out_server = end_idx >> 3;
+}
+
+if (out_prio) {
+*out_prio = end_idx & 0x7;
+}
+return 0;
+}
+
 static void spapr_xive_cpu_to_end(PowerPCCPU *cpu, uint8_t prio,
   uint8_t *out_end_blk, uint32_t *out_end_idx)
 {
@@ -792,6 +808,16 @@ static target_ulong h_int_set_source_config(PowerPCCPU 
*cpu,
 new_eas.w = xive_set_field64(EAS_END_DATA, new_eas.w, eisn);
 }
 
+if (kvm_irqchip_in_kernel()) {
+Error *local_err = NULL;
+
+kvmppc_xive_set_source_config(xive, lisn, &new_eas, &local_err);
+if (local_err) {
+error_report_err(local_err);
+return H_HARDWARE;
+}
+}
+
 out:
 xive->eat[lisn] = new_eas;
 return H_SUCCESS;
@@ -1103,6 +1129,16 @@ static target_ulong h_int_set_queue_config(PowerPCCPU 
*cpu,
  */
 
 out:
+if (kvm_irqchip_in_kernel()) {
+Error *local_err = NULL;
+
+kvmppc_xive_set_queue_config(xive, end_blk, end_idx, &end, &local_err);
+if (local_err) {
+error_report_err(local_err);
+return H_HARDWARE;
+}
+}
+
 /* Update END */
 memcpy(&xive->endt[end_idx], &end, sizeof(XiveEND));
 return H_SUCCESS;
@@ -1194,6 +1230,16 @@ static target_ulong h_int_get_queue_config(PowerPCCPU 
*cpu,
 args[2] = 0;
 }
 
+if (kvm_irqchip_in_kernel()) {
+Error *local_err = NULL;
+
+kvmppc_xive_get_queue_config(xive, end_blk, end_idx, end, &local_err);
+if (local_err) {
+error_report_err(local_err);
+return H_HARDWARE;
+}
+}
+
 /* TODO: do we need any locking on the END ? */
 if (flags & SPAPR_XIVE_END_DEBUG) {
 /* Load the event queue generation number into the return flags */
@@ -1346,15 +1392,20 @@ static target_ulong h_int_esb(PowerPCCPU *cpu,
 return H_P3;
 }
 
-mmio_addr = xive->vc_base + xive_source_esb_mgmt(xsrc, lisn) + offset;
+if (kvm_irqchip_in_kernel()) {
+args[0] = kvmppc_xive_esb_rw(xsrc, lisn, offset, data,
+ fl

[Qemu-devel] [PATCH v4 02/14] spapr/xive: add KVM support

This introduces a set of helpers when KVM is in use, which create the
KVM XIVE device, initialize the interrupt sources at a KVM level and
connect the interrupt presenters to the vCPU.

They also handle the initialization of the TIMA and the source ESB
memory regions of the controller. These have a different type under
KVM. They are 'ram device' memory mappings, similarly to VFIO, exposed
to the guest and the associated VMAs on the host are populated
dynamically with the appropriate pages using a fault handler.

Signed-off-by: Cédric Le Goater 
Reviewed-by: David Gibson 
---
 include/hw/ppc/spapr_xive.h |  10 ++
 include/hw/ppc/xive.h   |  13 ++
 target/ppc/kvm_ppc.h|   6 +
 hw/intc/spapr_xive.c|  48 +++-
 hw/intc/spapr_xive_kvm.c| 237 
 hw/intc/xive.c  |  21 +++-
 hw/ppc/spapr_irq.c  |   6 +-
 target/ppc/kvm.c|   7 ++
 hw/intc/Makefile.objs   |   1 +
 hw/ppc/Kconfig  |   5 +
 10 files changed, 344 insertions(+), 10 deletions(-)
 create mode 100644 hw/intc/spapr_xive_kvm.c

diff --git a/include/hw/ppc/spapr_xive.h b/include/hw/ppc/spapr_xive.h
index fc3e9652f99a..0edcc762dedd 100644
--- a/include/hw/ppc/spapr_xive.h
+++ b/include/hw/ppc/spapr_xive.h
@@ -38,6 +38,10 @@ typedef struct SpaprXive {
 /* TIMA mapping address */
 hwaddrtm_base;
 MemoryRegion  tm_mmio;
+
+/* KVM support */
+int   fd;
+void  *tm_mmap;
 } SpaprXive;
 
 bool spapr_xive_irq_claim(SpaprXive *xive, uint32_t lisn, bool lsi);
@@ -49,5 +53,11 @@ void spapr_dt_xive(SpaprMachineState *spapr, uint32_t 
nr_servers, void *fdt,
uint32_t phandle);
 void spapr_xive_set_tctx_os_cam(XiveTCTX *tctx);
 void spapr_xive_mmio_set_enabled(SpaprXive *xive, bool enable);
+void spapr_xive_map_mmio(SpaprXive *xive);
+
+/*
+ * KVM XIVE device helpers
+ */
+void kvmppc_xive_connect(SpaprXive *xive, Error **errp);
 
 #endif /* PPC_SPAPR_XIVE_H */
diff --git a/include/hw/ppc/xive.h b/include/hw/ppc/xive.h
index c4f27742ca09..dd115da30ebc 100644
--- a/include/hw/ppc/xive.h
+++ b/include/hw/ppc/xive.h
@@ -140,6 +140,7 @@
 #ifndef PPC_XIVE_H
 #define PPC_XIVE_H
 
+#include "sysemu/kvm.h"
 #include "hw/qdev-core.h"
 #include "hw/sysbus.h"
 #include "hw/ppc/xive_regs.h"
@@ -194,6 +195,9 @@ typedef struct XiveSource {
 uint32_tesb_shift;
 MemoryRegionesb_mmio;
 
+/* KVM support */
+void*esb_mmap;
+
 XiveNotifier*xive;
 } XiveSource;
 
@@ -423,4 +427,13 @@ static inline uint32_t xive_nvt_cam_line(uint8_t nvt_blk, 
uint32_t nvt_idx)
 return (nvt_blk << 19) | nvt_idx;
 }
 
+/*
+ * KVM XIVE device helpers
+ */
+
+void kvmppc_xive_source_reset_one(XiveSource *xsrc, int srcno, Error **errp);
+void kvmppc_xive_source_reset(XiveSource *xsrc, Error **errp);
+void kvmppc_xive_source_set_irq(void *opaque, int srcno, int val);
+void kvmppc_xive_cpu_connect(XiveTCTX *tctx, Error **errp);
+
 #endif /* PPC_XIVE_H */
diff --git a/target/ppc/kvm_ppc.h b/target/ppc/kvm_ppc.h
index 22385134b44d..45776cad79d9 100644
--- a/target/ppc/kvm_ppc.h
+++ b/target/ppc/kvm_ppc.h
@@ -60,6 +60,7 @@ bool kvmppc_has_cap_fixup_hcalls(void);
 bool kvmppc_has_cap_htm(void);
 bool kvmppc_has_cap_mmu_radix(void);
 bool kvmppc_has_cap_mmu_hash_v3(void);
+bool kvmppc_has_cap_xive(void);
 int kvmppc_get_cap_safe_cache(void);
 int kvmppc_get_cap_safe_bounds_check(void);
 int kvmppc_get_cap_safe_indirect_branch(void);
@@ -316,6 +317,11 @@ static inline bool kvmppc_has_cap_mmu_hash_v3(void)
 return false;
 }
 
+static inline bool kvmppc_has_cap_xive(void)
+{
+return false;
+}
+
 static inline int kvmppc_get_cap_safe_cache(void)
 {
 return 0;
diff --git a/hw/intc/spapr_xive.c b/hw/intc/spapr_xive.c
index df3c879826b4..1390fc109c80 100644
--- a/hw/intc/spapr_xive.c
+++ b/hw/intc/spapr_xive.c
@@ -174,7 +174,7 @@ void spapr_xive_pic_print_info(SpaprXive *xive, Monitor 
*mon)
 }
 }
 
-static void spapr_xive_map_mmio(SpaprXive *xive)
+void spapr_xive_map_mmio(SpaprXive *xive)
 {
 sysbus_mmio_map(SYS_BUS_DEVICE(xive), 0, xive->vc_base);
 sysbus_mmio_map(SYS_BUS_DEVICE(xive), 1, xive->end_base);
@@ -251,6 +251,9 @@ static void spapr_xive_instance_init(Object *obj)
 object_initialize_child(obj, "end_source", &xive->end_source,
 sizeof(xive->end_source), TYPE_XIVE_END_SOURCE,
 &error_abort, NULL);
+
+/* Not connected to the KVM XIVE device */
+xive->fd = -1;
 }
 
 static void spapr_xive_realize(DeviceState *dev, Error **errp)
@@ -259,6 +262,7 @@ static void spapr_xive_realize(DeviceState *dev, Error 
**errp)
 XiveSource *xsrc = &xive->source;
 XiveENDSource *end_xsrc = &xive->end_source;
 Error *local_err = NULL;
+MachineState *machine = MACHINE(qdev_get_machine());
 
 if (!xive->nr_irqs) {
 error_setg(errp, "Number of interrupt needs to be greater 0");
@@ -305,6 +309,32 @@ sta

[Qemu-devel] [PATCH v4 05/14] spapr/xive: introduce a VM state change handler

This handler is in charge of stabilizing the flow of event notifications
in the XIVE controller before migrating a guest. This is a requirement
before transferring the guest EQ pages to a destination.

When the VM is stopped, the handler sets the source PQs to PENDING to
stop the flow of events and to possibly catch a triggered interrupt
occuring while the VM is stopped. Their previous state is saved. The
XIVE controller is then synced through KVM to flush any in-flight
event notification and to stabilize the EQs. At this stage, the EQ
pages are marked dirty to make sure the EQ pages are transferred if a
migration sequence is in progress.

The previous configuration of the sources is restored when the VM
resumes, after a migration or a stop. If an interrupt was queued while
the VM was stopped, the handler simply generates the missing trigger.

Signed-off-by: Cédric Le Goater 
Reviewed-by: David Gibson 
---
 include/hw/ppc/spapr_xive.h |  1 +
 hw/intc/spapr_xive_kvm.c| 96 -
 2 files changed, 96 insertions(+), 1 deletion(-)

diff --git a/include/hw/ppc/spapr_xive.h b/include/hw/ppc/spapr_xive.h
index 7e49badd8c9a..734662c12a10 100644
--- a/include/hw/ppc/spapr_xive.h
+++ b/include/hw/ppc/spapr_xive.h
@@ -42,6 +42,7 @@ typedef struct SpaprXive {
 /* KVM support */
 int   fd;
 void  *tm_mmap;
+VMChangeStateEntry *change;
 } SpaprXive;
 
 /*
diff --git a/hw/intc/spapr_xive_kvm.c b/hw/intc/spapr_xive_kvm.c
index 8dd4f96e0b97..735577a6f816 100644
--- a/hw/intc/spapr_xive_kvm.c
+++ b/hw/intc/spapr_xive_kvm.c
@@ -433,9 +433,100 @@ static void kvmppc_xive_get_queues(SpaprXive *xive, Error 
**errp)
 }
 }
 
+/*
+ * The primary goal of the XIVE VM change handler is to mark the EQ
+ * pages dirty when all XIVE event notifications have stopped.
+ *
+ * Whenever the VM is stopped, the VM change handler sets the source
+ * PQs to PENDING to stop the flow of events and to possibly catch a
+ * triggered interrupt occuring while the VM is stopped. The previous
+ * state is saved in anticipation of a migration. The XIVE controller
+ * is then synced through KVM to flush any in-flight event
+ * notification and stabilize the EQs.
+ *
+ * At this stage, we can mark the EQ page dirty and let a migration
+ * sequence transfer the EQ pages to the destination, which is done
+ * just after the stop state.
+ *
+ * The previous configuration of the sources is restored when the VM
+ * runs again. If an interrupt was queued while the VM was stopped,
+ * simply generate a trigger.
+ */
+static void kvmppc_xive_change_state_handler(void *opaque, int running,
+ RunState state)
+{
+SpaprXive *xive = opaque;
+XiveSource *xsrc = &xive->source;
+Error *local_err = NULL;
+int i;
+
+/*
+ * Restore the sources to their initial state. This is called when
+ * the VM resumes after a stop or a migration.
+ */
+if (running) {
+for (i = 0; i < xsrc->nr_irqs; i++) {
+uint8_t pq = xive_source_esb_get(xsrc, i);
+uint8_t old_pq;
+
+old_pq = xive_esb_read(xsrc, i, XIVE_ESB_SET_PQ_00 + (pq << 8));
+
+/*
+ * An interrupt was queued while the VM was stopped,
+ * generate a trigger.
+ */
+if (pq == XIVE_ESB_RESET && old_pq == XIVE_ESB_QUEUED) {
+xive_esb_trigger(xsrc, i);
+}
+}
+
+return;
+}
+
+/*
+ * Mask the sources, to stop the flow of event notifications, and
+ * save the PQs locally in the XiveSource object. The XiveSource
+ * state will be collected later on by its vmstate handler if a
+ * migration is in progress.
+ */
+for (i = 0; i < xsrc->nr_irqs; i++) {
+uint8_t pq = xive_esb_read(xsrc, i, XIVE_ESB_GET);
+
+/*
+ * PQ is set to PENDING to possibly catch a triggered
+ * interrupt occuring while the VM is stopped (hotplug event
+ * for instance) .
+ */
+if (pq != XIVE_ESB_OFF) {
+pq = xive_esb_read(xsrc, i, XIVE_ESB_SET_PQ_10);
+}
+xive_source_esb_set(xsrc, i, pq);
+}
+
+/*
+ * Sync the XIVE controller in KVM, to flush in-flight event
+ * notification that should be enqueued in the EQs and mark the
+ * XIVE EQ pages dirty to collect all updates.
+ */
+kvm_device_access(xive->fd, KVM_DEV_XIVE_GRP_CTRL,
+  KVM_DEV_XIVE_EQ_SYNC, NULL, true, &local_err);
+if (local_err) {
+error_report_err(local_err);
+return;
+}
+}
+
 void kvmppc_xive_synchronize_state(SpaprXive *xive, Error **errp)
 {
-kvmppc_xive_source_get_state(&xive->source);
+/*
+ * When the VM is stopped, the sources are masked and the previous
+ * state is saved in anticipation of a migration. We should not
+ * synchronize the source state in that case else we will override
+ * the saved state

[Qemu-devel] [PATCH v4 10/14] spapr: check for the activation of the KVM IRQ device

The activation of the KVM IRQ device depends on the interrupt mode
chosen at CAS time by the machine and some methods used at reset or by
the migration need to be protected.

Signed-off-by: Cédric Le Goater 
Reviewed-by: David Gibson 
Signed-off-by: Cédric Le Goater 
---

 May be we can improve these checkd by using spapr->ov5_cas in some
 cases.

 Changes since v3:

 - update in kvmppc_xive_source_reset_one()

 hw/intc/spapr_xive_kvm.c | 33 +
 hw/intc/xics_kvm.c   | 31 ++-
 2 files changed, 63 insertions(+), 1 deletion(-)

diff --git a/hw/intc/spapr_xive_kvm.c b/hw/intc/spapr_xive_kvm.c
index 259cd1db9582..078d18d7757f 100644
--- a/hw/intc/spapr_xive_kvm.c
+++ b/hw/intc/spapr_xive_kvm.c
@@ -90,9 +90,15 @@ static void kvmppc_xive_cpu_set_state(XiveTCTX *tctx, Error 
**errp)
 
 void kvmppc_xive_cpu_get_state(XiveTCTX *tctx, Error **errp)
 {
+SpaprXive *xive = SPAPR_MACHINE(qdev_get_machine())->xive;
 uint64_t state[2] = { 0 };
 int ret;
 
+/* The KVM XIVE device is not in use */
+if (xive->fd == -1) {
+return;
+}
+
 ret = kvm_get_one_reg(tctx->cs, KVM_REG_PPC_VP_STATE, state);
 if (ret != 0) {
 error_setg_errno(errp, errno,
@@ -143,6 +149,11 @@ void kvmppc_xive_cpu_connect(XiveTCTX *tctx, Error **errp)
 unsigned long vcpu_id;
 int ret;
 
+/* The KVM XIVE device is not in use */
+if (xive->fd == -1) {
+return;
+}
+
 /* Check if CPU was hot unplugged and replugged. */
 if (kvm_cpu_is_enabled(tctx->cs)) {
 return;
@@ -219,6 +230,11 @@ void kvmppc_xive_source_reset_one(XiveSource *xsrc, int 
srcno, Error **errp)
 SpaprXive *xive = SPAPR_XIVE(xsrc->xive);
 uint64_t state = 0;
 
+/* The KVM XIVE device is not in use */
+if (xive->fd == -1) {
+return;
+}
+
 if (xive_source_irq_is_lsi(xsrc, srcno)) {
 state |= KVM_XIVE_LEVEL_SENSITIVE;
 if (xsrc->status[srcno] & XIVE_STATUS_ASSERTED) {
@@ -319,9 +335,13 @@ static void kvmppc_xive_source_get_state(XiveSource *xsrc)
 void kvmppc_xive_source_set_irq(void *opaque, int srcno, int val)
 {
 XiveSource *xsrc = opaque;
+SpaprXive *xive = SPAPR_XIVE(xsrc->xive);
 struct kvm_irq_level args;
 int rc;
 
+/* The KVM XIVE device should be in use */
+assert(xive->fd != -1);
+
 args.irq = srcno;
 if (!xive_source_irq_is_lsi(xsrc, srcno)) {
 if (!val) {
@@ -546,6 +566,11 @@ static void kvmppc_xive_change_state_handler(void *opaque, 
int running,
 
 void kvmppc_xive_synchronize_state(SpaprXive *xive, Error **errp)
 {
+/* The KVM XIVE device is not in use */
+if (xive->fd == -1) {
+return;
+}
+
 /*
  * When the VM is stopped, the sources are masked and the previous
  * state is saved in anticipation of a migration. We should not
@@ -571,6 +596,11 @@ int kvmppc_xive_pre_save(SpaprXive *xive)
 {
 Error *local_err = NULL;
 
+/* The KVM XIVE device is not in use */
+if (xive->fd == -1) {
+return 0;
+}
+
 /* EAT: there is no extra state to query from KVM */
 
 /* ENDT */
@@ -595,6 +625,9 @@ int kvmppc_xive_post_load(SpaprXive *xive, int version_id)
 CPUState *cs;
 int i;
 
+/* The KVM XIVE device should be in use */
+assert(xive->fd != -1);
+
 /* Restore the ENDT first. The targetting depends on it. */
 for (i = 0; i < xive->nr_ends; i++) {
 if (!xive_end_is_valid(&xive->endt[i])) {
diff --git a/hw/intc/xics_kvm.c b/hw/intc/xics_kvm.c
index 1185846ff183..12bd5190cfad 100644
--- a/hw/intc/xics_kvm.c
+++ b/hw/intc/xics_kvm.c
@@ -69,6 +69,11 @@ void icp_get_kvm_state(ICPState *icp)
 uint64_t state;
 int ret;
 
+/* The KVM XICS device is not in use */
+if (kernel_xics_fd == -1) {
+return;
+}
+
 /* ICP for this CPU thread is not in use, exiting */
 if (!icp->cs) {
 return;
@@ -105,6 +110,11 @@ int icp_set_kvm_state(ICPState *icp)
 uint64_t state;
 int ret;
 
+/* The KVM XICS device is not in use */
+if (kernel_xics_fd == -1) {
+return 0;
+}
+
 /* ICP for this CPU thread is not in use, exiting */
 if (!icp->cs) {
 return 0;
@@ -133,8 +143,9 @@ void icp_kvm_realize(DeviceState *dev, Error **errp)
 unsigned long vcpu_id;
 int ret;
 
+/* The KVM XICS device is not in use */
 if (kernel_xics_fd == -1) {
-abort();
+return;
 }
 
 cs = icp->cs;
@@ -170,6 +181,11 @@ void ics_get_kvm_state(ICSState *ics)
 uint64_t state;
 int i;
 
+/* The KVM XICS device is not in use */
+if (kernel_xics_fd == -1) {
+return;
+}
+
 for (i = 0; i < ics->nr_irqs; i++) {
 ICSIRQState *irq = &ics->irqs[i];
 
@@ -230,6 +246,11 @@ int ics_set_kvm_state_one(ICSState *ics, int srcno)
 ICSIRQState *irq = &ics->irqs[srcno];
 int ret;
 
+/* The KVM XICS device is not in use */
+if (kernel_xics_fd == -1) {
+retu

Re: [Qemu-devel] [PATCH v3 0/3] rng-builtin: add an RNG backend that uses qemu_guest_getrandom()

2019-05-13 Thread Kashyap Chamarthy

On Mon, May 13, 2019 at 08:36:23AM +0200, Laurent Vivier wrote:
> On 12/05/2019 20:21, Michael S. Tsirkin wrote:

[...]

> > > Kashyap Chamarthy (1):
> > >VirtIO-RNG: Update default entropy source to `/dev/urandom`
> > > 
> > > Laurent Vivier (2):
> > >rng-builtin: add an RNG backend that uses qemu_guest_getrandom()
> > >virtio-rng: change default backend to rng-builtin
> > 
> > 
> > OK pls address Marku's comment on commit msg and I will merge.
> 
> Kashyap,
> 
> as this patch is from you, do you agree?

Yes.

> If so, I can update the message and send a new version of the series
> (or you canr esend your patch alone if you prefer).

Please go ahead and add it, the below is the text (from Dan/Markus):

What about other OSes?
--

`/dev/urandom` exists and works on OS-X, FreeBSD, DragonFlyBSD, NetBSD
and OpenBSD, which cover all the non-Linux platforms we explicitly
support, aside from Windows.

On Windows `/dev/random` doesn't work either so we don't regress.
This is actually another argument in favour of using the newly
proposed 'rng-builtin' backend by default, as that will work on
Windows.

Thanks!

[...]

-- 
/kashyap

[Qemu-devel] [PATCH v4 14/14] spapr/irq: add KVM support to the 'dual' machine

The interrupt mode is chosen by the CAS negotiation process and
activated after a reset to take into account the required changes in
the machine. This brings new constraints on how the associated KVM IRQ
device is initialized.

Currently, each model takes care of the initialization of the KVM
device in their realize method but this is not possible anymore as the
initialization needs to be done globaly when the interrupt mode is
known, i.e. when machine is reseted. It also means that we need a way
to delete a KVM device when another mode is chosen.

Also, to support migration, the QEMU objects holding the state to
transfer should always be available but not necessarily activated.

The overall approach of this proposal is to initialize both interrupt
mode at the QEMU level to keep the IRQ number space in sync and to
allow switching from one mode to another. For the KVM side of things,
the whole initialization of the KVM device, sources and presenters, is
grouped in a single routine. The XICS and XIVE sPAPR IRQ reset
handlers are modified accordingly to handle the init and the delete
sequences of the KVM device.

Signed-off-by: Cédric Le Goater 
Reviewed-by: David Gibson 
---

 Changes since v3:

 - removed extra spapr_irq_init_device() in spapr_irq_init_xive() 
 - reworked slightly the code sequence in xics_kvm_init() creating the
   presenters and connecting them to the KVM XICS device.
 
 include/hw/ppc/xive.h|  1 -
 hw/intc/spapr_xive_kvm.c | 29 +++-
 hw/intc/xics_kvm.c   | 31 +
 hw/intc/xive.c   |  4 ---
 hw/ppc/spapr_irq.c   | 58 ++--
 5 files changed, 97 insertions(+), 26 deletions(-)

diff --git a/include/hw/ppc/xive.h b/include/hw/ppc/xive.h
index edb8937f17fb..d872f96d1a1b 100644
--- a/include/hw/ppc/xive.h
+++ b/include/hw/ppc/xive.h
@@ -432,7 +432,6 @@ static inline uint32_t xive_nvt_cam_line(uint8_t nvt_blk, 
uint32_t nvt_idx)
  */
 
 void kvmppc_xive_source_reset_one(XiveSource *xsrc, int srcno, Error **errp);
-void kvmppc_xive_source_reset(XiveSource *xsrc, Error **errp);
 void kvmppc_xive_source_set_irq(void *opaque, int srcno, int val);
 void kvmppc_xive_cpu_connect(XiveTCTX *tctx, Error **errp);
 void kvmppc_xive_cpu_synchronize_state(XiveTCTX *tctx, Error **errp);
diff --git a/hw/intc/spapr_xive_kvm.c b/hw/intc/spapr_xive_kvm.c
index 078d18d7757f..ec170b304555 100644
--- a/hw/intc/spapr_xive_kvm.c
+++ b/hw/intc/spapr_xive_kvm.c
@@ -246,7 +246,7 @@ void kvmppc_xive_source_reset_one(XiveSource *xsrc, int 
srcno, Error **errp)
   true, errp);
 }
 
-void kvmppc_xive_source_reset(XiveSource *xsrc, Error **errp)
+static void kvmppc_xive_source_reset(XiveSource *xsrc, Error **errp)
 {
 int i;
 
@@ -697,6 +697,15 @@ void kvmppc_xive_connect(SpaprXive *xive, Error **errp)
 Error *local_err = NULL;
 size_t esb_len = (1ull << xsrc->esb_shift) * xsrc->nr_irqs;
 size_t tima_len = 4ull << TM_SHIFT;
+CPUState *cs;
+
+/*
+ * The KVM XIVE device already in use. This is the case when
+ * rebooting under the XIVE-only interrupt mode.
+ */
+if (xive->fd != -1) {
+return;
+}
 
 if (!kvmppc_has_cap_xive()) {
 error_setg(errp, "IRQ_XIVE capability must be present for KVM");
@@ -745,6 +754,24 @@ void kvmppc_xive_connect(SpaprXive *xive, Error **errp)
 xive->change = qemu_add_vm_change_state_handler(
 kvmppc_xive_change_state_handler, xive);
 
+/* Connect the presenters to the initial VCPUs of the machine */
+CPU_FOREACH(cs) {
+PowerPCCPU *cpu = POWERPC_CPU(cs);
+
+kvmppc_xive_cpu_connect(spapr_cpu_state(cpu)->tctx, &local_err);
+if (local_err) {
+error_propagate(errp, local_err);
+return;
+}
+}
+
+/* Update the KVM sources */
+kvmppc_xive_source_reset(xsrc, &local_err);
+if (local_err) {
+error_propagate(errp, local_err);
+return;
+}
+
 kvm_kernel_irqchip = true;
 kvm_msi_via_irqfd_allowed = true;
 kvm_gsi_direct_mapping = true;
diff --git a/hw/intc/xics_kvm.c b/hw/intc/xics_kvm.c
index 12bd5190cfad..5ba5b775615e 100644
--- a/hw/intc/xics_kvm.c
+++ b/hw/intc/xics_kvm.c
@@ -33,6 +33,7 @@
 #include "trace.h"
 #include "sysemu/kvm.h"
 #include "hw/ppc/spapr.h"
+#include "hw/ppc/spapr_cpu_core.h"
 #include "hw/ppc/xics.h"
 #include "hw/ppc/xics_spapr.h"
 #include "kvm_ppc.h"
@@ -342,6 +343,16 @@ static void rtas_dummy(PowerPCCPU *cpu, SpaprMachineState 
*spapr,
 int xics_kvm_init(SpaprMachineState *spapr, Error **errp)
 {
 int rc;
+CPUState *cs;
+Error *local_err = NULL;
+
+/*
+ * The KVM XICS device already in use. This is the case when
+ * rebooting under the XICS-only interrupt mode.
+ */
+if (kernel_xics_fd != -1) {
+return 0;
+}
 
 if (!kvm_enabled() || !kvm_check_extension(kvm_state, KVM_CAP_IRQ_XICS)) {
 error_setg(errp,
@@ -390,6 +401,26 @@ int xics_kvm

[Qemu-devel] [PATCH v4 13/14] ppc/xics: fix irq priority in ics_set_irq_type()

Recent commits changed the behavior of ics_set_irq_type() to
initialize correctly LSIs at the KVM level. ics_set_irq_type() is also
called by the realize routine of the different devices of the machine
when initial interrupts are claimed, before the ICSState device is
reseted.

In the case, the ICSIRQState priority is 0x0 and the call to
ics_set_irq_type() results in configuring the target of the
interrupt. On P9, when using the KVM XICS-on-XIVE device, the target
is configured to be server 0, priority 0 and the event queue 0 is
created automatically by KVM.

With the dual interrupt mode creating the KVM device at reset, it
leads to unexpected effects on the guest, mostly blocking IPIs. This
is wrong, fix it by reseting the ICSIRQState structure when
ics_set_irq_type() is called.

Fixes: commit 6cead90c5c9c ("xics: Write source state to KVM at claim time")
Signed-off-by: Greg Kurz 
Signed-off-by: Cédric Le Goater 
---
 hw/intc/xics.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/hw/intc/xics.c b/hw/intc/xics.c
index af7dc709abab..79f5a8a91665 100644
--- a/hw/intc/xics.c
+++ b/hw/intc/xics.c
@@ -610,6 +610,12 @@ static const TypeInfo ics_simple_info = {
 .class_size = sizeof(ICSStateClass),
 };
 
+static void ics_reset_irq(ICSIRQState *irq)
+{
+irq->priority = 0xff;
+irq->saved_priority = 0xff;
+}
+
 static void ics_base_reset(DeviceState *dev)
 {
 ICSState *ics = ICS_BASE(dev);
@@ -623,8 +629,7 @@ static void ics_base_reset(DeviceState *dev)
 memset(ics->irqs, 0, sizeof(ICSIRQState) * ics->nr_irqs);
 
 for (i = 0; i < ics->nr_irqs; i++) {
-ics->irqs[i].priority = 0xff;
-ics->irqs[i].saved_priority = 0xff;
+ics_reset_irq(ics->irqs + i);
 ics->irqs[i].flags = flags[i];
 }
 }
@@ -760,6 +765,7 @@ void ics_set_irq_type(ICSState *ics, int srcno, bool lsi)
 lsi ? XICS_FLAGS_IRQ_LSI : XICS_FLAGS_IRQ_MSI;
 
 if (kvm_irqchip_in_kernel()) {
+ics_reset_irq(ics->irqs + srcno);
 ics_set_kvm_state_one(ics, srcno);
 }
 }
-- 
2.20.1

[Qemu-devel] [PATCH v4 12/14] spapr/irq: initialize the IRQ device only once

Add a check to make sure that the routine initializing the emulated
IRQ device is called once. We don't have much to test on the XICS
side, so we introduce a 'init' boolean under ICSState.

Signed-off-by: Cédric Le Goater 
---

 Changes since v3:

 - introduced a 'init' boolean under ICSState
 
 include/hw/ppc/xics.h | 1 +
 hw/intc/spapr_xive.c  | 9 +
 hw/intc/xics_spapr.c  | 7 +++
 3 files changed, 17 insertions(+)

diff --git a/include/hw/ppc/xics.h b/include/hw/ppc/xics.h
index eb65ad7e43b7..d6f8e4c4c282 100644
--- a/include/hw/ppc/xics.h
+++ b/include/hw/ppc/xics.h
@@ -119,6 +119,7 @@ struct ICSState {
 uint32_t offset;
 ICSIRQState *irqs;
 XICSFabric *xics;
+bool init; /* sPAPR ICS device initialized */
 };
 
 #define ICS_PROP_XICS "xics"
diff --git a/hw/intc/spapr_xive.c b/hw/intc/spapr_xive.c
index 246b21ae7f31..1e649d6cdbe1 100644
--- a/hw/intc/spapr_xive.c
+++ b/hw/intc/spapr_xive.c
@@ -338,6 +338,15 @@ void spapr_xive_init(SpaprXive *xive, Error **errp)
 XiveSource *xsrc = &xive->source;
 XiveENDSource *end_xsrc = &xive->end_source;
 
+/*
+ * The emulated XIVE device can only be initialized once. If the
+ * ESB memory region has been already mapped, it means we have been
+ * through there.
+ */
+if (memory_region_is_mapped(&xsrc->esb_mmio)) {
+return;
+}
+
 /* TIMA initialization */
 memory_region_init_io(&xive->tm_mmio, OBJECT(xive), &xive_tm_ops, xive,
   "xive.tima", 4ull << TM_SHIFT);
diff --git a/hw/intc/xics_spapr.c b/hw/intc/xics_spapr.c
index 9d2b8adef7c5..5a1835e8b1ed 100644
--- a/hw/intc/xics_spapr.c
+++ b/hw/intc/xics_spapr.c
@@ -239,6 +239,13 @@ static void rtas_int_on(PowerPCCPU *cpu, SpaprMachineState 
*spapr,
 
 void xics_spapr_init(SpaprMachineState *spapr)
 {
+/* Emulated mode can only be initialized once. */
+if (spapr->ics->init) {
+return;
+}
+
+spapr->ics->init = true;
+
 /* Registration of global state belongs into realize */
 spapr_rtas_register(RTAS_IBM_SET_XIVE, "ibm,set-xive", rtas_set_xive);
 spapr_rtas_register(RTAS_IBM_GET_XIVE, "ibm,get-xive", rtas_get_xive);
-- 
2.20.1

[Qemu-devel] [PATCH v4 08/14] sysbus: add a sysbus_mmio_unmap() helper

This will be used to remove the MMIO regions of the POWER9 XIVE
interrupt controller when the sPAPR machine is reseted.

Signed-off-by: Cédric Le Goater 
Reviewed-by: David Gibson 
---
 include/hw/sysbus.h |  1 +
 hw/core/sysbus.c| 10 ++
 2 files changed, 11 insertions(+)

diff --git a/include/hw/sysbus.h b/include/hw/sysbus.h
index 1aedcf05c92b..4c668fbbdc60 100644
--- a/include/hw/sysbus.h
+++ b/include/hw/sysbus.h
@@ -89,6 +89,7 @@ qemu_irq sysbus_get_connected_irq(SysBusDevice *dev, int n);
 void sysbus_mmio_map(SysBusDevice *dev, int n, hwaddr addr);
 void sysbus_mmio_map_overlap(SysBusDevice *dev, int n, hwaddr addr,
  int priority);
+void sysbus_mmio_unmap(SysBusDevice *dev, int n);
 void sysbus_add_io(SysBusDevice *dev, hwaddr addr,
MemoryRegion *mem);
 MemoryRegion *sysbus_address_space(SysBusDevice *dev);
diff --git a/hw/core/sysbus.c b/hw/core/sysbus.c
index 307cf90a5196..689a867a2274 100644
--- a/hw/core/sysbus.c
+++ b/hw/core/sysbus.c
@@ -153,6 +153,16 @@ static void sysbus_mmio_map_common(SysBusDevice *dev, int 
n, hwaddr addr,
 }
 }
 
+void sysbus_mmio_unmap(SysBusDevice *dev, int n)
+{
+assert(n >= 0 && n < dev->num_mmio);
+
+if (dev->mmio[n].addr != (hwaddr)-1) {
+memory_region_del_subregion(get_system_memory(), dev->mmio[n].memory);
+dev->mmio[n].addr = (hwaddr)-1;
+}
+}
+
 void sysbus_mmio_map(SysBusDevice *dev, int n, hwaddr addr)
 {
 sysbus_mmio_map_common(dev, n, addr, false, 0);
-- 
2.20.1

[Qemu-devel] [PATCH v4 06/14] spapr/xive: add migration support for KVM

When the VM is stopped, the VM state handler stabilizes the XIVE IC
and marks the EQ pages dirty. These are then transferred to destination
before the transfer of the device vmstates starts.

The SpaprXive interrupt controller model captures the XIVE internal
tables, EAT and ENDT and the XiveTCTX model does the same for the
thread interrupt context registers.

At restart, the SpaprXive 'post_load' method restores all the XIVE
states. It is called by the sPAPR machine 'post_load' method, when all
XIVE states have been transferred and loaded.

Finally, the source states are restored in the VM change state handler
when the machine reaches the running state.

Signed-off-by: Cédric Le Goater 
Reviewed-by: David Gibson 
---
 include/hw/ppc/spapr_xive.h |  3 ++
 include/hw/ppc/xive.h   |  1 +
 hw/intc/spapr_xive.c| 24 ++
 hw/intc/spapr_xive_kvm.c| 95 -
 hw/intc/xive.c  | 17 +++
 hw/ppc/spapr_irq.c  |  2 +-
 6 files changed, 140 insertions(+), 2 deletions(-)

diff --git a/include/hw/ppc/spapr_xive.h b/include/hw/ppc/spapr_xive.h
index 734662c12a10..04294b0ca266 100644
--- a/include/hw/ppc/spapr_xive.h
+++ b/include/hw/ppc/spapr_xive.h
@@ -55,6 +55,7 @@ typedef struct SpaprXive {
 bool spapr_xive_irq_claim(SpaprXive *xive, uint32_t lisn, bool lsi);
 bool spapr_xive_irq_free(SpaprXive *xive, uint32_t lisn);
 void spapr_xive_pic_print_info(SpaprXive *xive, Monitor *mon);
+int spapr_xive_post_load(SpaprXive *xive, int version_id);
 
 void spapr_xive_hcall_init(SpaprMachineState *spapr);
 void spapr_dt_xive(SpaprMachineState *spapr, uint32_t nr_servers, void *fdt,
@@ -83,5 +84,7 @@ void kvmppc_xive_get_queue_config(SpaprXive *xive, uint8_t 
end_blk,
  uint32_t end_idx, XiveEND *end,
  Error **errp);
 void kvmppc_xive_synchronize_state(SpaprXive *xive, Error **errp);
+int kvmppc_xive_pre_save(SpaprXive *xive);
+int kvmppc_xive_post_load(SpaprXive *xive, int version_id);
 
 #endif /* PPC_SPAPR_XIVE_H */
diff --git a/include/hw/ppc/xive.h b/include/hw/ppc/xive.h
index 78c919c4a590..edb8937f17fb 100644
--- a/include/hw/ppc/xive.h
+++ b/include/hw/ppc/xive.h
@@ -436,5 +436,6 @@ void kvmppc_xive_source_reset(XiveSource *xsrc, Error 
**errp);
 void kvmppc_xive_source_set_irq(void *opaque, int srcno, int val);
 void kvmppc_xive_cpu_connect(XiveTCTX *tctx, Error **errp);
 void kvmppc_xive_cpu_synchronize_state(XiveTCTX *tctx, Error **errp);
+void kvmppc_xive_cpu_get_state(XiveTCTX *tctx, Error **errp);
 
 #endif /* PPC_XIVE_H */
diff --git a/hw/intc/spapr_xive.c b/hw/intc/spapr_xive.c
index 84cd30e1faff..d02993f489df 100644
--- a/hw/intc/spapr_xive.c
+++ b/hw/intc/spapr_xive.c
@@ -472,10 +472,34 @@ static const VMStateDescription vmstate_spapr_xive_eas = {
 },
 };
 
+static int vmstate_spapr_xive_pre_save(void *opaque)
+{
+if (kvm_irqchip_in_kernel()) {
+return kvmppc_xive_pre_save(SPAPR_XIVE(opaque));
+}
+
+return 0;
+}
+
+/*
+ * Called by the sPAPR IRQ backend 'post_load' method at the machine
+ * level.
+ */
+int spapr_xive_post_load(SpaprXive *xive, int version_id)
+{
+if (kvm_irqchip_in_kernel()) {
+return kvmppc_xive_post_load(xive, version_id);
+}
+
+return 0;
+}
+
 static const VMStateDescription vmstate_spapr_xive = {
 .name = TYPE_SPAPR_XIVE,
 .version_id = 1,
 .minimum_version_id = 1,
+.pre_save = vmstate_spapr_xive_pre_save,
+.post_load = NULL, /* handled at the machine level */
 .fields = (VMStateField[]) {
 VMSTATE_UINT32_EQUAL(nr_irqs, SpaprXive, NULL),
 VMSTATE_STRUCT_VARRAY_POINTER_UINT32(eat, SpaprXive, nr_irqs,
diff --git a/hw/intc/spapr_xive_kvm.c b/hw/intc/spapr_xive_kvm.c
index 735577a6f816..3999e4b7edfb 100644
--- a/hw/intc/spapr_xive_kvm.c
+++ b/hw/intc/spapr_xive_kvm.c
@@ -15,6 +15,7 @@
 #include "sysemu/cpus.h"
 #include "sysemu/kvm.h"
 #include "hw/ppc/spapr.h"
+#include "hw/ppc/spapr_cpu_core.h"
 #include "hw/ppc/spapr_xive.h"
 #include "hw/ppc/xive.h"
 #include "kvm_ppc.h"
@@ -60,7 +61,24 @@ static void kvm_cpu_enable(CPUState *cs)
 /*
  * XIVE Thread Interrupt Management context (KVM)
  */
-static void kvmppc_xive_cpu_get_state(XiveTCTX *tctx, Error **errp)
+
+static void kvmppc_xive_cpu_set_state(XiveTCTX *tctx, Error **errp)
+{
+uint64_t state[2];
+int ret;
+
+/* word0 and word1 of the OS ring. */
+state[0] = *((uint64_t *) &tctx->regs[TM_QW1_OS]);
+
+ret = kvm_set_one_reg(tctx->cs, KVM_REG_PPC_VP_STATE, state);
+if (ret != 0) {
+error_setg_errno(errp, errno,
+ "XIVE: could not restore KVM state of CPU %ld",
+ kvm_arch_vcpu_id(tctx->cs));
+}
+}
+
+void kvmppc_xive_cpu_get_state(XiveTCTX *tctx, Error **errp)
 {
 uint64_t state[2] = { 0 };
 int ret;
@@ -534,6 +552,81 @@ void kvmppc_xive_synchronize_state(SpaprXive *xive, Error 
**errp)
 kvmppc_xive_get_queues(xive, errp);
 }

[Qemu-devel] [PATCH v4 04/14] spapr/xive: add state synchronization with KVM

This extends the KVM XIVE device backend with 'synchronize_state'
methods used to retrieve the state from KVM. The HW state of the
sources, the KVM device and the thread interrupt contexts are
collected for the monitor usage and also migration.

These get operations rely on their KVM counterpart in the host kernel
which acts as a proxy for OPAL, the host firmware. The set operations
will be added for migration support later.

Signed-off-by: Cédric Le Goater 
---
 include/hw/ppc/spapr_xive.h |  8 
 include/hw/ppc/xive.h   |  1 +
 hw/intc/spapr_xive.c| 17 ---
 hw/intc/spapr_xive_kvm.c| 90 +
 hw/intc/xive.c  | 10 +
 5 files changed, 119 insertions(+), 7 deletions(-)

diff --git a/include/hw/ppc/spapr_xive.h b/include/hw/ppc/spapr_xive.h
index 03685910e76b..7e49badd8c9a 100644
--- a/include/hw/ppc/spapr_xive.h
+++ b/include/hw/ppc/spapr_xive.h
@@ -44,6 +44,13 @@ typedef struct SpaprXive {
 void  *tm_mmap;
 } SpaprXive;
 
+/*
+ * The sPAPR machine has a unique XIVE IC device. Assign a fixed value
+ * to the controller block id value. It can nevertheless be changed
+ * for testing purpose.
+ */
+#define SPAPR_XIVE_BLOCK_ID 0x0
+
 bool spapr_xive_irq_claim(SpaprXive *xive, uint32_t lisn, bool lsi);
 bool spapr_xive_irq_free(SpaprXive *xive, uint32_t lisn);
 void spapr_xive_pic_print_info(SpaprXive *xive, Monitor *mon);
@@ -74,5 +81,6 @@ void kvmppc_xive_set_queue_config(SpaprXive *xive, uint8_t 
end_blk,
 void kvmppc_xive_get_queue_config(SpaprXive *xive, uint8_t end_blk,
  uint32_t end_idx, XiveEND *end,
  Error **errp);
+void kvmppc_xive_synchronize_state(SpaprXive *xive, Error **errp);
 
 #endif /* PPC_SPAPR_XIVE_H */
diff --git a/include/hw/ppc/xive.h b/include/hw/ppc/xive.h
index dd115da30ebc..78c919c4a590 100644
--- a/include/hw/ppc/xive.h
+++ b/include/hw/ppc/xive.h
@@ -435,5 +435,6 @@ void kvmppc_xive_source_reset_one(XiveSource *xsrc, int 
srcno, Error **errp);
 void kvmppc_xive_source_reset(XiveSource *xsrc, Error **errp);
 void kvmppc_xive_source_set_irq(void *opaque, int srcno, int val);
 void kvmppc_xive_cpu_connect(XiveTCTX *tctx, Error **errp);
+void kvmppc_xive_cpu_synchronize_state(XiveTCTX *tctx, Error **errp);
 
 #endif /* PPC_XIVE_H */
diff --git a/hw/intc/spapr_xive.c b/hw/intc/spapr_xive.c
index 6beda26ee440..84cd30e1faff 100644
--- a/hw/intc/spapr_xive.c
+++ b/hw/intc/spapr_xive.c
@@ -40,13 +40,6 @@
 
 #define SPAPR_XIVE_NVT_BASE 0x400
 
-/*
- * The sPAPR machine has a unique XIVE IC device. Assign a fixed value
- * to the controller block id value. It can nevertheless be changed
- * for testing purpose.
- */
-#define SPAPR_XIVE_BLOCK_ID 0x0
-
 /*
  * sPAPR NVT and END indexing helpers
  */
@@ -157,6 +150,16 @@ void spapr_xive_pic_print_info(SpaprXive *xive, Monitor 
*mon)
 XiveSource *xsrc = &xive->source;
 int i;
 
+if (kvm_irqchip_in_kernel()) {
+Error *local_err = NULL;
+
+kvmppc_xive_synchronize_state(xive, &local_err);
+if (local_err) {
+error_report_err(local_err);
+return;
+}
+}
+
 monitor_printf(mon, "  LISN PQEISN CPU/PRIO EQ\n");
 
 for (i = 0; i < xive->nr_irqs; i++) {
diff --git a/hw/intc/spapr_xive_kvm.c b/hw/intc/spapr_xive_kvm.c
index 964bad0c23fb..8dd4f96e0b97 100644
--- a/hw/intc/spapr_xive_kvm.c
+++ b/hw/intc/spapr_xive_kvm.c
@@ -60,6 +60,54 @@ static void kvm_cpu_enable(CPUState *cs)
 /*
  * XIVE Thread Interrupt Management context (KVM)
  */
+static void kvmppc_xive_cpu_get_state(XiveTCTX *tctx, Error **errp)
+{
+uint64_t state[2] = { 0 };
+int ret;
+
+ret = kvm_get_one_reg(tctx->cs, KVM_REG_PPC_VP_STATE, state);
+if (ret != 0) {
+error_setg_errno(errp, errno,
+ "XIVE: could not capture KVM state of CPU %ld",
+ kvm_arch_vcpu_id(tctx->cs));
+return;
+}
+
+/* word0 and word1 of the OS ring. */
+*((uint64_t *) &tctx->regs[TM_QW1_OS]) = state[0];
+}
+
+typedef struct {
+XiveTCTX *tctx;
+Error *err;
+} XiveCpuGetState;
+
+static void kvmppc_xive_cpu_do_synchronize_state(CPUState *cpu,
+ run_on_cpu_data arg)
+{
+XiveCpuGetState *s = arg.host_ptr;
+
+kvmppc_xive_cpu_get_state(s->tctx, &s->err);
+}
+
+void kvmppc_xive_cpu_synchronize_state(XiveTCTX *tctx, Error **errp)
+{
+XiveCpuGetState s = {
+.tctx = tctx,
+.err = NULL,
+};
+
+/*
+ * Kick the vCPU to make sure they are available for the KVM ioctl.
+ */
+run_on_cpu(tctx->cs, kvmppc_xive_cpu_do_synchronize_state,
+   RUN_ON_CPU_HOST_PTR(&s));
+
+if (s.err) {
+error_propagate(errp, s.err);
+return;
+}
+}
 
 void kvmppc_xive_cpu_connect(XiveTCTX *tctx, Error **errp)
 {
@@ -227,6 +275,19 @@ uint64_t kvmppc_xive_esb_rw(XiveSource *xsrc, int srcno, 
uint32_t of

[Qemu-devel] [PATCH] linux-user: Implement membarrier syscall

2019-05-13 Thread Andreas Schwab

Signed-off-by: Andreas Schwab 
---
 linux-user/syscall.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index f5ff6f5dc8..80399f4eb0 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -313,6 +313,9 @@ _syscall3(int, getrandom, void *, buf, size_t, buflen, 
unsigned int, flags)
 _syscall5(int, kcmp, pid_t, pid1, pid_t, pid2, int, type,
   unsigned long, idx1, unsigned long, idx2)
 #endif
+#if defined(TARGET_NR_membarrier) && defined(__NR_membarrier)
+_syscall2(int, membarrier, int, cmd, int, flags)
+#endif
 
 static bitmask_transtbl fcntl_flags_tbl[] = {
   { TARGET_O_ACCMODE,   TARGET_O_WRONLY,O_ACCMODE,   O_WRONLY,},
@@ -11620,6 +11623,10 @@ static abi_long do_syscall1(void *cpu_env, int num, 
abi_long arg1,
 /* PowerPC specific.  */
 return do_swapcontext(cpu_env, arg1, arg2, arg3);
 #endif
+#if defined TARGET_NR_membarrier && defined __NR_membarrier
+case TARGET_NR_membarrier:
+return get_errno(membarrier(arg1, arg2));
+#endif
 
 default:
 qemu_log_mask(LOG_UNIMP, "Unsupported syscall: %d\n", num);
-- 
2.21.0


-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

[Qemu-devel] [PATCH v4 09/14] spapr: introduce routines to delete the KVM IRQ device

If a new interrupt mode is chosen by CAS, the machine generates a
reset to reconfigure. At this point, the connection with the previous
KVM device needs to be closed and a new connection needs to opened
with the KVM device operating the chosen interrupt mode.

New routines are introduced to destroy the XICS and the XIVE KVM
devices. They make use of a new KVM device ioctl which destroys the
device and also disconnects the IRQ presenters from the vCPUs.

Signed-off-by: Cédric Le Goater 
Reviewed-by: David Gibson 
---

 Changes since v3:

 - removed KVM_DESTROY_DEVICE control. KVM device is destroyed when
   the fd is closed.

 include/hw/ppc/spapr_xive.h |  1 +
 include/hw/ppc/xics_spapr.h |  1 +
 hw/intc/spapr_xive_kvm.c| 56 +
 hw/intc/xics_kvm.c  | 51 +
 4 files changed, 109 insertions(+)

diff --git a/include/hw/ppc/spapr_xive.h b/include/hw/ppc/spapr_xive.h
index 04294b0ca266..0b5e972d52c8 100644
--- a/include/hw/ppc/spapr_xive.h
+++ b/include/hw/ppc/spapr_xive.h
@@ -71,6 +71,7 @@ int spapr_xive_end_to_target(uint8_t end_blk, uint32_t 
end_idx,
  * KVM XIVE device helpers
  */
 void kvmppc_xive_connect(SpaprXive *xive, Error **errp);
+void kvmppc_xive_disconnect(SpaprXive *xive, Error **errp);
 void kvmppc_xive_reset(SpaprXive *xive, Error **errp);
 void kvmppc_xive_set_source_config(SpaprXive *xive, uint32_t lisn, XiveEAS 
*eas,
Error **errp);
diff --git a/include/hw/ppc/xics_spapr.h b/include/hw/ppc/xics_spapr.h
index 15a8dcff66fc..2476b540edfa 100644
--- a/include/hw/ppc/xics_spapr.h
+++ b/include/hw/ppc/xics_spapr.h
@@ -34,6 +34,7 @@
 void spapr_dt_xics(SpaprMachineState *spapr, uint32_t nr_servers, void *fdt,
uint32_t phandle);
 int xics_kvm_init(SpaprMachineState *spapr, Error **errp);
+void xics_kvm_disconnect(SpaprMachineState *spapr, Error **errp);
 void xics_spapr_init(SpaprMachineState *spapr);
 
 #endif /* XICS_SPAPR_H */
diff --git a/hw/intc/spapr_xive_kvm.c b/hw/intc/spapr_xive_kvm.c
index 3999e4b7edfb..259cd1db9582 100644
--- a/hw/intc/spapr_xive_kvm.c
+++ b/hw/intc/spapr_xive_kvm.c
@@ -58,6 +58,16 @@ static void kvm_cpu_enable(CPUState *cs)
 QLIST_INSERT_HEAD(&kvm_enabled_cpus, enabled_cpu, node);
 }
 
+static void kvm_cpu_disable_all(void)
+{
+KVMEnabledCPU *enabled_cpu, *next;
+
+QLIST_FOREACH_SAFE(enabled_cpu, &kvm_enabled_cpus, node, next) {
+QLIST_REMOVE(enabled_cpu, node);
+g_free(enabled_cpu);
+}
+}
+
 /*
  * XIVE Thread Interrupt Management context (KVM)
  */
@@ -709,3 +719,49 @@ void kvmppc_xive_connect(SpaprXive *xive, Error **errp)
 /* Map all regions */
 spapr_xive_map_mmio(xive);
 }
+
+void kvmppc_xive_disconnect(SpaprXive *xive, Error **errp)
+{
+XiveSource *xsrc;
+size_t esb_len;
+
+/* The KVM XIVE device is not in use */
+if (!xive || xive->fd == -1) {
+return;
+}
+
+if (!kvmppc_has_cap_xive()) {
+error_setg(errp, "IRQ_XIVE capability must be present for KVM");
+return;
+}
+
+/* Clear the KVM mapping */
+xsrc = &xive->source;
+esb_len = (1ull << xsrc->esb_shift) * xsrc->nr_irqs;
+
+sysbus_mmio_unmap(SYS_BUS_DEVICE(xive), 0);
+munmap(xsrc->esb_mmap, esb_len);
+
+sysbus_mmio_unmap(SYS_BUS_DEVICE(xive), 1);
+
+sysbus_mmio_unmap(SYS_BUS_DEVICE(xive), 2);
+munmap(xive->tm_mmap, 4ull << TM_SHIFT);
+
+/*
+ * When the KVM device fd is closed, the KVM device is destroyed
+ * and removed from the list of devices of the VM. The VCPU
+ * presenters are also detached from the device.
+ */
+close(xive->fd);
+xive->fd = -1;
+
+kvm_kernel_irqchip = false;
+kvm_msi_via_irqfd_allowed = false;
+kvm_gsi_direct_mapping = false;
+
+/* Clear the local list of presenter (hotplug) */
+kvm_cpu_disable_all();
+
+/* VM Change state handler is not needed anymore */
+qemu_del_vm_change_state_handler(xive->change);
+}
diff --git a/hw/intc/xics_kvm.c b/hw/intc/xics_kvm.c
index 78a252e6dfd4..1185846ff183 100644
--- a/hw/intc/xics_kvm.c
+++ b/hw/intc/xics_kvm.c
@@ -51,6 +51,16 @@ typedef struct KVMEnabledICP {
 static QLIST_HEAD(, KVMEnabledICP)
 kvm_enabled_icps = QLIST_HEAD_INITIALIZER(&kvm_enabled_icps);
 
+static void kvm_disable_icps(void)
+{
+KVMEnabledICP *enabled_icp, *next;
+
+QLIST_FOREACH_SAFE(enabled_icp, &kvm_enabled_icps, node, next) {
+QLIST_REMOVE(enabled_icp, node);
+g_free(enabled_icp);
+}
+}
+
 /*
  * ICP-KVM
  */
@@ -360,3 +370,44 @@ fail:
 kvmppc_define_rtas_kernel_token(0, "ibm,int-off");
 return -1;
 }
+
+void xics_kvm_disconnect(SpaprMachineState *spapr, Error **errp)
+{
+/* The KVM XICS device is not in use */
+if (kernel_xics_fd == -1) {
+return;
+}
+
+if (!kvm_enabled() || !kvm_check_extension(kvm_state, KVM_CAP_IRQ_XICS)) {
+error_setg(errp,
+   "KVM and IRQ_XICS capability must be

[Qemu-devel] [PATCH v4 11/14] spapr/irq: introduce a spapr_irq_init_device() helper

The way the XICS and the XIVE devices are initialized follows the same
pattern. First, try to connect to the KVM device and if not possible
fallback on the emulated device, unless a kernel_irqchip is required.
The spapr_irq_init_device() routine implements this sequence in
generic way using new sPAPR IRQ handlers ->init_emu() and ->init_kvm().

The XIVE init sequence is moved under the associated sPAPR IRQ
->init() handler. This will change again when KVM support is added for
the dual interrupt mode.

Signed-off-by: Cédric Le Goater 
Reviewed-by: David Gibson 
---
 include/hw/ppc/spapr_irq.h  |  2 +
 include/hw/ppc/spapr_xive.h |  1 +
 hw/intc/spapr_xive.c| 26 +++
 hw/ppc/spapr_irq.c  | 89 +
 4 files changed, 78 insertions(+), 40 deletions(-)

diff --git a/include/hw/ppc/spapr_irq.h b/include/hw/ppc/spapr_irq.h
index b855f74e4428..14cab73c9c07 100644
--- a/include/hw/ppc/spapr_irq.h
+++ b/include/hw/ppc/spapr_irq.h
@@ -48,6 +48,8 @@ typedef struct SpaprIrq {
 void (*reset)(SpaprMachineState *spapr, Error **errp);
 void (*set_irq)(void *opaque, int srcno, int val);
 const char *(*get_nodename)(SpaprMachineState *spapr);
+void (*init_emu)(SpaprMachineState *spapr, Error **errp);
+void (*init_kvm)(SpaprMachineState *spapr, Error **errp);
 } SpaprIrq;
 
 extern SpaprIrq spapr_irq_xics;
diff --git a/include/hw/ppc/spapr_xive.h b/include/hw/ppc/spapr_xive.h
index 0b5e972d52c8..b26befcf6b56 100644
--- a/include/hw/ppc/spapr_xive.h
+++ b/include/hw/ppc/spapr_xive.h
@@ -66,6 +66,7 @@ void spapr_xive_map_mmio(SpaprXive *xive);
 
 int spapr_xive_end_to_target(uint8_t end_blk, uint32_t end_idx,
  uint32_t *out_server, uint8_t *out_prio);
+void spapr_xive_init(SpaprXive *xive, Error **errp);
 
 /*
  * KVM XIVE device helpers
diff --git a/hw/intc/spapr_xive.c b/hw/intc/spapr_xive.c
index d02993f489df..246b21ae7f31 100644
--- a/hw/intc/spapr_xive.c
+++ b/hw/intc/spapr_xive.c
@@ -281,7 +281,6 @@ static void spapr_xive_realize(DeviceState *dev, Error 
**errp)
 XiveSource *xsrc = &xive->source;
 XiveENDSource *end_xsrc = &xive->end_source;
 Error *local_err = NULL;
-MachineState *machine = MACHINE(qdev_get_machine());
 
 if (!xive->nr_irqs) {
 error_setg(errp, "Number of interrupt needs to be greater 0");
@@ -332,27 +331,12 @@ static void spapr_xive_realize(DeviceState *dev, Error 
**errp)
xive->tm_base + XIVE_TM_USER_PAGE * (1 << 
TM_SHIFT));
 
 qemu_register_reset(spapr_xive_reset, dev);
+}
 
-if (kvm_enabled() && machine_kernel_irqchip_allowed(machine)) {
-kvmppc_xive_connect(xive, &local_err);
-if (local_err && machine_kernel_irqchip_required(machine)) {
-error_prepend(&local_err,
-  "kernel_irqchip requested but unavailable: ");
-error_propagate(errp, local_err);
-return;
-}
-
-if (!local_err) {
-return;
-}
-
-/*
- * We failed to initialize the XIVE KVM device, fallback to
- * emulated mode
- */
-error_prepend(&local_err, "kernel_irqchip allowed but unavailable: ");
-warn_report_err(local_err);
-}
+void spapr_xive_init(SpaprXive *xive, Error **errp)
+{
+XiveSource *xsrc = &xive->source;
+XiveENDSource *end_xsrc = &xive->end_source;
 
 /* TIMA initialization */
 memory_region_init_io(&xive->tm_mmio, OBJECT(xive), &xive_tm_ops, xive,
diff --git a/hw/ppc/spapr_irq.c b/hw/ppc/spapr_irq.c
index e969683f5c49..d1e87577fb0e 100644
--- a/hw/ppc/spapr_irq.c
+++ b/hw/ppc/spapr_irq.c
@@ -62,36 +62,50 @@ void spapr_irq_msi_reset(SpaprMachineState *spapr)
 bitmap_clear(spapr->irq_map, 0, spapr->irq_map_nr);
 }
 
-
-/*
- * XICS IRQ backend.
- */
-
-static void spapr_irq_init_xics(SpaprMachineState *spapr, int nr_irqs,
-Error **errp)
+static void spapr_irq_init_device(SpaprMachineState *spapr,
+  SpaprIrq *irq, Error **errp)
 {
 MachineState *machine = MACHINE(spapr);
-Object *obj;
 Error *local_err = NULL;
-bool xics_kvm = false;
 
-if (kvm_enabled()) {
-if (machine_kernel_irqchip_allowed(machine) &&
-!xics_kvm_init(spapr, &local_err)) {
-xics_kvm = true;
-}
-if (machine_kernel_irqchip_required(machine) && !xics_kvm) {
+if (kvm_enabled() && machine_kernel_irqchip_allowed(machine)) {
+irq->init_kvm(spapr, &local_err);
+if (local_err && machine_kernel_irqchip_required(machine)) {
 error_prepend(&local_err,
   "kernel_irqchip requested but unavailable: ");
 error_propagate(errp, local_err);
 return;
 }
-error_free(local_err);
-local_err = NULL;
+
+if (!local_err) {
+return;
+}
+
+/*
+ * We failed to initialize th

[Qemu-devel] [PATCH v4 07/14] spapr/xive: activate KVM support

All is in place for KVM now. State synchronization and migration will
come next.

Signed-off-by: Cédric Le Goater 
Reviewed-by: David Gibson 
---
 hw/ppc/spapr_irq.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/hw/ppc/spapr_irq.c b/hw/ppc/spapr_irq.c
index 8d371523e66e..e969683f5c49 100644
--- a/hw/ppc/spapr_irq.c
+++ b/hw/ppc/spapr_irq.c
@@ -248,19 +248,10 @@ SpaprIrq spapr_irq_xics = {
 static void spapr_irq_init_xive(SpaprMachineState *spapr, int nr_irqs,
 Error **errp)
 {
-MachineState *machine = MACHINE(spapr);
 uint32_t nr_servers = spapr_max_server_number(spapr);
 DeviceState *dev;
 int i;
 
-/* KVM XIVE device not yet available */
-if (kvm_enabled()) {
-if (machine_kernel_irqchip_required(machine)) {
-error_setg(errp, "kernel_irqchip requested. no KVM XIVE support");
-return;
-}
-}
-
 dev = qdev_create(NULL, TYPE_SPAPR_XIVE);
 qdev_prop_set_uint32(dev, "nr-irqs", nr_irqs);
 /*
-- 
2.20.1

[Qemu-devel] [PATCH] linux-user: implement getsockopt SO_RCVTIMEO and SO_SNDTIMEO

2019-05-13 Thread Andreas Schwab

Signed-off-by: Andreas Schwab 
---
 linux-user/syscall.c | 36 ++--
 1 file changed, 34 insertions(+), 2 deletions(-)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index d113a65831..ba5775a94e 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -2171,10 +2171,42 @@ static abi_long do_getsockopt(int sockfd, int level, 
int optname,
 level = SOL_SOCKET;
 switch (optname) {
 /* These don't just return a single integer */
-case TARGET_SO_RCVTIMEO:
-case TARGET_SO_SNDTIMEO:
 case TARGET_SO_PEERNAME:
 goto unimplemented;
+case TARGET_SO_RCVTIMEO: {
+struct timeval tv;
+socklen_t tvlen;
+
+optname = SO_RCVTIMEO;
+
+get_timeout:
+if (get_user_u32(len, optlen)) {
+return -TARGET_EFAULT;
+}
+if (len < 0) {
+return -TARGET_EINVAL;
+}
+
+tvlen = sizeof(tv);
+ret = get_errno(getsockopt(sockfd, level, optname,
+   &tv, &tvlen));
+if (ret < 0) {
+return ret;
+}
+if (len > sizeof(struct target_timeval)) {
+len = sizeof(struct target_timeval);
+}
+if (copy_to_user_timeval(optval_addr, &tv)) {
+return -TARGET_EFAULT;
+}
+if (put_user_u32(len, optlen)) {
+return -TARGET_EFAULT;
+}
+break;
+}
+case TARGET_SO_SNDTIMEO:
+optname = SO_SNDTIMEO;
+goto get_timeout;
 case TARGET_SO_PEERCRED: {
 struct ucred cr;
 socklen_t crlen;
-- 
2.21.0


-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [Qemu-devel] [PATCH] configure: Change capstone's default state to disabled

2019-05-13 Thread Daniel P . Berrangé

On Sun, May 12, 2019 at 03:47:49PM +0200, Thomas Huth wrote:
> Maybe try to clean the folder first:
> 
>  rm -r capstone
>  mkdir capstone
>  make git-submodule-update
> 
> If that does not help, maybe try a completely fresh git checkout?

Rather than deleting stuff like that, it is best to use git to put your
dir back to a clean state.

   git submodule deinit --all --force
   git clean -f -x -d 

After doing this, then run  'configure' again with normal args and try
to build.

If it still fails, please provide the /full/ output printed by configure,
as well as all output from make, and also the contents of the 'config.log'
file.

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

Re: [Qemu-devel] [PATCH v4 01/15] tests: acpi: rename acpi_parse_rsdp_table() into acpi_fetch_rsdp_table()

2019-05-13 Thread Igor Mammedov

On Sun, 12 May 2019 14:19:08 -0400
"Michael S. Tsirkin"  wrote:

> On Thu, May 02, 2019 at 04:51:49PM +0200, Igor Mammedov wrote:
> > so name would reflect what the function does
> > 
> > Signed-off-by: Igor Mammedov 
> > Reviewed-by: Philippe Mathieu-Daudé 
> > Reviewed-by: Wei Yang 
> > ---
> > v4:
> >  * make it as the first patch in series
> > ---
> 
> 
> FYI this trips up git am.
> Don't do two --- please: just one is enough,
> second is not needed.

strange, git am works for me just fine.
I've always formated par patch comments this way and I think it's rather
common approach on the list.

What version of git do you use?

Anyways,
shall I rebase and resend series? (it doesn't apply to master anymore)

> 
[...]

[Qemu-devel] [RFC v2 PATCH 0/3] ppc: spapr: virtual NVDIMM support

The patchset attempts to implement the virtual NVDIMM for pseries.

PAPR semantics is such that each NVDIMM device is comprising of multiple
SCM(Storage Class Memory) blocks. The hypervisor is expected to prepare the
FDT for the NVDIMM device and send guest a hotplug interrupt with new type
RTAS_LOG_V6_HP_TYPE_PMEM currently handled by the upstream kernel. In response
to that interrupt, the guest requests the hypervisor to bind each of the SCM
blocks of the NVDIMM device using hcalls. There can be SCM block unbind
requests in case of driver errors or unplug(not supported now) use cases. The
NVDIMM label read/writes are done through hcalls.

There are also new futuristic hcalls added(currently unused in the kernel), for
querying the informations such as binding, logical addresses of the SCM blocks.
The current patchset leaves them unimplemented.

Since each virtual NVDIMM device is divided into multiple SCM blocks, the bind,
unbind, and queries using hcalls on those blocks can come independently. This
doesnt fit well into the qemu device semantics, where the map/unmap are done at
the (whole)device/object level granularity. The patchset uses the existing
NVDIMM class structures for the implementation. The bind/unbind is left to
happen at the object_add/del phase itself instead of at hcalls on-demand.

The guest kernel makes bind/unbind requests for the virtual NVDIMM device at the
region level granularity. Without interleaving, each virtual NVDIMM device is
presented as separate region. There is no way to configure the virtual NVDIMM
interleaving for the guests today. So, there is no way a partial bind/unbind
request can come for the vNVDIMM in a hcall for a subset of SCM blocks of a
virtual NVDIMM. Hence it is safe to do bind/unbind everything during the
object_add/del.

The free device-memory region which is used for memory hotplug are done using
multiple LMBs of size(256MiB) and are expected to be aligned to 256 MiB. As the
SCM blocks are mapped to the same region, the SCM blocks also need to be
aligned to this size for the subsequent memory hotplug to work. The minimum SCM
block size is set to this size for that reason and can be made user configurable
in future if required.

The first patch moves around the existing static function to common area
for using it in the subsequent patches. Second patch adds the FDT entries and
basic device support, the third patch adds the hcalls implementation.

The patches are also available at https://github.com/ShivaprasadGBhat/qemu.git -
pseries-nvdimm branch and can be used with the upstream kernel. ndctl can be
used for configuring the nvdimms inside the guest.

This is how it can be used ..
Add nvdimm=on to the qemu machine argument,
Ex : -machine pseries,nvdimm=on
For coldplug, the device to be added in qemu command line as shown below
-object
memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0,share=yes,size=1073872896
-device
nvdimm,label-size=128k,uuid=75a3cdd7-6a2f-4791-8d15-fe0a920e8e9e,memdev=memnvdimm0,id=nvdimm0,slot=0

For hotplug, the device to be added from monitor as below
object_add
memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0,share=yes,size=1073872896
device_add
nvdimm,label-size=128k,uuid=75a3cdd7-6a2f-4791-8d15-fe0a920e8e9e,memdev=memnvdimm0,id=nvdimm0,slot=0

---
v1 : http://lists.nongnu.org/archive/html/qemu-devel/2019-02/msg01545.html
Changes from v1:
- Rebased to upstream, this required required dt_populate implementation
for nvdimm hotplug support
- Added uuid option to nvdimm device
- Removed the memory region sizing down code as suggested by Igor,
now erroring out if NVDIMM size excluding the label area is not
aligned to 256MB, so patch 2 from previous series no longer needed.
- Removed un-implemented hcalls
- Changed the hcalls to different kinds of checks and return
different values.
- Addressed comments for v1

Shivaprasad G Bhat (3):
mem: make nvdimm_device_list global
spapr: Add NVDIMM device support
spapr: Add Hcalls to support PAPR NVDIMM device

--
Signature

[Qemu-devel] [RFC v2 PATCH 1/3] mem: make nvdimm_device_list global

nvdimm_device_list is required for parsing the list for devices
in subsequent patches. Move it to common area.

Signed-off-by: Shivaprasad G Bhat 
Reviewed-By: Igor Mammedov 
---
This looks to break the mips*-softmmu build.
The mips depend on CONFIG_NVDIMM_ACPI, adding CONFIG_NVDIMM looks wrong.
Is there some CONFIG tweak I need to do here? OR

Should I move these functions to utilities like I have
done here 
-(https://github.com/ShivaprasadGBhat/qemu/commit/1b8eaea132a8b19c90b4fcc4d93da356029f4667)?
---
 hw/acpi/nvdimm.c|   27 ---
 hw/mem/nvdimm.c |   27 +++
 include/hw/mem/nvdimm.h |2 ++
 3 files changed, 29 insertions(+), 27 deletions(-)

diff --git a/hw/acpi/nvdimm.c b/hw/acpi/nvdimm.c
index 9fdad6dc3f..94baba1b8f 100644
--- a/hw/acpi/nvdimm.c
+++ b/hw/acpi/nvdimm.c
@@ -33,33 +33,6 @@
 #include "hw/nvram/fw_cfg.h"
 #include "hw/mem/nvdimm.h"
 
-static int nvdimm_device_list(Object *obj, void *opaque)
-{
-GSList **list = opaque;
-
-if (object_dynamic_cast(obj, TYPE_NVDIMM)) {
-*list = g_slist_append(*list, DEVICE(obj));
-}
-
-object_child_foreach(obj, nvdimm_device_list, opaque);
-return 0;
-}
-
-/*
- * inquire NVDIMM devices and link them into the list which is
- * returned to the caller.
- *
- * Note: it is the caller's responsibility to free the list to avoid
- * memory leak.
- */
-static GSList *nvdimm_get_device_list(void)
-{
-GSList *list = NULL;
-
-object_child_foreach(qdev_get_machine(), nvdimm_device_list, &list);
-return list;
-}
-
 #define NVDIMM_UUID_LE(a, b, c, d0, d1, d2, d3, d4, d5, d6, d7) \
{ (a) & 0xff, ((a) >> 8) & 0xff, ((a) >> 16) & 0xff, ((a) >> 24) & 0xff, \
  (b) & 0xff, ((b) >> 8) & 0xff, (c) & 0xff, ((c) >> 8) & 0xff,  \
diff --git a/hw/mem/nvdimm.c b/hw/mem/nvdimm.c
index bf2adf5e16..f221ec7a9a 100644
--- a/hw/mem/nvdimm.c
+++ b/hw/mem/nvdimm.c
@@ -29,6 +29,33 @@
 #include "hw/mem/nvdimm.h"
 #include "hw/mem/memory-device.h"
 
+static int nvdimm_device_list(Object *obj, void *opaque)
+{
+GSList **list = opaque;
+
+if (object_dynamic_cast(obj, TYPE_NVDIMM)) {
+*list = g_slist_append(*list, DEVICE(obj));
+}
+
+object_child_foreach(obj, nvdimm_device_list, opaque);
+return 0;
+}
+
+/*
+ * inquire NVDIMM devices and link them into the list which is
+ * returned to the caller.
+ *
+ * Note: it is the caller's responsibility to free the list to avoid
+ * memory leak.
+ */
+GSList *nvdimm_get_device_list(void)
+{
+GSList *list = NULL;
+
+object_child_foreach(qdev_get_machine(), nvdimm_device_list, &list);
+return list;
+}
+
 static void nvdimm_get_label_size(Object *obj, Visitor *v, const char *name,
   void *opaque, Error **errp)
 {
diff --git a/include/hw/mem/nvdimm.h b/include/hw/mem/nvdimm.h
index 523a9b3d4a..bad4fc04b5 100644
--- a/include/hw/mem/nvdimm.h
+++ b/include/hw/mem/nvdimm.h
@@ -150,4 +150,6 @@ void nvdimm_build_acpi(GArray *table_offsets, GArray 
*table_data,
uint32_t ram_slots);
 void nvdimm_plug(NVDIMMState *state);
 void nvdimm_acpi_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev);
+GSList *nvdimm_get_device_list(void);
+
 #endif

[Qemu-devel] [RFC v2 PATCH 2/3] spapr: Add NVDIMM device support

Add support for NVDIMM devices for sPAPR. Piggyback on existing nvdimm
device interface in QEMU to support virtual NVDIMM devices for Power (May have
to re-look at this later).  Create the required DT entries for the
device (some entries have dummy values right now).

The patch creates the required DT node and sends a hotplug
interrupt to the guest. Guest is expected to undertake the normal
DR resource add path in response and start issuing PAPR SCM hcalls.

This is how it can be used ..
Add nvdimm=on to the qemu machine argument.
Ex : -machine pseries,nvdimm=on
For coldplug, the device to be added in qemu command line as shown below
-object 
memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0,share=yes,size=1073872896
-device 
nvdimm,label-size=128k,uuid=75a3cdd7-6a2f-4791-8d15-fe0a920e8e9e,memdev=memnvdimm0,id=nvdimm0,slot=0

For hotplug, the device to be added from monitor as below
object_add 
memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0,share=yes,size=1073872896
device_add 
nvdimm,label-size=128k,uuid=75a3cdd7-6a2f-4791-8d15-fe0a920e8e9e,memdev=memnvdimm0,id=nvdimm0,slot=0

Signed-off-by: Shivaprasad G Bhat 
Signed-off-by: Bharata B Rao 
   [Early implementation]
---
---
 default-configs/ppc64-softmmu.mak |1 
 hw/mem/Kconfig|2 
 hw/mem/nvdimm.c   |   43 
 hw/ppc/spapr.c|  202 +++--
 hw/ppc/spapr_drc.c|   18 +++
 hw/ppc/spapr_events.c |4 +
 include/hw/mem/nvdimm.h   |6 +
 include/hw/ppc/spapr.h|   12 ++
 include/hw/ppc/spapr_drc.h|9 ++
 9 files changed, 286 insertions(+), 11 deletions(-)

diff --git a/default-configs/ppc64-softmmu.mak 
b/default-configs/ppc64-softmmu.mak
index cca52665d9..ae0841fa3a 100644
--- a/default-configs/ppc64-softmmu.mak
+++ b/default-configs/ppc64-softmmu.mak
@@ -8,3 +8,4 @@ CONFIG_POWERNV=y
 
 # For pSeries
 CONFIG_PSERIES=y
+CONFIG_NVDIMM=y
diff --git a/hw/mem/Kconfig b/hw/mem/Kconfig
index 620fd4cb59..2ad052a536 100644
--- a/hw/mem/Kconfig
+++ b/hw/mem/Kconfig
@@ -8,4 +8,4 @@ config MEM_DEVICE
 config NVDIMM
 bool
 default y
-depends on PC
+depends on (PC || PSERIES)
diff --git a/hw/mem/nvdimm.c b/hw/mem/nvdimm.c
index f221ec7a9a..deaeb5 100644
--- a/hw/mem/nvdimm.c
+++ b/hw/mem/nvdimm.c
@@ -93,11 +93,54 @@ out:
 error_propagate(errp, local_err);
 }
 
+static void nvdimm_get_uuid(Object *obj, Visitor *v, const char *name,
+  void *opaque, Error **errp)
+{
+NVDIMMDevice *nvdimm = NVDIMM(obj);
+char *value = NULL;
+
+value = qemu_uuid_unparse_strdup(&nvdimm->uuid);
+
+visit_type_str(v, name, &value, errp);
+}
+
+
+static void nvdimm_set_uuid(Object *obj, Visitor *v, const char *name,
+  void *opaque, Error **errp)
+{
+NVDIMMDevice *nvdimm = NVDIMM(obj);
+Error *local_err = NULL;
+char *value;
+
+visit_type_str(v, name, &value, &local_err);
+if (local_err) {
+goto out;
+}
+
+if (strcmp(value, "") == 0) {
+error_setg(&local_err, "Property '%s.%s' %s is required"
+   " at least 0x%lx", object_get_typename(obj),
+   name, value, MIN_NAMESPACE_LABEL_SIZE);
+goto out;
+}
+
+if (qemu_uuid_parse(value, &nvdimm->uuid) != 0) {
+error_setg(errp, "Invalid UUID");
+return;
+}
+out:
+error_propagate(errp, local_err);
+}
+
+
 static void nvdimm_init(Object *obj)
 {
 object_property_add(obj, NVDIMM_LABEL_SIZE_PROP, "int",
 nvdimm_get_label_size, nvdimm_set_label_size, NULL,
 NULL, NULL);
+
+object_property_add(obj, NVDIMM_UUID_PROP, "QemuUUID", nvdimm_get_uuid,
+nvdimm_set_uuid, NULL, NULL, NULL);
 }
 
 static void nvdimm_finalize(Object *obj)
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 2ef3ce4362..b6951577e7 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -74,6 +74,7 @@
 #include "qemu/cutils.h"
 #include "hw/ppc/spapr_cpu_core.h"
 #include "hw/mem/memory-device.h"
+#include "hw/mem/nvdimm.h"
 
 #include 
 
@@ -699,6 +700,7 @@ static int spapr_populate_drmem_v2(SpaprMachineState 
*spapr, void *fdt,
 uint8_t *int_buf, *cur_index;
 int ret;
 uint64_t lmb_size = SPAPR_MEMORY_BLOCK_SIZE;
+uint64_t scm_block_size = SPAPR_MINIMUM_SCM_BLOCK_SIZE;
 uint64_t addr, cur_addr, size;
 uint32_t nr_boot_lmbs = (machine->device_memory->base / lmb_size);
 uint64_t mem_end = machine->device_memory->base +
@@ -735,12 +737,20 @@ static int spapr_populate_drmem_v2(SpaprMachineState 
*spapr, void *fdt,
 nr_entries++;
 }
 
-/* Entry for DIMM */
-drc = spapr_drc_by_id(TYPE_SPAPR_DRC_LMB, addr / lmb_size);
-g_assert(drc);
-elem = spapr_get_drconf_cell(size / lmb_size, addr,
-

[Qemu-devel] [RFC v2 PATCH 3/3] spapr: Add Hcalls to support PAPR NVDIMM device

This patch implements few of the necessary hcalls for the nvdimm support.

PAPR semantics is such that each NVDIMM device is comprising of multiple
SCM(Storage Class Memory) blocks. The guest requests the hypervisor to bind
each of the SCM blocks of the NVDIMM device using hcalls. There can be
SCM block unbind requests in case of driver errors or unplug(not supported now)
use cases. The NVDIMM label read/writes are done through hcalls.

Since each virtual NVDIMM device is divided into multiple SCM blocks, the bind,
unbind, and queries using hcalls on those blocks can come independently. This
doesn't fit well into the qemu device semantics, where the map/unmap are done
at the (whole)device/object level granularity. The patch doesnt actually
bind/unbind on hcalls but let it happen at the object_add/del phase itself
instead.

The guest kernel makes bind/unbind requests for the virtual NVDIMM device at the
region level granularity. Without interleaving, each virtual NVDIMM device is
presented as separate region. There is no way to configure the virtual NVDIMM
interleaving for the guests today. So, there is no way a partial bind/unbind
request can come for the vNVDIMM in a hcall for a subset of SCM blocks of a
virtual NVDIMM. Hence it is safe to do bind/unbind everything during the
object_add/del.

Signed-off-by: Shivaprasad G Bhat 
---
 hw/ppc/spapr_hcall.c   |  202 
 include/hw/ppc/spapr.h |7 +-
 2 files changed, 208 insertions(+), 1 deletion(-)

diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
index 6c16d2b120..b6e7d04dcf 100644
--- a/hw/ppc/spapr_hcall.c
+++ b/hw/ppc/spapr_hcall.c
@@ -3,11 +3,13 @@
 #include "sysemu/hw_accel.h"
 #include "sysemu/sysemu.h"
 #include "qemu/log.h"
+#include "qemu/range.h"
 #include "qemu/error-report.h"
 #include "cpu.h"
 #include "exec/exec-all.h"
 #include "helper_regs.h"
 #include "hw/ppc/spapr.h"
+#include "hw/ppc/spapr_drc.h"
 #include "hw/ppc/spapr_cpu_core.h"
 #include "mmu-hash64.h"
 #include "cpu-models.h"
@@ -16,6 +18,7 @@
 #include "hw/ppc/spapr_ovec.h"
 #include "mmu-book3s-v3.h"
 #include "hw/mem/memory-device.h"
+#include "hw/mem/nvdimm.h"
 
 static bool has_spr(PowerPCCPU *cpu, int spr)
 {
@@ -1795,6 +1798,199 @@ static target_ulong h_update_dt(PowerPCCPU *cpu, 
SpaprMachineState *spapr,
 return H_SUCCESS;
 }
 
+static target_ulong h_scm_read_metadata(PowerPCCPU *cpu,
+SpaprMachineState *spapr,
+target_ulong opcode,
+target_ulong *args)
+{
+uint32_t drc_index = args[0];
+uint64_t offset = args[1];
+uint64_t numBytesToRead = args[2];
+SpaprDrc *drc = spapr_drc_by_index(drc_index);
+NVDIMMDevice *nvdimm = NULL;
+NVDIMMClass *ddc = NULL;
+
+if (drc && spapr_drc_type(drc) != SPAPR_DR_CONNECTOR_TYPE_PMEM) {
+return H_PARAMETER;
+}
+
+if (numBytesToRead != 1 && numBytesToRead != 2 &&
+numBytesToRead != 4 && numBytesToRead != 8) {
+return H_P3;
+}
+
+nvdimm = NVDIMM(drc->dev);
+if ((offset + numBytesToRead < offset) ||
+(nvdimm->label_size < numBytesToRead + offset)) {
+return H_P2;
+}
+
+ddc = NVDIMM_GET_CLASS(nvdimm);
+ddc->read_label_data(nvdimm, &args[0], numBytesToRead, offset);
+
+return H_SUCCESS;
+}
+
+
+static target_ulong h_scm_write_metadata(PowerPCCPU *cpu,
+ SpaprMachineState *spapr,
+ target_ulong opcode,
+ target_ulong *args)
+{
+uint32_t drc_index = args[0];
+uint64_t offset = args[1];
+uint64_t data = args[2];
+int8_t numBytesToWrite = args[3];
+SpaprDrc *drc = spapr_drc_by_index(drc_index);
+NVDIMMDevice *nvdimm = NULL;
+DeviceState *dev = NULL;
+NVDIMMClass *ddc = NULL;
+
+if (drc && spapr_drc_type(drc) != SPAPR_DR_CONNECTOR_TYPE_PMEM) {
+return H_PARAMETER;
+}
+
+if (numBytesToWrite != 1 && numBytesToWrite != 2 &&
+numBytesToWrite != 4 && numBytesToWrite != 8) {
+return H_P4;
+}
+
+dev = drc->dev;
+nvdimm = NVDIMM(dev);
+if ((nvdimm->label_size < numBytesToWrite + offset) ||
+(offset + numBytesToWrite < offset)) {
+return H_P2;
+}
+
+ddc = NVDIMM_GET_CLASS(nvdimm);
+ddc->write_label_data(nvdimm, &data, numBytesToWrite, offset);
+
+return H_SUCCESS;
+}
+
+static target_ulong h_scm_bind_mem(PowerPCCPU *cpu, SpaprMachineState *spapr,
+target_ulong opcode,
+target_ulong *args)
+{
+uint32_t drc_index = args[0];
+uint64_t starting_idx = args[1];
+uint64_t no_of_scm_blocks_to_bind = args[2];
+uint64_t target_logical_mem_addr = args[3];
+uint64_t continue_token = args[4];
+uint64_t size;
+uint64_t total_no_of_scm_blocks;
+
+SpaprDrc

Re: [Qemu-devel] [PATCH 00/13] target/arm/kvm: enable SVE in guests

2019-05-13 Thread Andrea Bolognani

On Sun, 2019-05-12 at 10:36 +0200, Andrew Jones wrote:
[...]
>CPU type | accel | sve-max-vq | sve-vls-map
>---
>  1) max | tcg   |  $MAX_VQ   |  $VLS_MAP
>  2) max | kvm   |  $MAX_VQ   |  $VLS_MAP
>  3)host | kvm   |  N/A   |  $VLS_MAP
> 
> Where for (1) $MAX_VQ sets the maximum vq and smaller vqs are
> all supported when $VLS_MAP is zero, or when the vqs are selected
> in $VLS_MAP.

I'm a bit confused by the nomenclature here. VL clearly stands for
Vector Length, but what does VQ stand for? You seem to be using the
two terms pretty much interchangeably throughout the cover letter.

[...]
> There is never any need to provide both properties, but if both
> are provided then they are checked for consistency.

I would personally just error out when both are provided.

> The QMP query returns a list of valid vq lists. For example, if
> a guest can use vqs 1, 2, 3, and 4, then the following list will
> be returned
> 
>  [ [ 1 ], [ 1, 2 ], [ 1, 2, 3 ], [ 1, 2, 3, 4 ] ]
> 
> Another example might be 1, 2, 4, as the architecture states 3
> is optional. In that case the list would be
> 
>  [ [ 1 ], [ 1, 2 ], [ 1, 2, 4 ] ]

I think the proposed QMP command is problematic, because it reports
the valid vector lengths for either KVM or TCG based on which
accelerator is currently enabled: it should report all information
at all times instead, similarly to how query-gic-capabilities does
it.

[...]
> And now for what might be a bit more controversial; how we input
> the valid vector set with sve-vls-map. Well, sve-vls-map is a
> 64-bit bitmap, which is admittedly not user friendly and also not
> the same size as KVM's vls bitmap (which is 8 64-bit words). Here's
> the justification:
> 
>  1) We want to use the QEMU command line in order for the information
> to be migrated without needing to add more VM state.
>  2) It's not easy/pretty to input arrays on the QEMU command line.
>  3) We already need to use the QMP query to get a valid set, which
> isn't user friendly either, meaning we're already in libvirt
> territory.
>  4) A 64-bit map (supporting up to 8192-bit vectors) is likely big
> enough for quite some time (currently KVM and TCG only support
> 2048-bit vectors).
>  5) If user friendliness is needed more than migratability then
> the 'max' cpu type can be used with the sve-max-vq property.
>  6) It's possible to probe the full valid vector set from the
> command line by using something like sve-vls-map=0x and
> then, when it fails, the error message will state the correct
> map, e.g. 0xb.

I don't have a problem with having to use a bitmap internally,
though libvirt will clearly want to expose a more approachable
interface to users.

However, QMP reporting the information in the current format means
we'd have to build an additional parser on top of the bitmap handling
and conversion routines we'll clearly need to make this work; plus it
just feels weird that the information reported by QMP can't be used
on the command line without going through some tranformation first.

Wouldn't it make more sense to both accept and report bitmaps?

-- 
Andrea Bolognani / Red Hat / Virtualization

Re: [Qemu-devel] [PATCH v4] s390: diagnose 318 info reset and migration support




On 13.05.19 10:03, David Hildenbrand wrote:
>>> +if ((SCCB_SIZE - sizeof(ReadInfo)) / sizeof(CPUEntry) < S390_MAX_CPUS)
>>> +mc->max_cpus = S390_MAX_CPUS - 8;
>>
>> This is too complicated, just set it always to 240.
>>
>> However, I am still not sure how to best handle this scenario. One
>> solution is
>>
>> 1. Set it statically to 240 for machine > 4.1
>> 2. Keep the old machines unmodifed
>> 3. Don't indicate the CPU feature for machines <= 4.0
>>
>> #3 is the problematic part, as it mixes host CPU features and machines.
>> Bad. The host CPU model should always look the same on all machines. I
>> don't like this.
>>
> 
> FWIW, #3 is only an issue when modeling it via the CPU model, like
> Christian suggested.
> 
> I suggest the following
> 
> 1. Set the max #cpus for 4.1 to 240 (already done)
> 2. Keep it for the other machines unmodified (as suggested by Thomas)
> 3. Create the layout of the SCCB depending on the machine type (to be done)
> 
> If we want to model diag318 via a CPU feature (which makes sense for
> migration):
> 
> 4. Disable diag318 with a warning if used with a machine < 4.1
> 

I think there is a simpler solution. It is perfectly fine to fail the startup
if we cannot fulfil the cpu model. So lets just allow 248 and allow this 
feature 
also for older machines. And if somebody chooses both at the same time,
lets fails the startup.

Re: [Qemu-devel] [PATCH 6/6] virtfs: Fix documentation of -fsdev and -virtfs

On Mon, 13 May 2019 10:39:17 +0200
Thomas Huth  wrote:

> On 09/05/2019 15.18, Greg Kurz wrote:
> > On Wed, 8 May 2019 17:54:42 +0200
> > Thomas Huth  wrote:
> >   
> >> On 07/05/2019 10.45, Greg Kurz wrote:  
> >>> This fixes several things:
> >>> - add "id" description to -virtfs documentation
> >>> - split the description into several lines in both usage and documentation
> >>>   for accurateness and clarity
> >>> - add documentation and usage of the synth fsdriver
> >>> - add "throttling.*" description to -fsdev local
> >>> - add some missing periods
> >>>
> >>> Buglink: https://bugs.launchpad.net/qemu/+bug/1581976
> >>> Signed-off-by: Greg Kurz 
> >>> ---
> >>>  qemu-options.hx |   84 
> >>> +++
> >>>  1 file changed, 60 insertions(+), 24 deletions(-)
> >>>
> >>> diff --git a/qemu-options.hx b/qemu-options.hx
> >>> index 9c5cc2e6bf70..975342dfbd66 100644
> >>> --- a/qemu-options.hx
> >>> +++ b/qemu-options.hx
> >>> @@ -1232,26 +1232,35 @@ the write back by pressing @key{C-a s} 
> >>> (@pxref{disk_images}).
> >>>  ETEXI
> >>>  
> >>>  DEF("fsdev", HAS_ARG, QEMU_OPTION_fsdev,
> >>> -"-fsdev 
> >>> fsdriver,id=id[,path=path,][security_model={mapped-xattr|mapped-file|passthrough|none}]\n"
> >>> -" 
> >>> [,writeout=immediate][,readonly][,socket=socket|sock_fd=sock_fd][,fmode=fmode][,dmode=dmode]\n"
> >>> +"-fsdev 
> >>> local,id=id,path=path,security_model=mapped-xattr|mapped-file|passthrough|none\n"
> >>> +" [,writeout=immediate][,readonly][,fmode=fmode][,dmode=dmode]\n"
> >>>  " 
> >>> [[,throttling.bps-total=b]|[[,throttling.bps-read=r][,throttling.bps-write=w]]]\n"
> >>>  " 
> >>> [[,throttling.iops-total=i]|[[,throttling.iops-read=r][,throttling.iops-write=w]]]\n"
> >>>  " 
> >>> [[,throttling.bps-total-max=bm]|[[,throttling.bps-read-max=rm][,throttling.bps-write-max=wm]]]\n"
> >>>  " 
> >>> [[,throttling.iops-total-max=im]|[[,throttling.iops-read-max=irm][,throttling.iops-write-max=iwm]]]\n"
> >>> -" [[,throttling.iops-size=is]]\n",
> >>> +" [[,throttling.iops-size=is]]\n"
> >>> +"-fsdev proxy,id=id,socket=socket[,writeout=immediate][,readonly]\n"
> >>> +"-fsdev 
> >>> proxy,id=id,sock_fd=sock_fd[,writeout=immediate][,readonly]\n"
> >>> +"-fsdev synth,id=id\n",
> >>>  QEMU_ARCH_ALL)
> >>>  
> >>>  STEXI
> >>>  
> >>> -@item -fsdev 
> >>> @var{fsdriver},id=@var{id},path=@var{path},[security_model=@var{security_model}][,writeout=@var{writeout}][,readonly][,socket=@var{socket}|sock_fd=@var{sock_fd}][,fmode=@var{fmode}][,dmode=@var{dmode}]
> >>> +@item -fsdev 
> >>> local,id=@var{id},path=@var{path},security_model=@var{security_model} 
> >>> [,writeout=@var{writeout}][,readonly][,fmode=@var{fmode}][,dmode=@var{dmode}]
> >>>  
> >>> [,throttling.@var{option}=@var{value}[,throttling.@var{option}=@var{value}[,...]]]
> >>> +@itemx -fsdev 
> >>> proxy,id=@var{id},socket=@var{socket}[,writeout=@var{writeout}][,readonly]
> >>> +@itemx -fsdev 
> >>> proxy,id=@var{id},sock_fd=@var{sock_fd}[,writeout=@var{writeout}][,readonly]
> >>> +@itemx -fsdev synth,id=@var{id}[,readonly]
> >>>  @findex -fsdev
> >>>  Define a new file system device. Valid options are:
> >>>  @table @option
> >>> -@item @var{fsdriver}
> >>> -This option specifies the fs driver backend to use.
> >>> -Currently "local" and "proxy" file system drivers are supported.
> >>> +@item local
> >>> +Accesses to the filesystem are done by QEMU.
> >>> +@item proxy
> >>> +Accesses to the filesystem are done by virtfs-proxy-helper(1).
> >>> +@item synth
> >>> +Synthetic filesystem, only used by QTests.
> >>>  @item id=@var{id}
> >>> -Specifies identifier for this device
> >>> +Specifies identifier for this device.
> >>>  @item path=@var{path}
> >>>  Specifies the export path for the file system device. Files under
> >>>  this path will be available to the 9p client on the guest.
> >>> @@ -1279,17 +1288,33 @@ Enables exporting 9p share as a readonly mount 
> >>> for guests. By default
> >>>  read-write access is given.
> >>>  @item socket=@var{socket}
> >>>  Enables proxy filesystem driver to use passed socket file for 
> >>> communicating
> >>> -with virtfs-proxy-helper
> >>> +with virtfs-proxy-helper(1).
> >>
> >> Why did you add a "(1)" after each virtfs-proxy-helper?
> >>  
> > 
> > Oops forgot to mention that in the changelog... We have a manual page for 
> > the
> > virtfs-proxy-helper command, and IIUC this is the way for a manual page to
> > reference another one. Makes sense ?  
> 
> Makes sense for the man page ... but it might look a little bit strange
> in the qemu-doc.html file? I've got no strong opinion, but I think I'd
> rather not include the "(1)" here.
> 

FWIW, we already have some similar references to manual pages:

$ grep '([1-9])' qemu-doc.html
Note that, by default, GUS shares IRQ(7) with parallel ports and so
QEMU mmap(2) mem-path, and accepts common suffixes, eg
is a QEMU user creatable object definition. See the qemu(1)

Re: [Qemu-devel] [PATCH v4 01/15] tests: acpi: rename acpi_parse_rsdp_table() into acpi_fetch_rsdp_table()

2019-05-13 Thread Igor Mammedov

On Mon, 13 May 2019 11:04:40 +0200
Igor Mammedov  wrote:

> On Sun, 12 May 2019 14:19:08 -0400
> "Michael S. Tsirkin"  wrote:
> 
> > On Thu, May 02, 2019 at 04:51:49PM +0200, Igor Mammedov wrote:
> > > so name would reflect what the function does
> > > 
> > > Signed-off-by: Igor Mammedov 
> > > Reviewed-by: Philippe Mathieu-Daudé 
> > > Reviewed-by: Wei Yang 
> > > ---
> > > v4:
> > >  * make it as the first patch in series
> > > ---
> > 
> > 
> > FYI this trips up git am.
> > Don't do two --- please: just one is enough,
> > second is not needed.
> 
> strange, git am works for me just fine.
> I've always formated par patch comments this way and I think it's rather
> common approach on the list.
> 
> What version of git do you use?
> 
[...]
> (it doesn't apply to master anymore)
  never mind, it applies just fine (I've missed one patch when applying)

> 
> > 
> [...]
> 
>

Re: [Qemu-devel] [PATCH v4] s390: diagnose 318 info reset and migration support

On 13.05.19 11:34, Christian Borntraeger wrote:
> 
> 
> On 13.05.19 10:03, David Hildenbrand wrote:
 +if ((SCCB_SIZE - sizeof(ReadInfo)) / sizeof(CPUEntry) < S390_MAX_CPUS)
 +mc->max_cpus = S390_MAX_CPUS - 8;
>>>
>>> This is too complicated, just set it always to 240.
>>>
>>> However, I am still not sure how to best handle this scenario. One
>>> solution is
>>>
>>> 1. Set it statically to 240 for machine > 4.1
>>> 2. Keep the old machines unmodifed
>>> 3. Don't indicate the CPU feature for machines <= 4.0
>>>
>>> #3 is the problematic part, as it mixes host CPU features and machines.
>>> Bad. The host CPU model should always look the same on all machines. I
>>> don't like this.
>>>
>>
>> FWIW, #3 is only an issue when modeling it via the CPU model, like
>> Christian suggested.
>>
>> I suggest the following
>>
>> 1. Set the max #cpus for 4.1 to 240 (already done)
>> 2. Keep it for the other machines unmodified (as suggested by Thomas)
>> 3. Create the layout of the SCCB depending on the machine type (to be done)
>>
>> If we want to model diag318 via a CPU feature (which makes sense for
>> migration):
>>
>> 4. Disable diag318 with a warning if used with a machine < 4.1
>>
> 
> I think there is a simpler solution. It is perfectly fine to fail the startup
> if we cannot fulfil the cpu model. So lets just allow 248 and allow this 
> feature 
> also for older machines. And if somebody chooses both at the same time,
> lets fails the startup.

To which knob do you want to glue the layout of the SCLP response? Like
I described?  Do you mean instead of warning and masking the feature off
as I suggested, simply failing?

In that case, -machine ..-4.0 -cpu host will not work on new HW with new
KVM. Just noting.

-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PULL 00/15] Block layer patches

On Fri, 10 May 2019 at 17:18, Kevin Wolf  wrote:
>
> The following changes since commit efb4f3b62c69383a7308d7b739a3193e7c0ccae8:
>
>   Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' 
> into staging (2019-05-10 14:49:36 +0100)
>
> are available in the Git repository at:
>
>   git://repo.or.cz/qemu/kevin.git tags/for-upstream
>
> for you to fetch changes up to 11f6fc50e7501b5f5d04100ea1c21fa8f1cf7b53:
>
>   iotests: Add test for rebase without input base (2019-05-10 16:45:40 +0200)
>
> 
> Block layer patches:
>
> - block: Remove bdrv_read() and bdrv_write()
> - qemu-img: Allow rebase with no input base
> - blockjob: Fix coroutine thread after AioContext change
> - MAINTAINERS updates for pflash, curl and gluster
>
> 


Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/4.1
for any user-visible changes.

-- PMM

Re: [Qemu-devel] [PATCH 6/6] virtfs: Fix documentation of -fsdev and -virtfs

On 13/05/2019 11.34, Greg Kurz wrote:
> On Mon, 13 May 2019 10:39:17 +0200
> Thomas Huth  wrote:
> 
>> On 09/05/2019 15.18, Greg Kurz wrote:
>>> On Wed, 8 May 2019 17:54:42 +0200
>>> Thomas Huth  wrote:
>>>   
 On 07/05/2019 10.45, Greg Kurz wrote:  
> This fixes several things:
> - add "id" description to -virtfs documentation
> - split the description into several lines in both usage and documentation
>   for accurateness and clarity
> - add documentation and usage of the synth fsdriver
> - add "throttling.*" description to -fsdev local
> - add some missing periods
>
> Buglink: https://bugs.launchpad.net/qemu/+bug/1581976
> Signed-off-by: Greg Kurz 
> ---
>  qemu-options.hx |   84 
> +++
>  1 file changed, 60 insertions(+), 24 deletions(-)
>
> diff --git a/qemu-options.hx b/qemu-options.hx
> index 9c5cc2e6bf70..975342dfbd66 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -1232,26 +1232,35 @@ the write back by pressing @key{C-a s} 
> (@pxref{disk_images}).
>  ETEXI
>  
>  DEF("fsdev", HAS_ARG, QEMU_OPTION_fsdev,
> -"-fsdev 
> fsdriver,id=id[,path=path,][security_model={mapped-xattr|mapped-file|passthrough|none}]\n"
> -" 
> [,writeout=immediate][,readonly][,socket=socket|sock_fd=sock_fd][,fmode=fmode][,dmode=dmode]\n"
> +"-fsdev 
> local,id=id,path=path,security_model=mapped-xattr|mapped-file|passthrough|none\n"
> +" [,writeout=immediate][,readonly][,fmode=fmode][,dmode=dmode]\n"
>  " 
> [[,throttling.bps-total=b]|[[,throttling.bps-read=r][,throttling.bps-write=w]]]\n"
>  " 
> [[,throttling.iops-total=i]|[[,throttling.iops-read=r][,throttling.iops-write=w]]]\n"
>  " 
> [[,throttling.bps-total-max=bm]|[[,throttling.bps-read-max=rm][,throttling.bps-write-max=wm]]]\n"
>  " 
> [[,throttling.iops-total-max=im]|[[,throttling.iops-read-max=irm][,throttling.iops-write-max=iwm]]]\n"
> -" [[,throttling.iops-size=is]]\n",
> +" [[,throttling.iops-size=is]]\n"
> +"-fsdev proxy,id=id,socket=socket[,writeout=immediate][,readonly]\n"
> +"-fsdev 
> proxy,id=id,sock_fd=sock_fd[,writeout=immediate][,readonly]\n"
> +"-fsdev synth,id=id\n",
>  QEMU_ARCH_ALL)
>  
>  STEXI
>  
> -@item -fsdev 
> @var{fsdriver},id=@var{id},path=@var{path},[security_model=@var{security_model}][,writeout=@var{writeout}][,readonly][,socket=@var{socket}|sock_fd=@var{sock_fd}][,fmode=@var{fmode}][,dmode=@var{dmode}]
> +@item -fsdev 
> local,id=@var{id},path=@var{path},security_model=@var{security_model} 
> [,writeout=@var{writeout}][,readonly][,fmode=@var{fmode}][,dmode=@var{dmode}]
>  
> [,throttling.@var{option}=@var{value}[,throttling.@var{option}=@var{value}[,...]]]
> +@itemx -fsdev 
> proxy,id=@var{id},socket=@var{socket}[,writeout=@var{writeout}][,readonly]
> +@itemx -fsdev 
> proxy,id=@var{id},sock_fd=@var{sock_fd}[,writeout=@var{writeout}][,readonly]
> +@itemx -fsdev synth,id=@var{id}[,readonly]
>  @findex -fsdev
>  Define a new file system device. Valid options are:
>  @table @option
> -@item @var{fsdriver}
> -This option specifies the fs driver backend to use.
> -Currently "local" and "proxy" file system drivers are supported.
> +@item local
> +Accesses to the filesystem are done by QEMU.
> +@item proxy
> +Accesses to the filesystem are done by virtfs-proxy-helper(1).
> +@item synth
> +Synthetic filesystem, only used by QTests.
>  @item id=@var{id}
> -Specifies identifier for this device
> +Specifies identifier for this device.
>  @item path=@var{path}
>  Specifies the export path for the file system device. Files under
>  this path will be available to the 9p client on the guest.
> @@ -1279,17 +1288,33 @@ Enables exporting 9p share as a readonly mount 
> for guests. By default
>  read-write access is given.
>  @item socket=@var{socket}
>  Enables proxy filesystem driver to use passed socket file for 
> communicating
> -with virtfs-proxy-helper
> +with virtfs-proxy-helper(1).

 Why did you add a "(1)" after each virtfs-proxy-helper?
  
>>>
>>> Oops forgot to mention that in the changelog... We have a manual page for 
>>> the
>>> virtfs-proxy-helper command, and IIUC this is the way for a manual page to
>>> reference another one. Makes sense ?  
>>
>> Makes sense for the man page ... but it might look a little bit strange
>> in the qemu-doc.html file? I've got no strong opinion, but I think I'd
>> rather not include the "(1)" here.
>>
> 
> FWIW, we already have some similar references to manual pages:
> 
> $ grep '([1-9])' qemu-doc.html
> Note that, by default, GUS shares IRQ(7) with parallel ports and so
> QEMU mmap(2) mem-path, and accepts common suffixes, eg
>

Re: [Qemu-devel] [PATCH] configure: Change capstone's default state to disabled

On Mon, 13 May 2019 at 10:08, Daniel P. Berrangé  wrote:
>
> On Sun, May 12, 2019 at 03:47:49PM +0200, Thomas Huth wrote:
> > Maybe try to clean the folder first:
> >
> >  rm -r capstone
> >  mkdir capstone
> >  make git-submodule-update
> >
> > If that does not help, maybe try a completely fresh git checkout?
>
> Rather than deleting stuff like that, it is best to use git to put your
> dir back to a clean state.
>
>git submodule deinit --all --force
>git clean -f -x -d

That git clean line will blow away any untracked files in
your entire tree, won't it? If so, better move anything
you cared about somewhere else first...

thanks
-- PMM

Re: [Qemu-devel] [PATCH] configure: Change capstone's default state to disabled

2019-05-13 Thread Daniel P . Berrangé

On Mon, May 13, 2019 at 10:48:58AM +0100, Peter Maydell wrote:
> On Mon, 13 May 2019 at 10:08, Daniel P. Berrangé  wrote:
> >
> > On Sun, May 12, 2019 at 03:47:49PM +0200, Thomas Huth wrote:
> > > Maybe try to clean the folder first:
> > >
> > >  rm -r capstone
> > >  mkdir capstone
> > >  make git-submodule-update
> > >
> > > If that does not help, maybe try a completely fresh git checkout?
> >
> > Rather than deleting stuff like that, it is best to use git to put your
> > dir back to a clean state.
> >
> >git submodule deinit --all --force
> >git clean -f -x -d
> 
> That git clean line will blow away any untracked files in
> your entire tree, won't it? If so, better move anything
> you cared about somewhere else first...

Yes, git clean blows away everything that isn't tracked.

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

Re: [Qemu-devel] [PATCH 00/13] target/arm/kvm: enable SVE in guests

On Sun, 12 May 2019 at 09:36, Andrew Jones  wrote:
>
> With the recent KVM guest SVE support pull request [1] KVM will be
> ready for guests with SVE. This series provides the QEMU bits for
> that enablement. The series starts with the bits needed for the KVM
> SVE ioctls. Then it enables the arm 'max'cpu type, which with TCG
> already supports SVE, to also support SVE when using KVM. Next
> a new QMP query is added that allows users to ask which vector
> lengths are supported by the host, allowing them to select a valid
> set of vectors for the guest. In order to select those vectors a
> new property 'sve-vls-map' is added to the 'max' cpu type, and then
> also to the 'host' cpu type. The table below shows the resulting user
> interfaces.
>
>CPU type | accel | sve-max-vq | sve-vls-map
>---
>  1) max | tcg   |  $MAX_VQ   |  $VLS_MAP
>  2) max | kvm   |  $MAX_VQ   |  $VLS_MAP
>  3)host | kvm   |  N/A   |  $VLS_MAP
>
> Where for (1) $MAX_VQ sets the maximum vq and smaller vqs are
> all supported when $VLS_MAP is zero, or when the vqs are selected
> in $VLS_MAP.
>
> (2) is the same as (1) except KVM has the final say on what
> vqs are valid.
>
> (3) doesn't accept sve-max-vq because a guest that uses this
> property without sve-vls-map cannot be safely migrated.

Is this "migrated between two hosts with the same host CPU
type but with different kernel versions which expose different
subsets of the host's permitted vector lengths" ?

thanks
-- PMM

Re: [Qemu-devel] [PATCH v4] s390: diagnose 318 info reset and migration support




On 13.05.19 11:40, David Hildenbrand wrote:
> On 13.05.19 11:34, Christian Borntraeger wrote:
>>
>>
>> On 13.05.19 10:03, David Hildenbrand wrote:
> +if ((SCCB_SIZE - sizeof(ReadInfo)) / sizeof(CPUEntry) < 
> S390_MAX_CPUS)
> +mc->max_cpus = S390_MAX_CPUS - 8;

 This is too complicated, just set it always to 240.

 However, I am still not sure how to best handle this scenario. One
 solution is

 1. Set it statically to 240 for machine > 4.1
 2. Keep the old machines unmodifed
 3. Don't indicate the CPU feature for machines <= 4.0

 #3 is the problematic part, as it mixes host CPU features and machines.
 Bad. The host CPU model should always look the same on all machines. I
 don't like this.

>>>
>>> FWIW, #3 is only an issue when modeling it via the CPU model, like
>>> Christian suggested.
>>>
>>> I suggest the following
>>>
>>> 1. Set the max #cpus for 4.1 to 240 (already done)
>>> 2. Keep it for the other machines unmodified (as suggested by Thomas)
>>> 3. Create the layout of the SCCB depending on the machine type (to be done)
>>>
>>> If we want to model diag318 via a CPU feature (which makes sense for
>>> migration):
>>>
>>> 4. Disable diag318 with a warning if used with a machine < 4.1
>>>
>>
>> I think there is a simpler solution. It is perfectly fine to fail the startup
>> if we cannot fulfil the cpu model. So lets just allow 248 and allow this 
>> feature 
>> also for older machines. And if somebody chooses both at the same time,
>> lets fails the startup.
> 
> To which knob do you want to glue the layout of the SCLP response? Like
> I described?  Do you mean instead of warning and masking the feature off
> as I suggested, simply failing?

The sclp response will depend on the dia318 cpu model flag. If its on, the sclp
response will have it, otherwise not.
- host-passthrough: not migration safe anyway
- host-model: if the target has diag318 good, otherwise we reject migration 
> 
> In that case, -machine ..-4.0 -cpu host will not work on new HW with new
> KVM. Just noting.

Only if you have 248 CPUs (which is unlikely). My point was to do that for all
machine levels.

Re: [Qemu-devel] [PATCH v7 5/5] block/backup: refactor: split out backup_calculate_cluster_size

2019-05-13 Thread Vladimir Sementsov-Ogievskiy

09.05.2019 19:12, Max Reitz wrote:
> On 29.04.19 11:08, Vladimir Sementsov-Ogievskiy wrote:
>> Split out cluster_size calculation. Move copy-bitmap creation above
>> block-job creation, as we are going to share it with upcoming
>> backup-top filter, which also should be created before actual block job
>> creation.
>>
>> Also, while being here, drop unnecessary "goto error" from
>> bdrv_getlength error path.
> 
> This paragraph should be dropped now.  Do you mind me doing it?
> 

Of course, don't mind)



-- 
Best regards,
Vladimir

Re: [Qemu-devel] [PATCH v6 0/8] qcow2: encryption threads

2019-05-13 Thread Vladimir Sementsov-Ogievskiy

09.05.2019 17:56, Max Reitz wrote:
> On 06.05.19 16:27, Vladimir Sementsov-Ogievskiy wrote:
>> v6:
>>   - Rebase on master, so 02 changed to reflect changes in
>> qcow2_compress(), keep r-b.
>>   - Rewrite 06 to even simpler locking [Max], drop r-b
>> Drop following
>> "qcow2: qcow2_co_preadv: skip using hd_qiov when possible", I'll do
>> it in my other coming soon series, and it is actually unrelated to
>> current.
>>   - Drop controversial perf test, hope I'll return to this topic, but not
>> in context of these series.
>>   - Add Max's r-b's to all here, except 06
>>
>> Vladimir Sementsov-Ogievskiy (8):
>>qcow2.h: add missing include
>>qcow2: add separate file for threaded data processing functions
>>qcow2-threads: use thread_pool_submit_co
>>qcow2-threads: qcow2_co_do_compress: protect queuing by mutex
>>qcow2-threads: split out generic path
>>qcow2: qcow2_co_preadv: improve locking
>>qcow2: bdrv_co_pwritev: move encryption code out of the lock
>>qcow2: do encryption in threads
>>
>>   block/qcow2.h  |  20 ++-
>>   block/qcow2-bitmap.c   |   1 -
>>   block/qcow2-cache.c|   1 -
>>   block/qcow2-cluster.c  |   8 +-
>>   block/qcow2-refcount.c |   1 -
>>   block/qcow2-snapshot.c |   1 -
>>   block/qcow2-threads.c  | 268 +
>>   block/qcow2.c  | 241 +---
>>   block/Makefile.objs|   2 +-
>>   9 files changed, 321 insertions(+), 222 deletions(-)
>>   create mode 100644 block/qcow2-threads.c
> 
> Thanks, applied to my block branch:
> 
> https://git.xanclic.moe/XanClic/qemu/commits/branch/block
> 

Thank you!!


-- 
Best regards,
Vladimir

Re: [Qemu-devel] [PATCH v4] s390: diagnose 318 info reset and migration support

On 13.05.19 11:51, Christian Borntraeger wrote:
> 
> 
> On 13.05.19 11:40, David Hildenbrand wrote:
>> On 13.05.19 11:34, Christian Borntraeger wrote:
>>>
>>>
>>> On 13.05.19 10:03, David Hildenbrand wrote:
>> +if ((SCCB_SIZE - sizeof(ReadInfo)) / sizeof(CPUEntry) < 
>> S390_MAX_CPUS)
>> +mc->max_cpus = S390_MAX_CPUS - 8;
>
> This is too complicated, just set it always to 240.
>
> However, I am still not sure how to best handle this scenario. One
> solution is
>
> 1. Set it statically to 240 for machine > 4.1
> 2. Keep the old machines unmodifed
> 3. Don't indicate the CPU feature for machines <= 4.0
>
> #3 is the problematic part, as it mixes host CPU features and machines.
> Bad. The host CPU model should always look the same on all machines. I
> don't like this.
>

 FWIW, #3 is only an issue when modeling it via the CPU model, like
 Christian suggested.

 I suggest the following

 1. Set the max #cpus for 4.1 to 240 (already done)
 2. Keep it for the other machines unmodified (as suggested by Thomas)
 3. Create the layout of the SCCB depending on the machine type (to be done)

 If we want to model diag318 via a CPU feature (which makes sense for
 migration):

 4. Disable diag318 with a warning if used with a machine < 4.1

>>>
>>> I think there is a simpler solution. It is perfectly fine to fail the 
>>> startup
>>> if we cannot fulfil the cpu model. So lets just allow 248 and allow this 
>>> feature 
>>> also for older machines. And if somebody chooses both at the same time,
>>> lets fails the startup.
>>
>> To which knob do you want to glue the layout of the SCLP response? Like
>> I described?  Do you mean instead of warning and masking the feature off
>> as I suggested, simply failing?
> 
> The sclp response will depend on the dia318 cpu model flag. If its on, the 
> sclp
> response will have it, otherwise not.
> - host-passthrough: not migration safe anyway
> - host-model: if the target has diag318 good, otherwise we reject migration 
>>
>> In that case, -machine ..-4.0 -cpu host will not work on new HW with new
>> KVM. Just noting.
> 
> Only if you have 248 CPUs (which is unlikely). My point was to do that for all
> machine levels.
> 

The issue with this approach is that e.g. libvirt is not aware of this
restriction. It could query "max_cpus" and expand the host-cpu model,
but starting a guest with > 240 cpus would fail. Maybe this is acceptable.

The approach you describe is actually pretty nice. We would have to

1. Modify SCLP code to change the layout based on the feature availability
2. Check against the cpus when trying to enable the cpu model.

-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH] nbd/server: Nicer spelling of max BLOCK_STATUS reply length

2019-05-13 Thread Vladimir Sementsov-Ogievskiy

10.05.2019 18:17, Eric Blake wrote:
> Commit 3d068aff (3.0) introduced NBD_MAX_BITMAP_EXTENTS as a limit on
> how large we would allow a reply to NBD_CMD_BLOCK_STATUS to grow when
> it is visiting a qemu:dirty-bitmap: context.  Later, commit fb7afc79
> (3.1) reused the constant to limit base:allocation context replies,
> although the name is now less appropriate in that situation.
> 
> Rename things, and improve the macro to use units.h for better
> legibility. Then reformat the comment to comply with checkpatch rules
> added in the meantime. No semantic change.
> 
> Signed-off-by: Eric Blake 


With or without Stefano's suggestion:

Signed-off-by: Vladimir Sementsov-Ogievskiy 


-- 
Best regards,
Vladimir

Re: [Qemu-devel] [PATCH v3 3/3] virtio-rng: change default backend to rng-builtin


On 10/05/2019 18:36, Markus Armbruster wrote:

Laurent Vivier  writes:


Signed-off-by: Laurent Vivier 
---
  backends/rng-builtin.c |  8 +++-
  hw/virtio/virtio-rng.c |  2 +-
  include/hw/virtio/virtio-rng.h |  4 ++--
  include/sysemu/rng-builtin.h   | 17 +
  qemu-options.hx|  5 ++---
  5 files changed, 25 insertions(+), 11 deletions(-)
  create mode 100644 include/sysemu/rng-builtin.h

...

diff --git a/include/hw/virtio/virtio-rng.h b/include/hw/virtio/virtio-rng.h
index 922dce7caccf..f9b6339b19a4 100644
--- a/include/hw/virtio/virtio-rng.h
+++ b/include/hw/virtio/virtio-rng.h

...

  #define TYPE_VIRTIO_RNG "virtio-rng-device"
@@ -26,7 +26,7 @@ struct VirtIORNGConf {
  RngBackend *rng;
  uint64_t max_bytes;
  uint32_t period_ms;
-RngRandom *default_backend;
+RngBuiltin *default_backend;


This member appears to be superfluous.  As far as I can tell, it's only
used in the part of virtio-rng.c visible above.  If you replace it by a
local variable there (in a separate patch, perhaps), this patch will
become simpler.  In particular, you won't need to create rng-builtin.h.



I don't understand how we can remove the rng-builtin.h as we need its 
macros for "RNG_BUILTIN(object_new(TYPE_RNG_BUILTIN))". Could you explain?


Thanks,
Laurent

Re: [Qemu-devel] [Qemu-ppc] [PATCH v8 5/6] ppc: spapr: Enable FWNMI capability

2019-05-13 Thread Aravinda Prasad




On Friday 10 May 2019 03:23 PM, David Gibson wrote:
> On Fri, May 10, 2019 at 12:45:29PM +0530, Aravinda Prasad wrote:
>>
>>
>> On Friday 10 May 2019 12:16 PM, David Gibson wrote:
>>> On Mon, Apr 22, 2019 at 12:33:35PM +0530, Aravinda Prasad wrote:
 Enable the KVM capability KVM_CAP_PPC_FWNMI so that
 the KVM causes guest exit with NMI as exit reason
 when it encounters a machine check exception on the
 address belonging to a guest. Without this capability
 enabled, KVM redirects machine check exceptions to
 guest's 0x200 vector.

 This patch also deals with the case when a guest with
 the KVM_CAP_PPC_FWNMI capability enabled is attempted
 to migrate to a host that does not support this
 capability.

 Signed-off-by: Aravinda Prasad 
 ---
  hw/ppc/spapr.c |1 +
  hw/ppc/spapr_caps.c|   26 ++
  hw/ppc/spapr_rtas.c|   14 ++
  include/hw/ppc/spapr.h |4 +++-
  target/ppc/kvm.c   |   14 ++
  target/ppc/kvm_ppc.h   |6 ++
  6 files changed, 64 insertions(+), 1 deletion(-)

 diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
 index ffd1715..44e09bb 100644
 --- a/hw/ppc/spapr.c
 +++ b/hw/ppc/spapr.c
 @@ -4372,6 +4372,7 @@ static void spapr_machine_class_init(ObjectClass 
 *oc, void *data)
  smc->default_caps.caps[SPAPR_CAP_NESTED_KVM_HV] = SPAPR_CAP_OFF;
  smc->default_caps.caps[SPAPR_CAP_LARGE_DECREMENTER] = SPAPR_CAP_ON;
  smc->default_caps.caps[SPAPR_CAP_CCF_ASSIST] = SPAPR_CAP_OFF;
 +smc->default_caps.caps[SPAPR_CAP_FWNMI_MCE] = SPAPR_CAP_OFF;
  spapr_caps_add_properties(smc, &error_abort);
  smc->irq = &spapr_irq_xics;
  smc->dr_phb_enabled = true;
 diff --git a/hw/ppc/spapr_caps.c b/hw/ppc/spapr_caps.c
 index edc5ed0..5b3af04 100644
 --- a/hw/ppc/spapr_caps.c
 +++ b/hw/ppc/spapr_caps.c
 @@ -473,6 +473,22 @@ static void cap_ccf_assist_apply(SpaprMachineState 
 *spapr, uint8_t val,
  }
  }
  
 +static void cap_fwnmi_mce_apply(SpaprMachineState *spapr, uint8_t val,
 +Error **errp)
 +{
 +PowerPCCPU *cpu = POWERPC_CPU(first_cpu);
 +
 +if (!val) {
 +return; /* Disabled by default */
 +}
 +
 +if (kvm_enabled()) {
 +if (kvmppc_fwnmi_enable(cpu)) {
 +error_setg(errp, "Requested fwnmi capability not support by 
 KVM");
 +}
 +}
 +}
 +
  SpaprCapabilityInfo capability_table[SPAPR_CAP_NUM] = {
  [SPAPR_CAP_HTM] = {
  .name = "htm",
 @@ -571,6 +587,15 @@ SpaprCapabilityInfo capability_table[SPAPR_CAP_NUM] = 
 {
  .type = "bool",
  .apply = cap_ccf_assist_apply,
  },
 +[SPAPR_CAP_FWNMI_MCE] = {
 +.name = "fwnmi-mce",
 +.description = "Handle fwnmi machine check exceptions",
 +.index = SPAPR_CAP_FWNMI_MCE,
 +.get = spapr_cap_get_bool,
 +.set = spapr_cap_set_bool,
 +.type = "bool",
 +.apply = cap_fwnmi_mce_apply,
 +},
  };
  
  static SpaprCapabilities default_caps_with_cpu(SpaprMachineState *spapr,
 @@ -706,6 +731,7 @@ SPAPR_CAP_MIG_STATE(ibs, SPAPR_CAP_IBS);
  SPAPR_CAP_MIG_STATE(nested_kvm_hv, SPAPR_CAP_NESTED_KVM_HV);
  SPAPR_CAP_MIG_STATE(large_decr, SPAPR_CAP_LARGE_DECREMENTER);
  SPAPR_CAP_MIG_STATE(ccf_assist, SPAPR_CAP_CCF_ASSIST);
 +SPAPR_CAP_MIG_STATE(fwnmi, SPAPR_CAP_FWNMI_MCE);
  
  void spapr_caps_init(SpaprMachineState *spapr)
  {
 diff --git a/hw/ppc/spapr_rtas.c b/hw/ppc/spapr_rtas.c
 index d3499f9..997cf19 100644
 --- a/hw/ppc/spapr_rtas.c
 +++ b/hw/ppc/spapr_rtas.c
 @@ -49,6 +49,7 @@
  #include "hw/ppc/fdt.h"
  #include "target/ppc/mmu-hash64.h"
  #include "target/ppc/mmu-book3s-v3.h"
 +#include "kvm_ppc.h"
  
  static void rtas_display_character(PowerPCCPU *cpu, SpaprMachineState 
 *spapr,
 uint32_t token, uint32_t nargs,
 @@ -354,6 +355,7 @@ static void rtas_ibm_nmi_register(PowerPCCPU *cpu,
target_ulong args,
uint32_t nret, target_ulong rets)
  {
 +int ret;
  uint64_t rtas_addr = spapr_get_rtas_addr();
  
  if (!rtas_addr) {
 @@ -361,6 +363,18 @@ static void rtas_ibm_nmi_register(PowerPCCPU *cpu,
  return;
  }
  
 +ret = kvmppc_fwnmi_enable(cpu);
>>>
>>> You shouldn't need this here as well as in cap_fwnmi_mce_apply().
>>>
>>> Instead, you should unconditionally fail the nmi-register if the
>>> capability is not enabled.
>>
>> cap_fwnmi is not enabled by default, because if it is enabled by default
>> them KVM will start routing m

[Qemu-devel] [PATCH v2 1/2] vl: Deprecate -virtfs_synth

The synth fsdriver never got used for anything else but the QTest
testcase for VirtIO 9P. And even there, QTest uses -fsdev synth and
-device virtio-9p-... directly.

Signed-off-by: Greg Kurz 
---
v2: - change "no replacement" to "use '-fsdev synth' instead"
---
 qemu-deprecated.texi |5 +
 qemu-options.hx  |3 ++-
 vl.c |4 
 3 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
index 842e71b11dcc..1a821b68f435 100644
--- a/qemu-deprecated.texi
+++ b/qemu-deprecated.texi
@@ -72,6 +72,11 @@ backend settings instead of environment variables.  To ease 
migration to
 the new format, the ``-audiodev-help'' option can be used to convert
 the current values of the environment variables to ``-audiodev'' options.
 
+@subsection -virtfs_synth (since 4.1)
+
+The ``-virtfs_synth'' argument is now deprecated. Please use ``-fsdev synth''
+and ``-device virtio-9p-...'' instead.
+
 @section QEMU Machine Protocol (QMP) commands
 
 @subsection block-dirty-bitmap-add "autoload" parameter (since 2.12.0)
diff --git a/qemu-options.hx b/qemu-options.hx
index 51802cbb266a..03c50ba0f0b2 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1368,7 +1368,8 @@ DEF("virtfs_synth", 0, QEMU_OPTION_virtfs_synth,
 STEXI
 @item -virtfs_synth
 @findex -virtfs_synth
-Create synthetic file system image
+Create synthetic file system image. Note that this option is now deprecated.
+Please use @code{-fsdev synth} and @code{-device virtio-9p-...} instead.
 ETEXI
 
 DEF("iscsi", HAS_ARG, QEMU_OPTION_iscsi,
diff --git a/vl.c b/vl.c
index b6709514c1bb..8456f006edbd 100644
--- a/vl.c
+++ b/vl.c
@@ -3535,6 +3535,10 @@ int main(int argc, char **argv, char **envp)
 QemuOpts *fsdev;
 QemuOpts *device;
 
+warn_report("'-virtfs_synth' is deprecated, please use "
+ "'-fsdev synth' and '-device virtio-9p-...' "
+"instead");
+
 fsdev = qemu_opts_create(qemu_find_opts("fsdev"), "v_synth",
  1, NULL);
 if (!fsdev) {

[Qemu-devel] [PATCH v2 0/2] fsdev/virtfs: Assorted cleanups and fixes

I've already applied patches from v1 with r-b tags to 9p-next. Please find
updated versions of the -virtfs_synth deprecation and the documentation
patches.

--
Greg

---

Greg Kurz (2):
  vl: Deprecate -virtfs_synth
  virtfs: Fix documentation of -fsdev and -virtfs


 qemu-deprecated.texi |5 +++
 qemu-options.hx  |   96 +++---
 vl.c |4 ++
 3 files changed, 77 insertions(+), 28 deletions(-)

[Qemu-devel] [PATCH v2 2/2] virtfs: Fix documentation of -fsdev and -virtfs

This fixes several things:
- add "id" description to -virtfs documentation
- split the description into several lines in both usage and documentation
  for accurateness and clarity
- add documentation and usage of the synth fsdriver
- add "throttling.*" description to -fsdev local
- add some missing periods
- add proper reference to the virtfs-proxy-helper(1) manual page
- document that the virtio device may be either virtio-9p-pci, virtio-9p-ccw
  or virtio-9p-device, depending on the machine type

Buglink: https://bugs.launchpad.net/qemu/+bug/1581976
Signed-off-by: Greg Kurz 
---
v2: - mention virtfs-proxy-helper(1) change in the changelog
- mention virtio-9p-ccw and virtio-9p-device
---
 qemu-options.hx |   93 +++
 1 file changed, 66 insertions(+), 27 deletions(-)

diff --git a/qemu-options.hx b/qemu-options.hx
index 03c50ba0f0b2..fa705b63b157 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1232,26 +1232,35 @@ the write back by pressing @key{C-a s} 
(@pxref{disk_images}).
 ETEXI
 
 DEF("fsdev", HAS_ARG, QEMU_OPTION_fsdev,
-"-fsdev 
fsdriver,id=id[,path=path,][security_model={mapped-xattr|mapped-file|passthrough|none}]\n"
-" 
[,writeout=immediate][,readonly][,socket=socket|sock_fd=sock_fd][,fmode=fmode][,dmode=dmode]\n"
+"-fsdev 
local,id=id,path=path,security_model=mapped-xattr|mapped-file|passthrough|none\n"
+" [,writeout=immediate][,readonly][,fmode=fmode][,dmode=dmode]\n"
 " 
[[,throttling.bps-total=b]|[[,throttling.bps-read=r][,throttling.bps-write=w]]]\n"
 " 
[[,throttling.iops-total=i]|[[,throttling.iops-read=r][,throttling.iops-write=w]]]\n"
 " 
[[,throttling.bps-total-max=bm]|[[,throttling.bps-read-max=rm][,throttling.bps-write-max=wm]]]\n"
 " 
[[,throttling.iops-total-max=im]|[[,throttling.iops-read-max=irm][,throttling.iops-write-max=iwm]]]\n"
-" [[,throttling.iops-size=is]]\n",
+" [[,throttling.iops-size=is]]\n"
+"-fsdev proxy,id=id,socket=socket[,writeout=immediate][,readonly]\n"
+"-fsdev proxy,id=id,sock_fd=sock_fd[,writeout=immediate][,readonly]\n"
+"-fsdev synth,id=id\n",
 QEMU_ARCH_ALL)
 
 STEXI
 
-@item -fsdev 
@var{fsdriver},id=@var{id},path=@var{path},[security_model=@var{security_model}][,writeout=@var{writeout}][,readonly][,socket=@var{socket}|sock_fd=@var{sock_fd}][,fmode=@var{fmode}][,dmode=@var{dmode}]
+@item -fsdev 
local,id=@var{id},path=@var{path},security_model=@var{security_model} 
[,writeout=@var{writeout}][,readonly][,fmode=@var{fmode}][,dmode=@var{dmode}] 
[,throttling.@var{option}=@var{value}[,throttling.@var{option}=@var{value}[,...]]]
+@itemx -fsdev 
proxy,id=@var{id},socket=@var{socket}[,writeout=@var{writeout}][,readonly]
+@itemx -fsdev 
proxy,id=@var{id},sock_fd=@var{sock_fd}[,writeout=@var{writeout}][,readonly]
+@itemx -fsdev synth,id=@var{id}[,readonly]
 @findex -fsdev
 Define a new file system device. Valid options are:
 @table @option
-@item @var{fsdriver}
-This option specifies the fs driver backend to use.
-Currently "local" and "proxy" file system drivers are supported.
+@item local
+Accesses to the filesystem are done by QEMU.
+@item proxy
+Accesses to the filesystem are done by virtfs-proxy-helper(1).
+@item synth
+Synthetic filesystem, only used by QTests.
 @item id=@var{id}
-Specifies identifier for this device
+Specifies identifier for this device.
 @item path=@var{path}
 Specifies the export path for the file system device. Files under
 this path will be available to the 9p client on the guest.
@@ -1279,48 +1288,76 @@ Enables exporting 9p share as a readonly mount for 
guests. By default
 read-write access is given.
 @item socket=@var{socket}
 Enables proxy filesystem driver to use passed socket file for communicating
-with virtfs-proxy-helper
+with virtfs-proxy-helper(1).
 @item sock_fd=@var{sock_fd}
 Enables proxy filesystem driver to use passed socket descriptor for
-communicating with virtfs-proxy-helper. Usually a helper like libvirt
-will create socketpair and pass one of the fds as sock_fd
+communicating with virtfs-proxy-helper(1). Usually a helper like libvirt
+will create socketpair and pass one of the fds as sock_fd.
 @item fmode=@var{fmode}
 Specifies the default mode for newly created files on the host. Works only
 with security models "mapped-xattr" and "mapped-file".
 @item dmode=@var{dmode}
 Specifies the default mode for newly created directories on the host. Works
 only with security models "mapped-xattr" and "mapped-file".
+@item 
throttling.bps-total=@var{b},throttling.bps-read=@var{r},throttling.bps-write=@var{w}
+Specify bandwidth throttling limits in bytes per second, either for all request
+types or for reads or writes only.
+@item 
throttling.bps-total-max=@var{bm},bps-read-max=@var{rm},bps-write-max=@var{wm}
+Specify bursts in bytes per second, either for all request types or for reads
+or writes only.  Bursts allow the guest I/O to spike above the limit
+temporarily.
+@item throttling.iops-total=@var{i},thrott

Re: [Qemu-devel] [PATCH v4] s390: diagnose 318 info reset and migration support




On 13.05.19 11:57, David Hildenbrand wrote:
> On 13.05.19 11:51, Christian Borntraeger wrote:
>>
>>
>> On 13.05.19 11:40, David Hildenbrand wrote:
>>> On 13.05.19 11:34, Christian Borntraeger wrote:


 On 13.05.19 10:03, David Hildenbrand wrote:
>>> +if ((SCCB_SIZE - sizeof(ReadInfo)) / sizeof(CPUEntry) < 
>>> S390_MAX_CPUS)
>>> +mc->max_cpus = S390_MAX_CPUS - 8;
>>
>> This is too complicated, just set it always to 240.
>>
>> However, I am still not sure how to best handle this scenario. One
>> solution is
>>
>> 1. Set it statically to 240 for machine > 4.1
>> 2. Keep the old machines unmodifed
>> 3. Don't indicate the CPU feature for machines <= 4.0
>>
>> #3 is the problematic part, as it mixes host CPU features and machines.
>> Bad. The host CPU model should always look the same on all machines. I
>> don't like this.
>>
>
> FWIW, #3 is only an issue when modeling it via the CPU model, like
> Christian suggested.
>
> I suggest the following
>
> 1. Set the max #cpus for 4.1 to 240 (already done)
> 2. Keep it for the other machines unmodified (as suggested by Thomas)
> 3. Create the layout of the SCCB depending on the machine type (to be 
> done)
>
> If we want to model diag318 via a CPU feature (which makes sense for
> migration):
>
> 4. Disable diag318 with a warning if used with a machine < 4.1
>

 I think there is a simpler solution. It is perfectly fine to fail the 
 startup
 if we cannot fulfil the cpu model. So lets just allow 248 and allow this 
 feature 
 also for older machines. And if somebody chooses both at the same time,
 lets fails the startup.
>>>
>>> To which knob do you want to glue the layout of the SCLP response? Like
>>> I described?  Do you mean instead of warning and masking the feature off
>>> as I suggested, simply failing?
>>
>> The sclp response will depend on the dia318 cpu model flag. If its on, the 
>> sclp
>> response will have it, otherwise not.
>> - host-passthrough: not migration safe anyway
>> - host-model: if the target has diag318 good, otherwise we reject migration 
>>>
>>> In that case, -machine ..-4.0 -cpu host will not work on new HW with new
>>> KVM. Just noting.
>>
>> Only if you have 248 CPUs (which is unlikely). My point was to do that for 
>> all
>> machine levels.
>>
> 
> The issue with this approach is that e.g. libvirt is not aware of this
> restriction. It could query "max_cpus" and expand the host-cpu model,
> but starting a guest with > 240 cpus would fail. Maybe this is acceptable.

As of today we do the cpu model check in the same way. libvirt actually tries
to run QEMU and handles failures.

For a failure, the user still has still to use >240 CPUs in its XML. The only 
downside
is that libvirt will not reject this right away.

During startup we would then print an error message like

"The diag318 cpu feature is only supported for 240 and less CPUs."

This is of similar quality as
"Selected CPU GA level is too new. Maximum supported model in the 
configuration: \'%s\'",

and others that we have today.

So yes, I think this would be acceptable.



> 
> The approach you describe is actually pretty nice. We would have to
> 
> 1. Modify SCLP code to change the layout based on the feature availability
> 2. Check against the cpus when trying to enable the cpu model.
>

Re: [Qemu-devel] [PATCH] linux-user: implement getsockopt SO_RCVTIMEO and SO_SNDTIMEO


On 13/05/2019 11:06, Andreas Schwab wrote:

Signed-off-by: Andreas Schwab 
---
  linux-user/syscall.c | 36 ++--
  1 file changed, 34 insertions(+), 2 deletions(-)



Reviewed-by: Laurent Vivier

[Qemu-devel] [Bug 1823458] Update Released

2019-05-13 Thread Łukasz Zemczak

The verification of the Stable Release Update for qemu has completed
successfully and the package has now been released to -updates.
Subsequently, the Ubuntu Stable Release Updates Team is being
unsubscribed and will not receive messages about this bug report.  In
the event that you encounter a regression using the package from
-updates please report a new bug using ubuntu-bug and tag the bug report
regression-update so we can easily find any regressions.

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

Title:
  race condition between vhost_net_stop and CHR_EVENT_CLOSED on shutdown
  crashes qemu

Status in Ubuntu Cloud Archive:
  Fix Released
Status in Ubuntu Cloud Archive mitaka series:
  Fix Committed
Status in Ubuntu Cloud Archive ocata series:
  Fix Committed
Status in QEMU:
  Fix Released
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Trusty:
  Won't Fix
Status in qemu source package in Xenial:
  Fix Committed
Status in qemu source package in Bionic:
  Fix Released
Status in qemu source package in Cosmic:
  Fix Released
Status in qemu source package in Disco:
  Fix Released

Bug description:
  [impact]

  on shutdown of a guest, there is a race condition that results in qemu
  crashing instead of normally shutting down.  The bt looks similar to
  this (depending on the specific version of qemu, of course; this is
  taken from 2.5 version of qemu):

  (gdb) bt
  #0  __GI___pthread_mutex_lock (mutex=0x0) at ../nptl/pthread_mutex_lock.c:66
  #1  0x5636c0bc4389 in qemu_mutex_lock (mutex=mutex@entry=0x0) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/util/qemu-thread-posix.c:73
  #2  0x5636c0988130 in qemu_chr_fe_write_all (s=s@entry=0x0, 
buf=buf@entry=0x7ffe65c086a0 "\v", len=len@entry=20) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/qemu-char.c:205
  #3  0x5636c08f3483 in vhost_user_write (msg=msg@entry=0x7ffe65c086a0, 
fds=fds@entry=0x0, fd_num=fd_num@entry=0, dev=0x5636c1bf6b70, 
dev=0x5636c1bf6b70)
  at /build/qemu-7I4i1R/qemu-2.5+dfsg/hw/virtio/vhost-user.c:195
  #4  0x5636c08f411c in vhost_user_get_vring_base (dev=0x5636c1bf6b70, 
ring=0x7ffe65c087e0) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/hw/virtio/vhost-user.c:364
  #5  0x5636c08efff0 in vhost_virtqueue_stop (dev=dev@entry=0x5636c1bf6b70, 
vdev=vdev@entry=0x5636c2853338, vq=0x5636c1bf6d00, idx=1) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/hw/virtio/vhost.c:895
  #6  0x5636c08f2944 in vhost_dev_stop (hdev=hdev@entry=0x5636c1bf6b70, 
vdev=vdev@entry=0x5636c2853338) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/hw/virtio/vhost.c:1262
  #7  0x5636c08db2a8 in vhost_net_stop_one (net=0x5636c1bf6b70, 
dev=dev@entry=0x5636c2853338) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/hw/net/vhost_net.c:293
  #8  0x5636c08dbe5b in vhost_net_stop (dev=dev@entry=0x5636c2853338, 
ncs=0x5636c209d110, total_queues=total_queues@entry=1) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/hw/net/vhost_net.c:371
  #9  0x5636c08d7745 in virtio_net_vhost_status (status=7 '\a', 
n=0x5636c2853338) at /build/qemu-7I4i1R/qemu-2.5+dfsg/hw/net/virtio-net.c:150
  #10 virtio_net_set_status (vdev=, status=) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/hw/net/virtio-net.c:162
  #11 0x5636c08ec42c in virtio_set_status (vdev=0x5636c2853338, 
val=) at /build/qemu-7I4i1R/qemu-2.5+dfsg/hw/virtio/virtio.c:624
  #12 0x5636c098fed2 in vm_state_notify (running=running@entry=0, 
state=state@entry=RUN_STATE_SHUTDOWN) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/vl.c:1605
  #13 0x5636c089172a in do_vm_stop (state=RUN_STATE_SHUTDOWN) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/cpus.c:724
  #14 vm_stop (state=RUN_STATE_SHUTDOWN) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/cpus.c:1407
  #15 0x5636c085d240 in main_loop_should_exit () at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/vl.c:1883
  #16 main_loop () at /build/qemu-7I4i1R/qemu-2.5+dfsg/vl.c:1931
  #17 main (argc=, argv=, envp=) 
at /build/qemu-7I4i1R/qemu-2.5+dfsg/vl.c:4683

  [test case]

  unfortunately since this is a race condition, it's very hard to
  arbitrarily reproduce; it depends very much on the overall
  configuration of the guest as well as how exactly it's shut down -
  specifically, its vhost user net must be closed from the host side at
  a specific time during qemu shutdown.

  I have someone with such a setup who has reported to me their setup is
  able to reproduce this reliably, but the config is too complex for me
  to reproduce so I have relied on their reproduction and testing to
  debug and craft the patch for this.

  [regression potential]

  the change adds a flag to prevent repeated calls to vhost_net_stop().
  This also prevents any calls to vhost_net_cleanup() from
  net_vhost_user_event().  Any regression would be seen when stopping
  and/or cleaning up a vhost net.  Regressions might include failure to
  hot-remove a vhost net from a guest, or failure to cleanup (i.e. mem
  leak), or crashes during cleanup or st

[Qemu-devel] [Bug 1823458] Re: race condition between vhost_net_stop and CHR_EVENT_CLOSED on shutdown crashes qemu

2019-05-13 Thread Łukasz Zemczak

This is even more than what I wanted, thanks!

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

Title:
  race condition between vhost_net_stop and CHR_EVENT_CLOSED on shutdown
  crashes qemu

Status in Ubuntu Cloud Archive:
  Fix Released
Status in Ubuntu Cloud Archive mitaka series:
  Fix Committed
Status in Ubuntu Cloud Archive ocata series:
  Fix Committed
Status in QEMU:
  Fix Released
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Trusty:
  Won't Fix
Status in qemu source package in Xenial:
  Fix Committed
Status in qemu source package in Bionic:
  Fix Released
Status in qemu source package in Cosmic:
  Fix Released
Status in qemu source package in Disco:
  Fix Released

Bug description:
  [impact]

  on shutdown of a guest, there is a race condition that results in qemu
  crashing instead of normally shutting down.  The bt looks similar to
  this (depending on the specific version of qemu, of course; this is
  taken from 2.5 version of qemu):

  (gdb) bt
  #0  __GI___pthread_mutex_lock (mutex=0x0) at ../nptl/pthread_mutex_lock.c:66
  #1  0x5636c0bc4389 in qemu_mutex_lock (mutex=mutex@entry=0x0) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/util/qemu-thread-posix.c:73
  #2  0x5636c0988130 in qemu_chr_fe_write_all (s=s@entry=0x0, 
buf=buf@entry=0x7ffe65c086a0 "\v", len=len@entry=20) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/qemu-char.c:205
  #3  0x5636c08f3483 in vhost_user_write (msg=msg@entry=0x7ffe65c086a0, 
fds=fds@entry=0x0, fd_num=fd_num@entry=0, dev=0x5636c1bf6b70, 
dev=0x5636c1bf6b70)
  at /build/qemu-7I4i1R/qemu-2.5+dfsg/hw/virtio/vhost-user.c:195
  #4  0x5636c08f411c in vhost_user_get_vring_base (dev=0x5636c1bf6b70, 
ring=0x7ffe65c087e0) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/hw/virtio/vhost-user.c:364
  #5  0x5636c08efff0 in vhost_virtqueue_stop (dev=dev@entry=0x5636c1bf6b70, 
vdev=vdev@entry=0x5636c2853338, vq=0x5636c1bf6d00, idx=1) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/hw/virtio/vhost.c:895
  #6  0x5636c08f2944 in vhost_dev_stop (hdev=hdev@entry=0x5636c1bf6b70, 
vdev=vdev@entry=0x5636c2853338) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/hw/virtio/vhost.c:1262
  #7  0x5636c08db2a8 in vhost_net_stop_one (net=0x5636c1bf6b70, 
dev=dev@entry=0x5636c2853338) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/hw/net/vhost_net.c:293
  #8  0x5636c08dbe5b in vhost_net_stop (dev=dev@entry=0x5636c2853338, 
ncs=0x5636c209d110, total_queues=total_queues@entry=1) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/hw/net/vhost_net.c:371
  #9  0x5636c08d7745 in virtio_net_vhost_status (status=7 '\a', 
n=0x5636c2853338) at /build/qemu-7I4i1R/qemu-2.5+dfsg/hw/net/virtio-net.c:150
  #10 virtio_net_set_status (vdev=, status=) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/hw/net/virtio-net.c:162
  #11 0x5636c08ec42c in virtio_set_status (vdev=0x5636c2853338, 
val=) at /build/qemu-7I4i1R/qemu-2.5+dfsg/hw/virtio/virtio.c:624
  #12 0x5636c098fed2 in vm_state_notify (running=running@entry=0, 
state=state@entry=RUN_STATE_SHUTDOWN) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/vl.c:1605
  #13 0x5636c089172a in do_vm_stop (state=RUN_STATE_SHUTDOWN) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/cpus.c:724
  #14 vm_stop (state=RUN_STATE_SHUTDOWN) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/cpus.c:1407
  #15 0x5636c085d240 in main_loop_should_exit () at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/vl.c:1883
  #16 main_loop () at /build/qemu-7I4i1R/qemu-2.5+dfsg/vl.c:1931
  #17 main (argc=, argv=, envp=) 
at /build/qemu-7I4i1R/qemu-2.5+dfsg/vl.c:4683

  [test case]

  unfortunately since this is a race condition, it's very hard to
  arbitrarily reproduce; it depends very much on the overall
  configuration of the guest as well as how exactly it's shut down -
  specifically, its vhost user net must be closed from the host side at
  a specific time during qemu shutdown.

  I have someone with such a setup who has reported to me their setup is
  able to reproduce this reliably, but the config is too complex for me
  to reproduce so I have relied on their reproduction and testing to
  debug and craft the patch for this.

  [regression potential]

  the change adds a flag to prevent repeated calls to vhost_net_stop().
  This also prevents any calls to vhost_net_cleanup() from
  net_vhost_user_event().  Any regression would be seen when stopping
  and/or cleaning up a vhost net.  Regressions might include failure to
  hot-remove a vhost net from a guest, or failure to cleanup (i.e. mem
  leak), or crashes during cleanup or stopping a vhost net.

  [other info]

  this was originally seen in the 2.5 version of qemu - specifically,
  the UCA version in trusty-mitaka (which uses the xenial qemu
  codebase).

  After discussion upstream, it appears this was fixed upstream by
  commit e7c83a885f8, which is included starting in version 2.9.
  However, this commit depends on at least commit 5345fdb4467, and
  likely more other previous co

Re: [Qemu-devel] [PATCH] linux-user: Implement membarrier syscall


On 13/05/2019 11:02, Andreas Schwab wrote:

Signed-off-by: Andreas Schwab 
---
  linux-user/syscall.c | 7 +++
  1 file changed, 7 insertions(+)



Reviewed-by: Laurent Vivier

[Qemu-devel] [Bug 1823458] Re: race condition between vhost_net_stop and CHR_EVENT_CLOSED on shutdown crashes qemu

2019-05-13 Thread Launchpad Bug Tracker

This bug was fixed in the package qemu - 1:2.5+dfsg-5ubuntu10.37

---
qemu (1:2.5+dfsg-5ubuntu10.37) xenial; urgency=medium

  * d/p/lp1823458/add-VirtIONet-vhost_stopped-flag-to-prevent-multiple.patch,
d/p/lp1823458/do-not-call-vhost_net_cleanup-on-running-net-from-ch.patch:
- Prevent crash due to race condition on shutdown;
  this is fixed differently upstream (starting in Bionic), but
  the change is too large to backport into Xenial.  These two very
  small patches work around the problem in an unintrusive way.
  (LP: #1823458)

 -- Dan Streetman   Tue, 23 Apr 2019 05:19:55
-0400

** Changed in: qemu (Ubuntu Xenial)
   Status: Fix Committed => Fix Released

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

Title:
  race condition between vhost_net_stop and CHR_EVENT_CLOSED on shutdown
  crashes qemu

Status in Ubuntu Cloud Archive:
  Fix Released
Status in Ubuntu Cloud Archive mitaka series:
  Fix Committed
Status in Ubuntu Cloud Archive ocata series:
  Fix Committed
Status in QEMU:
  Fix Released
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Trusty:
  Won't Fix
Status in qemu source package in Xenial:
  Fix Released
Status in qemu source package in Bionic:
  Fix Released
Status in qemu source package in Cosmic:
  Fix Released
Status in qemu source package in Disco:
  Fix Released

Bug description:
  [impact]

  on shutdown of a guest, there is a race condition that results in qemu
  crashing instead of normally shutting down.  The bt looks similar to
  this (depending on the specific version of qemu, of course; this is
  taken from 2.5 version of qemu):

  (gdb) bt
  #0  __GI___pthread_mutex_lock (mutex=0x0) at ../nptl/pthread_mutex_lock.c:66
  #1  0x5636c0bc4389 in qemu_mutex_lock (mutex=mutex@entry=0x0) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/util/qemu-thread-posix.c:73
  #2  0x5636c0988130 in qemu_chr_fe_write_all (s=s@entry=0x0, 
buf=buf@entry=0x7ffe65c086a0 "\v", len=len@entry=20) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/qemu-char.c:205
  #3  0x5636c08f3483 in vhost_user_write (msg=msg@entry=0x7ffe65c086a0, 
fds=fds@entry=0x0, fd_num=fd_num@entry=0, dev=0x5636c1bf6b70, 
dev=0x5636c1bf6b70)
  at /build/qemu-7I4i1R/qemu-2.5+dfsg/hw/virtio/vhost-user.c:195
  #4  0x5636c08f411c in vhost_user_get_vring_base (dev=0x5636c1bf6b70, 
ring=0x7ffe65c087e0) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/hw/virtio/vhost-user.c:364
  #5  0x5636c08efff0 in vhost_virtqueue_stop (dev=dev@entry=0x5636c1bf6b70, 
vdev=vdev@entry=0x5636c2853338, vq=0x5636c1bf6d00, idx=1) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/hw/virtio/vhost.c:895
  #6  0x5636c08f2944 in vhost_dev_stop (hdev=hdev@entry=0x5636c1bf6b70, 
vdev=vdev@entry=0x5636c2853338) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/hw/virtio/vhost.c:1262
  #7  0x5636c08db2a8 in vhost_net_stop_one (net=0x5636c1bf6b70, 
dev=dev@entry=0x5636c2853338) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/hw/net/vhost_net.c:293
  #8  0x5636c08dbe5b in vhost_net_stop (dev=dev@entry=0x5636c2853338, 
ncs=0x5636c209d110, total_queues=total_queues@entry=1) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/hw/net/vhost_net.c:371
  #9  0x5636c08d7745 in virtio_net_vhost_status (status=7 '\a', 
n=0x5636c2853338) at /build/qemu-7I4i1R/qemu-2.5+dfsg/hw/net/virtio-net.c:150
  #10 virtio_net_set_status (vdev=, status=) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/hw/net/virtio-net.c:162
  #11 0x5636c08ec42c in virtio_set_status (vdev=0x5636c2853338, 
val=) at /build/qemu-7I4i1R/qemu-2.5+dfsg/hw/virtio/virtio.c:624
  #12 0x5636c098fed2 in vm_state_notify (running=running@entry=0, 
state=state@entry=RUN_STATE_SHUTDOWN) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/vl.c:1605
  #13 0x5636c089172a in do_vm_stop (state=RUN_STATE_SHUTDOWN) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/cpus.c:724
  #14 vm_stop (state=RUN_STATE_SHUTDOWN) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/cpus.c:1407
  #15 0x5636c085d240 in main_loop_should_exit () at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/vl.c:1883
  #16 main_loop () at /build/qemu-7I4i1R/qemu-2.5+dfsg/vl.c:1931
  #17 main (argc=, argv=, envp=) 
at /build/qemu-7I4i1R/qemu-2.5+dfsg/vl.c:4683

  [test case]

  unfortunately since this is a race condition, it's very hard to
  arbitrarily reproduce; it depends very much on the overall
  configuration of the guest as well as how exactly it's shut down -
  specifically, its vhost user net must be closed from the host side at
  a specific time during qemu shutdown.

  I have someone with such a setup who has reported to me their setup is
  able to reproduce this reliably, but the config is too complex for me
  to reproduce so I have relied on their reproduction and testing to
  debug and craft the patch for this.

  [regression potential]

  the change adds a flag to prevent repeated calls to vhost_net_stop().
  This also prevents any calls to vhost_net_cleanup() from
  net

Re: [Qemu-devel] [PATCH] block/file-posix: Truncate in xfs_write_zeroes()

2019-05-13 Thread Kevin Wolf

Am 10.05.2019 um 23:12 hat Max Reitz geschrieben:
> XFS_IOC_ZERO_RANGE does not increase the file length:
> $ touch foo
> $ xfs_io -c 'zero 0 65536' foo
> $ stat -c "size=%s, blocks=%b" foo
> size=0, blocks=128
> 
> We do want writes beyond the EOF to automatically increase the file
> length, however.  This is evidenced by the fact that iotest 061 is
> broken on XFS since qcow2's check implementation checks for blocks
> beyond the EOF.
> 
> Reported-by: Kevin Wolf 
> Signed-off-by: Max Reitz 

Just for the record, the commit that made the problem visible in 061 is
commit a5fff8d4.

Thanks, applied to the block branch.

Though I wonder if we should prefer FALLOC_FL_ZERO_RANGE now if
available, which is a single syscall and consistent for all filesystems.

Kevin

Re: [Qemu-devel] [PATCH 11/13] target/arm/cpu64: max cpu: Introduce sve-vls-map

2019-05-13 Thread Dave Martin

On Sun, May 12, 2019 at 09:36:22AM +0100, Andrew Jones wrote:
> Introduce another cpu property to control SVE vector lengths,
> sve-vls-map, which allows the user to explicitly select the
> set of vector lengths the guest can use. The map must conform
> to QEMU's limits and architectural constraints, checked when
> the property is set. Inconsistencies with sve-max-vq are also
> checked. The bit number of a set bit in the map represents the
> allowed vector length in number of quadwords.
> 
> Note, as the map is implemented with a single 64-bit word we
> currently only support up to 8192-bit vectors. As QEMU and
> KVM only support up to 2048-bit vectors then this sufficient
> now, and probably for some time. Extending the bitmap beyond
> a single word will likely require changing the property to
> a string and adding yet another parser to QEMU.
> 
> Signed-off-by: Andrew Jones 
> ---
>  target/arm/cpu.c |  4 +++
>  target/arm/cpu.h |  3 ++
>  target/arm/cpu64.c   | 70 +---
>  target/arm/helper.c  | 10 ++-
>  target/arm/monitor.c |  9 --
>  5 files changed, 88 insertions(+), 8 deletions(-)
> 

[...]

> diff --git a/target/arm/cpu.h b/target/arm/cpu.h
> index 8292d547e8f9..f0d0ce759ba8 100644
> --- a/target/arm/cpu.h
> +++ b/target/arm/cpu.h
> @@ -920,6 +920,9 @@ struct ARMCPU {
>  
>  /* Used to set the maximum vector length the cpu will support.  */
>  uint32_t sve_max_vq;
> +
> +/* Each bit represents a supported vector length of (bitnum * 16) bytes 
> */
> +uint64_t sve_vls_map;

Just to be clear, the representation here is different from the
representation in KVM_REG_ARM64_SVE_VLS?

In the latter, bit n represents vector length ((n + 1) * 16) bytes.

(QEMU is free to choose its own internal representation, naturally.)

[...]

> diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c

[...]

> +static void cpu_set_sve_vls_map(Object *obj, Visitor *v, const char *name,
> +void *opaque, Error **errp)
> +{
> +ARMCPU *cpu = ARM_CPU(obj);
> +Error *err = NULL;
> +uint64_t mask = ~(BIT_MASK(ARM_MAX_VQ - 1) - 1);
> +int i;
> +
> +visit_type_uint64(v, name, &cpu->sve_vls_map, errp);
> +
> +if (!err) {
> +if (cpu->sve_vls_map == 0) {
> +error_setg(&err, "SVE vector length map cannot be zero");

Maybe say "empty" here, since the map represents a set?

(But it this is just for debug rather than reporting errors to the user,
it probably doesn't matter much.)

[...]

> diff --git a/target/arm/helper.c b/target/arm/helper.c
> index 1e6eb0d0f360..bedec1ea0b27 100644
> --- a/target/arm/helper.c
> +++ b/target/arm/helper.c
> @@ -5254,12 +5254,20 @@ uint32_t sve_zcr_len_for_el(CPUARMState *env, int el)
>  static void zcr_write(CPUARMState *env, const ARMCPRegInfo *ri,
>uint64_t value)
>  {
> +ARMCPU *cpu = arm_env_get_cpu(env);
>  int cur_el = arm_current_el(env);
>  int old_len = sve_zcr_len_for_el(env, cur_el);
>  int new_len;
>  
>  /* Bits other than [3:0] are RAZ/WI.  */
> -raw_write(env, ri, value & 0xf);
> +value &= 0xf;

You might want to sanity-check that the max vq you configured for the
vcpu is <= 16 here.

> +
> +if (value && !(BIT_MASK(value) & cpu->sve_vls_map)) {
> +uint64_t map = cpu->sve_vls_map & (BIT_MASK(value) - 1);
> +value = arm_cpu_fls64(map) - 1;
> +}
> +
> +raw_write(env, ri, value);

[...]

Cheers
---Dave

Re: [Qemu-devel] [PATCH 00/13] target/arm/kvm: enable SVE in guests

2019-05-13 Thread Dave Martin

On Mon, May 13, 2019 at 10:32:46AM +0100, Andrea Bolognani wrote:
> On Sun, 2019-05-12 at 10:36 +0200, Andrew Jones wrote:
> [...]
> >CPU type | accel | sve-max-vq | sve-vls-map
> >---
> >  1) max | tcg   |  $MAX_VQ   |  $VLS_MAP
> >  2) max | kvm   |  $MAX_VQ   |  $VLS_MAP
> >  3)host | kvm   |  N/A   |  $VLS_MAP
> > 
> > Where for (1) $MAX_VQ sets the maximum vq and smaller vqs are
> > all supported when $VLS_MAP is zero, or when the vqs are selected
> > in $VLS_MAP.
> 
> I'm a bit confused by the nomenclature here. VL clearly stands for
> Vector Length, but what does VQ stand for? You seem to be using the
> two terms pretty much interchangeably throughout the cover letter.

>From the Linux end, "vector length" or VL refers to the size of a vector
register, either in no particular unit or in bytes.

"VQ" refers specifically to the vector length in 128-bit quadwords.

In some situations, neither terminology is obviously better than the
other, such as in the way KVM_REG_ARM64_SVE_VLS is encoded.

> [...]
> > There is never any need to provide both properties, but if both
> > are provided then they are checked for consistency.
> 
> I would personally just error out when both are provided.
> 
> > The QMP query returns a list of valid vq lists. For example, if
> > a guest can use vqs 1, 2, 3, and 4, then the following list will
> > be returned
> > 
> >  [ [ 1 ], [ 1, 2 ], [ 1, 2, 3 ], [ 1, 2, 3, 4 ] ]
> > 
> > Another example might be 1, 2, 4, as the architecture states 3
> > is optional. In that case the list would be
> > 
> >  [ [ 1 ], [ 1, 2 ], [ 1, 2, 4 ] ]
> 
> I think the proposed QMP command is problematic, because it reports
> the valid vector lengths for either KVM or TCG based on which
> accelerator is currently enabled: it should report all information
> at all times instead, similarly to how query-gic-capabilities does
> it.

I wonder if this is premature flexibility?

The size of these lists is going to get cumbersome if the architecture
is ever extended.  Even today, we might need over 100 items in this
(nested) list.  If this is to be presented to the user this will be
far from friendly, it could get much worse if the architecutre changes
in future to allow larger vectors or more flexible virtualisation.

Could we just have a list of supported vector lengths and a possibly
empty list of additional capabilities that describe what kinds of
flexibility are allowed?

So, for example, we might support vector lengths of 1, 2, 4 and 8
quadwords, with the the ability to clamp the max vector length the
guest sees: the kernel ABI guarantees that you can do this, even
if you can't disable/enable each individual vector length independently.

So, [ 1, 2, 4, 8 ] seems sufficient to describe this in a forwards
compatible way.

Some day, we might report { "independent", [ 1, 2, 4, 8, 16, 32, ... ] }

I'm guessing about the data representation here.

[...]

Cheers
---Dave

Re: [Qemu-devel] [Qemu-ppc] [PATCH v8 4/6] target/ppc: Build rtas error log upon an MCE

On Mon, 22 Apr 2019 12:33:26 +0530
Aravinda Prasad  wrote:

> Upon a machine check exception (MCE) in a guest address space,
> KVM causes a guest exit to enable QEMU to build and pass the
> error to the guest in the PAPR defined rtas error log format.
> 
> This patch builds the rtas error log, copies it to the rtas_addr
> and then invokes the guest registered machine check handler. The
> handler in the guest takes suitable action(s) depending on the type
> and criticality of the error. For example, if an error is
> unrecoverable memory corruption in an application inside the
> guest, then the guest kernel sends a SIGBUS to the application.
> For recoverable errors, the guest performs recovery actions and
> logs the error.
> 
> Signed-off-by: Aravinda Prasad 
> ---
>  hw/ppc/spapr.c |4 +
>  hw/ppc/spapr_events.c  |  245 
> 
>  include/hw/ppc/spapr.h |4 +
>  3 files changed, 253 insertions(+)
> 
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index 2779efe..ffd1715 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -2918,6 +2918,10 @@ static void spapr_machine_init(MachineState *machine)
>  error_report("Could not get size of LPAR rtas '%s'", filename);
>  exit(1);
>  }
> +
> +/* Resize blob to accommodate error log. */
> +spapr->rtas_size = spapr_get_rtas_size(spapr->rtas_size);
> +

This is the only user for spapr_get_rtas_size(), which is trivial.
I suggest you simply open-code it here.

But also, spapr->rtas_size is a guest visible thing, "rtas-size" prop in the
DT. Since existing machine types don't do that, I guess we should only use
the new size if cap-fwnmi-mce=on for the sake of compatibility.

>  spapr->rtas_blob = g_malloc(spapr->rtas_size);
>  if (load_image_size(filename, spapr->rtas_blob, spapr->rtas_size) < 0) {
>  error_report("Could not load LPAR rtas '%s'", filename);
> diff --git a/hw/ppc/spapr_events.c b/hw/ppc/spapr_events.c
> index 9922a23..4032db0 100644
> --- a/hw/ppc/spapr_events.c
> +++ b/hw/ppc/spapr_events.c
> @@ -212,6 +212,106 @@ struct hp_extended_log {
>  struct rtas_event_log_v6_hp hp;
>  } QEMU_PACKED;
>  
> +struct rtas_event_log_v6_mc {

Even if the rest of the code in this file seems to ignore CODING_STYLE,
maybe it's time to start using CamelCase.

David ?

> +#define RTAS_LOG_V6_SECTION_ID_MC   0x4D43 /* MC */
> +struct rtas_event_log_v6_section_header hdr;
> +uint32_t fru_id;
> +uint32_t proc_id;
> +uint8_t error_type;
> +#define RTAS_LOG_V6_MC_TYPE_UE   0
> +#define RTAS_LOG_V6_MC_TYPE_SLB  1
> +#define RTAS_LOG_V6_MC_TYPE_ERAT 2
> +#define RTAS_LOG_V6_MC_TYPE_TLB  4
> +#define RTAS_LOG_V6_MC_TYPE_D_CACHE  5
> +#define RTAS_LOG_V6_MC_TYPE_I_CACHE  7
> +uint8_t sub_err_type;
> +#define RTAS_LOG_V6_MC_UE_INDETERMINATE  0
> +#define RTAS_LOG_V6_MC_UE_IFETCH 1
> +#define RTAS_LOG_V6_MC_UE_PAGE_TABLE_WALK_IFETCH 2
> +#define RTAS_LOG_V6_MC_UE_LOAD_STORE 3
> +#define RTAS_LOG_V6_MC_UE_PAGE_TABLE_WALK_LOAD_STORE 4
> +#define RTAS_LOG_V6_MC_SLB_PARITY0
> +#define RTAS_LOG_V6_MC_SLB_MULTIHIT  1
> +#define RTAS_LOG_V6_MC_SLB_INDETERMINATE 2
> +#define RTAS_LOG_V6_MC_ERAT_PARITY   1
> +#define RTAS_LOG_V6_MC_ERAT_MULTIHIT 2
> +#define RTAS_LOG_V6_MC_ERAT_INDETERMINATE3
> +#define RTAS_LOG_V6_MC_TLB_PARITY1
> +#define RTAS_LOG_V6_MC_TLB_MULTIHIT  2
> +#define RTAS_LOG_V6_MC_TLB_INDETERMINATE 3
> +uint8_t reserved_1[6];
> +uint64_t effective_address;
> +uint64_t logical_address;
> +} QEMU_PACKED;
> +
> +struct mc_extended_log {
> +struct rtas_event_log_v6 v6hdr;
> +struct rtas_event_log_v6_mc mc;
> +} QEMU_PACKED;
> +
> +struct MC_ierror_table {
> +unsigned long srr1_mask;
> +unsigned long srr1_value;
> +bool nip_valid; /* nip is a valid indicator of faulting address */
> +uint8_t error_type;
> +uint8_t error_subtype;
> +unsigned int initiator;
> +unsigned int severity;
> +};
> +
> +static const struct MC_ierror_table mc_ierror_table[] = {
> +{ 0x081c, 0x0004, true,
> +  RTAS_LOG_V6_MC_TYPE_UE, RTAS_LOG_V6_MC_UE_IFETCH,
> +  RTAS_LOG_INITIATOR_CPU, RTAS_LOG_SEVERITY_ERROR_SYNC, },
> +{ 0x081c, 0x0008, true,
> +  RTAS_LOG_V6_MC_TYPE_SLB, RTAS_LOG_V6_MC_SLB_PARITY,
> +  RTAS_LOG_INITIATOR_CPU, RTAS_LOG_SEVERITY_ERROR_SYNC, },
> +{ 0x081c, 0x000c, true,
> +  RTAS_LOG_V6_MC_TYPE_SLB, RTAS_LOG_V6_MC_SLB_MULTIHIT,
> +  RTAS_LOG_INITIATOR_CPU, RTAS_LOG_SEVERITY_ERROR_SYNC, },
> +{ 0x081c, 0x0010, true,
> +  RTAS_LOG_

Re: [Qemu-devel] [PATCH] qcow2: Define and use QCOW2_COMPRESSED_SECTOR_SIZE

2019-05-13 Thread Stefano Garzarella

The patch LGTM, just a comment below.

On Fri, May 10, 2019 at 07:22:54PM +0300, Alberto Garcia wrote:
> When an L2 table entry points to a compressed cluster the space used
> by the data is specified in 512-byte sectors. This size is independent
> from BDRV_SECTOR_SIZE and is specific to the qcow2 file format.
> 
> The QCOW2_COMPRESSED_SECTOR_SIZE constant defined in this patch makes
> this explicit.
> 
> Signed-off-by: Alberto Garcia 
> ---
>  block/qcow2-cluster.c  |  5 +++--
>  block/qcow2-refcount.c | 25 ++---
>  block/qcow2.c  |  3 ++-
>  block/qcow2.h  |  4 
>  4 files changed, 23 insertions(+), 14 deletions(-)
> 
> diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
> index 974a4e8656..b36f4aa84a 100644
> --- a/block/qcow2-cluster.c
> +++ b/block/qcow2-cluster.c
> @@ -796,8 +796,9 @@ int 
> qcow2_alloc_compressed_cluster_offset(BlockDriverState *bs,
>  return cluster_offset;
>  }
>  
> -nb_csectors = ((cluster_offset + compressed_size - 1) >> 9) -
> -  (cluster_offset >> 9);
> +nb_csectors =
> +(cluster_offset + compressed_size - 1) / 
> QCOW2_COMPRESSED_SECTOR_SIZE -
> +(cluster_offset / QCOW2_COMPRESSED_SECTOR_SIZE);
>  
>  cluster_offset |= QCOW_OFLAG_COMPRESSED |
>((uint64_t)nb_csectors << s->csize_shift);
> diff --git a/block/qcow2-refcount.c b/block/qcow2-refcount.c
> index fa7ac1f7cb..780bd49a00 100644
> --- a/block/qcow2-refcount.c
> +++ b/block/qcow2-refcount.c
> @@ -1172,12 +1172,11 @@ void qcow2_free_any_clusters(BlockDriverState *bs, 
> uint64_t l2_entry,
>  switch (ctype) {
>  case QCOW2_CLUSTER_COMPRESSED:
>  {
> -int nb_csectors;
> -nb_csectors = ((l2_entry >> s->csize_shift) &
> -   s->csize_mask) + 1;
> -qcow2_free_clusters(bs,
> -(l2_entry & s->cluster_offset_mask) & ~511,
> -nb_csectors * 512, type);
> +int64_t offset = (l2_entry & s->cluster_offset_mask)
> +& QCOW2_COMPRESSED_SECTOR_MASK;
> +int size = QCOW2_COMPRESSED_SECTOR_SIZE *
> +(((l2_entry >> s->csize_shift) & s->csize_mask) + 1);

What about using int64_t type for the 'size' variable?
(because the qcow2_free_clusters() 'size' parameter is int64_t)

> +qcow2_free_clusters(bs, offset, size, type);
>  }
>  break;
>  case QCOW2_CLUSTER_NORMAL:
> @@ -1317,9 +1316,12 @@ int qcow2_update_snapshot_refcount(BlockDriverState 
> *bs,
>  nb_csectors = ((entry >> s->csize_shift) &
> s->csize_mask) + 1;
>  if (addend != 0) {
> +uint64_t coffset = (entry & 
> s->cluster_offset_mask)
> +& QCOW2_COMPRESSED_SECTOR_MASK;
>  ret = update_refcount(
> -bs, (entry & s->cluster_offset_mask) & ~511,
> -nb_csectors * 512, abs(addend), addend < 0,
> +bs, coffset,
> +nb_csectors * QCOW2_COMPRESSED_SECTOR_SIZE,
> +abs(addend), addend < 0,
>  QCOW2_DISCARD_SNAPSHOT);
>  if (ret < 0) {
>  goto fail;
> @@ -1635,9 +1637,10 @@ static int check_refcounts_l2(BlockDriverState *bs, 
> BdrvCheckResult *res,
>  nb_csectors = ((l2_entry >> s->csize_shift) &
> s->csize_mask) + 1;
>  l2_entry &= s->cluster_offset_mask;
> -ret = qcow2_inc_refcounts_imrt(bs, res,
> -   refcount_table, 
> refcount_table_size,
> -   l2_entry & ~511, nb_csectors * 
> 512);
> +ret = qcow2_inc_refcounts_imrt(
> +bs, res, refcount_table, refcount_table_size,
> +l2_entry & QCOW2_COMPRESSED_SECTOR_MASK,
> +nb_csectors * QCOW2_COMPRESSED_SECTOR_SIZE);
>  if (ret < 0) {
>  goto fail;
>  }
> diff --git a/block/qcow2.c b/block/qcow2.c
> index a520d116ef..80679a84d2 100644
> --- a/block/qcow2.c
> +++ b/block/qcow2.c
> @@ -4188,7 +4188,8 @@ qcow2_co_preadv_compressed(BlockDriverState *bs,
>  
>  coffset = file_cluster_offset & s->cluster_offset_mask;
>  nb_csectors = ((file_cluster_offset >> s->csize_shift) & s->csize_mask) 
> + 1;
> -csize = nb_csectors * 512 - (coffset & 511);
> +csize = nb_csectors * QCOW2_COMPRESSED_SECTOR_SIZE -
> +(coffset & ~QCOW2_COMPRESSED_SECTOR_MASK);
>  
>  buf = g_try_malloc(csize);
>  if (!buf) {
> diff --git a/block/qcow2.h b/block/qcow2.h
> index fdee297f33..7e796877d6 100644
> --- a/block/qcow2.h
> +++ b/block/qcow2.h
> @@ -74,6 +74,10 @@
>  #define MIN_

Re: [Qemu-devel] [PATCH] blockdev: fix missed target unref for drive-backup

2019-05-13 Thread Kevin Wolf

Am 10.05.2019 um 23:52 hat John Snow geschrieben:
> If the bitmap can't be used for whatever reason, we skip putting down
> the reference. Fix that.
> 
> In practice, this means that if you attempt to gracefully exit QEMU
> after a backup command being rejected, bdrv_close_all will fail and
> tell you some unpleasant things via assert().
> 
> Reported-by: aihua liang 
> Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1703916
> Signed-off-by: John Snow 
> ---
>  blockdev.c | 12 +---
>  1 file changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/blockdev.c b/blockdev.c
> index 79fbac8450..278ecdd122 100644
> --- a/blockdev.c
> +++ b/blockdev.c
> @@ -3525,8 +3525,7 @@ static BlockJob *do_drive_backup(DriveBackup *backup, 
> JobTxn *txn,
>  if (set_backing_hd) {
>  bdrv_set_backing_hd(target_bs, source, &local_err);
>  if (local_err) {
> -bdrv_unref(target_bs);
> -goto out;
> +goto unref;
>  }
>  }
>  
> @@ -3534,11 +3533,10 @@ static BlockJob *do_drive_backup(DriveBackup *backup, 
> JobTxn *txn,
>  bmap = bdrv_find_dirty_bitmap(bs, backup->bitmap);
>  if (!bmap) {
>  error_setg(errp, "Bitmap '%s' could not be found", 
> backup->bitmap);
> -bdrv_unref(target_bs);
> -goto out;
> +goto unref;
>  }
>  if (bdrv_dirty_bitmap_check(bmap, BDRV_BITMAP_DEFAULT, errp)) {
> -goto out;
> +goto unref;
>  }
>  }
>  if (!backup->auto_finalize) {
> @@ -3552,12 +3550,12 @@ static BlockJob *do_drive_backup(DriveBackup *backup, 
> JobTxn *txn,
>  backup->sync, bmap, backup->compress,
>  backup->on_source_error, backup->on_target_error,
>  job_flags, NULL, NULL, txn, &local_err);
> -bdrv_unref(target_bs);
>  if (local_err != NULL) {
>  error_propagate(errp, local_err);
> -goto out;

Please leave a 'goto unref' here so we can later add more code without
modifying unrelated error paths (or, more likely, forgetting to modify
them).

>  }
>  
> +unref:
> +bdrv_unref(target_bs);
>  out:
>  aio_context_release(aio_context);
>  return job;

With this fixed:
Reviewed-by: Kevin Wolf

Re: [Qemu-devel] [PATCH v4] s390: diagnose 318 info reset and migration support

On 13.05.19 12:55, Christian Borntraeger wrote:
> 
> 
> On 13.05.19 11:57, David Hildenbrand wrote:
>> On 13.05.19 11:51, Christian Borntraeger wrote:
>>>
>>>
>>> On 13.05.19 11:40, David Hildenbrand wrote:
 On 13.05.19 11:34, Christian Borntraeger wrote:
>
>
> On 13.05.19 10:03, David Hildenbrand wrote:
 +if ((SCCB_SIZE - sizeof(ReadInfo)) / sizeof(CPUEntry) < 
 S390_MAX_CPUS)
 +mc->max_cpus = S390_MAX_CPUS - 8;
>>>
>>> This is too complicated, just set it always to 240.
>>>
>>> However, I am still not sure how to best handle this scenario. One
>>> solution is
>>>
>>> 1. Set it statically to 240 for machine > 4.1
>>> 2. Keep the old machines unmodifed
>>> 3. Don't indicate the CPU feature for machines <= 4.0
>>>
>>> #3 is the problematic part, as it mixes host CPU features and machines.
>>> Bad. The host CPU model should always look the same on all machines. I
>>> don't like this.
>>>
>>
>> FWIW, #3 is only an issue when modeling it via the CPU model, like
>> Christian suggested.
>>
>> I suggest the following
>>
>> 1. Set the max #cpus for 4.1 to 240 (already done)
>> 2. Keep it for the other machines unmodified (as suggested by Thomas)
>> 3. Create the layout of the SCCB depending on the machine type (to be 
>> done)
>>
>> If we want to model diag318 via a CPU feature (which makes sense for
>> migration):
>>
>> 4. Disable diag318 with a warning if used with a machine < 4.1
>>
>
> I think there is a simpler solution. It is perfectly fine to fail the 
> startup
> if we cannot fulfil the cpu model. So lets just allow 248 and allow this 
> feature 
> also for older machines. And if somebody chooses both at the same time,
> lets fails the startup.

 To which knob do you want to glue the layout of the SCLP response? Like
 I described?  Do you mean instead of warning and masking the feature off
 as I suggested, simply failing?
>>>
>>> The sclp response will depend on the dia318 cpu model flag. If its on, the 
>>> sclp
>>> response will have it, otherwise not.
>>> - host-passthrough: not migration safe anyway
>>> - host-model: if the target has diag318 good, otherwise we reject migration 

 In that case, -machine ..-4.0 -cpu host will not work on new HW with new
 KVM. Just noting.
>>>
>>> Only if you have 248 CPUs (which is unlikely). My point was to do that for 
>>> all
>>> machine levels.
>>>
>>
>> The issue with this approach is that e.g. libvirt is not aware of this
>> restriction. It could query "max_cpus" and expand the host-cpu model,
>> but starting a guest with > 240 cpus would fail. Maybe this is acceptable.
> 
> As of today we do the cpu model check in the same way. libvirt actually tries
> to run QEMU and handles failures.
> 
> For a failure, the user still has still to use >240 CPUs in its XML. The only 
> downside
> is that libvirt will not reject this right away.
> 
> During startup we would then print an error message like
> 
> "The diag318 cpu feature is only supported for 240 and less CPUs."
> 
> This is of similar quality as
> "Selected CPU GA level is too new. Maximum supported model in the 
> configuration: \'%s\'",
> 

But that can be tested using the runability information if I am not wrong.

> and others that we have today.
> 
> So yes, I think this would be acceptable.

I guess it is acceptable yes. I doubt anybody uses that many CPUs in
production either way. But you never know.

-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH v4] s390: diagnose 318 info reset and migration support

2019-05-13 Thread Cornelia Huck

On Mon, 13 May 2019 13:34:35 +0200
David Hildenbrand  wrote:

> On 13.05.19 12:55, Christian Borntraeger wrote:
> > 
> > 
> > On 13.05.19 11:57, David Hildenbrand wrote:  
> >> On 13.05.19 11:51, Christian Borntraeger wrote:  
> >>>
> >>>
> >>> On 13.05.19 11:40, David Hildenbrand wrote:  
>  On 13.05.19 11:34, Christian Borntraeger wrote:  
> >
> >
> > On 13.05.19 10:03, David Hildenbrand wrote:  
>  +if ((SCCB_SIZE - sizeof(ReadInfo)) / sizeof(CPUEntry) < 
>  S390_MAX_CPUS)
>  +mc->max_cpus = S390_MAX_CPUS - 8;  
> >>>
> >>> This is too complicated, just set it always to 240.
> >>>
> >>> However, I am still not sure how to best handle this scenario. One
> >>> solution is
> >>>
> >>> 1. Set it statically to 240 for machine > 4.1
> >>> 2. Keep the old machines unmodifed
> >>> 3. Don't indicate the CPU feature for machines <= 4.0
> >>>
> >>> #3 is the problematic part, as it mixes host CPU features and 
> >>> machines.
> >>> Bad. The host CPU model should always look the same on all machines. I
> >>> don't like this.
> >>>  
> >>
> >> FWIW, #3 is only an issue when modeling it via the CPU model, like
> >> Christian suggested.
> >>
> >> I suggest the following
> >>
> >> 1. Set the max #cpus for 4.1 to 240 (already done)
> >> 2. Keep it for the other machines unmodified (as suggested by Thomas)
> >> 3. Create the layout of the SCCB depending on the machine type (to be 
> >> done)
> >>
> >> If we want to model diag318 via a CPU feature (which makes sense for
> >> migration):
> >>
> >> 4. Disable diag318 with a warning if used with a machine < 4.1
> >>  
> >
> > I think there is a simpler solution. It is perfectly fine to fail the 
> > startup
> > if we cannot fulfil the cpu model. So lets just allow 248 and allow 
> > this feature 
> > also for older machines. And if somebody chooses both at the same time,
> > lets fails the startup.  
> 
>  To which knob do you want to glue the layout of the SCLP response? Like
>  I described?  Do you mean instead of warning and masking the feature off
>  as I suggested, simply failing?  
> >>>
> >>> The sclp response will depend on the dia318 cpu model flag. If its on, 
> >>> the sclp
> >>> response will have it, otherwise not.
> >>> - host-passthrough: not migration safe anyway
> >>> - host-model: if the target has diag318 good, otherwise we reject 
> >>> migration   
> 
>  In that case, -machine ..-4.0 -cpu host will not work on new HW with new
>  KVM. Just noting.  
> >>>
> >>> Only if you have 248 CPUs (which is unlikely). My point was to do that 
> >>> for all
> >>> machine levels.
> >>>  
> >>
> >> The issue with this approach is that e.g. libvirt is not aware of this
> >> restriction. It could query "max_cpus" and expand the host-cpu model,
> >> but starting a guest with > 240 cpus would fail. Maybe this is acceptable. 
> >>  
> > 
> > As of today we do the cpu model check in the same way. libvirt actually 
> > tries
> > to run QEMU and handles failures.
> > 
> > For a failure, the user still has still to use >240 CPUs in its XML. The 
> > only downside
> > is that libvirt will not reject this right away.
> > 
> > During startup we would then print an error message like
> > 
> > "The diag318 cpu feature is only supported for 240 and less CPUs."
> > 
> > This is of similar quality as
> > "Selected CPU GA level is too new. Maximum supported model in the 
> > configuration: \'%s\'",
> >   
> 
> But that can be tested using the runability information if I am not wrong.

You mean the cpu level information, right?

> 
> > and others that we have today.
> > 
> > So yes, I think this would be acceptable.  
> 
> I guess it is acceptable yes. I doubt anybody uses that many CPUs in
> production either way. But you never know.

I think that using that many cpus is a more uncommon setup, but I still
think that having to wait for actual failure is worse than being able
to find out beforehand. Any way to make this discoverable?

Re: [Qemu-devel] [PATCH 0/3] Export machine type deprecation info through QMP

Eduardo Habkost  writes:

> On Fri, May 10, 2019 at 11:29:53AM +0200, Markus Armbruster wrote:
> [...]
>> >> >> > We could extend QAPI introspection to return that if necessary,
>> >> >> > right?
>> >> >> 
>> >> >> I'm confident we can come up with *something*.  It might kill the neat
>> >> >> and simple "use QAPI features to communicate deprecation" idea, though.
>> >> >
>> >> > If something is important enough to be communicated through
>> >> > stderr, it's important enough to be communicated through QMP.
>> >> 
>> >> Mostly.  Differences are due to the different consumers.
>> >> 
>> >> stderr is primarily for human users.  We print stuff useful to human
>> >> users.
>> >
>> > We have users that don't have access to stderr.  They might have
>> > access to log files, but log files are pretty bad user
>> > interfaces.  If it's important for some set of human users, apps
>> > using libvirt or QMP need access to that information so they can
>> > show it to their human users too.
>> 
>> Command line means stderr.
>
> I disagree.
>
>> I'm afraid our command line is awkward both for machines and for humans,
>> albeit for different reasons.
>> 
>> For humans doing simple things, the command line is okay.  But beyond
>> that, it gets forbiddingly unwieldy[2].
>> 
>> Machines are fine with that kind of unwieldy, but would prefer something
>> with more structure, both on input (talking to QEMU) and even more so on
>> output (QEMU talking back).
>> 
>> Ideally, we'd support machines do their work in (structured) QMP,
>> resorting to the command line only to set up a QMP monitor.  We're not
>> anywhere close to this.
>> 
>> As long as management applications use the command line in not-trivial
>> ways, they have to deal with configuration errors reported via stderr.
>
> That's only true if we want to.
>
> Command line is an interface usable by machines.  Not the ideal,
> but it works.
>
> Messages on stderr are not an interface for machines.  We must
> provide something better, and I don't think "wait until we
> convert everything to QMP" is a reasonable answer.

Where else do you propose to report command line errors?

In what format?

>> >> QMP is primarily for machines, secondarily for the humans building these
>> >> machines.  We send stuff useful to the machines themselves, and stuff
>> >> the machines can use to be more useful for their users (which may be
>> >> machines or humans).  We can also send stuff to help the humans building
>> >> the machines.
>> >>
>> >> In any case, the information we provide is limited by the cost to
>> >> provide it.
>> >
>> > Absolutely.
>> >
>> >> 
>> >> > Is that enough reason to provide something more complex?
>> >> 
>> >> We need to consider cost / benefit.
>> >> 
>> >> On benefit, I'd like to know what libvirt would do with the additional
>> >> information beyond logging it.
>> >
>> > I'd say it should provide it to apps, otherwise this won't be
>> > more useful than the existing log files.
>> 
>> A management application simply showing its user whatever error QEMU
>> reports or hint it provides is bound to be confusing: since QEMU talks
>> in QEMU terms, its errors and hints generally need translation to make
>> sense at higher layers.  Translation involves recognizing specific
>> messages, which means it's limited to special cases (and painfully
>> brittle).
>> 
>> The farther you propagate QEMU's messages up the stack, the less sense
>> they'll likely make.
>> 
>> Management applications logging QEMU's messages is useful anyway, mainly
>> because it's better than nothing.
>> 
>> I doubt logging them some more further up the stack would be all that
>> useful, but I might be wrong.
>> 
>> Discussed further elsewhere in this thread.
>> 
>> >> Is the additional information you propose to provide static or dynamic?
>> >> 
>> >> By "static", I mean each occurence of a feature in the QAPI schema is
>> >> tied to one fixed instance of "additional information".
>> >
>> > I don't think I understand this description of "static".  I
>> > expect the data to be fixed at build time, but I expect it to be
>> > different in downstream distributions of QEMU.
>> 
>> Let me try differently.
>> 
>> QAPI features as currently envisaged convey one bit of information:
>> there / not there.  The information is fixed at build time.  It is tied
>> to a specific QAPI entity (command, object type, enumeration value,
>> ...).
>> 
>> My question is about the difference between this and what you have in
>> mind.  Specifically, is the difference only the amount of information
>> (one bit vs. a pair of string literals), or is there more?
>
> Right now, it's only in the amount of information.
>
>> 
>> "More" includes string values that can vary at run time or between
>> different uses of the QAPI entity in the schema.
>
> Right now, it includes string values that are fixed at build
> time, but collected dynamically at run time (because we are
> describing QOM types, which are collected dynamically).

Thank

Re: [Qemu-devel] [PATCH] qcow2: Define and use QCOW2_COMPRESSED_SECTOR_SIZE

2019-05-13 Thread Alberto Garcia

On Mon 13 May 2019 01:28:46 PM CEST, Stefano Garzarella wrote:
>> +int size = QCOW2_COMPRESSED_SECTOR_SIZE *
>> +(((l2_entry >> s->csize_shift) & s->csize_mask) + 1);
>
> What about using int64_t type for the 'size' variable?
> (because the qcow2_free_clusters() 'size' parameter is int64_t)

The maximum size that can be read from a compressed cluster descriptor
using the formula above is twice the cluster size (more information on
commit abd3622cc03cf41ed542126a540385f30a4c0175 and on the Compressed
Clusters Descriptor spec in docs/interop/qcow2.txt).

Since the maximum allowed cluster size is 2MB, the value of the 'size'
variable can never be larger than 4MB, which fits comfortably on a
32-bit integer. We would need to support 512MB clusters in order to have
problems with this.

Berto

Re: [Qemu-devel] [PATCH v4 3/5] linux-user: Add support the SIOCIFPFLAGS ioctls for all targets


On 03/05/2019 19:50, Aleksandar Markovic wrote:

From: Neng Chen 

Add support for getting and setting extended private flags of a
network device via SIOCSIFPFLAGS and SIOCGIFPFLAGS ioctls.

The ioctl numeric values are platform-independent and determined by
the file include/uapi/linux/sockios.h in Linux kernel source code:

   #define SIOCSIFPFLAGS 0x8934
   #define SIOCGIFPFLAGS0x8935

These ioctls get (or set) the field ifr_flags of type short in the
structure ifreq. Such functionality is achieved in QEMU by using
MK_STRUCT() and MK_PTR() macros with an appropriate argument, as
it was done for existing similar cases.

Signed-off-by: Neng Chen 
Signed-off-by: Aleksandar Markovic 
Message-Id: <1554839486-3527-1-git-send-email-aleksandar.marko...@rt-rk.com>
---
  linux-user/ioctls.h   | 2 ++
  linux-user/syscall_defs.h | 2 ++
  2 files changed, 4 insertions(+)


Reviewed-by: Laurent Vivier

[Qemu-devel] [PATCH V3 2/3] hw/display/ramfb: lock guest resolution after it's set

From: Hou Qiming 

Only allow one resolution change per guest boot, which prevents a
crash when the guest writes garbage to the configuration space (e.g.
when rebooting).

Signed-off-by: HOU Qiming 
[fixed malformed patch]
Signed-off-by: Marcel Apfelbaum 
---
 hw/display/ramfb.c | 26 ++
 1 file changed, 22 insertions(+), 4 deletions(-)

diff --git a/hw/display/ramfb.c b/hw/display/ramfb.c
index 1955b048dd..0fe79aa856 100644
--- a/hw/display/ramfb.c
+++ b/hw/display/ramfb.c
@@ -30,6 +30,7 @@ struct RAMFBState {
 DisplaySurface *ds;
 uint32_t width, height;
 struct RAMFBCfg cfg;
+bool locked;
 };
 
 static void ramfb_unmap_display_surface(pixman_image_t *image, void *unused)
@@ -70,18 +71,25 @@ static DisplaySurface *ramfb_create_display_surface(int 
width, int height,
 static void ramfb_fw_cfg_write(void *dev, off_t offset, size_t len)
 {
 RAMFBState *s = dev;
-uint32_t fourcc, format;
+uint32_t fourcc, format, width, height;
 hwaddr stride, addr;
 
-s->width  = be32_to_cpu(s->cfg.width);
-s->height = be32_to_cpu(s->cfg.height);
+width = be32_to_cpu(s->cfg.width);
+height= be32_to_cpu(s->cfg.height);
 stride= be32_to_cpu(s->cfg.stride);
 fourcc= be32_to_cpu(s->cfg.fourcc);
 addr  = be64_to_cpu(s->cfg.addr);
 format= qemu_drm_format_to_pixman(fourcc);
 
 fprintf(stderr, "%s: %dx%d @ 0x%" PRIx64 "\n", __func__,
-s->width, s->height, addr);
+width, height, addr);
+if (s->locked) {
+fprintf(stderr, "%s: resolution locked, change rejected\n", __func__);
+return;
+}
+s->locked = true;
+s->width = width;
+s->height = height;
 s->ds = ramfb_create_display_surface(s->width, s->height,
  format, stride, addr);
 }
@@ -101,6 +109,13 @@ void ramfb_display_update(QemuConsole *con, RAMFBState *s)
 dpy_gfx_update_full(con);
 }
 
+static void ramfb_reset(void *opaque)
+{
+RAMFBState *s = (RAMFBState *)opaque;
+s->locked = false;
+memset(&s->cfg, 0, sizeof(s->cfg));
+}
+
 RAMFBState *ramfb_setup(Error **errp)
 {
 FWCfgState *fw_cfg = fw_cfg_find();
@@ -113,9 +128,12 @@ RAMFBState *ramfb_setup(Error **errp)
 
 s = g_new0(RAMFBState, 1);
 
+s->locked = false;
+
 rom_add_vga("vgabios-ramfb.bin");
 fw_cfg_add_file_callback(fw_cfg, "etc/ramfb",
  NULL, ramfb_fw_cfg_write, s,
  &s->cfg, sizeof(s->cfg), false);
+qemu_register_reset(ramfb_reset, s);
 return s;
 }
-- 
2.17.1

[Qemu-devel] [PATCH V3 0/3] ramfb improvements

Please see the description in each patch.

Qiming, thanks for taking the time to upstream your patches!
Marcel

V2 - V3:
 - rebase to latest master
 - send as new series
 - use QEMU coding conventions
 - fixed malformed patches (maybe I didn't import them right)

Hou Qiming (3):
  hw/display/ramfb: fix guest memory un-mapping
  hw/display/ramfb: lock guest resolution after it's set
  hw/display/ramfb: initialize fw-config space with xres/ yres

 hw/display/ramfb-standalone.c | 12 -
 hw/display/ramfb.c| 89 ---
 hw/vfio/display.c |  4 +-
 include/hw/display/ramfb.h|  2 +-
 stubs/ramfb.c |  2 +-
 5 files changed, 88 insertions(+), 21 deletions(-)

-- 
2.17.1

Re: [Qemu-devel] [PULL 0/5] demacro SoftMMU

On Fri, 10 May 2019 at 21:01, Alex Bennée  wrote:
>
> The following changes since commit a6ae23831b05a11880b40f7d58e332c45a6b04f7:
>
>   Merge remote-tracking branch 
> 'remotes/ehabkost/tags/python-next-pull-request' into staging (2019-05-03 
> 15:26:09 +0100)
>
> are available in the Git repository at:
>
>   https://github.com/stsquad/qemu.git tags/pull-demacro-softmmu-100519-1
>
> for you to fetch changes up to 4601f8d10d7628bcaf2a8179af36e04b42879e91:
>
>   cputlb: Do unaligned store recursion to outermost function (2019-05-10 
> 20:23:21 +0100)
>
> 
> Demacrofy the SoftMMU
>
>   - the demacro itself
>   - refactor TLB_RECHECK and fix bug
>   - move unaligned handler out
>


Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/4.1
for any user-visible changes.

-- PMM

Re: [Qemu-devel] [PATCH v4 3/8] hw/acpi: Add ACPI Generic Event Device Support

2019-05-13 Thread Shameerali Kolothum Thodi

Hi Igor,

> -Original Message-
> From: Shameerali Kolothum Thodi
> Sent: 03 May 2019 13:46
> To: 'Igor Mammedov' 
> Cc: qemu-devel@nongnu.org; qemu-...@nongnu.org;
> eric.au...@redhat.com; peter.mayd...@linaro.org;
> shannon.zha...@gmail.com; sa...@linux.intel.com;
> sebastien.bo...@intel.com; xuwei (O) ;
> ler...@redhat.com; ard.biesheu...@linaro.org; Linuxarm
> 
> Subject: RE: [PATCH v4 3/8] hw/acpi: Add ACPI Generic Event Device Support
> 
> Hi Igor,
> 
> > -Original Message-
> > From: Igor Mammedov [mailto:imamm...@redhat.com]
> > Sent: 02 May 2019 17:13
> > To: Shameerali Kolothum Thodi 
> > Cc: qemu-devel@nongnu.org; qemu-...@nongnu.org;
> > eric.au...@redhat.com; peter.mayd...@linaro.org;
> > shannon.zha...@gmail.com; sa...@linux.intel.com;
> > sebastien.bo...@intel.com; xuwei (O) ;
> > ler...@redhat.com; ard.biesheu...@linaro.org; Linuxarm
> > 
> > Subject: Re: [PATCH v4 3/8] hw/acpi: Add ACPI Generic Event Device Support
> >

[...]

> > > +}
> > > +
> > > +static Property acpi_ged_properties[] = {
> > > +/*
> > > + * Memory hotplug base address is a property of GED here,
> > > + * because GED handles memory hotplug event and
> > MEMORY_HOTPLUG_DEVICE
> > > + * gets initialized when GED device is realized.
> > > + */
> > > +DEFINE_PROP_UINT64("memhp-base", AcpiGedState, memhp_base,
> > 0),
> > > +DEFINE_PROP_BOOL("memory-hotplug-support", AcpiGedState,
> > > + memhp_state.is_enabled, true),
> > > +DEFINE_PROP_PTR("gsi", AcpiGedState, gsi),
> >
> > PTR shouldn't be used in new code, look at object_property_add_link() & co
> 
> Ok. I will take a look at that.

I attempted to remove _PROP_PTR for "ged-events" and use _PROP_LINK and
_set_link(),


diff --git a/hw/acpi/generic_event_device.c b/hw/acpi/generic_event_device.c
index 856ca04c01..978c8e088e 100644
--- a/hw/acpi/generic_event_device.c
+++ b/hw/acpi/generic_event_device.c
@@ -268,7 +268,8 @@ static Property acpi_ged_properties[] = {
 DEFINE_PROP_PTR("gsi", AcpiGedState, gsi),
 DEFINE_PROP_UINT64("ged-base", AcpiGedState, ged_base, 0),
 DEFINE_PROP_UINT32("ged-irq", AcpiGedState, ged_irq, 0),
-DEFINE_PROP_PTR("ged-events", AcpiGedState, ged_events),
+DEFINE_PROP_LINK("ged-events", AcpiGedState, ged_events, TYPE_ACPI_GED,
+ GedEvent *),
 DEFINE_PROP_UINT32("ged-events-size", AcpiGedState, ged_events_size, 0),
 DEFINE_PROP_END_OF_LIST(),
 };
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 8179b3e511..c89b7b7120 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -537,7 +537,8 @@ static inline DeviceState *create_acpi_ged(VirtMachineState 
*vms)
 qdev_prop_set_ptr(dev, "gsi", vms->gsi);
 qdev_prop_set_uint64(dev, "ged-base", vms->memmap[VIRT_ACPI_GED].base);
 qdev_prop_set_uint32(dev, "ged-irq", vms->irqmap[VIRT_ACPI_GED]);
-qdev_prop_set_ptr(dev, "ged-events", ged_events);
+object_property_set_link(OBJECT(dev), OBJECT(ged_events), "ged-events",
+ &error_abort);
 qdev_prop_set_uint32(dev, "ged-events-size", ARRAY_SIZE(ged_events));
 
 object_property_add_child(qdev_get_machine(), "acpi-ged",
diff --git a/include/hw/acpi/generic_event_device.h 
b/include/hw/acpi/generic_event_device.h
index 9c840d8064..588f4ecfba 100644
--- a/include/hw/acpi/generic_event_device.h
+++ b/include/hw/acpi/generic_event_device.h
@@ -111,7 +111,7 @@ typedef struct AcpiGedState {
 hwaddr ged_base;
 GEDState ged_state;
 uint32_t ged_irq;
-void *ged_events;
+GedEvent *ged_events;
 uint32_t ged_events_size;
 } AcpiGedState;


And with this I get,

Segmentation fault  (core dumped) ./qemu-system-aarch64-ged-v5
-machine virt, -cpu cortex-a57 -machine type=virt -nographic -smp 1 -m
4G,maxmem=8G,slots=10 -drive if=none,file=ubuntu-est-5.0,id=fs -device
virtio-blk-device,drive=fs -kernel Image_memhp_remove -bios
QEMU_EFI_Release.fd -object memory-backend-ram,id=mem1,size=1G -device
pc-dimm,id=dimm1,memdev=mem1 -numa node,nodeid=0 -append
"console=ttyAMA0 root=/dev/vda rw acpi=force movable_node"

It looks like struct pointer cannot be used directly and has to make a QOM 
object
for DEFINE_PROP_LINK use. Not sure there is an easy way for setting ptr property
using link() functions. Please let me know if there any reference 
implementation I
can take a look.

Appreciate your help,

Thanks,
Shameer

[Qemu-devel] [PATCH V3 3/3] hw/display/ramfb: initialize fw-config space with xres/ yres

From: Hou Qiming 

If xres / yres were specified in QEMU command line, write them as an initial
resolution to the fw-config space on guest reset, which a later BIOS / OVMF
patch can take advantage of.

Signed-off-by: HOU Qiming 
[fixed malformed patch]
Signed-off-by: Marcel Apfelbaum 
---
 hw/display/ramfb-standalone.c | 12 +++-
 hw/display/ramfb.c| 16 +++-
 hw/vfio/display.c |  4 ++--
 include/hw/display/ramfb.h|  2 +-
 stubs/ramfb.c |  2 +-
 5 files changed, 30 insertions(+), 6 deletions(-)

diff --git a/hw/display/ramfb-standalone.c b/hw/display/ramfb-standalone.c
index da3229a1f6..6441449e7b 100644
--- a/hw/display/ramfb-standalone.c
+++ b/hw/display/ramfb-standalone.c
@@ -1,6 +1,7 @@
 #include "qemu/osdep.h"
 #include "qapi/error.h"
 #include "hw/loader.h"
+#include "hw/isa/isa.h"
 #include "hw/display/ramfb.h"
 #include "ui/console.h"
 #include "sysemu/sysemu.h"
@@ -11,6 +12,8 @@ typedef struct RAMFBStandaloneState {
 SysBusDevice parent_obj;
 QemuConsole *con;
 RAMFBState *state;
+uint32_t xres;
+uint32_t yres;
 } RAMFBStandaloneState;
 
 static void display_update_wrapper(void *dev)
@@ -33,15 +36,22 @@ static void ramfb_realizefn(DeviceState *dev, Error **errp)
 RAMFBStandaloneState *ramfb = RAMFB(dev);
 
 ramfb->con = graphic_console_init(dev, 0, &wrapper_ops, dev);
-ramfb->state = ramfb_setup(errp);
+ramfb->state = ramfb_setup(dev, errp);
 }
 
+static Property ramfb_properties[] = {
+DEFINE_PROP_UINT32("xres", RAMFBStandaloneState, xres, 0),
+DEFINE_PROP_UINT32("yres", RAMFBStandaloneState, yres, 0),
+DEFINE_PROP_END_OF_LIST(),
+};
+
 static void ramfb_class_initfn(ObjectClass *klass, void *data)
 {
 DeviceClass *dc = DEVICE_CLASS(klass);
 
 set_bit(DEVICE_CATEGORY_DISPLAY, dc->categories);
 dc->realize = ramfb_realizefn;
+dc->props = ramfb_properties;
 dc->desc = "ram framebuffer standalone device";
 dc->user_creatable = true;
 }
diff --git a/hw/display/ramfb.c b/hw/display/ramfb.c
index 0fe79aa856..b4eb283ef8 100644
--- a/hw/display/ramfb.c
+++ b/hw/display/ramfb.c
@@ -12,6 +12,7 @@
  */
 #include "qemu/osdep.h"
 #include "qapi/error.h"
+#include "qemu/option.h"
 #include "hw/loader.h"
 #include "hw/display/ramfb.h"
 #include "ui/console.h"
@@ -29,6 +30,7 @@ struct QEMU_PACKED RAMFBCfg {
 struct RAMFBState {
 DisplaySurface *ds;
 uint32_t width, height;
+uint32_t starting_width, starting_height;
 struct RAMFBCfg cfg;
 bool locked;
 };
@@ -114,9 +116,11 @@ static void ramfb_reset(void *opaque)
 RAMFBState *s = (RAMFBState *)opaque;
 s->locked = false;
 memset(&s->cfg, 0, sizeof(s->cfg));
+s->cfg.width = s->starting_width;
+s->cfg.height = s->starting_height;
 }
 
-RAMFBState *ramfb_setup(Error **errp)
+RAMFBState *ramfb_setup(DeviceState* dev, Error **errp)
 {
 FWCfgState *fw_cfg = fw_cfg_find();
 RAMFBState *s;
@@ -128,6 +132,16 @@ RAMFBState *ramfb_setup(Error **errp)
 
 s = g_new0(RAMFBState, 1);
 
+const char *s_fb_width = qemu_opt_get(dev->opts, "xres");
+const char *s_fb_height = qemu_opt_get(dev->opts, "yres");
+if (s_fb_width) {
+s->cfg.width = atoi(s_fb_width);
+s->starting_width = s->cfg.width;
+}
+if (s_fb_height) {
+s->cfg.height = atoi(s_fb_height);
+s->starting_height = s->cfg.height;
+}
 s->locked = false;
 
 rom_add_vga("vgabios-ramfb.bin");
diff --git a/hw/vfio/display.c b/hw/vfio/display.c
index a3d9c8f5be..2c2d3e5b71 100644
--- a/hw/vfio/display.c
+++ b/hw/vfio/display.c
@@ -352,7 +352,7 @@ static int vfio_display_dmabuf_init(VFIOPCIDevice *vdev, 
Error **errp)
   &vfio_display_dmabuf_ops,
   vdev);
 if (vdev->enable_ramfb) {
-vdev->dpy->ramfb = ramfb_setup(errp);
+vdev->dpy->ramfb = ramfb_setup(DEVICE(vdev), errp);
 }
 vfio_display_edid_init(vdev);
 return 0;
@@ -478,7 +478,7 @@ static int vfio_display_region_init(VFIOPCIDevice *vdev, 
Error **errp)
   &vfio_display_region_ops,
   vdev);
 if (vdev->enable_ramfb) {
-vdev->dpy->ramfb = ramfb_setup(errp);
+vdev->dpy->ramfb = ramfb_setup(DEVICE(vdev), errp);
 }
 return 0;
 }
diff --git a/include/hw/display/ramfb.h b/include/hw/display/ramfb.h
index b33a2c467b..f6c2de93b2 100644
--- a/include/hw/display/ramfb.h
+++ b/include/hw/display/ramfb.h
@@ -4,7 +4,7 @@
 /* ramfb.c */
 typedef struct RAMFBState RAMFBState;
 void ramfb_display_update(QemuConsole *con, RAMFBState *s);
-RAMFBState *ramfb_setup(Error **errp);
+RAMFBState *ramfb_setup(DeviceState *dev, Error **errp);
 
 /* ramfb-standalone.c */
 #define TYPE_RAMFB_DEVICE "ramfb"
diff --git a/stubs/ramfb.c b/stubs/ramfb.c
index 48143f3354..0799093a5d 100644
--- a/stubs/ramfb.c
+++ b/stubs/ramfb.c
@@ -6,7 +6,7 @@ void

[Qemu-devel] [PATCH V3 1/3] hw/display/ramfb: fix guest memory un-mapping

From: Hou Qiming 

Pulled back the `qemu_create_displaysurface_guestmem` function to create
the display surface so that the guest memory gets properly unmapped.

Signed-off-by: HOU Qiming 
[rename the new functions and use QEMU coding style]
Signed-off-by: Marcel Apfelbaum 
---
 hw/display/ramfb.c | 51 ++
 1 file changed, 38 insertions(+), 13 deletions(-)

diff --git a/hw/display/ramfb.c b/hw/display/ramfb.c
index 25c8ad7c25..1955b048dd 100644
--- a/hw/display/ramfb.c
+++ b/hw/display/ramfb.c
@@ -32,33 +32,58 @@ struct RAMFBState {
 struct RAMFBCfg cfg;
 };
 
+static void ramfb_unmap_display_surface(pixman_image_t *image, void *unused)
+{
+void *data = pixman_image_get_data(image);
+uint32_t size = pixman_image_get_stride(image) *
+pixman_image_get_height(image);
+cpu_physical_memory_unmap(data, size, 0, 0);
+}
+
+static DisplaySurface *ramfb_create_display_surface(int width, int height,
+pixman_format_code_t 
format,
+int linesize, uint64_t 
addr)
+{
+DisplaySurface *surface;
+hwaddr size;
+void *data;
+
+if (linesize == 0) {
+linesize = width * PIXMAN_FORMAT_BPP(format) / 8;
+}
+
+size = (hwaddr)linesize * height;
+data = cpu_physical_memory_map(addr, &size, 0);
+if (size != (hwaddr)linesize * height) {
+cpu_physical_memory_unmap(data, size, 0, 0);
+return NULL;
+}
+
+surface = qemu_create_displaysurface_from(width, height,
+  format, linesize, data);
+pixman_image_set_destroy_function(surface->image,
+  ramfb_unmap_display_surface, NULL);
+
+return surface;
+}
+
 static void ramfb_fw_cfg_write(void *dev, off_t offset, size_t len)
 {
 RAMFBState *s = dev;
-void *framebuffer;
 uint32_t fourcc, format;
-hwaddr stride, addr, length;
+hwaddr stride, addr;
 
 s->width  = be32_to_cpu(s->cfg.width);
 s->height = be32_to_cpu(s->cfg.height);
 stride= be32_to_cpu(s->cfg.stride);
 fourcc= be32_to_cpu(s->cfg.fourcc);
 addr  = be64_to_cpu(s->cfg.addr);
-length= stride * s->height;
 format= qemu_drm_format_to_pixman(fourcc);
 
 fprintf(stderr, "%s: %dx%d @ 0x%" PRIx64 "\n", __func__,
 s->width, s->height, addr);
-framebuffer = address_space_map(&address_space_memory,
-addr, &length, false,
-MEMTXATTRS_UNSPECIFIED);
-if (!framebuffer || length < stride * s->height) {
-s->width = 0;
-s->height = 0;
-return;
-}
-s->ds = qemu_create_displaysurface_from(s->width, s->height,
-format, stride, framebuffer);
+s->ds = ramfb_create_display_surface(s->width, s->height,
+ format, stride, addr);
 }
 
 void ramfb_display_update(QemuConsole *con, RAMFBState *s)
-- 
2.17.1

Re: [Qemu-devel] [PATCH v4 4/5] linux-user: Add support for setsockopt() options IPV6__MEMBERSHIP