Re: [PATCH] accel: Move Xen accelerator code under accel/xen/

[Philippe Mathieu-Daudé]

On 5/7/20 5:58 PM, Philippe Mathieu-Daudé wrote:

This code is not related to hardware emulation.
Move it under accel/ with the other hypervisors.

Signed-off-by: Philippe Mathieu-Daudé 
---
We could also move the memory management functions from
hw/i386/xen/xen-hvm.c but it is not trivial.

Necessary step to remove "exec/ram_addr.h" in the next series.
---
  include/exec/ram_addr.h|  2 +-
  include/hw/xen/xen.h   | 11 --
  include/sysemu/xen.h   | 40 ++
  hw/xen/xen-common.c => accel/xen/xen-all.c |  3 ++
  hw/acpi/piix4.c|  2 +-
  hw/i386/pc.c   |  1 +
  hw/i386/pc_piix.c  |  1 +
  hw/i386/pc_q35.c   |  1 +
  hw/i386/xen/xen-hvm.c  |  1 +
  hw/i386/xen/xen_platform.c |  1 +
  hw/isa/piix3.c |  1 +
  hw/pci/msix.c  |  1 +
  migration/savevm.c |  2 +-
  softmmu/vl.c   |  2 +-
  stubs/xen-hvm.c|  9 -
  target/i386/cpu.c  |  2 +-
  MAINTAINERS|  2 ++
  accel/Makefile.objs|  1 +
  accel/xen/Makefile.objs|  1 +
  hw/xen/Makefile.objs   |  2 +-
  20 files changed, 60 insertions(+), 26 deletions(-)
  create mode 100644 include/sysemu/xen.h
  rename hw/xen/xen-common.c => accel/xen/xen-all.c (99%)
  create mode 100644 accel/xen/Makefile.objs

diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h
index 5e59a3d8d7..4e05292f91 100644
--- a/include/exec/ram_addr.h
+++ b/include/exec/ram_addr.h
@@ -21,7 +21,7 @@
  
  #ifndef CONFIG_USER_ONLY

  #include "cpu.h"
-#include "hw/xen/xen.h"
+#include "sysemu/xen.h"
  #include "sysemu/tcg.h"
  #include "exec/ramlist.h"
  #include "exec/ramblock.h"
diff --git a/include/hw/xen/xen.h b/include/hw/xen/xen.h
index 5ac1c6dc55..771dd447f2 100644
--- a/include/hw/xen/xen.h
+++ b/include/hw/xen/xen.h
@@ -20,13 +20,6 @@ extern uint32_t xen_domid;
  extern enum xen_mode xen_mode;
  extern bool xen_domid_restrict;
  
-extern bool xen_allowed;

-
-static inline bool xen_enabled(void)
-{
-return xen_allowed;
-}
-
  int xen_pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num);
  void xen_piix3_set_irq(void *opaque, int irq_num, int level);
  void xen_piix_pci_write_config_client(uint32_t address, uint32_t val, int 
len);
@@ -39,10 +32,6 @@ void xenstore_store_pv_console_info(int i, struct Chardev 
*chr);
  
  void xen_hvm_init(PCMachineState *pcms, MemoryRegion **ram_memory);
  
-void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size,

-   struct MemoryRegion *mr, Error **errp);
-void xen_hvm_modified_memory(ram_addr_t start, ram_addr_t length);
-
  void xen_register_framebuffer(struct MemoryRegion *mr);
  
  #endif /* QEMU_HW_XEN_H */

diff --git a/include/sysemu/xen.h b/include/sysemu/xen.h
new file mode 100644
index 00..609d2d4184
--- /dev/null
+++ b/include/sysemu/xen.h
@@ -0,0 +1,40 @@
+/*
+ * QEMU Xen support
+ *
+ * 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 SYSEMU_XEN_H
+#define SYSEMU_XEN_H
+
+#ifdef CONFIG_XEN
+
+extern bool xen_allowed;
+
+#define xen_enabled() (xen_allowed)
+
+#ifndef CONFIG_USER_ONLY
+void xen_hvm_modified_memory(ram_addr_t start, ram_addr_t length);
+void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size,
+   struct MemoryRegion *mr, Error **errp);
+#endif
+
+#else /* !CONFIG_XEN */
+
+#define xen_enabled() 0
+#ifndef CONFIG_USER_ONLY
+static inline void xen_hvm_modified_memory(ram_addr_t start, ram_addr_t length)
+{
+abort();
+}
+static inline void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size,
+ MemoryRegion *mr, Error **errp)
+{
+abort();
+}
+#endif


Unfortunately this triggers:

#1  0x7fca778a5895 abort (libc.so.6)
#2  0x55f51ebd3e12 xen_hvm_modified_memory (qemu-system-aarch64)
#3  0x55f51ebd44c9 cpu_physical_memory_set_dirty_range 
(qemu-system-aarch64)

#4  0x55f51ebd9de4 ram_block_add (qemu-system-aarch64)
#5  0x55f51ebda2e3 qemu_ram_alloc_internal (qemu-system-aarch64)
#6  0x55f51ebda3be qemu_ram_alloc (qemu-system-aarch64)
#7  0x55f51ec3db9b memory_region_init_ram_shared_nomigrate 
(qemu-system-aarch64)

#8  0x55f51ef089e6 ram_backend_memory_alloc (qemu-system-aarch64)
#9  0x55f51ef081ae host_memory_backend_memory_complete 
(qemu-system-aarch64)

#10 0x55f51f2b624b user_creatable_complete (qemu-system-aarch64)
#11 0x55f51ed93382 create_default_memdev (qemu-system-aarch64)
#12 0x55f51ed96d1a qemu_init (qemu-system-aarch64)
#13 0x55f51f3b14bb main (qemu-system-aarch64)
#14 0x7fca778a6f43 __libc_start_main (libc.so.6)
#15 

Re: [PATCH] accel: Move Xen accelerator code under accel/xen/

[no-reply]

Patchew URL: https://patchew.org/QEMU/20200507155813.16169-1-phi...@redhat.com/



Hi,

This series failed the docker-quick@centos7 build test. Please find the testing 
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.

=== TEST SCRIPT BEGIN ===
#!/bin/bash
make docker-image-centos7 V=1 NETWORK=1
time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1
=== TEST SCRIPT END ===

/tmp/qemu-test/src/tests/qtest/libqtest.c:175: kill_qemu() detected QEMU death 
from signal 6 (Aborted) (core dumped)
  TESTcheck-unit: tests/check-qdict
  TESTiotest-qcow2: 007
ERROR - too few tests run (expected 5, got 0)
make: *** [check-qtest-aarch64] Error 1
make: *** Waiting for unfinished jobs
  TESTcheck-qtest-x86_64: tests/qtest/fdc-test
  TESTcheck-unit: tests/check-block-qdict
---
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', 
'--label', 'com.qemu.instance.uuid=e594b974940444968b77f9424310ca3c', '-u', 
'1003', '--security-opt', 'seccomp=unconfined', '--rm', '-e', 'TARGET_LIST=', 
'-e', 'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=14', '-e', 'DEBUG=', '-e', 
'SHOW_ENV=1', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', 
'/home/patchew2/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', 
'/var/tmp/patchew-tester-tmp-p2n4ope2/src/docker-src.2020-05-08-01.15.14.21618:/var/tmp/qemu:z,ro',
 'qemu:centos7', '/var/tmp/qemu/run', 'test-quick']' returned non-zero exit 
status 2.
filter=--filter=label=com.qemu.instance.uuid=e594b974940444968b77f9424310ca3c
make[1]: *** [docker-run] Error 1
make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-p2n4ope2/src'
make: *** [docker-run-test-quick@centos7] Error 2

real13m16.276s
user0m8.185s


The full log is available at
http://patchew.org/logs/20200507155813.16169-1-phi...@redhat.com/testing.docker-quick@centos7/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

[PATCH v3 2/2] char-socket: initialize reconnect timer only when the timer doesn't start

[Li Feng]

When the disconnect event is triggered in the connecting stage,
the tcp_chr_disconnect_locked may be called twice.

The first call:
#0  qemu_chr_socket_restart_timer (chr=0x5582ee90) at 
chardev/char-socket.c:120
#1  0x5558e38c in tcp_chr_disconnect_locked (chr=) 
at chardev/char-socket.c:490
#2  0x5558e3cd in tcp_chr_disconnect (chr=0x5582ee90) at 
chardev/char-socket.c:497
#3  0x5558ea32 in tcp_chr_new_client (chr=chr@entry=0x5582ee90, 
sioc=sioc@entry=0x5582f0b0) at chardev/char-socket.c:892
#4  0x5558eeb8 in qemu_chr_socket_connected (task=0x5582f300, 
opaque=) at chardev/char-socket.c:1090
#5  0x55574352 in qio_task_complete 
(task=task@entry=0x5582f300) at io/task.c:196
#6  0x555745f4 in qio_task_thread_result (opaque=0x5582f300) at 
io/task.c:111
#7  qio_task_wait_thread (task=0x5582f300) at io/task.c:190
#8  0x5558f17e in tcp_chr_wait_connected (chr=0x5582ee90, 
errp=0x55802a08 ) at chardev/char-socket.c:1013
#9  0x55567cbd in char_socket_client_reconnect_test 
(opaque=0x557fe020 ) at tests/test-char.c:1152
The second call:
#0  0x75ac3277 in raise () from /lib64/libc.so.6
#1  0x75ac4968 in abort () from /lib64/libc.so.6
#2  0x75abc096 in __assert_fail_base () from /lib64/libc.so.6
#3  0x75abc142 in __assert_fail () from /lib64/libc.so.6
#4  0x5558d10a in qemu_chr_socket_restart_timer 
(chr=0x5582ee90) at chardev/char-socket.c:125
#5  0x5558df0c in tcp_chr_disconnect_locked (chr=) 
at chardev/char-socket.c:490
#6  0x5558df4d in tcp_chr_disconnect (chr=0x5582ee90) at 
chardev/char-socket.c:497
#7  0x5558e5b2 in tcp_chr_new_client (chr=chr@entry=0x5582ee90, 
sioc=sioc@entry=0x5582f0b0) at chardev/char-socket.c:892
#8  0x5558e93a in tcp_chr_connect_client_sync 
(chr=chr@entry=0x5582ee90, errp=errp@entry=0x7fffd178) at 
chardev/char-socket.c:944
#9  0x5558ec78 in tcp_chr_wait_connected (chr=0x5582ee90, 
errp=0x55802a08 ) at chardev/char-socket.c:1035
#10 0x5556804b in char_socket_client_test (opaque=0x557fe020 
) at tests/test-char.c:1023

Run test/test-char to reproduce this issue.

test-char: chardev/char-socket.c:125: qemu_chr_socket_restart_timer: Assertion 
`!s->reconnect_timer' failed.

Signed-off-by: Li Feng 
---
 chardev/char-socket.c |  2 +-
 tests/test-char.c | 68 ---
 2 files changed, 55 insertions(+), 15 deletions(-)

diff --git a/chardev/char-socket.c b/chardev/char-socket.c
index 1f14c2c7c8..d84330b3c9 100644
--- a/chardev/char-socket.c
+++ b/chardev/char-socket.c
@@ -486,7 +486,7 @@ static void tcp_chr_disconnect_locked(Chardev *chr)
 if (emit_close) {
 qemu_chr_be_event(chr, CHR_EVENT_CLOSED);
 }
-if (s->reconnect_time) {
+if (s->reconnect_time && !s->reconnect_timer) {
 qemu_chr_socket_restart_timer(chr);
 }
 }
diff --git a/tests/test-char.c b/tests/test-char.c
index 8d39bdc9fa..d5c9049eec 100644
--- a/tests/test-char.c
+++ b/tests/test-char.c
@@ -625,12 +625,14 @@ static void char_udp_test(void)
 typedef struct {
 int event;
 bool got_pong;
+CharBackend *be;
 } CharSocketTestData;
 
 
 #define SOCKET_PING "Hello"
 #define SOCKET_PONG "World"
 
+typedef void (*char_socket_cb)(void *opaque, QEMUChrEvent event);
 
 static void
 char_socket_event(void *opaque, QEMUChrEvent event)
@@ -639,6 +641,27 @@ char_socket_event(void *opaque, QEMUChrEvent event)
 data->event = event;
 }
 
+static void
+char_socket_event_with_error(void *opaque, QEMUChrEvent event)
+{
+static bool first_error;
+CharSocketTestData *data = opaque;
+CharBackend *be = data->be;
+data->event = event;
+switch (event) {
+case CHR_EVENT_OPENED:
+if (!first_error) {
+first_error = true;
+qemu_chr_fe_disconnect(be);
+}
+return;
+case CHR_EVENT_CLOSED:
+return;
+default:
+return;
+}
+}
+
 
 static void
 char_socket_read(void *opaque, const uint8_t *buf, int size)
@@ -699,19 +722,24 @@ char_socket_addr_to_opt_str(SocketAddress *addr, bool 
fd_pass,
 }
 
 
-static void
+static int
 char_socket_ping_pong(QIOChannel *ioc)
 {
 char greeting[sizeof(SOCKET_PING)];
 const char *response = SOCKET_PONG;
 
-qio_channel_read_all(ioc, greeting, sizeof(greeting), _abort);
+int ret;
+ret = qio_channel_read_all(ioc, greeting, sizeof(greeting), _abort);
+if (ret != 0) {
+object_unref(OBJECT(ioc));
+return -1;
+}
 
 g_assert(memcmp(greeting, SOCKET_PING, sizeof(greeting)) == 0);
 
 qio_channel_write_all(ioc, response, sizeof(SOCKET_PONG), _abort);
-
 object_unref(OBJECT(ioc));
+return 0;
 }
 
 
@@ -783,6 +811,7 @@ static void char_socket_server_test(gconstpointer opaque)
 
  

[PATCH v3 1/2] io/channel: fix crash when qio_channel_readv_all return 0

[Li Feng]

Root cause:
>From `man recvmsg`, the RETURN VALUE says:
These  calls return the number of bytes received, or -1 if an error occurred.
In the event of an error, errno is set to indicate the error.
The return value will be 0 when the peer has performed an orderly shutdown.

When an error happens, the socket will be closed, and recvmsg return 0,
then error_setg will trigger a crash.

This unit test could reproduce this issue:
tests/test-char -p /char/socket/client/reconnect-error/unix

The core file backtrace is :

(gdb) bt
#0  0x75ac3277 in raise () from /lib64/libc.so.6
#1  0x75ac4968 in abort () from /lib64/libc.so.6
#2  0x555aaa94 in error_handle_fatal (errp=, 
err=0x7fffec0012d0) at util/error.c:40
#3  0x555aab6d in error_setv (errp=0x55802a08 , 
src=0x555c4280 "io/channel.c", line=148,
func=0x555c4580 <__func__.17489> "qio_channel_readv_all", 
err_class=ERROR_CLASS_GENERIC_ERROR,
fmt=, ap=0x7423bae0, suffix=0x0) at util/error.c:73
#4  0x555aacf0 in error_setg_internal 
(errp=errp@entry=0x55802a08 ,
src=src@entry=0x555c4280 "io/channel.c", line=line@entry=148,
func=func@entry=0x555c4580 <__func__.17489> "qio_channel_readv_all",
fmt=fmt@entry=0x555c43a0 "Unexpected end-of-file before all bytes 
were read") at util/error.c:97
#5  0x5556c25c in qio_channel_readv_all (ioc=, 
iov=, niov=,
errp=0x55802a08 ) at io/channel.c:147
#6  0x5556c29a in qio_channel_read_all (ioc=, 
buf=, buflen=,
errp=) at io/channel.c:247
#7  0x5556ad22 in char_socket_ping_pong (ioc=0x7fffec0008c0) at 
tests/test-char.c:732
#8  0x5556ae12 in char_socket_client_server_thread 
(data=data@entry=0x5582e350) at tests/test-char.c:891
#9  0x555a95b6 in qemu_thread_start (args=) at 
util/qemu-thread-posix.c:519
#10 0x75e61e25 in start_thread () from /lib64/libpthread.so.0
#11 0x75b8bbad in clone () from /lib64/libc.so.6

Signed-off-by: Li Feng 
---
 io/channel.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/io/channel.c b/io/channel.c
index e4376eb0bc..1a4a505f01 100644
--- a/io/channel.c
+++ b/io/channel.c
@@ -144,8 +144,6 @@ int qio_channel_readv_all(QIOChannel *ioc,
 
 if (ret == 0) {
 ret = -1;
-error_setg(errp,
-   "Unexpected end-of-file before all bytes were read");
 } else if (ret == 1) {
 ret = 0;
 }
-- 
2.11.0

Re: [PATCH v4 5/6] net/colo-compare.c, softmmu/vl.c: Check that colo-compare is active

[Derek Su]

On 2020/5/8 上午10:26, Zhang, Chen wrote:




-Original Message-
From: Lukas Straub 
Sent: Thursday, May 7, 2020 11:54 PM
To: Zhang, Chen 
Cc: qemu-devel ; Li Zhijian
; Jason Wang ; Marc-
André Lureau ; Paolo Bonzini

Subject: Re: [PATCH v4 5/6] net/colo-compare.c, softmmu/vl.c: Check that
colo-compare is active

On Thu, 7 May 2020 11:38:04 +
"Zhang, Chen"  wrote:


-Original Message-
From: Lukas Straub 
Sent: Monday, May 4, 2020 6:28 PM
To: qemu-devel 
Cc: Zhang, Chen ; Li Zhijian
; Jason Wang ; Marc-
André Lureau ; Paolo Bonzini

Subject: [PATCH v4 5/6] net/colo-compare.c, softmmu/vl.c: Check that
colo- compare is active

If the colo-compare object is removed before failover and a
checkpoint happens, qemu crashes because it tries to lock the
destroyed event_mtx in colo_notify_compares_event.

Fix this by checking if everything is initialized by introducing a
new variable colo_compare_active which is protected by a new mutex
colo_compare_mutex. The new mutex also protects against concurrent
access of the net_compares list and makes sure that
colo_notify_compares_event isn't active while we destroy event_mtx
and event_complete_cond.

With this it also is again possible to use colo without colo-compare
(periodic
mode) and to use multiple colo-compare for multiple network interfaces.



Hi Lukas,

For this case I think we don't need to touch vl.c code, we can solve this

issue from another perspective:

How to remove colo-compare?
User will use qemu-monitor or QMP command to disable an object, so we
just need return operation failed When user try to remove colo-compare

object while COLO is running.

Yeah, but that still leaves the other problem that colo can't be used without
colo-compare (qemu crashes then).


Yes, the COLO-compare is necessary module in COLO original design.
At most cases, user need it do dynamic sync.
For rare cases, maybe we can add a new colo-compare parameter to bypass all the 
network workload.


Hi, Chen

In our application, we only need "periodical mode" because of the 
performance issue, and have internal patch now. Is it OK to send the 
internal patch for review?


Thanks.

Regards,
Derek



Thanks
Zhang Chen



Regards,
Lukas Straub


Thanks
Zhang Chen


Signed-off-by: Lukas Straub 
---
  net/colo-compare.c | 35 +--
  net/colo-compare.h |  1 +
  softmmu/vl.c   |  2 ++
  3 files changed, 32 insertions(+), 6 deletions(-)

diff --git a/net/colo-compare.c b/net/colo-compare.c index
56db3d3bfc..c7572d75e9 100644
--- a/net/colo-compare.c
+++ b/net/colo-compare.c
@@ -54,6 +54,8 @@ static NotifierList colo_compare_notifiers =
#define REGULAR_PACKET_CHECK_MS 3000  #define

DEFAULT_TIME_OUT_MS

3000

+static QemuMutex colo_compare_mutex; static bool
+colo_compare_active;
  static QemuMutex event_mtx;
  static QemuCond event_complete_cond;  static int
event_unhandled_count; @@ -906,6 +908,12 @@ static void
check_old_packet_regular(void *opaque) void
colo_notify_compares_event(void *opaque, int event, Error **errp)  {
  CompareState *s;
+qemu_mutex_lock(_compare_mutex);
+
+if (!colo_compare_active) {
+qemu_mutex_unlock(_compare_mutex);
+return;
+}

  qemu_mutex_lock(_mtx);
  QTAILQ_FOREACH(s, _compares, next) { @@ -919,6 +927,7 @@
void colo_notify_compares_event(void *opaque, int event, Error **errp)
  }

  qemu_mutex_unlock(_mtx);
+qemu_mutex_unlock(_compare_mutex);
  }

  static void colo_compare_timer_init(CompareState *s) @@ -1274,7
+1283,14 @@ static void colo_compare_complete(UserCreatable *uc,

Error **errp)

 s->vnet_hdr);
  }

+qemu_mutex_lock(_compare_mutex);
+if (!colo_compare_active) {
+qemu_mutex_init(_mtx);
+qemu_cond_init(_complete_cond);
+colo_compare_active = true;
+}
  QTAILQ_INSERT_TAIL(_compares, s, next);
+qemu_mutex_unlock(_compare_mutex);

  s->out_sendco.s = s;
  s->out_sendco.chr = >chr_out; @@ -1290,9 +1306,6 @@ static
void colo_compare_complete(UserCreatable
*uc, Error **errp)

  g_queue_init(>conn_list);

-qemu_mutex_init(_mtx);
-qemu_cond_init(_complete_cond);
-
  s->connection_track_table =
g_hash_table_new_full(connection_key_hash,
connection_key_equal,
g_free, @@
-1384,12 +1397,19 @@ static void colo_compare_finalize(Object *obj)

  qemu_bh_delete(s->event_bh);

+qemu_mutex_lock(_compare_mutex);
  QTAILQ_FOREACH(tmp, _compares, next) {
  if (tmp == s) {
  QTAILQ_REMOVE(_compares, s, next);
  break;
  }
  }
+if (QTAILQ_EMPTY(_compares)) {
+colo_compare_active = false;
+qemu_mutex_destroy(_mtx);
+qemu_cond_destroy(_complete_cond);
+}
+qemu_mutex_unlock(_compare_mutex);

  AioContext *ctx = iothread_get_aio_context(s->iothread);
  

[PATCH 2/2] migration/rdma: cleanup rdma context before g_free to avoid memleaks

[Pan Nengyuan]

When error happen in initializing 'rdma_return_path', we should cleanup rdma 
context
before g_free(rdma) to avoid some memleaks. This patch fix that.

Reported-by: Euler Robot 
Signed-off-by: Pan Nengyuan 
---
 migration/rdma.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/migration/rdma.c b/migration/rdma.c
index 72e8b1c95b..ec45d33ba3 100644
--- a/migration/rdma.c
+++ b/migration/rdma.c
@@ -4094,20 +4094,20 @@ void rdma_start_outgoing_migration(void *opaque,
 rdma_return_path = qemu_rdma_data_init(host_port, errp);
 
 if (rdma_return_path == NULL) {
-goto err;
+goto return_path_err;
 }
 
 ret = qemu_rdma_source_init(rdma_return_path,
 s->enabled_capabilities[MIGRATION_CAPABILITY_RDMA_PIN_ALL], errp);
 
 if (ret) {
-goto err;
+goto return_path_err;
 }
 
 ret = qemu_rdma_connect(rdma_return_path, errp);
 
 if (ret) {
-goto err;
+goto return_path_err;
 }
 
 rdma->return_path = rdma_return_path;
@@ -4120,6 +4120,8 @@ void rdma_start_outgoing_migration(void *opaque,
 s->to_dst_file = qemu_fopen_rdma(rdma, "wb");
 migrate_fd_connect(s, NULL);
 return;
+return_path_err:
+qemu_rdma_cleanup(rdma);
 err:
 g_free(rdma);
 g_free(rdma_return_path);
-- 
2.18.2

Re: [PATCH] ppc/pnv: Fix NMI system reset SRR1 value

[Nicholas Piggin]

Excerpts from Cédric Le Goater's message of May 8, 2020 3:14 am:
> On 5/7/20 1:48 PM, Nicholas Piggin wrote:
>> Commit a77fed5bd926 ("ppc/pnv: Add support for NMI interface") got the
>> SRR1 setting wrong for sresets that hit outside of power-save states.
>> 
>> Fix this, better documenting the source for the bit definitions.
>> 
>> Fixes: a77fed5bd926 ("ppc/pnv: Add support for NMI interface") got the
>> Cc: Cédric Le Goater 
>> Cc: David Gibson 
>> Signed-off-by: Nicholas Piggin 
> 
> We should introduce some defines like the SRR1_WAKE ones in Linux and 
> cleanup powerpc_reset_wakeup(). This function uses cryptic values. 
> That can be done later on as a followup.
> 
> Reviewed-by: Cédric Le Goater 

Thanks.

>> ---
>> 
>> Thanks to Cedric for pointing out concerns with a previous MCE patch
>> that unearthed this as well. Linux does not actually care what these
>> SRR1[42:45] bits look like for non-powersave sresets, but we should
>> follow documented behaviour as far as possible.
> 
> We should introduce some defines like the SRR1_WAKE ones in Linux and 
> cleanup powerpc_reset_wakeup(). This function uses cryptic values. 
> That can be done later on as a followup.
> 
> 
> I am currently after a bug which results in a CPU hard lockup because 
> of a pending interrupt. It occurs on a SMP PowerNV machine when it is 
> stressed with IO, such as scp of a big file. 
> 
> I am suspecting more and more an issue with an interrupt being handled 
> when the CPU is coming out of idle. I haven't seen anything wrong in

So you can't hit it when booting Linux with powersave=off?

Do we model stop with EC=0 properly? Looks like helper_pminsn seems to
be doing the right thing there.

> the models. Unless this maybe :
> 
> /* Pretend to be returning from doze always as we don't lose state */
> *msr |= (0x1ull << (63 - 47));
> 
> I am not sure how in sync it is with PSSCR.

That should be okay, the hardware can always enter a shallower state 
than was asked for. Linux will handle it. For testing purpose, we could
model deeper states by scribbling on registers and indicating state loss.

Aide from SRR1 sleep state value, Linux uses the SRR1 wake reason value 
to run the interrupt handler, but even if we got SRR1 wrong, Linux 
eventually enables MSR[EE] so the interrupt should get replayed then 
(this is what Linux used to do until we added the wake-reason processing 
for improved performance).

But we do appear to get those right in powerpc_reset_wakeup().

Thanks,
Nick

[PATCH 1/2] migration/rdma: fix potential nullptr access in rdma_start_incoming_migration

[Pan Nengyuan]

'rdma' is NULL when taking the first error branch in 
rdma_start_incoming_migration.
And it will cause a null pointer access in label 'err'. Fix that.

Fixes: 59c59c67ee6b0327ae932deb303caa47919aeb1e
Signed-off-by: Pan Nengyuan 
---
 migration/rdma.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/migration/rdma.c b/migration/rdma.c
index 967fda5b0c..72e8b1c95b 100644
--- a/migration/rdma.c
+++ b/migration/rdma.c
@@ -4056,7 +4056,9 @@ void rdma_start_incoming_migration(const char *host_port, 
Error **errp)
 return;
 err:
 error_propagate(errp, local_err);
-g_free(rdma->host);
+if (rdma) {
+g_free(rdma->host);
+}
 g_free(rdma);
 g_free(rdma_return_path);
 }
-- 
2.18.2

Re: [PATCH] ppc/pnv: Fix NMI system reset SRR1 value

[no-reply]

Patchew URL: https://patchew.org/QEMU/20200507114824.788942-1-npig...@gmail.com/



Hi,

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

Message-id: 20200507114824.788942-1-npig...@gmail.com
Subject: [PATCH] ppc/pnv: Fix NMI system reset SRR1 value
Type: series

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
fbe72cb ppc/pnv: Fix NMI system reset SRR1 value

=== OUTPUT BEGIN ===
ERROR: code indent should never use tabs
#35: FILE: hw/ppc/pnv.c:1991:
+^I * Power-save wakeups, as indicated by non-zero SRR1[46:47] put the$

ERROR: code indent should never use tabs
#36: FILE: hw/ppc/pnv.c:1992:
+^I * wakeup reason in SRR1[42:45], system reset is indicated with 0b0100$

ERROR: code indent should never use tabs
#37: FILE: hw/ppc/pnv.c:1993:
+^I * (PPC_BIT(43)).$

ERROR: code indent should never use tabs
#38: FILE: hw/ppc/pnv.c:1994:
+^I */$

ERROR: line over 90 characters
#40: FILE: hw/ppc/pnv.c:1996:
+warn_report("ppc_cpu_do_system_reset does not set system reset 
wakeup reason");

ERROR: code indent should never use tabs
#45: FILE: hw/ppc/pnv.c:2001:
+^I * For non-powersave system resets, SRR1[42:45] are defined to be$

ERROR: code indent should never use tabs
#46: FILE: hw/ppc/pnv.c:2002:
+^I * implementation-dependent. The POWER9 User Manual specifies that$

ERROR: code indent should never use tabs
#47: FILE: hw/ppc/pnv.c:2003:
+^I * an external (SCOM driven, which may come from a BMC nmi command or$

ERROR: code indent should never use tabs
#48: FILE: hw/ppc/pnv.c:2004:
+^I * another CPU requesting a NMI IPI) system reset exception should be$

ERROR: code indent should never use tabs
#49: FILE: hw/ppc/pnv.c:2005:
+^I * 0b0010 (PPC_BIT(44)).$

total: 10 errors, 0 warnings, 32 lines checked

Commit fbe72cb9d465 (ppc/pnv: Fix NMI system reset SRR1 value) has style 
problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
=== OUTPUT END ===

Test command exited with code: 1


The full log is available at
http://patchew.org/logs/20200507114824.788942-1-npig...@gmail.com/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

[PATCH 0/2] migration/rdma: fix nullptr-def in rdma_start_incoming_migration

[Pan Nengyuan]

I fix a memleak in rdma_start_incoming_migration some time ago.
https://patchwork.kernel.org/patch/11498191/

I'm sorry that it may cause a null-pointer access, this patch fix that.

Since we are here, rdma_start_outgoing_migration has the similar memleak, fix 
it together.

Pan Nengyuan (2):
  migration/rdma: fix potential nullptr access in
rdma_start_incoming_migration
  migration/rdma: cleanup rdma context before g_free to avoid memleaks

 migration/rdma.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

-- 
2.18.2

Re: [PATCH 0/5] target/i386: fxtract, fscale fixes

[Richard Henderson]

On 5/7/20 7:57 AM, Joseph Myers wrote:
> On Thu, 7 May 2020, no-re...@patchew.org wrote:
> 
>> === OUTPUT BEGIN ===
>> 1/5 Checking commit 69eed0bcaaaf (target/i386: implement special cases for 
>> fxtract)
>> WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
> 
> I don't think any MAINTAINERS update is needed for a new testcase in an 
> existing directory.
> 
>> ERROR: Use of volatile is usually wrong, please add a comment
> 
> I think the justification for volatile in such testcase code is obvious 
> without comments in individual cases - to avoid any code movement or 
> optimization that might break what the tests are intending to test (these 
> tests are making heavy use of mixed C and inline asm to test how emulated 
> instructions behave, including on input representations that are not valid 
> long double values in the ABI and with the rounding precision changed 
> behind the compiler's back).  I think making everything possibly relevant 
> volatile in these tests is better than trying to produce a fragile 
> argument that in fact certain data does not need to be volatile to avoid 
> problematic code movement.
> 
>> ERROR: spaces required around that '-' (ctx:VxV)
>> #139: FILE: tests/tcg/i386/test-i386-fxtract.c:80:
>> +  "0" (0x1p-16445L));
>> ^
> 
> No, this is a C99 hex float contstant, not a subtraction.  There are 
> already such constants in tests/tcg/multiarch/float_helpers.c and 
> tests/tcg/multiarch/float_madds.c at least, so I assume they are OK in 
> QEMU floating-point tests and this style checker should not be objecting 
> to them.
> 

Correct, these are all false positives.


r~

Re: [RFC v3 5/6] qmp: add QMP command x-debug-virtio-queue-element

[Jason Wang]

On 2020/5/7 下午7:49, Laurent Vivier wrote:

This new command shows the information of a VirtQueue element.

Signed-off-by: Laurent Vivier 
---
  hw/virtio/virtio-stub.c |   9 +++
  hw/virtio/virtio.c  | 130 
  qapi/virtio.json|  94 +
  3 files changed, 233 insertions(+)

diff --git a/hw/virtio/virtio-stub.c b/hw/virtio/virtio-stub.c
index 3c1bf172acf6..8275e31430e7 100644
--- a/hw/virtio/virtio-stub.c
+++ b/hw/virtio/virtio-stub.c
@@ -23,3 +23,12 @@ VirtQueueStatus *qmp_x_debug_virtio_queue_status(const char 
*path,
  {
  return qmp_virtio_unsupported(errp);
  }
+
+VirtioQueueElement *qmp_x_debug_virtio_queue_element(const char* path,
+ uint16_t queue,
+ bool has_index,
+ uint16_t index,
+ Error **errp)
+{
+return qmp_virtio_unsupported(errp);
+}
diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 57552bf05014..66dc2cef1b39 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -4033,6 +4033,136 @@ VirtioStatus *qmp_x_debug_virtio_status(const char* 
path, Error **errp)
  return status;
  }
  
+static VirtioRingDescFlagsList *qmp_decode_vring_desc_flags(uint16_t flags)

+{
+VirtioRingDescFlagsList *list = NULL;
+VirtioRingDescFlagsList *node;
+int i;
+struct {
+uint16_t flag;
+VirtioRingDescFlags value;
+} map[] = {
+{ VRING_DESC_F_NEXT, VIRTIO_RING_DESC_FLAGS_NEXT },
+{ VRING_DESC_F_WRITE, VIRTIO_RING_DESC_FLAGS_WRITE },
+{ VRING_DESC_F_INDIRECT, VIRTIO_RING_DESC_FLAGS_INDIRECT },
+{ 1 << VRING_PACKED_DESC_F_AVAIL, VIRTIO_RING_DESC_FLAGS_AVAIL },
+{ 1 << VRING_PACKED_DESC_F_USED, VIRTIO_RING_DESC_FLAGS_USED },
+{ 0, -1 }
+};
+
+for (i = 0; map[i].flag; i++) {
+if ((map[i].flag & flags) == 0) {
+continue;
+}
+node = g_malloc0(sizeof(VirtioRingDescFlagsList));
+node->value = map[i].value;
+node->next = list;
+list = node;
+}
+
+return list;
+}
+
+VirtioQueueElement *qmp_x_debug_virtio_queue_element(const char* path,
+ uint16_t queue,
+ bool has_index,
+ uint16_t index,
+ Error **errp)
+{
+VirtIODevice *vdev;
+VirtQueue *vq;
+VirtioQueueElement *element = NULL;
+
+vdev = virtio_device_find(path);
+if (vdev == NULL) {
+error_setg(errp, "Path %s is not a VirtIO device", path);
+return NULL;
+}
+
+if (queue >= VIRTIO_QUEUE_MAX || !virtio_queue_get_num(vdev, queue)) {
+error_setg(errp, "Invalid virtqueue number %d", queue);
+return NULL;
+}
+vq = >vq[queue];
+
+if (virtio_vdev_has_feature(vdev, VIRTIO_F_RING_PACKED)) {
+error_setg(errp, "Packed ring not supported");
+return NULL;
+} else {
+unsigned int head, i, max;
+VRingMemoryRegionCaches *caches;
+MemoryRegionCache indirect_desc_cache = MEMORY_REGION_CACHE_INVALID;
+MemoryRegionCache *desc_cache;
+VRingDesc desc;
+VirtioRingDescList *list = NULL;
+VirtioRingDescList *node;
+int rc;
+
+RCU_READ_LOCK_GUARD();
+
+max = vq->vring.num;
+
+if (!has_index) {
+head = vring_avail_ring(vq, vq->last_avail_idx % vq->vring.num);
+} else {
+head = vring_avail_ring(vq, index % vq->vring.num);
+}
+i = head;
+
+caches = vring_get_region_caches(vq);
+if (!caches) {
+error_setg(errp, "Region caches not initialized");
+return NULL;
+}
+
+if (caches->desc.len < max * sizeof(VRingDesc)) {
+error_setg(errp, "Cannot map descriptor ring");
+return NULL;
+}
+
+desc_cache = >desc;
+vring_split_desc_read(vdev, , desc_cache, i);
+if (desc.flags & VRING_DESC_F_INDIRECT) {
+int64_t len;
+
+len = address_space_cache_init(_desc_cache, vdev->dma_as,
+   desc.addr, desc.len, false);
+desc_cache = _desc_cache;
+if (len < desc.len) {
+error_setg(errp, "Cannot map indirect buffer");
+goto done;
+}
+i = 0;
+vring_split_desc_read(vdev, , desc_cache, i);
+}
+
+element = g_new0(VirtioQueueElement, 1);
+element->index = head;
+element->ndescs = 0;
+
+do {
+node = g_new0(VirtioRingDescList, 1);
+node->value = g_new0(VirtioRingDesc, 1);
+node->value->addr = desc.addr;
+   

RE: [PATCH v4 6/6] net/colo-compare.c: Correct ordering in complete and finalize

[Zhang, Chen]

> -Original Message-
> From: Lukas Straub 
> Sent: Friday, May 8, 2020 12:09 AM
> To: Zhang, Chen 
> Cc: qemu-devel ; Li Zhijian
> ; Jason Wang ; Marc-
> André Lureau ; Paolo Bonzini
> 
> Subject: Re: [PATCH v4 6/6] net/colo-compare.c: Correct ordering in
> complete and finalize
> 
> On Thu, 7 May 2020 13:26:11 +
> "Zhang, Chen"  wrote:
> 
> > > -Original Message-
> > > From: Lukas Straub 
> > > Sent: Monday, May 4, 2020 6:28 PM
> > > To: qemu-devel 
> > > Cc: Zhang, Chen ; Li Zhijian
> > > ; Jason Wang ; Marc-
> > > André Lureau ; Paolo Bonzini
> > > 
> > > Subject: [PATCH v4 6/6] net/colo-compare.c: Correct ordering in
> > > complete and finalize
> > >
> > > In colo_compare_complete, insert CompareState into net_compares
> only
> > > after everything has been initialized.
> > > In colo_compare_finalize, remove CompareState from net_compares
> > > before anything is deinitialized.
> >
> > S/deinitialized/finalized
> >
> > It looks no dependences on each step on initialization and finalization.
> > Do you means we just need add/remove each colo-compare module at last
> in logic?
> 
> Yes. While I didn't see any crashes here, there is the possibility that if 
> colo-
> compare is removed during checkpoint, the destroyed event_bh is called
> from colo_notify_compares_event. Same with colo_compare_complete
> (very unlikely) if colo-compare is created while colo is running,
> colo_notify_compares_event may call the uninitialized event_bh.

As we discussed on 5/6, remove colo-compare during checkpoint is an illegal 
operation.

Thanks
Zhang Chen

> 
> Regards,
> Lukas Straub
> 
> > Or current code have some issue?
> >
> > Thanks
> > Zhang Chen
> >
> > >
> > > Signed-off-by: Lukas Straub 
> > > ---
> > >  net/colo-compare.c | 45
> > > +++--
> > >  1 file changed, 23 insertions(+), 22 deletions(-)
> > >
> > > diff --git a/net/colo-compare.c b/net/colo-compare.c index
> > > c7572d75e9..6f80bcece6 100644
> > > --- a/net/colo-compare.c
> > > +++ b/net/colo-compare.c
> > > @@ -1283,15 +1283,6 @@ static void
> > > colo_compare_complete(UserCreatable *uc, Error **errp)
> > > s->vnet_hdr);
> > >  }
> > >
> > > -qemu_mutex_lock(_compare_mutex);
> > > -if (!colo_compare_active) {
> > > -qemu_mutex_init(_mtx);
> > > -qemu_cond_init(_complete_cond);
> > > -colo_compare_active = true;
> > > -}
> > > -QTAILQ_INSERT_TAIL(_compares, s, next);
> > > -qemu_mutex_unlock(_compare_mutex);
> > > -
> > >  s->out_sendco.s = s;
> > >  s->out_sendco.chr = >chr_out;
> > >  s->out_sendco.notify_remote_frame = false; @@ -1312,6 +1303,16
> > > @@ static void colo_compare_complete(UserCreatable *uc, Error **errp)
> > >
> > > connection_destroy);
> > >
> > >  colo_compare_iothread(s);
> > > +
> > > +qemu_mutex_lock(_compare_mutex);
> > > +if (!colo_compare_active) {
> > > +qemu_mutex_init(_mtx);
> > > +qemu_cond_init(_complete_cond);
> > > +colo_compare_active = true;
> > > +}
> > > +QTAILQ_INSERT_TAIL(_compares, s, next);
> > > +qemu_mutex_unlock(_compare_mutex);
> > > +
> > >  return;
> > >  }
> > >
> > > @@ -1384,19 +1385,6 @@ static void colo_compare_finalize(Object *obj)
> > >  CompareState *s = COLO_COMPARE(obj);
> > >  CompareState *tmp = NULL;
> > >
> > > -qemu_chr_fe_deinit(>chr_pri_in, false);
> > > -qemu_chr_fe_deinit(>chr_sec_in, false);
> > > -qemu_chr_fe_deinit(>chr_out, false);
> > > -if (s->notify_dev) {
> > > -qemu_chr_fe_deinit(>chr_notify_dev, false);
> > > -}
> > > -
> > > -if (s->iothread) {
> > > -colo_compare_timer_del(s);
> > > -}
> > > -
> > > -qemu_bh_delete(s->event_bh);
> > > -
> > >  qemu_mutex_lock(_compare_mutex);
> > >  QTAILQ_FOREACH(tmp, _compares, next) {
> > >  if (tmp == s) {
> > > @@ -1411,6 +1399,19 @@ static void colo_compare_finalize(Object *obj)
> > >  }
> > >  qemu_mutex_unlock(_compare_mutex);
> > >
> > > +qemu_chr_fe_deinit(>chr_pri_in, false);
> > > +qemu_chr_fe_deinit(>chr_sec_in, false);
> > > +qemu_chr_fe_deinit(>chr_out, false);
> > > +if (s->notify_dev) {
> > > +qemu_chr_fe_deinit(>chr_notify_dev, false);
> > > +}
> > > +
> > > +if (s->iothread) {
> > > +colo_compare_timer_del(s);
> > > +}
> > > +
> > > +qemu_bh_delete(s->event_bh);
> > > +
> > >  AioContext *ctx = iothread_get_aio_context(s->iothread);
> > >  aio_context_acquire(ctx);
> > >  AIO_WAIT_WHILE(ctx, !s->out_sendco.done);
> > > --
> > > 2.20.1

Re: [RFC v3 4/6] qmp: add QMP command x-debug-virtio-queue-status

[Jason Wang]

On 2020/5/7 下午7:49, Laurent Vivier wrote:

This new command shows internal status of a VirtQueue.
(vrings and indexes).

Signed-off-by: Laurent Vivier 



It looks to me that packed virtqueue is not supported. It's better to 
add them in the future.




---
  hw/virtio/virtio-stub.c |  6 +++
  hw/virtio/virtio.c  | 35 +++
  qapi/virtio.json| 98 +
  3 files changed, 139 insertions(+)

diff --git a/hw/virtio/virtio-stub.c b/hw/virtio/virtio-stub.c
index ddb592f72eee..3c1bf172acf6 100644
--- a/hw/virtio/virtio-stub.c
+++ b/hw/virtio/virtio-stub.c
@@ -17,3 +17,9 @@ VirtioStatus *qmp_x_debug_virtio_status(const char* path, 
Error **errp)
  {
  return qmp_virtio_unsupported(errp);
  }
+
+VirtQueueStatus *qmp_x_debug_virtio_queue_status(const char *path,
+ uint16_t queue, Error **errp)
+{
+return qmp_virtio_unsupported(errp);
+}
diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 59bf6ef651a6..57552bf05014 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -3877,6 +3877,41 @@ static VirtIODevice *virtio_device_find(const char *path)
  return NULL;
  }
  
+VirtQueueStatus *qmp_x_debug_virtio_queue_status(const char *path,

+ uint16_t queue, Error **errp)
+{
+VirtIODevice *vdev;
+VirtQueueStatus *status;
+
+vdev = virtio_device_find(path);
+if (vdev == NULL) {
+error_setg(errp, "Path %s is not a VirtIO device", path);
+return NULL;
+}
+
+if (queue >= VIRTIO_QUEUE_MAX || !virtio_queue_get_num(vdev, queue)) {
+error_setg(errp, "Invalid virtqueue number %d", queue);
+return NULL;
+}
+
+status = g_new0(VirtQueueStatus, 1);
+status->queue_index = vdev->vq[queue].queue_index;
+status->inuse = vdev->vq[queue].inuse;
+status->vring_num = vdev->vq[queue].vring.num;
+status->vring_num_default = vdev->vq[queue].vring.num_default;
+status->vring_align = vdev->vq[queue].vring.align;
+status->vring_desc = vdev->vq[queue].vring.desc;
+status->vring_avail = vdev->vq[queue].vring.avail;
+status->vring_used = vdev->vq[queue].vring.used;
+status->last_avail_idx = vdev->vq[queue].last_avail_idx;



This might not be correct when vhost is used.

We may consider to sync last_avail_idx from vhost backends here?

Thanks



+status->shadow_avail_idx = vdev->vq[queue].shadow_avail_idx;
+status->used_idx = vdev->vq[queue].used_idx;
+status->signalled_used = vdev->vq[queue].signalled_used;
+status->signalled_used_valid = vdev->vq[queue].signalled_used_valid;
+
+return status;
+}
+
  #define CONVERT_FEATURES(type, map)\
  ({   \
  type *list = NULL; \
diff --git a/qapi/virtio.json b/qapi/virtio.json
index 69dd107d0c9b..43c234a9fc69 100644
--- a/qapi/virtio.json
+++ b/qapi/virtio.json
@@ -308,3 +308,101 @@
'data': { 'path': 'str' },
'returns': 'VirtioStatus'
  }
+
+##
+# @VirtQueueStatus:
+#
+# Status of a VirtQueue
+#
+# @queue-index: VirtQueue queue_index
+#
+# @inuse: VirtQueue inuse
+#
+# @vring-num: VirtQueue vring.num
+#
+# @vring-num-default: VirtQueue vring.num_default
+#
+# @vring-align: VirtQueue vring.align
+#
+# @vring-desc: VirtQueue vring.desc
+#
+# @vring-avail: VirtQueue vring.avail
+#
+# @vring-used: VirtQueue vring.used
+#
+# @last-avail-idx: VirtQueue last_avail_idx
+#
+# @shadow-avail-idx: VirtQueue shadow_avail_idx
+#
+# @used-idx: VirtQueue used_idx
+#
+# @signalled-used: VirtQueue signalled_used
+#
+# @signalled-used-valid: VirtQueue signalled_used_valid
+#
+# Since: 5.1
+#
+##
+
+{ 'struct': 'VirtQueueStatus',
+  'data': {
+'queue-index': 'uint16',
+'inuse': 'uint32',
+'vring-num': 'int',
+'vring-num-default': 'int',
+'vring-align': 'int',
+'vring-desc': 'uint64',
+'vring-avail': 'uint64',
+'vring-used': 'uint64',
+'last-avail-idx': 'uint16',
+'shadow-avail-idx': 'uint16',
+'used-idx': 'uint16',
+'signalled-used': 'uint16',
+'signalled-used-valid': 'uint16'
+  }
+}
+
+##
+# @x-debug-virtio-queue-status:
+#
+# Return the status of a given VirtQueue
+#
+# @path: QOBject path of the VirtIODevice
+#
+# @queue: queue number to examine
+#
+# Returns: Status of the VirtQueue
+#
+# Since: 5.1
+#
+# Example:
+#
+# -> { "execute": "x-debug-virtio-queue-status",
+#  "arguments": {
+#  "path": "/machine/peripheral-anon/device[3]/virtio-backend",
+#  "queue": 0
+#  }
+#   }
+# <- { "return": {
+#  "signalled-used": 373,
+#  "inuse": 0,
+#  "vring-desc": 864411648,
+#  "vring-num-default": 256,
+#  "signalled-used-valid": 1,
+#  "vring-avail": 864415744,
+#  "last-avail-idx": 373,
+#  "queue-index": 0,
+#  "vring-used": 864416320,
+#  "shadow-avail-idx": 619,
+#  "used-idx": 373,
+#  "vring-num": 256,
+#  

Re: Emulating Solaris 10 on SPARC64 sun4u

[jasper.lowell]

> I don't know anything about this chip so don't know if it helps but
> if 
> it's any way similar to ESCC (and the ESCC2 name is not just
> marketing) 
> then there's some emulation of that in hw/char/escc.c that you may
> want to 
> look at.

From what I can tell, the SAB 82532 is a bit more complex than the ESCC
ones. It's not difficult to implement but a complete solution will be
lengthy because of the large combination of configuration options the
chip supports.

> Maybe you can get away with setting these to the values the driver
> would 
> set and hard coding it for now just to get some output. Then you can 
> ignore the corresponding registers which could simplify initial
> device 
> model.

I'll take this approach.

Thanks,
Jasper Lowell.

On Thu, 2020-05-07 at 20:54 +0200, BALATON Zoltan wrote:
> On Thu, 7 May 2020, jasper.low...@bt.com wrote:
> > I've started work on emulating the SAB 82532 ESSC2 but it's
> > unfortunately way more complex than than the 16550A. For instance,
> > it's
> 
> I don't know anything about this chip so don't know if it helps but
> if 
> it's any way similar to ESCC (and the ESCC2 name is not just
> marketing) 
> then there's some emulation of that in hw/char/escc.c that you may
> want to 
> look at.
> 
> > possible to configure different baudrates for receiving and
> > transmitting. QEMU's chardev interface doesn't appear to handle
> > that.
> > QEMUSerialSetParams has a single speed value that is passed to
> > cfsetispeed and cfsetospeed. The chip also has support for stick
> > parity
> > , which aren't valid options right now either. If I'm wrong on
> > either
> > of those points please correct me. Unless there is an alternative,
> > changes to the interface may need to be made if adding this device
> > is
> > to be considered.
> 
> Maybe you can get away with setting these to the values the driver
> would 
> set and hard coding it for now just to get some output. Then you can 
> ignore the corresponding registers which could simplify initial
> device 
> model.
> 
> Regards,
> BALATON Zoltan

Re: [RFC v3 3/6] qmp: decode feature bits in virtio-status

[Jason Wang]

On 2020/5/7 下午7:49, Laurent Vivier wrote:

Display feature names instead of a features bitmap for host, guest
and backend.

Decode features according device type, transport features are
on the first line. Undecoded bits (if any) are stored in a separate
field.

Signed-off-by: Laurent Vivier



This is really useful. I wonder maybe we need something similar in 
driver side, current sysfs can only display magic binary numbers.


Thanks

Re: Emulating Solaris 10 on SPARC64 sun4u

[jasper.lowell]

There are two different drivers for the 16550A in OpenSolaris.

There is a generic driver in /usr/src/uts/common/io/asy.c. This driver
clearly states in comments that it is assigning the device to tty[a-d]. 
It's really obvious to me that there is support in this driver for
using the device for a tty.

There is another driver at /usr/src/uts/sun4/io/su_driver.c. Judging
from the name this is specific for SuperIO. This driver is more than
1000 lines shorter than the other driver and contains a note at the top
of the file that it is "modified as sparc keyboard/mouse driver." I
don't have much experience with Solaris internals but I can't see any
obvious signs that this can be used as a tty. I'd also question why
there are two drivers if they have the same purpose/capability. If the
su_driver exists to only add support for the keyboard/mouse I'm not
sure why it would be shorter rather than longer. It would be helpful if
someone with Solaris experience, that knows what they're doing (I do
not), can take a look at this driver and give a better opinion.

When emulating Sun4u, the su driver is used. If you misconfigure the
serial device in QEMU, you can trigger errors that are unique to the
driver. Also, Solaris attaches the device as su0.

Solaris can access the registers, identify/attach the device, but it
just never attempts to use it. Interrupts are explicitly disabled and
the device is never polled. I don't think asyopen in su_driver.c is
ever called. I've thoroughly stepped through every register access for
the 16550A and nothing seems out of the ordinary to me. Something I've
considered is that OpenBIOS is not setting properties for the device in
a way that Solaris expects but I'm not familiar enough with Sun's
OpenBOOT to make progress here. I've read through the PROM functions
that Solaris calls when choosing what device to use as a console and
nothing seemed inconsistent with what OpenBIOS does. Unfortunately,
OpenBIOS seems to crash or hang when using the kernel debugger module,
so dynamic analysis using breakpoints isn't an option.

I don't have any concrete explanations for the broken console but
rather than do nothing I figured I'd see what happens by emulating the
SAB 82532.

> At least Fujitsu Siemens PRIMEPOWER250 had a tty attached to the
> 16550A UART. I think there were more such machines. I don't expect
> there is anything in the Solaris kernel which would prevent any
> serial
> device known to it to be used as a tty.

Do you happen to know if this was over SuperIO? If this machine was
using the same su_driver for a serial console it would rule out
emulating the hardware-faithful SAB 82532 as being a possible
improvement. I can't find anything online about someone using SuperIO
for a ttya on an Ultra 5 running Solaris.

> Well, theoretically yes, but practically there is just one baudrate
> which can be specified in the OBP. I think it's perfectly safe to use
> max(rxrate,txrate), or min(rxrate,txrate), whatever you prefer.

I'll do this while looking at whether or not the different chip fixes
the console problems on Sun4u. I'd personally like to avoid introducing
a device to QEMU that makes assumptions about how the guest may
configure the chip.

Thanks,
Jasper Lowell.


On Thu, 2020-05-07 at 17:02 +0200, Artyom Tarasenko wrote:
> On Thu, May 7, 2020 at 4:29 PM  wrote:
> > Just thought I'd chime in with an update.
> > 
> > We are currently emulating a 16550A UART. The guest sees this as
> > the SU
> > device, referring to the SuperIO port (a pair of 16550A UARTs). On
> > the
> > Ultra 5, the machine that Sun4u is modelled against, SuperIO was
> > used
> > for the keyboard and mouse. The Ultra 5 also had a DB25 (ttya
> > default)
> > and a DB9 (ttyb default) with a SAB82532 ESSC2.
> > 
> > Using tracing, I've looked through how the 16550A UART is touched
> > and
> > it looks like Solaris 10 has no issues identifying the device. I've
> > matched register accesses with driver code in OpenSolaris and I'm
> > pretty sure the device is attached successfully. Also, if you boot
> > Solaris 10 with debugging output, you can see that the device gets
> > labelled as su0. The only time Solaris is capable of writing to the
> > console is when OpenBIOS is used as a proxy.
> > 
> > Rather than Solaris deciding against using SuperIO as a tty, I
> > don't
> > think there was ever any support for doing so (at least on SPARC
> > machines). This could be an explanation for why the system appears
> > to
> > be trucking along just fine despite a seemingly frozen console -
> > there
> > is no console. I don't think the frozen console is the fault of
> > broken
> > interrupt routing as the 16550A UART is never programmed to
> > generate
> > them.
> 
> At least Fujitsu Siemens PRIMEPOWER250 had a tty attached to the
> 16550A UART. I think there were more such machines. I don't expect
> there is anything in the Solaris kernel which would prevent any
> serial
> device known to it to be used as a tty.
> 
> > I've 

RE: [PATCH v4 5/6] net/colo-compare.c, softmmu/vl.c: Check that colo-compare is active

[Zhang, Chen]

> -Original Message-
> From: Lukas Straub 
> Sent: Thursday, May 7, 2020 11:54 PM
> To: Zhang, Chen 
> Cc: qemu-devel ; Li Zhijian
> ; Jason Wang ; Marc-
> André Lureau ; Paolo Bonzini
> 
> Subject: Re: [PATCH v4 5/6] net/colo-compare.c, softmmu/vl.c: Check that
> colo-compare is active
> 
> On Thu, 7 May 2020 11:38:04 +
> "Zhang, Chen"  wrote:
> 
> > > -Original Message-
> > > From: Lukas Straub 
> > > Sent: Monday, May 4, 2020 6:28 PM
> > > To: qemu-devel 
> > > Cc: Zhang, Chen ; Li Zhijian
> > > ; Jason Wang ; Marc-
> > > André Lureau ; Paolo Bonzini
> > > 
> > > Subject: [PATCH v4 5/6] net/colo-compare.c, softmmu/vl.c: Check that
> > > colo- compare is active
> > >
> > > If the colo-compare object is removed before failover and a
> > > checkpoint happens, qemu crashes because it tries to lock the
> > > destroyed event_mtx in colo_notify_compares_event.
> > >
> > > Fix this by checking if everything is initialized by introducing a
> > > new variable colo_compare_active which is protected by a new mutex
> > > colo_compare_mutex. The new mutex also protects against concurrent
> > > access of the net_compares list and makes sure that
> > > colo_notify_compares_event isn't active while we destroy event_mtx
> > > and event_complete_cond.
> > >
> > > With this it also is again possible to use colo without colo-compare
> > > (periodic
> > > mode) and to use multiple colo-compare for multiple network interfaces.
> > >
> >
> > Hi Lukas,
> >
> > For this case I think we don't need to touch vl.c code, we can solve this
> issue from another perspective:
> > How to remove colo-compare?
> > User will use qemu-monitor or QMP command to disable an object, so we
> > just need return operation failed When user try to remove colo-compare
> object while COLO is running.
> 
> Yeah, but that still leaves the other problem that colo can't be used without
> colo-compare (qemu crashes then).

Yes, the COLO-compare is necessary module in COLO original design.
At most cases, user need it do dynamic sync.
For rare cases, maybe we can add a new colo-compare parameter to bypass all the 
network workload.

Thanks
Zhang Chen 

> 
> Regards,
> Lukas Straub
> 
> > Thanks
> > Zhang Chen
> >
> > > Signed-off-by: Lukas Straub 
> > > ---
> > >  net/colo-compare.c | 35 +--
> > >  net/colo-compare.h |  1 +
> > >  softmmu/vl.c   |  2 ++
> > >  3 files changed, 32 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/net/colo-compare.c b/net/colo-compare.c index
> > > 56db3d3bfc..c7572d75e9 100644
> > > --- a/net/colo-compare.c
> > > +++ b/net/colo-compare.c
> > > @@ -54,6 +54,8 @@ static NotifierList colo_compare_notifiers =
> > > #define REGULAR_PACKET_CHECK_MS 3000  #define
> DEFAULT_TIME_OUT_MS
> > > 3000
> > >
> > > +static QemuMutex colo_compare_mutex; static bool
> > > +colo_compare_active;
> > >  static QemuMutex event_mtx;
> > >  static QemuCond event_complete_cond;  static int
> > > event_unhandled_count; @@ -906,6 +908,12 @@ static void
> > > check_old_packet_regular(void *opaque) void
> > > colo_notify_compares_event(void *opaque, int event, Error **errp)  {
> > >  CompareState *s;
> > > +qemu_mutex_lock(_compare_mutex);
> > > +
> > > +if (!colo_compare_active) {
> > > +qemu_mutex_unlock(_compare_mutex);
> > > +return;
> > > +}
> > >
> > >  qemu_mutex_lock(_mtx);
> > >  QTAILQ_FOREACH(s, _compares, next) { @@ -919,6 +927,7 @@
> > > void colo_notify_compares_event(void *opaque, int event, Error **errp)
> > >  }
> > >
> > >  qemu_mutex_unlock(_mtx);
> > > +qemu_mutex_unlock(_compare_mutex);
> > >  }
> > >
> > >  static void colo_compare_timer_init(CompareState *s) @@ -1274,7
> > > +1283,14 @@ static void colo_compare_complete(UserCreatable *uc,
> Error **errp)
> > > s->vnet_hdr);
> > >  }
> > >
> > > +qemu_mutex_lock(_compare_mutex);
> > > +if (!colo_compare_active) {
> > > +qemu_mutex_init(_mtx);
> > > +qemu_cond_init(_complete_cond);
> > > +colo_compare_active = true;
> > > +}
> > >  QTAILQ_INSERT_TAIL(_compares, s, next);
> > > +qemu_mutex_unlock(_compare_mutex);
> > >
> > >  s->out_sendco.s = s;
> > >  s->out_sendco.chr = >chr_out; @@ -1290,9 +1306,6 @@ static
> > > void colo_compare_complete(UserCreatable
> > > *uc, Error **errp)
> > >
> > >  g_queue_init(>conn_list);
> > >
> > > -qemu_mutex_init(_mtx);
> > > -qemu_cond_init(_complete_cond);
> > > -
> > >  s->connection_track_table =
> > > g_hash_table_new_full(connection_key_hash,
> > >
> > > connection_key_equal,
> > >g_free, @@
> > > -1384,12 +1397,19 @@ static void colo_compare_finalize(Object *obj)
> > >
> > >  qemu_bh_delete(s->event_bh);
> > >
> > > +qemu_mutex_lock(_compare_mutex);
> > >  QTAILQ_FOREACH(tmp, _compares, next) {
> > >  

[PATCH RESEND v26 08/10] ACPI: Record Generic Error Status Block(GESB) table

[Dongjiu Geng]

kvm_arch_on_sigbus_vcpu() error injection uses source_id as
index in etc/hardware_errors to find out Error Status Data
Block entry corresponding to error source. So supported source_id
values should be assigned here and not be changed afterwards to
make sure that guest will write error into expected Error Status
Data Block.

Before QEMU writes a new error to ACPI table, it will check whether
previous error has been acknowledged. If not acknowledged, the new
errors will be ignored and not be recorded. For the errors section
type, QEMU simulate it to memory section error.

Signed-off-by: Dongjiu Geng 
Signed-off-by: Xiang Zheng 
Reviewed-by: Igor Mammedov 
Reviewed-by: Michael S. Tsirkin 
---
 hw/acpi/ghes.c | 219 +
 include/hw/acpi/ghes.h |   1 +
 2 files changed, 220 insertions(+)

diff --git a/hw/acpi/ghes.c b/hw/acpi/ghes.c
index e74af23..b363bc3 100644
--- a/hw/acpi/ghes.c
+++ b/hw/acpi/ghes.c
@@ -26,6 +26,7 @@
 #include "qemu/error-report.h"
 #include "hw/acpi/generic_event_device.h"
 #include "hw/nvram/fw_cfg.h"
+#include "qemu/uuid.h"
 
 #define ACPI_GHES_ERRORS_FW_CFG_FILE"etc/hardware_errors"
 #define ACPI_GHES_DATA_ADDR_FW_CFG_FILE "etc/hardware_errors_addr"
@@ -43,6 +44,36 @@
 #define GAS_ADDR_OFFSET 4
 
 /*
+ * The total size of Generic Error Data Entry
+ * ACPI 6.1/6.2: 18.3.2.7.1 Generic Error Data,
+ * Table 18-343 Generic Error Data Entry
+ */
+#define ACPI_GHES_DATA_LENGTH   72
+
+/* The memory section CPER size, UEFI 2.6: N.2.5 Memory Error Section */
+#define ACPI_GHES_MEM_CPER_LENGTH   80
+
+/* Masks for block_status flags */
+#define ACPI_GEBS_UNCORRECTABLE 1
+
+/*
+ * Total size for Generic Error Status Block except Generic Error Data Entries
+ * ACPI 6.2: 18.3.2.7.1 Generic Error Data,
+ * Table 18-380 Generic Error Status Block
+ */
+#define ACPI_GHES_GESB_SIZE 20
+
+/*
+ * Values for error_severity field
+ */
+enum AcpiGenericErrorSeverity {
+ACPI_CPER_SEV_RECOVERABLE = 0,
+ACPI_CPER_SEV_FATAL = 1,
+ACPI_CPER_SEV_CORRECTED = 2,
+ACPI_CPER_SEV_NONE = 3,
+};
+
+/*
  * Hardware Error Notification
  * ACPI 4.0: 17.3.2.7 Hardware Error Notification
  * Composes dummy Hardware Error Notification descriptor of specified type
@@ -73,6 +104,138 @@ static void build_ghes_hw_error_notification(GArray 
*table, const uint8_t type)
 }
 
 /*
+ * Generic Error Data Entry
+ * ACPI 6.1: 18.3.2.7.1 Generic Error Data
+ */
+static void acpi_ghes_generic_error_data(GArray *table,
+const uint8_t *section_type, uint32_t error_severity,
+uint8_t validation_bits, uint8_t flags,
+uint32_t error_data_length, QemuUUID fru_id,
+uint64_t time_stamp)
+{
+const uint8_t fru_text[20] = {0};
+
+/* Section Type */
+g_array_append_vals(table, section_type, 16);
+
+/* Error Severity */
+build_append_int_noprefix(table, error_severity, 4);
+/* Revision */
+build_append_int_noprefix(table, 0x300, 2);
+/* Validation Bits */
+build_append_int_noprefix(table, validation_bits, 1);
+/* Flags */
+build_append_int_noprefix(table, flags, 1);
+/* Error Data Length */
+build_append_int_noprefix(table, error_data_length, 4);
+
+/* FRU Id */
+g_array_append_vals(table, fru_id.data, ARRAY_SIZE(fru_id.data));
+
+/* FRU Text */
+g_array_append_vals(table, fru_text, sizeof(fru_text));
+
+/* Timestamp */
+build_append_int_noprefix(table, time_stamp, 8);
+}
+
+/*
+ * Generic Error Status Block
+ * ACPI 6.1: 18.3.2.7.1 Generic Error Data
+ */
+static void acpi_ghes_generic_error_status(GArray *table, uint32_t 
block_status,
+uint32_t raw_data_offset, uint32_t raw_data_length,
+uint32_t data_length, uint32_t error_severity)
+{
+/* Block Status */
+build_append_int_noprefix(table, block_status, 4);
+/* Raw Data Offset */
+build_append_int_noprefix(table, raw_data_offset, 4);
+/* Raw Data Length */
+build_append_int_noprefix(table, raw_data_length, 4);
+/* Data Length */
+build_append_int_noprefix(table, data_length, 4);
+/* Error Severity */
+build_append_int_noprefix(table, error_severity, 4);
+}
+
+/* UEFI 2.6: N.2.5 Memory Error Section */
+static void acpi_ghes_build_append_mem_cper(GArray *table,
+uint64_t error_physical_addr)
+{
+/*
+ * Memory Error Record
+ */
+
+/* Validation Bits */
+build_append_int_noprefix(table,
+  (1ULL << 14) | /* Type Valid */
+  (1ULL << 1) /* Physical Address Valid */,
+  8);
+/* Error Status */
+build_append_int_noprefix(table, 0, 8);
+/* Physical Address */
+build_append_int_noprefix(table, error_physical_addr, 8);
+/* Skip all the detailed information normally found in such a record */
+

[PATCH RESEND v26 09/10] target-arm: kvm64: handle SIGBUS signal from kernel or KVM

[Dongjiu Geng]

Add a SIGBUS signal handler. In this handler, it checks the SIGBUS type,
translates the host VA delivered by host to guest PA, then fills this PA
to guest APEI GHES memory, then notifies guest according to the SIGBUS
type.

When guest accesses the poisoned memory, it will generate a Synchronous
External Abort(SEA). Then host kernel gets an APEI notification and calls
memory_failure() to unmapped the affected page in stage 2, finally
returns to guest.

Guest continues to access the PG_hwpoison page, it will trap to KVM as
stage2 fault, then a SIGBUS_MCEERR_AR synchronous signal is delivered to
Qemu, Qemu records this error address into guest APEI GHES memory and
notifes guest using Synchronous-External-Abort(SEA).

In order to inject a vSEA, we introduce the kvm_inject_arm_sea() function
in which we can setup the type of exception and the syndrome information.
When switching to guest, the target vcpu will jump to the synchronous
external abort vector table entry.

The ESR_ELx.DFSC is set to synchronous external abort(0x10), and the
ESR_ELx.FnV is set to not valid(0x1), which will tell guest that FAR is
not valid and hold an UNKNOWN value. These values will be set to KVM
register structures through KVM_SET_ONE_REG IOCTL.

Signed-off-by: Dongjiu Geng 
Signed-off-by: Xiang Zheng 
Reviewed-by: Michael S. Tsirkin 
Acked-by: Xiang Zheng 
Reviewed-by: Peter Maydell 
Reviewed-by: Igor Mammedov 
---
 include/sysemu/kvm.h|  3 +-
 target/arm/cpu.h|  4 +++
 target/arm/helper.c |  2 +-
 target/arm/internals.h  |  5 ++--
 target/arm/kvm64.c  | 77 +
 target/arm/tlb_helper.c |  2 +-
 target/i386/cpu.h   |  2 ++
 7 files changed, 89 insertions(+), 6 deletions(-)

diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
index 141342d..3b22504 100644
--- a/include/sysemu/kvm.h
+++ b/include/sysemu/kvm.h
@@ -379,8 +379,7 @@ bool kvm_vcpu_id_is_valid(int vcpu_id);
 /* Returns VCPU ID to be used on KVM_CREATE_VCPU ioctl() */
 unsigned long kvm_arch_vcpu_id(CPUState *cpu);
 
-#ifdef TARGET_I386
-#define KVM_HAVE_MCE_INJECTION 1
+#ifdef KVM_HAVE_MCE_INJECTION
 void kvm_arch_on_sigbus_vcpu(CPUState *cpu, int code, void *addr);
 #endif
 
diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 8608da6..89f51c6 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -28,6 +28,10 @@
 /* ARM processors have a weak memory model */
 #define TCG_GUEST_DEFAULT_MO  (0)
 
+#ifdef TARGET_AARCH64
+#define KVM_HAVE_MCE_INJECTION 1
+#endif
+
 #define EXCP_UDEF1   /* undefined instruction */
 #define EXCP_SWI 2   /* software interrupt */
 #define EXCP_PREFETCH_ABORT  3
diff --git a/target/arm/helper.c b/target/arm/helper.c
index a94f650..355b2d5 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -3481,7 +3481,7 @@ static uint64_t do_ats_write(CPUARMState *env, uint64_t 
value,
  * Report exception with ESR indicating a fault due to a
  * translation table walk for a cache maintenance instruction.
  */
-syn = syn_data_abort_no_iss(current_el == target_el,
+syn = syn_data_abort_no_iss(current_el == target_el, 0,
 fi.ea, 1, fi.s1ptw, 1, fsc);
 env->exception.vaddress = value;
 env->exception.fsr = fsr;
diff --git a/target/arm/internals.h b/target/arm/internals.h
index e633aff..37c22a9 100644
--- a/target/arm/internals.h
+++ b/target/arm/internals.h
@@ -451,13 +451,14 @@ static inline uint32_t syn_insn_abort(int same_el, int 
ea, int s1ptw, int fsc)
 | ARM_EL_IL | (ea << 9) | (s1ptw << 7) | fsc;
 }
 
-static inline uint32_t syn_data_abort_no_iss(int same_el,
+static inline uint32_t syn_data_abort_no_iss(int same_el, int fnv,
  int ea, int cm, int s1ptw,
  int wnr, int fsc)
 {
 return (EC_DATAABORT << ARM_EL_EC_SHIFT) | (same_el << ARM_EL_EC_SHIFT)
| ARM_EL_IL
-   | (ea << 9) | (cm << 8) | (s1ptw << 7) | (wnr << 6) | fsc;
+   | (fnv << 10) | (ea << 9) | (cm << 8) | (s1ptw << 7)
+   | (wnr << 6) | fsc;
 }
 
 static inline uint32_t syn_data_abort_with_iss(int same_el,
diff --git a/target/arm/kvm64.c b/target/arm/kvm64.c
index be5b31c..d53f7f2 100644
--- a/target/arm/kvm64.c
+++ b/target/arm/kvm64.c
@@ -28,6 +28,9 @@
 #include "sysemu/kvm_int.h"
 #include "kvm_arm.h"
 #include "internals.h"
+#include "hw/acpi/acpi.h"
+#include "hw/acpi/ghes.h"
+#include "hw/arm/virt.h"
 
 static bool have_guest_debug;
 
@@ -893,6 +896,30 @@ int kvm_arm_cpreg_level(uint64_t regidx)
 return KVM_PUT_RUNTIME_STATE;
 }
 
+/* Callers must hold the iothread mutex lock */
+static void kvm_inject_arm_sea(CPUState *c)
+{
+ARMCPU *cpu = ARM_CPU(c);
+CPUARMState *env = >env;
+CPUClass *cc = CPU_GET_CLASS(c);
+uint32_t esr;
+bool same_el;
+
+c->exception_index = EXCP_DATA_ABORT;
+

Re: [PATCH v2] e1000e: Added ICR clearing by corresponding IMS bit.

[Jason Wang]

On 2020/5/7 上午5:26, and...@daynix.com wrote:

From: Andrew Melnychenko 

Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1707441
Added ICR clearing if there is IMS bit - according to the note by
section 13.3.27 of the 8257X developers manual.

Signed-off-by: Andrew Melnychenko 
---
  hw/net/e1000e_core.c | 9 +
  hw/net/trace-events  | 1 +
  2 files changed, 10 insertions(+)

diff --git a/hw/net/e1000e_core.c b/hw/net/e1000e_core.c
index d5676871fa..302e99ff46 100644
--- a/hw/net/e1000e_core.c
+++ b/hw/net/e1000e_core.c
@@ -2624,6 +2624,15 @@ e1000e_mac_icr_read(E1000ECore *core, int index)
  e1000e_clear_ims_bits(core, core->mac[IAM]);
  }
  
+/*

+ * PCIe* GbE Controllers Open Source Software Developer's Manual
+ * 13.3.27 Interrupt Cause Read Register
+ */



Hi Andrew:

Which version of the manual did you use? I try to use the one mentioned 
in e1000e.c which is 
http://www.intel.com/content/dam/doc/datasheet/82574l-gbe-controller-datasheet.pdf.


But I couldn't find chapter 13.3.27.

Thanks



+if (core->mac[ICR] & core->mac[IMS]) {
+trace_e1000e_irq_icr_clear_icr_bit_ims(core->mac[ICR], core->mac[IMS]);
+core->mac[ICR] = 0;
+}
+
  trace_e1000e_irq_icr_read_exit(core->mac[ICR]);
  e1000e_update_interrupt_state(core);
  return ret;
diff --git a/hw/net/trace-events b/hw/net/trace-events
index e18f883cfd..46e40fcfa9 100644
--- a/hw/net/trace-events
+++ b/hw/net/trace-events
@@ -237,6 +237,7 @@ e1000e_irq_icr_read_entry(uint32_t icr) "Starting ICR read. 
Current ICR: 0x%x"
  e1000e_irq_icr_read_exit(uint32_t icr) "Ending ICR read. Current ICR: 0x%x"
  e1000e_irq_icr_clear_zero_ims(void) "Clearing ICR on read due to zero IMS"
  e1000e_irq_icr_clear_iame(void) "Clearing ICR on read due to IAME"
+e1000e_irq_icr_clear_icr_bit_ims(uint32_t icr, uint32_t ims) "Clearing ICR on read due 
corresponding IMS bit: 0x%x & 0x%x"
  e1000e_irq_iam_clear_eiame(uint32_t iam, uint32_t cause) "Clearing IMS due to 
EIAME, IAM: 0x%X, cause: 0x%X"
  e1000e_irq_icr_clear_eiac(uint32_t icr, uint32_t eiac) "Clearing ICR bits due to 
EIAC, ICR: 0x%X, EIAC: 0x%X"
  e1000e_irq_ims_clear_set_imc(uint32_t val) "Clearing IMS bits due to IMC write 
0x%x"

[PATCH RESEND v26 10/10] MAINTAINERS: Add ACPI/HEST/GHES entries

[Dongjiu Geng]

I and Xiang are willing to review the APEI-related patches and
volunteer as the reviewers for the HEST/GHES part.

Signed-off-by: Dongjiu Geng 
Signed-off-by: Xiang Zheng 
Reviewed-by: Philippe Mathieu-Daudé 
Acked-by: Michael S. Tsirkin 
---
 MAINTAINERS | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 1f84e3a..9619b90 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1516,6 +1516,15 @@ F: tests/qtest/bios-tables-test.c
 F: tests/qtest/acpi-utils.[hc]
 F: tests/data/acpi/
 
+ACPI/HEST/GHES
+R: Dongjiu Geng 
+R: Xiang Zheng 
+L: qemu-...@nongnu.org
+S: Maintained
+F: hw/acpi/ghes.c
+F: include/hw/acpi/ghes.h
+F: docs/specs/acpi_hest_ghes.rst
+
 ppc4xx
 M: David Gibson 
 L: qemu-...@nongnu.org
-- 
1.8.3.1

[PATCH RESEND v26 04/10] ACPI: Build related register address fields via hardware error fw_cfg blob

[Dongjiu Geng]

This patch builds error_block_address and read_ack_register fields
in hardware errors table , the error_block_address points to Generic
Error Status Block(GESB) via bios_linker. The max size for one GESB
is 1kb, For more detailed information, please refer to
document: docs/specs/acpi_hest_ghes.rst

Now we only support one Error source, if necessary, we can extend to
support more.

Suggested-by: Laszlo Ersek 
Signed-off-by: Xiang Zheng 
Reviewed-by: Jonathan Cameron 
Reviewed-by: Igor Mammedov 
Signed-off-by: Dongjiu Geng 
Reviewed-by: Michael S. Tsirkin 
---
 default-configs/arm-softmmu.mak |  1 +
 hw/acpi/Kconfig |  4 ++
 hw/acpi/Makefile.objs   |  1 +
 hw/acpi/aml-build.c |  2 +
 hw/acpi/ghes.c  | 89 +
 hw/arm/virt-acpi-build.c|  5 +++
 include/hw/acpi/aml-build.h |  1 +
 include/hw/acpi/ghes.h  | 28 +
 8 files changed, 131 insertions(+)
 create mode 100644 hw/acpi/ghes.c
 create mode 100644 include/hw/acpi/ghes.h

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index 36a0e89..8fc09a4 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -42,3 +42,4 @@ CONFIG_FSL_IMX7=y
 CONFIG_FSL_IMX6UL=y
 CONFIG_SEMIHOSTING=y
 CONFIG_ALLWINNER_H3=y
+CONFIG_ACPI_APEI=y
diff --git a/hw/acpi/Kconfig b/hw/acpi/Kconfig
index 54209c6..1932f66 100644
--- a/hw/acpi/Kconfig
+++ b/hw/acpi/Kconfig
@@ -28,6 +28,10 @@ config ACPI_HMAT
 bool
 depends on ACPI
 
+config ACPI_APEI
+bool
+depends on ACPI
+
 config ACPI_PCI
 bool
 depends on ACPI && PCI
diff --git a/hw/acpi/Makefile.objs b/hw/acpi/Makefile.objs
index cab9bcd..72886c7 100644
--- a/hw/acpi/Makefile.objs
+++ b/hw/acpi/Makefile.objs
@@ -8,6 +8,7 @@ common-obj-$(CONFIG_ACPI_NVDIMM) += nvdimm.o
 common-obj-$(CONFIG_ACPI_VMGENID) += vmgenid.o
 common-obj-$(CONFIG_ACPI_HW_REDUCED) += generic_event_device.o
 common-obj-$(CONFIG_ACPI_HMAT) += hmat.o
+common-obj-$(CONFIG_ACPI_APEI) += ghes.o
 common-obj-$(call lnot,$(CONFIG_ACPI_X86)) += acpi-stub.o
 common-obj-$(call lnot,$(CONFIG_PC)) += acpi-x86-stub.o
 
diff --git a/hw/acpi/aml-build.c b/hw/acpi/aml-build.c
index 2c3702b..3681ec6 100644
--- a/hw/acpi/aml-build.c
+++ b/hw/acpi/aml-build.c
@@ -1578,6 +1578,7 @@ void acpi_build_tables_init(AcpiBuildTables *tables)
 tables->table_data = g_array_new(false, true /* clear */, 1);
 tables->tcpalog = g_array_new(false, true /* clear */, 1);
 tables->vmgenid = g_array_new(false, true /* clear */, 1);
+tables->hardware_errors = g_array_new(false, true /* clear */, 1);
 tables->linker = bios_linker_loader_init();
 }
 
@@ -1588,6 +1589,7 @@ void acpi_build_tables_cleanup(AcpiBuildTables *tables, 
bool mfre)
 g_array_free(tables->table_data, true);
 g_array_free(tables->tcpalog, mfre);
 g_array_free(tables->vmgenid, mfre);
+g_array_free(tables->hardware_errors, mfre);
 }
 
 /*
diff --git a/hw/acpi/ghes.c b/hw/acpi/ghes.c
new file mode 100644
index 000..e1b3f8f
--- /dev/null
+++ b/hw/acpi/ghes.c
@@ -0,0 +1,89 @@
+/*
+ * Support for generating APEI tables and recording CPER for Guests
+ *
+ * Copyright (c) 2020 HUAWEI TECHNOLOGIES CO., LTD.
+ *
+ * Author: Dongjiu Geng 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see .
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/units.h"
+#include "hw/acpi/ghes.h"
+#include "hw/acpi/aml-build.h"
+
+#define ACPI_GHES_ERRORS_FW_CFG_FILE"etc/hardware_errors"
+#define ACPI_GHES_DATA_ADDR_FW_CFG_FILE "etc/hardware_errors_addr"
+
+/* The max size in bytes for one error block */
+#define ACPI_GHES_MAX_RAW_DATA_LENGTH   (1 * KiB)
+
+/* Now only support ARMv8 SEA notification type error source */
+#define ACPI_GHES_ERROR_SOURCE_COUNT1
+
+/*
+ * Build table for the hardware error fw_cfg blob.
+ * Initialize "etc/hardware_errors" and "etc/hardware_errors_addr" fw_cfg 
blobs.
+ * See docs/specs/acpi_hest_ghes.rst for blobs format.
+ */
+void build_ghes_error_table(GArray *hardware_errors, BIOSLinker *linker)
+{
+int i, error_status_block_offset;
+
+/* Build error_block_address */
+for (i = 0; i < ACPI_GHES_ERROR_SOURCE_COUNT; i++) {
+build_append_int_noprefix(hardware_errors, 0, sizeof(uint64_t));
+}
+
+/* Build read_ack_register */
+for (i = 0; i < 

[PATCH RESEND v26 06/10] ACPI: Record the Generic Error Status Block address

[Dongjiu Geng]

Record the GHEB address via fw_cfg file, when recording
a error to CPER, it will use this address to find out
Generic Error Data Entries and write the error.

In order to avoid migration failure, make hardware
error table address to a part of GED device instead
of global variable, then this address will be migrated
to target QEMU.

Acked-by: Xiang Zheng 
Signed-off-by: Dongjiu Geng 
Reviewed-by: Igor Mammedov 
Reviewed-by: Michael S. Tsirkin 
---
 hw/acpi/generic_event_device.c | 19 +++
 hw/acpi/ghes.c | 14 ++
 hw/arm/virt-acpi-build.c   |  8 
 include/hw/acpi/generic_event_device.h |  2 ++
 include/hw/acpi/ghes.h |  6 ++
 5 files changed, 49 insertions(+)

diff --git a/hw/acpi/generic_event_device.c b/hw/acpi/generic_event_device.c
index 5d17f78..b1cbdd8 100644
--- a/hw/acpi/generic_event_device.c
+++ b/hw/acpi/generic_event_device.c
@@ -247,6 +247,24 @@ static const VMStateDescription vmstate_ged_state = {
 }
 };
 
+static bool ghes_needed(void *opaque)
+{
+AcpiGedState *s = opaque;
+return s->ghes_state.ghes_addr_le;
+}
+
+static const VMStateDescription vmstate_ghes_state = {
+.name = "acpi-ged/ghes",
+.version_id = 1,
+.minimum_version_id = 1,
+.needed = ghes_needed,
+.fields  = (VMStateField[]) {
+VMSTATE_STRUCT(ghes_state, AcpiGedState, 1,
+   vmstate_ghes_state, AcpiGhesState),
+VMSTATE_END_OF_LIST()
+}
+};
+
 static const VMStateDescription vmstate_acpi_ged = {
 .name = "acpi-ged",
 .version_id = 1,
@@ -257,6 +275,7 @@ static const VMStateDescription vmstate_acpi_ged = {
 },
 .subsections = (const VMStateDescription * []) {
 _memhp_state,
+_ghes_state,
 NULL
 }
 };
diff --git a/hw/acpi/ghes.c b/hw/acpi/ghes.c
index 091fd87..e74af23 100644
--- a/hw/acpi/ghes.c
+++ b/hw/acpi/ghes.c
@@ -24,6 +24,8 @@
 #include "hw/acpi/ghes.h"
 #include "hw/acpi/aml-build.h"
 #include "qemu/error-report.h"
+#include "hw/acpi/generic_event_device.h"
+#include "hw/nvram/fw_cfg.h"
 
 #define ACPI_GHES_ERRORS_FW_CFG_FILE"etc/hardware_errors"
 #define ACPI_GHES_DATA_ADDR_FW_CFG_FILE "etc/hardware_errors_addr"
@@ -213,3 +215,15 @@ void acpi_build_hest(GArray *table_data, BIOSLinker 
*linker)
 build_header(linker, table_data, (void *)(table_data->data + hest_start),
 "HEST", table_data->len - hest_start, 1, NULL, NULL);
 }
+
+void acpi_ghes_add_fw_cfg(AcpiGhesState *ags, FWCfgState *s,
+  GArray *hardware_error)
+{
+/* Create a read-only fw_cfg file for GHES */
+fw_cfg_add_file(s, ACPI_GHES_ERRORS_FW_CFG_FILE, hardware_error->data,
+hardware_error->len);
+
+/* Create a read-write fw_cfg file for Address */
+fw_cfg_add_file_callback(s, ACPI_GHES_DATA_ADDR_FW_CFG_FILE, NULL, NULL,
+NULL, &(ags->ghes_addr_le), sizeof(ags->ghes_addr_le), false);
+}
diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
index ef94e03..1b0a584 100644
--- a/hw/arm/virt-acpi-build.c
+++ b/hw/arm/virt-acpi-build.c
@@ -917,6 +917,7 @@ void virt_acpi_setup(VirtMachineState *vms)
 {
 AcpiBuildTables tables;
 AcpiBuildState *build_state;
+AcpiGedState *acpi_ged_state;
 
 if (!vms->fw_cfg) {
 trace_virt_acpi_setup();
@@ -947,6 +948,13 @@ void virt_acpi_setup(VirtMachineState *vms)
 fw_cfg_add_file(vms->fw_cfg, ACPI_BUILD_TPMLOG_FILE, tables.tcpalog->data,
 acpi_data_len(tables.tcpalog));
 
+if (vms->ras) {
+assert(vms->acpi_dev);
+acpi_ged_state = ACPI_GED(vms->acpi_dev);
+acpi_ghes_add_fw_cfg(_ged_state->ghes_state,
+ vms->fw_cfg, tables.hardware_errors);
+}
+
 build_state->rsdp_mr = acpi_add_rom_blob(virt_acpi_build_update,
  build_state, tables.rsdp,
  ACPI_BUILD_RSDP_FILE, 0);
diff --git a/include/hw/acpi/generic_event_device.h 
b/include/hw/acpi/generic_event_device.h
index 9eb86ca..83917de 100644
--- a/include/hw/acpi/generic_event_device.h
+++ b/include/hw/acpi/generic_event_device.h
@@ -61,6 +61,7 @@
 
 #include "hw/sysbus.h"
 #include "hw/acpi/memory_hotplug.h"
+#include "hw/acpi/ghes.h"
 
 #define ACPI_POWER_BUTTON_DEVICE "PWRB"
 
@@ -96,6 +97,7 @@ typedef struct AcpiGedState {
 GEDState ged_state;
 uint32_t ged_event_bitmap;
 qemu_irq irq;
+AcpiGhesState ghes_state;
 } AcpiGedState;
 
 void build_ged_aml(Aml *table, const char* name, HotplugHandler *hotplug_dev,
diff --git a/include/hw/acpi/ghes.h b/include/hw/acpi/ghes.h
index 18debd8..a3420fc 100644
--- a/include/hw/acpi/ghes.h
+++ b/include/hw/acpi/ghes.h
@@ -62,6 +62,12 @@ enum {
 ACPI_HEST_SRC_ID_RESERVED,
 };
 
+typedef struct AcpiGhesState {
+uint64_t ghes_addr_le;
+} AcpiGhesState;
+
 void build_ghes_error_table(GArray *hardware_errors, BIOSLinker 

RE: [PATCH v4 3/6] net/colo-compare.c: Fix deadlock in compare_chr_send

[Zhang, Chen]

> -Original Message-
> From: Lukas Straub 
> Sent: Thursday, May 7, 2020 11:51 PM
> To: Zhang, Chen 
> Cc: qemu-devel ; Li Zhijian
> ; Jason Wang ; Marc-
> André Lureau ; Paolo Bonzini
> 
> Subject: Re: [PATCH v4 3/6] net/colo-compare.c: Fix deadlock in
> compare_chr_send
> 
> On Thu, 7 May 2020 11:00:26 +
> "Zhang, Chen"  wrote:
> 
> > > -Original Message-
> > > From: Lukas Straub 
> > > Sent: Monday, May 4, 2020 6:28 PM
> > > To: qemu-devel 
> > > Cc: Zhang, Chen ; Li Zhijian
> > > ; Jason Wang ; Marc-
> > > André Lureau ; Paolo Bonzini
> > > 
> > > Subject: [PATCH v4 3/6] net/colo-compare.c: Fix deadlock in
> > > compare_chr_send
> > >
> > > The chr_out chardev is connected to a filter-redirector running in
> > > the main loop. qemu_chr_fe_write_all might block here in
> > > compare_chr_send if the (socket-)buffer is full.
> > > If another filter-redirector in the main loop want's to send data to
> > > chr_pri_in it might also block if the buffer is full. This leads to
> > > a deadlock because both event loops get blocked.
> > >
> > > Fix this by converting compare_chr_send to a coroutine and putting
> > > the packets in a send queue.
> > >
> > > Signed-off-by: Lukas Straub 
> > > ---
> > >  net/colo-compare.c | 187 ++---
> 
> > > 
> > >  net/colo.c |   7 ++
> > >  net/colo.h |   1 +
> > >  3 files changed, 150 insertions(+), 45 deletions(-)
> > >
> > > diff --git a/net/colo-compare.c b/net/colo-compare.c index
> > > 1de4220fe2..2a4e7f7c4e 100644
> > > --- a/net/colo-compare.c
> > > +++ b/net/colo-compare.c
> > > @@ -32,6 +32,9 @@
> > >  #include "migration/migration.h"
> > >  #include "util.h"
> > >
> > > +#include "block/aio-wait.h"
> > > +#include "qemu/coroutine.h"
> > > +
> > >  #define TYPE_COLO_COMPARE "colo-compare"
> > >  #define COLO_COMPARE(obj) \
> > >  OBJECT_CHECK(CompareState, (obj), TYPE_COLO_COMPARE) @@ -
> 77,6
> > > +80,23 @@ static int event_unhandled_count;
> > >   *|packet  |  |packet  +|packet  | |packet  +
> > >   *++  ++++ ++
> > >   */
> > > +
> > > +typedef struct SendCo {
> > > +Coroutine *co;
> > > +struct CompareState *s;
> > > +CharBackend *chr;
> > > +GQueue send_list;
> > > +bool notify_remote_frame;
> > > +bool done;
> > > +int ret;
> > > +} SendCo;
> > > +
> > > +typedef struct SendEntry {
> > > +uint32_t size;
> > > +uint32_t vnet_hdr_len;
> > > +uint8_t *buf;
> > > +} SendEntry;
> > > +
> > >  typedef struct CompareState {
> > >  Object parent;
> > >
> > > @@ -91,6 +111,8 @@ typedef struct CompareState {
> > >  SocketReadState pri_rs;
> > >  SocketReadState sec_rs;
> > >  SocketReadState notify_rs;
> > > +SendCo out_sendco;
> > > +SendCo notify_sendco;
> > >  bool vnet_hdr;
> > >  uint32_t compare_timeout;
> > >  uint32_t expired_scan_cycle;
> > > @@ -124,10 +146,11 @@ enum {
> > >
> > >
> > >  static int compare_chr_send(CompareState *s,
> > > -const uint8_t *buf,
> > > +uint8_t *buf,
> > >  uint32_t size,
> > >  uint32_t vnet_hdr_len,
> > > -bool notify_remote_frame);
> > > +bool notify_remote_frame,
> > > +bool zero_copy);
> > >
> > >  static bool packet_matches_str(const char *str,
> > > const uint8_t *buf, @@ -145,7 +168,7
> > > @@ static void notify_remote_frame(CompareState *s)
> > >  char msg[] = "DO_CHECKPOINT";
> > >  int ret = 0;
> > >
> > > -ret = compare_chr_send(s, (uint8_t *)msg, strlen(msg), 0, true);
> > > +ret = compare_chr_send(s, (uint8_t *)msg, strlen(msg), 0, true,
> > > + false);
> > >  if (ret < 0) {
> > >  error_report("Notify Xen COLO-frame failed");
> > >  }
> > > @@ -272,12 +295,13 @@ static void
> > > colo_release_primary_pkt(CompareState *s, Packet *pkt)
> > > pkt->data,
> > > pkt->size,
> > > pkt->vnet_hdr_len,
> > > -   false);
> > > +   false,
> > > +   true);
> > >  if (ret < 0) {
> > >  error_report("colo send primary packet failed");
> > >  }
> > >  trace_colo_compare_main("packet same and release packet");
> > > -packet_destroy(pkt, NULL);
> > > +packet_destroy_partial(pkt, NULL);
> > >  }
> > >
> > >  /*
> > > @@ -699,65 +723,115 @@ static void colo_compare_connection(void
> > > *opaque, void *user_data)
> > >  }
> > >  }
> > >
> > > -static int compare_chr_send(CompareState *s,
> > > -const uint8_t *buf,
> > > -uint32_t size,
> > > -uint32_t vnet_hdr_len,
> > > -   

[PATCH RESEND v26 03/10] docs: APEI GHES generation and CPER record description

[Dongjiu Geng]

Add APEI/GHES detailed design document

Signed-off-by: Dongjiu Geng 
Signed-off-by: Xiang Zheng 
Reviewed-by: Michael S. Tsirkin 
Reviewed-by: Igor Mammedov 
---
 docs/specs/acpi_hest_ghes.rst | 110 ++
 docs/specs/index.rst  |   1 +
 2 files changed, 111 insertions(+)
 create mode 100644 docs/specs/acpi_hest_ghes.rst

diff --git a/docs/specs/acpi_hest_ghes.rst b/docs/specs/acpi_hest_ghes.rst
new file mode 100644
index 000..68f1fbe
--- /dev/null
+++ b/docs/specs/acpi_hest_ghes.rst
@@ -0,0 +1,110 @@
+APEI tables generating and CPER record
+==
+
+..
+   Copyright (c) 2020 HUAWEI TECHNOLOGIES CO., LTD.
+
+   This work is licensed under the terms of the GNU GPL, version 2 or later.
+   See the COPYING file in the top-level directory.
+
+Design Details
+--
+
+::
+
+ etc/acpi/tables   etc/hardware_errors
+     ===
+  + +--+++
+  | | HEST | +->|error_block_address1
|--+
+  | +--+ |  ++ 
 |
+  | | GHES1| | +--->|error_block_address2
|--+-+
+  | +--+ | |++ 
 | |
+  | | .| | ||  ..| 
 | |
+  | | error_status_address-+-+ |-+ 
 | |
+  | | .|   |   +--->|error_block_addressN
|--+-+---+
+  | | read_ack_register+-+ |   |++ 
 | |   |
+  | | read_ack_preserve| +-+---+--->| read_ack_register1 | 
 | |   |
+  | | read_ack_write   |   |   |++ 
 | |   |
+  + +--+   | +-+--->| read_ack_register2 | 
 | |   |
+  | | GHES2|   | | |++ 
 | |   |
+  + +--+   | | ||   .| 
 | |   |
+  | | .|   | | |++ 
 | |   |
+  | | error_status_address-+---+ | | +->| read_ack_registerN | 
 | |   |
+  | | .| | | |  ++ 
 | |   |
+  | | read_ack_register+-+ | |  |Generic Error Status Block 
1|<-+ |   |
+  | | read_ack_preserve|   | |  |-++-+ 
   |   |
+  | | read_ack_write   |   | |  | |  CPER  | | 
   |   |
+  + +--|   | |  | |  CPER  | | 
   |   |
+  | | ...  |   | |  | |    | | 
   |   |
+  + +--+   | |  | |  CPER  | | 
   |   |
+  | | GHESN|   | |  |-++-| 
   |   |
+  + +--+   | |  |Generic Error Status Block 
2|<---+   |
+  | | .|   | |  |-++-+ 
   |
+  | | error_status_address-+---+ |  | |   CPER | | 
   |
+  | | .| |  | |   CPER | | 
   |
+  | | read_ack_register+-+  | |    | | 
   |
+  | | read_ack_preserve|| |   CPER | | 
   |
+  | | read_ack_write   |+-++-+ 
   |
+  + +--+| .. | 
   |
+|+ 
   |
+|Generic Error Status Block N 
|<--+
+|-+-+-+
+| |  CPER   | |
+| |  CPER   | |
+| |     | |
+| |  CPER   | |
++-+-+-+
+
+
+(1) QEMU generates the ACPI HEST table. This table goes in the current
+"etc/acpi/tables" fw_cfg blob. Each error source has different
+notification types.
+
+(2) A new fw_cfg blob called "etc/hardware_errors" is introduced. QEMU
+also needs to populate this blob. The "etc/hardware_errors" fw_cfg blob
+contains an address registers table and an Error Status Data Block table.
+
+(3) The address registers table contains N Error Block Address entries
+and N Read Ack 

[PATCH RESEND v26 01/10] acpi: nvdimm: change NVDIMM_UUID_LE to a common macro

[Dongjiu Geng]

The little end UUID is used in many places, so make
NVDIMM_UUID_LE to a common macro to convert the UUID
to a little end array.

Reviewed-by: Xiang Zheng 
Signed-off-by: Dongjiu Geng 
---
Change since v25:
1. Address Peter's comments to add a proper doc-comment comment for
   UUID_LE macros.
---
 hw/acpi/nvdimm.c| 10 +++---
 include/qemu/uuid.h | 27 +++
 2 files changed, 30 insertions(+), 7 deletions(-)

diff --git a/hw/acpi/nvdimm.c b/hw/acpi/nvdimm.c
index fa7bf8b..9316d12 100644
--- a/hw/acpi/nvdimm.c
+++ b/hw/acpi/nvdimm.c
@@ -27,6 +27,7 @@
  */
 
 #include "qemu/osdep.h"
+#include "qemu/uuid.h"
 #include "hw/acpi/acpi.h"
 #include "hw/acpi/aml-build.h"
 #include "hw/acpi/bios-linker-loader.h"
@@ -34,18 +35,13 @@
 #include "hw/mem/nvdimm.h"
 #include "qemu/nvdimm-utils.h"
 
-#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,  \
- (d0), (d1), (d2), (d3), (d4), (d5), (d6), (d7) }
-
 /*
  * define Byte Addressable Persistent Memory (PM) Region according to
  * ACPI 6.0: 5.2.25.1 System Physical Address Range Structure.
  */
 static const uint8_t nvdimm_nfit_spa_uuid[] =
-  NVDIMM_UUID_LE(0x66f0d379, 0xb4f3, 0x4074, 0xac, 0x43, 0x0d, 0x33,
- 0x18, 0xb7, 0x8c, 0xdb);
+  UUID_LE(0x66f0d379, 0xb4f3, 0x4074, 0xac, 0x43, 0x0d, 0x33,
+  0x18, 0xb7, 0x8c, 0xdb);
 
 /*
  * NVDIMM Firmware Interface Table
diff --git a/include/qemu/uuid.h b/include/qemu/uuid.h
index 129c45f..9925feb 100644
--- a/include/qemu/uuid.h
+++ b/include/qemu/uuid.h
@@ -34,6 +34,33 @@ typedef struct {
 };
 } QemuUUID;
 
+/**
+ * UUID_LE - converts the fields of UUID to little-endian array,
+ * each of parameters is the filed of UUID.
+ *
+ * @time_low: The low field of the timestamp
+ * @time_mid: The middle field of the timestamp
+ * @time_hi_and_version: The high field of the timestamp
+ *   multiplexed with the version number
+ * @clock_seq_hi_and_reserved: The high field of the clock
+ * sequence multiplexed with the variant
+ * @clock_seq_low: The low field of the clock sequence
+ * @node0: The spatially unique node0 identifier
+ * @node1: The spatially unique node1 identifier
+ * @node2: The spatially unique node2 identifier
+ * @node3: The spatially unique node3 identifier
+ * @node4: The spatially unique node4 identifier
+ * @node5: The spatially unique node5 identifier
+ */
+#define UUID_LE(time_low, time_mid, time_hi_and_version,\
+  clock_seq_hi_and_reserved, clock_seq_low, node0, node1, node2,\
+  node3, node4, node5)  \
+  { (time_low) & 0xff, ((time_low) >> 8) & 0xff, ((time_low) >> 16) & 0xff, \
+((time_low) >> 24) & 0xff, (time_mid) & 0xff, ((time_mid) >> 8) & 0xff, \
+(time_hi_and_version) & 0xff, ((time_hi_and_version) >> 8) & 0xff,  \
+(clock_seq_hi_and_reserved), (clock_seq_low), (node0), (node1), (node2),\
+(node3), (node4), (node5) }
+
 #define UUID_FMT "%02hhx%02hhx%02hhx%02hhx-" \
  "%02hhx%02hhx-%02hhx%02hhx-" \
  "%02hhx%02hhx-" \
-- 
1.8.3.1

[PATCH RESEND v26 07/10] KVM: Move hwpoison page related functions into kvm-all.c

[Dongjiu Geng]

kvm_hwpoison_page_add() and kvm_unpoison_all() will both
be used by X86 and ARM platforms, so moving them into
"accel/kvm/kvm-all.c" to avoid duplicate code.

For architectures that don't use the poison-list functionality
the reset handler will harmlessly do nothing, so let's register
the kvm_unpoison_all() function in the generic kvm_init() function.

Reviewed-by: Peter Maydell 
Signed-off-by: Dongjiu Geng 
Signed-off-by: Xiang Zheng 
Acked-by: Xiang Zheng 
---
 accel/kvm/kvm-all.c  | 36 
 include/sysemu/kvm_int.h | 12 
 target/i386/kvm.c| 36 
 3 files changed, 48 insertions(+), 36 deletions(-)

diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index 439a4ef..36be117 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -44,6 +44,7 @@
 #include "qapi/visitor.h"
 #include "qapi/qapi-types-common.h"
 #include "qapi/qapi-visit-common.h"
+#include "sysemu/reset.h"
 
 #include "hw/boards.h"
 
@@ -883,6 +884,39 @@ int kvm_vm_check_extension(KVMState *s, unsigned int 
extension)
 return ret;
 }
 
+typedef struct HWPoisonPage {
+ram_addr_t ram_addr;
+QLIST_ENTRY(HWPoisonPage) list;
+} HWPoisonPage;
+
+static QLIST_HEAD(, HWPoisonPage) hwpoison_page_list =
+QLIST_HEAD_INITIALIZER(hwpoison_page_list);
+
+static void kvm_unpoison_all(void *param)
+{
+HWPoisonPage *page, *next_page;
+
+QLIST_FOREACH_SAFE(page, _page_list, list, next_page) {
+QLIST_REMOVE(page, list);
+qemu_ram_remap(page->ram_addr, TARGET_PAGE_SIZE);
+g_free(page);
+}
+}
+
+void kvm_hwpoison_page_add(ram_addr_t ram_addr)
+{
+HWPoisonPage *page;
+
+QLIST_FOREACH(page, _page_list, list) {
+if (page->ram_addr == ram_addr) {
+return;
+}
+}
+page = g_new(HWPoisonPage, 1);
+page->ram_addr = ram_addr;
+QLIST_INSERT_HEAD(_page_list, page, list);
+}
+
 static uint32_t adjust_ioeventfd_endianness(uint32_t val, uint32_t size)
 {
 #if defined(HOST_WORDS_BIGENDIAN) != defined(TARGET_WORDS_BIGENDIAN)
@@ -2085,6 +2119,8 @@ static int kvm_init(MachineState *ms)
 s->kernel_irqchip_split = mc->default_kernel_irqchip_split ? 
ON_OFF_AUTO_ON : ON_OFF_AUTO_OFF;
 }
 
+qemu_register_reset(kvm_unpoison_all, NULL);
+
 if (s->kernel_irqchip_allowed) {
 kvm_irqchip_create(s);
 }
diff --git a/include/sysemu/kvm_int.h b/include/sysemu/kvm_int.h
index ac2d1f8..c660a70 100644
--- a/include/sysemu/kvm_int.h
+++ b/include/sysemu/kvm_int.h
@@ -42,4 +42,16 @@ void kvm_memory_listener_register(KVMState *s, 
KVMMemoryListener *kml,
   AddressSpace *as, int as_id);
 
 void kvm_set_max_memslot_size(hwaddr max_slot_size);
+
+/**
+ * kvm_hwpoison_page_add:
+ *
+ * Parameters:
+ *  @ram_addr: the address in the RAM for the poisoned page
+ *
+ * Add a poisoned page to the list
+ *
+ * Return: None.
+ */
+void kvm_hwpoison_page_add(ram_addr_t ram_addr);
 #endif
diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index 4901c6d..34f8387 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -24,7 +24,6 @@
 #include "sysemu/sysemu.h"
 #include "sysemu/hw_accel.h"
 #include "sysemu/kvm_int.h"
-#include "sysemu/reset.h"
 #include "sysemu/runstate.h"
 #include "kvm_i386.h"
 #include "hyperv.h"
@@ -533,40 +532,6 @@ uint64_t kvm_arch_get_supported_msr_feature(KVMState *s, 
uint32_t index)
 }
 }
 
-
-typedef struct HWPoisonPage {
-ram_addr_t ram_addr;
-QLIST_ENTRY(HWPoisonPage) list;
-} HWPoisonPage;
-
-static QLIST_HEAD(, HWPoisonPage) hwpoison_page_list =
-QLIST_HEAD_INITIALIZER(hwpoison_page_list);
-
-static void kvm_unpoison_all(void *param)
-{
-HWPoisonPage *page, *next_page;
-
-QLIST_FOREACH_SAFE(page, _page_list, list, next_page) {
-QLIST_REMOVE(page, list);
-qemu_ram_remap(page->ram_addr, TARGET_PAGE_SIZE);
-g_free(page);
-}
-}
-
-static void kvm_hwpoison_page_add(ram_addr_t ram_addr)
-{
-HWPoisonPage *page;
-
-QLIST_FOREACH(page, _page_list, list) {
-if (page->ram_addr == ram_addr) {
-return;
-}
-}
-page = g_new(HWPoisonPage, 1);
-page->ram_addr = ram_addr;
-QLIST_INSERT_HEAD(_page_list, page, list);
-}
-
 static int kvm_get_mce_cap_supported(KVMState *s, uint64_t *mce_cap,
  int *max_banks)
 {
@@ -2180,7 +2145,6 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
 fprintf(stderr, "e820_add_entry() table is full\n");
 return ret;
 }
-qemu_register_reset(kvm_unpoison_all, NULL);
 
 shadow_mem = object_property_get_int(OBJECT(s), "kvm-shadow-mem", 
_abort);
 if (shadow_mem != -1) {
-- 
1.8.3.1

[PATCH RESEND v26 05/10] ACPI: Build Hardware Error Source Table

[Dongjiu Geng]

This patch builds Hardware Error Source Table(HEST) via fw_cfg blobs.
Now it only supports ARMv8 SEA, a type of Generic Hardware Error
Source version 2(GHESv2) error source. Afterwards, we can extend
the supported types if needed. For the CPER section, currently it
is memory section because kernel mainly wants userspace to handle
the memory errors.

This patch follows the spec ACPI 6.2 to build the Hardware Error
Source table. For more detailed information, please refer to
document: docs/specs/acpi_hest_ghes.rst

build_ghes_hw_error_notification() helper will help to add Hardware
Error Notification to ACPI tables without using packed C structures
and avoid endianness issues as API doesn't need explicit conversion.

Signed-off-by: Xiang Zheng 
Signed-off-by: Dongjiu Geng 
Reviewed-by: Igor Mammedov 
Reviewed-by: Michael S. Tsirkin 
---
 hw/acpi/ghes.c   | 126 +++
 hw/arm/virt-acpi-build.c |   2 +
 include/hw/acpi/ghes.h   |  39 +++
 3 files changed, 167 insertions(+)

diff --git a/hw/acpi/ghes.c b/hw/acpi/ghes.c
index e1b3f8f..091fd87 100644
--- a/hw/acpi/ghes.c
+++ b/hw/acpi/ghes.c
@@ -23,6 +23,7 @@
 #include "qemu/units.h"
 #include "hw/acpi/ghes.h"
 #include "hw/acpi/aml-build.h"
+#include "qemu/error-report.h"
 
 #define ACPI_GHES_ERRORS_FW_CFG_FILE"etc/hardware_errors"
 #define ACPI_GHES_DATA_ADDR_FW_CFG_FILE "etc/hardware_errors_addr"
@@ -33,6 +34,42 @@
 /* Now only support ARMv8 SEA notification type error source */
 #define ACPI_GHES_ERROR_SOURCE_COUNT1
 
+/* Generic Hardware Error Source version 2 */
+#define ACPI_GHES_SOURCE_GENERIC_ERROR_V2   10
+
+/* Address offset in Generic Address Structure(GAS) */
+#define GAS_ADDR_OFFSET 4
+
+/*
+ * Hardware Error Notification
+ * ACPI 4.0: 17.3.2.7 Hardware Error Notification
+ * Composes dummy Hardware Error Notification descriptor of specified type
+ */
+static void build_ghes_hw_error_notification(GArray *table, const uint8_t type)
+{
+/* Type */
+build_append_int_noprefix(table, type, 1);
+/*
+ * Length:
+ * Total length of the structure in bytes
+ */
+build_append_int_noprefix(table, 28, 1);
+/* Configuration Write Enable */
+build_append_int_noprefix(table, 0, 2);
+/* Poll Interval */
+build_append_int_noprefix(table, 0, 4);
+/* Vector */
+build_append_int_noprefix(table, 0, 4);
+/* Switch To Polling Threshold Value */
+build_append_int_noprefix(table, 0, 4);
+/* Switch To Polling Threshold Window */
+build_append_int_noprefix(table, 0, 4);
+/* Error Threshold Value */
+build_append_int_noprefix(table, 0, 4);
+/* Error Threshold Window */
+build_append_int_noprefix(table, 0, 4);
+}
+
 /*
  * Build table for the hardware error fw_cfg blob.
  * Initialize "etc/hardware_errors" and "etc/hardware_errors_addr" fw_cfg 
blobs.
@@ -87,3 +124,92 @@ void build_ghes_error_table(GArray *hardware_errors, 
BIOSLinker *linker)
 bios_linker_loader_write_pointer(linker, ACPI_GHES_DATA_ADDR_FW_CFG_FILE,
 0, sizeof(uint64_t), ACPI_GHES_ERRORS_FW_CFG_FILE, 0);
 }
+
+/* Build Generic Hardware Error Source version 2 (GHESv2) */
+static void build_ghes_v2(GArray *table_data, int source_id, BIOSLinker 
*linker)
+{
+uint64_t address_offset;
+/*
+ * Type:
+ * Generic Hardware Error Source version 2(GHESv2 - Type 10)
+ */
+build_append_int_noprefix(table_data, ACPI_GHES_SOURCE_GENERIC_ERROR_V2, 
2);
+/* Source Id */
+build_append_int_noprefix(table_data, source_id, 2);
+/* Related Source Id */
+build_append_int_noprefix(table_data, 0x, 2);
+/* Flags */
+build_append_int_noprefix(table_data, 0, 1);
+/* Enabled */
+build_append_int_noprefix(table_data, 1, 1);
+
+/* Number of Records To Pre-allocate */
+build_append_int_noprefix(table_data, 1, 4);
+/* Max Sections Per Record */
+build_append_int_noprefix(table_data, 1, 4);
+/* Max Raw Data Length */
+build_append_int_noprefix(table_data, ACPI_GHES_MAX_RAW_DATA_LENGTH, 4);
+
+address_offset = table_data->len;
+/* Error Status Address */
+build_append_gas(table_data, AML_AS_SYSTEM_MEMORY, 0x40, 0,
+ 4 /* QWord access */, 0);
+bios_linker_loader_add_pointer(linker, ACPI_BUILD_TABLE_FILE,
+address_offset + GAS_ADDR_OFFSET, sizeof(uint64_t),
+ACPI_GHES_ERRORS_FW_CFG_FILE, source_id * sizeof(uint64_t));
+
+switch (source_id) {
+case ACPI_HEST_SRC_ID_SEA:
+/*
+ * Notification Structure
+ * Now only enable ARMv8 SEA notification type
+ */
+build_ghes_hw_error_notification(table_data, ACPI_GHES_NOTIFY_SEA);
+break;
+default:
+error_report("Not support this error source");
+abort();
+}
+
+/* Error Status Block Length */
+build_append_int_noprefix(table_data, ACPI_GHES_MAX_RAW_DATA_LENGTH, 4);
+
+/*
+ * Read Ack Register
+ * ACPI 

[PATCH RESEND v26 02/10] hw/arm/virt: Introduce a RAS machine option

[Dongjiu Geng]

RAS Virtualization feature is not supported now, so
add a RAS machine option and disable it by default.

Reviewed-by: Peter Maydell 
Signed-off-by: Dongjiu Geng 
Signed-off-by: Xiang Zheng 
Reviewed-by: Jonathan Cameron 
Reviewed-by: Igor Mammedov 
---
 hw/arm/virt.c | 23 +++
 include/hw/arm/virt.h |  1 +
 2 files changed, 24 insertions(+)

diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 171e690..2d46c3f 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -1995,6 +1995,20 @@ static void virt_set_acpi(Object *obj, Visitor *v, const 
char *name,
 visit_type_OnOffAuto(v, name, >acpi, errp);
 }
 
+static bool virt_get_ras(Object *obj, Error **errp)
+{
+VirtMachineState *vms = VIRT_MACHINE(obj);
+
+return vms->ras;
+}
+
+static void virt_set_ras(Object *obj, bool value, Error **errp)
+{
+VirtMachineState *vms = VIRT_MACHINE(obj);
+
+vms->ras = value;
+}
+
 static char *virt_get_gic_version(Object *obj, Error **errp)
 {
 VirtMachineState *vms = VIRT_MACHINE(obj);
@@ -2327,6 +2341,15 @@ static void virt_instance_init(Object *obj)
 "Valid values are none and smmuv3",
 NULL);
 
+/* Default disallows RAS instantiation */
+vms->ras = false;
+object_property_add_bool(obj, "ras", virt_get_ras,
+ virt_set_ras, NULL);
+object_property_set_description(obj, "ras",
+"Set on/off to enable/disable reporting 
host memory errors "
+"to a KVM guest using ACPI and guest 
external abort exceptions",
+NULL);
+
 vms->irqmap = a15irqmap;
 
 virt_flash_create(vms);
diff --git a/include/hw/arm/virt.h b/include/hw/arm/virt.h
index 6d67ace..31878dd 100644
--- a/include/hw/arm/virt.h
+++ b/include/hw/arm/virt.h
@@ -132,6 +132,7 @@ typedef struct {
 bool highmem_ecam;
 bool its;
 bool virt;
+bool ras;
 OnOffAuto acpi;
 VirtGICType gic_version;
 VirtIOMMUType iommu;
-- 
1.8.3.1

[PATCH RESEND v26 00/10] Add ARMv8 RAS virtualization support in QEMU

[Dongjiu Geng]

In the ARMv8 platform, the CPU error types includes synchronous external 
abort(SEA)
and SError Interrupt (SEI). If exception happens in guest, host does not know 
the detailed
information of guest, so it is expected that guest can do the recovery. For 
example, if an
exception happens in a guest user-space application, host does not know which 
application
encounters errors, only guest knows it.

For the ARMv8 SEA/SEI, KVM or host kernel delivers SIGBUS to notify userspace.
After user space gets the notification, it will record the CPER into guest GHES
buffer and inject an exception or IRQ to guest.

In the current implementation, if the type of SIGBUS is BUS_MCEERR_AR, we will
treat it as a synchronous exception, and notify guest with ARMv8 SEA
notification type after recording CPER into guest.

A) This series of patches are based on Qemu 4.2, which include two parts:
1. Generate APEI/GHES table.
2. Handle the SIGBUS signal, record the CPER in runtime and fill it into guest
   memory, then notify guest according to the type of SIGBUS.

B) The solution was suggested by James(james.mo...@arm.com); The APEI part 
solution was suggested by Laszlo(ler...@redhat.com). Show some discussions in 
[1].

C) This series of patches have already been tested on ARM64 platform with RAS
feature enabled:
1. Show the APEI part verification result in [2].
2. Show the SIGBUS of BUS_MCEERR_AR handling verification result in [3].

D) Add 'ras' option in command Line to enable guest RAS error recovery feature, 
For example:
KVM model: ./qemu-system-aarch64 --enable-kvm -cpu host --bios QEMU_EFI.fd_new  
-machine virt,gic-version=3,ras,kernel-irqchip=on
-smp 4 -nographic -kernel Image  -append "rdinit=/init console=ttyAMA0 mem=512M 
root=/dev/ram0" -initrd guestfs_new.cpio.gz
TCG model: ./qemu-system-aarch64 -cpu cortex-a57 --bios QEMU_EFI.fd_new  
-machine virt,gic-version=3,ras,kernel-irqchip=on  -smp 4
-nographic -kernel Image  -append "rdinit=/init console=ttyAMA0 mem=512M 
root=/dev/ram0" -initrd guestfs_new.cpio.gz
---
Change since v23:
1. fix a warning for uuid

Change since v22:
1. Using 1 * KiB instead of 0x400 to define max size of one error block
2. Make the alignment to 8 bytes in bios_linker_loader_alloc()
3. Change "Copyright (c) 2019" to "Copyright (c) 2020" in file header
4. Fix some code style warnings/errors and add some comments in code
5. Address Jonathan's comments to easily support CCIX error injection
6. Add vmstate_ghes_state .subsections in vmstate_acpi_ged

Change since v21:
1. Make the user-facing 'ras' option description more clearly to address 
Peter's comments.
2. Update the doc description in "docs/specs/acpi_hest_ghes.rst"
3. Split HEST/GHES patches to more patches to make the review easily
4. Using source_id to index the location to save the CPER.
5. Optimize and simplify the logic to build HEST/GHES table to address 
Igor/Michael/Beata comments.
6. make ghes_addr_le a part of GED device.

Change since v20:
1. Move some implementation details from acpi_ghes.h to acpi_ghes.c
2. Add the reviewers for the ACPI/APEI/GHES part

Change since v19:
1. Fix clang compile error
2. Fix sphinx build error

Change since v18:
1. Fix some code-style and typo/grammar problems.
2. Remove no_ras in the VirtMachineClass struct.
3. Convert documentation to rst format.
4. Simplize the code and add comments for some magic value.
5. Move kvm_inject_arm_sea() function into the patch where it's used.
6. Register the reset handler(kvm_unpoison_all()) in the kvm_init() function.

Change since v17:
1. Improve some commit messages and comments.
2. Fix some code-style problems.
3. Add a *ras* machine option.
4. Move HEST/GHES related structures and macros into "hw/acpi/acpi_ghes.*".
5. Move HWPoison page functions into "include/sysemu/kvm_int.h".
6. Fix some bugs.
7. Improve the design document.

Change since v16:
1. check whether ACPI table is enabled when handling the memory error in the 
SIGBUS handler.

Change since v15:
1. Add a doc-comment in the proper format for 'include/exec/ram_addr.h'
2. Remove write_part_cpustate_to_list() because there is another bug fix patch
   has been merged "arm: Allow system registers for KVM guests to be changed by 
QEMU code"
3. Add some comments for kvm_inject_arm_sea() in 'target/arm/kvm64.c'
4. Compare the arm_current_el() return value to 0,1,2,3, not to PSTATE_MODE_* 
constants.
5. Change the RAS support wasn't introduced before 4.1 QEMU version.
6. Move the no_ras flag  patch to begin in this series

Change since v14:
1. Remove the BUS_MCEERR_AO handling logic because this asynchronous signal was 
masked by main thread
2. Address some Igor Mammedov's comments(ACPI part)
   1) change the comments for the enum AcpiHestNotifyType definition and remove 
ditto in patch 1
   2) change some patch commit messages and separate "APEI GHES table 
generation" patch to more patches.
3. Address some peter's comments(arm64 Synchronous External Abort injection)
   1) change some code notes
   2) 

Re: [PATCH] migration/rdma: fix a memleak on error path in rdma_start_incoming_migration

[Pan Nengyuan]

On 4/24/2020 5:46 PM, Dr. David Alan Gilbert wrote:
> * Pan Nengyuan (pannengy...@huawei.com) wrote:
>> 'rdma->host' is malloced in qemu_rdma_data_init, but forgot to free on the 
>> error
>> path in rdma_start_incoming_migration(), this patch fix that.
>>
>> The leak stack:
>> Direct leak of 2 byte(s) in 1 object(s) allocated from:
>> #0 0x7fb7add18ae8 in __interceptor_malloc (/lib64/libasan.so.5+0xefae8)
>> #1 0x7fb7ad0df1d5 in g_malloc (/lib64/libglib-2.0.so.0+0x531d5)
>> #2 0x7fb7ad0f8b32 in g_strdup (/lib64/libglib-2.0.so.0+0x6cb32)
>> #3 0x55a0464a0f6f in qemu_rdma_data_init 
>> /mnt/sdb/qemu/migration/rdma.c:2647
>> #4 0x55a0464b0e76 in rdma_start_incoming_migration 
>> /mnt/sdb/qemu/migration/rdma.c:4020
>> #5 0x55a0463f898a in qemu_start_incoming_migration 
>> /mnt/sdb/qemu/migration/migration.c:365
>> #6 0x55a0458c75d3 in qemu_init /mnt/sdb/qemu/softmmu/vl.c:4438
>> #7 0x55a046a3d811 in main /mnt/sdb/qemu/softmmu/main.c:48
>> #8 0x7fb7a8417872 in __libc_start_main (/lib64/libc.so.6+0x23872)
>> #9 0x55a04536b26d in _start 
>> (/mnt/sdb/qemu/build/x86_64-softmmu/qemu-system-x86_64+0x286926d)
>>
>> Reported-by: Euler Robot 
>> Signed-off-by: Pan Nengyuan 
> 
> Thanks,
> 
> 
> Reviewed-by: Dr. David Alan Gilbert 
> 
>> ---
>>  migration/rdma.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/migration/rdma.c b/migration/rdma.c
>> index f61587891b..967fda5b0c 100644
>> --- a/migration/rdma.c
>> +++ b/migration/rdma.c
>> @@ -4056,6 +4056,7 @@ void rdma_start_incoming_migration(const char 
>> *host_port, Error **errp)
>>  return;
>>  err:
>>  error_propagate(errp, local_err);
>> +g_free(rdma->host);
>>  g_free(rdma);
>>  g_free(rdma_return_path);
>>  }
>> -- 
>> 2.18.2
>>

Oh, I'm sorry, this may cause a potential nullptr access when taking the first 
error branch in rdma_start_incoming_migration:

rdma = qemu_rdma_data_init(host_port, _err);

if (rdma == NULL) {
goto err;
}
...

Since it has applied, I will send a new patch to fix it.

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

Re: Parameter 'driver' expects pluggable device type

[Priyamvad Acharya]

 Hi,
Thanks for providing relevant information.
FYI
I am using Qemu version *4.2.94 (v5.0.0-rc4-dirty).*
I am using *virt* board.

Where we need to set *user creatable *to true?
Any other modification is needed to allow sysbus device support?

Below is the script which I am using  to boot linux image with pl061 device
on virt board.

#!/bin/bash
>
> KERNEL="/lhome/priyamvad/debian_qemu_arm32/vmlinuz-3.16.0-6-armmp-lpae"
>
> INIT_IMAGE="/lhome/priyamvad/debian_qemu_arm32/initrd.img-3.16.0-6-armmp-lpae"
> DISK="/lhome/priyamvad/debian_qemu_arm32/hda30.qcow2"
>
> ./qemu-system-arm \
> -M virt \
> -m 1024 \
> -smp 4 \
> -kernel $KERNEL \
> -object rng-random,filename=/dev/urandom,id=rng0 \
> -device virtio-rng-device,rng=rng0 \
> -initrd $INIT_IMAGE \
> -append 'root=/dev/vda2' \
> -drive if=none,file=$DISK,format=qcow2,id=hd \
> -device pl061 \
> -device virtio-blk-device,drive=hd \
> -device virtio-net-device,netdev=usernet \
> -netdev user,id=usernet,hostfwd=tcp::-:22 \
> -nographic
>

Is the above script  correct  to boot linux image with pl061 device on virt
board?

On Fri, 8 May 2020 at 02:32, John Snow  wrote:

>
>
> On 5/6/20 8:56 AM, Priyamvad Acharya wrote:
> >
> > Hello developer community,
> > I want to allow a *sysbus *type device to boot with kernel image(arm
> > architecture) via Qemu command line .
> >
> > When I run qemu arm system executable with *-device *option via qemu
> > command line,I get following error message
> >
> >> qemu-system-arm: -device pl061: Parameter 'driver' expects pluggable
> > device type
> >
> > So, how to allow a sysbus device via command line?
> > Is there any working patch?
>
> Hi, it looks like the pl061 device is not declared "user creatable" so
> it is unavailable from the CLI. As a sysbus device, QEMU is not aware,
> in the abstract, of how to "connect" the device to other devices.
>
> See the sysbus class initialization code for more detail:
> https://github.com/qemu/qemu/blob/master/hw/core/sysbus.c#L301
>
>
> However, It looks like these boards/devices create such a device:
>
> hw/arm/highbank
> hw/arm/realview
> hw/arm/sbsa-ref
> hw/arm/stellaris
> hw/arm/versatilepb
> hw/arm/virt
>
> If you want one on some other kind of machine, you'll need to write it
> up yourself in the machine board code, but you didn't tell us what
> version of QEMU you're using, what machine type you are trying to use, etc.
>
> --js
>
>

Re: Parameter 'driver' expects pluggable device type

[Priyamvad Acharya]

Hi,
Thanks for providing relevant information.
FYI
I am using Qemu version *4.2.94 (v5.0.0-rc4-dirty).*
I am using *virt* board.

Where we need to set *user creatable *to true?
Any other modification is needed to allow sysbus device support?

Below is the script which I am using  to boot linux image with pl061 device
on virt board.

#!/bin/bash
>
> KERNEL="/lhome/priyamvad/debian_qemu_arm32/vmlinuz-3.16.0-6-armmp-lpae"
>
> INIT_IMAGE="/lhome/priyamvad/debian_qemu_arm32/initrd.img-3.16.0-6-armmp-lpae"
> DISK="/lhome/priyamvad/debian_qemu_arm32/hda30.qcow2"
>
> ./qemu-system-arm \
> -M virt \
> -m 1024 \
> -smp 4 \
> -kernel $KERNEL \
> -object rng-random,filename=/dev/urandom,id=rng0 \
> -device virtio-rng-device,rng=rng0 \
> -initrd $INIT_IMAGE \
> -append 'root=/dev/vda2' \
> -drive if=none,file=$DISK,format=qcow2,id=hd \
> -device pl061 \
> -device virtio-blk-device,drive=hd \
> -device virtio-net-device,netdev=usernet \
> -netdev user,id=usernet,hostfwd=tcp::-:22 \
> -nographic
>

Is this script  to boot linux image with pl061 device on virt board?


On Fri, 8 May 2020 at 02:32, John Snow  wrote:

>
>
> On 5/6/20 8:56 AM, Priyamvad Acharya wrote:
> >
> > Hello developer community,
> > I want to allow a *sysbus *type device to boot with kernel image(arm
> > architecture) via Qemu command line .
> >
> > When I run qemu arm system executable with *-device *option via qemu
> > command line,I get following error message
> >
> >> qemu-system-arm: -device pl061: Parameter 'driver' expects pluggable
> > device type
> >
> > So, how to allow a sysbus device via command line?
> > Is there any working patch?
>
> Hi, it looks like the pl061 device is not declared "user creatable" so
> it is unavailable from the CLI. As a sysbus device, QEMU is not aware,
> in the abstract, of how to "connect" the device to other devices.
>
> See the sysbus class initialization code for more detail:
> https://github.com/qemu/qemu/blob/master/hw/core/sysbus.c#L301
>
>
> However, It looks like these boards/devices create such a device:
>
> hw/arm/highbank
> hw/arm/realview
> hw/arm/sbsa-ref
> hw/arm/stellaris
> hw/arm/versatilepb
> hw/arm/virt
>
> If you want one on some other kind of machine, you'll need to write it
> up yourself in the machine board code, but you didn't tell us what
> version of QEMU you're using, what machine type you are trying to use, etc.
>
> --js
>
>

Re: [PATCH v1 2/2] Sample mtty: Add migration capability to mtty module

[Yan Zhao]

On Thu, May 07, 2020 at 11:19:40AM +0530, Kirti Wankhede wrote:
> 
> 
> On 5/7/2020 6:31 AM, Yan Zhao wrote:
> > On Tue, May 05, 2020 at 01:54:20AM +0800, Kirti Wankhede wrote:
> > > This patch makes mtty device migration capable. Purpose od this code is
> > > to test migration interface. Only stop-and-copy phase is implemented.
> > > Postcopy migration is not supported.
> > > 
> > > Actual data for mtty device migration is very less. Appended dummy data to
> > > migration data stream, default 100 Mbytes. Added sysfs file
> > > 'dummy_data_size_MB' to get dummy data size from user which can be used
> > > to check performance of based of data size. During resuming dummy data is
> > > read and discarded.
> > > 
> > > Signed-off-by: Kirti Wankhede 
> > > ---
> > >   samples/vfio-mdev/mtty.c | 602 
> > > ---
> > >   1 file changed, 574 insertions(+), 28 deletions(-)
> > > 
> > > diff --git a/samples/vfio-mdev/mtty.c b/samples/vfio-mdev/mtty.c
> > > index bf666cce5bb7..f9194234fc6a 100644
> > > --- a/samples/vfio-mdev/mtty.c
> > > +++ b/samples/vfio-mdev/mtty.c
> > > @@ -44,9 +44,23 @@
> > >   #define MTTY_STRING_LEN 16
> > > -#define MTTY_CONFIG_SPACE_SIZE  0xff
> > > -#define MTTY_IO_BAR_SIZE0x8
> > > -#define MTTY_MMIO_BAR_SIZE  0x10
> > > +#define MTTY_CONFIG_SPACE_SIZE   0xff
> > > +#define MTTY_IO_BAR_SIZE 0x8
> > > +#define MTTY_MMIO_BAR_SIZE   0x10
> > > +#define MTTY_MIGRATION_REGION_SIZE   0x100   // 16M
> > > +
> > > +#define MTTY_MIGRATION_REGION_INDEX  VFIO_PCI_NUM_REGIONS
> > > +#define MTTY_REGIONS_MAX (MTTY_MIGRATION_REGION_INDEX + 1)
> > > +
> > > +/* Data section start from page aligned offset */
> > > +#define MTTY_MIGRATION_REGION_DATA_OFFSET(0x1000)
> > > +
> > > +/* First page is used for struct vfio_device_migration_info */
> > > +#define MTTY_MIGRATION_REGION_SIZE_MMAP \
> > > + (MTTY_MIGRATION_REGION_SIZE - MTTY_MIGRATION_REGION_DATA_OFFSET)
> > > +
> > > +#define MIGRATION_INFO_OFFSET(MEMBER)\
> > > + offsetof(struct vfio_device_migration_info, MEMBER)
> > >   #define STORE_LE16(addr, val)   (*(u16 *)addr = val)
> > >   #define STORE_LE32(addr, val)   (*(u32 *)addr = val)
> > > @@ -129,6 +143,28 @@ struct serial_port {
> > >   u8 intr_trigger_level;  /* interrupt trigger level */
> > >   };
> > > +/* Migration packet */
> > > +#define PACKET_ID(u16)(0xfeedbaba)
> > > +
> > > +#define PACKET_FLAGS_ACTUAL_DATA (1 << 0)
> > > +#define PACKET_FLAGS_DUMMY_DATA  (1 << 1)
> > > +
> > > +#define PACKET_DATA_SIZE_MAX (8 * 1024 * 1024)
> > > +
> > > +struct packet {
> > > + u16 id;
> > > + u16 flags;
> > > + u32 data_size;
> > > + u8 data[];
> > > +};
> > > +
> > > +enum {
> > > + PACKET_STATE_NONE = 0,
> > > + PACKET_STATE_PREPARED,
> > > + PACKET_STATE_COPIED,
> > > + PACKET_STATE_LAST,
> > > +};
> > > +
> > >   /* State of each mdev device */
> > >   struct mdev_state {
> > >   int irq_fd;
> > > @@ -138,22 +174,37 @@ struct mdev_state {
> > >   u8 *vconfig;
> > >   struct mutex ops_lock;
> > >   struct mdev_device *mdev;
> > > - struct mdev_region_info region_info[VFIO_PCI_NUM_REGIONS];
> > > - u32 bar_mask[VFIO_PCI_NUM_REGIONS];
> > > + struct mdev_region_info region_info[MTTY_REGIONS_MAX];
> > > + u32 bar_mask[MTTY_REGIONS_MAX];
> > >   struct list_head next;
> > >   struct serial_port s[2];
> > >   struct mutex rxtx_lock;
> > >   struct vfio_device_info dev_info;
> > > - int nr_ports;
> > > + u32 nr_ports;
> > >   /* List of pinned gpfns, gpfn as index and content is 
> > > translated hpfn */
> > >   unsigned long *gpfn_to_hpfn;
> > >   struct notifier_block nb;
> > > +
> > > + u32 device_state;
> > > + u64 saved_size;
> > > + void *mig_region_base;
> > > + bool is_actual_data_sent;
> > > + struct packet *pkt;
> > > + u32 packet_state;
> > > + u64 dummy_data_size;
> > >   };
> > >   static struct mutex mdev_list_lock;
> > >   static struct list_head mdev_devices_list;
> > > +/*
> > > + * Default dummy data size set to 100 MB. To change value of dummy data 
> > > size at
> > > + * runtime but before migration write size in MB to sysfs file
> > > + * dummy_data_size_MB
> > > + */
> > > +static unsigned long user_dummy_data_size = (100 * 1024 * 1024);
> > > +
> > >   static const struct file_operations vd_fops = {
> > >   .owner  = THIS_MODULE,
> > >   };
> > > @@ -639,6 +690,288 @@ static void mdev_read_base(struct mdev_state 
> > > *mdev_state)
> > >   }
> > >   }
> > > +static int save_setup(struct mdev_state *mdev_state)
> > > +{
> > > + mdev_state->is_actual_data_sent = false;
> > > +
> > > + memset(mdev_state->pkt, 0, sizeof(struct packet) +
> > > +PACKET_DATA_SIZE_MAX);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int set_device_state(struct 

Re: [PATCH for-5.1 V3 0/7] mips: Add Loongson-3 machine support (with KVM)

[Huacai Chen]

Hi, Aleksandar,

On Thu, May 7, 2020 at 8:18 PM Aleksandar Markovic
 wrote:
>
> сре, 6. мај 2020. у 03:43 Huacai Chen  је написао/ла:
> >
> > Hi, Aleksandar,
> >
> > On Tue, May 5, 2020 at 6:12 PM Aleksandar Markovic
> >  wrote:
> > >
> > >
> > >
> > > уторак, 05. мај 2020., chen huacai  је написао/ла:
> > >>
> > >> Hi, Aleksandar,
> > >>
> > >> On Sun, May 3, 2020 at 6:50 PM Aleksandar Markovic
> > >>  wrote:
> > >> >
> > >> > нед, 3. мај 2020. у 12:21 Huacai Chen  је 
> > >> > написао/ла:
> > >> > >
> > >> > > Loongson-3 CPU family include Loongson-3A R1/R2/R3/R4 and Loongson-3B
> > >> > > R1/R2. Loongson-3A R1 is the oldest and its ISA is the smallest, 
> > >> > > while
> > >> > > Loongson-3A R4 is the newest and its ISA is almost the superset of 
> > >> > > all
> > >> > > others. To reduce complexity, in QEMU we just define two CPU types:
> > >> > >
> > >> > > 1, "Loongson-3A1000" CPU which is corresponding to Loongson-3A R1. 
> > >> > > It is
> > >> > >suitable for TCG because Loongson-3A R1 has fewest ASE.
> > >> > > 2, "Loongson-3A4000" CPU which is corresponding to Loongson-3A R4. 
> > >> > > It is
> > >> > >suitable for KVM because Loongson-3A R4 has the VZ ASE.
> > >> > >
> > >> >
> > >> > Huacai, thanks for putting together v3, which is a little better than 
> > >> > v2, and
> > >> > thanks for addressing my previous suggestions.
> > >> >
> > >> > Now, give us some time to digest new data on Loongson3.  We will
> > >> > respond, but it won't happen immediately, which is, you'd agree,
> > >> > reasonable. Just be patient.
> > >> >
> > >> > But again, in general, I salute your efforts very much!
> > >> >
> > >> > Yours, Aleksandar
> > >> I'm sorry for this late response because I have done many tests to
> > >> reproduce the problem reported at
> > >> https://patchew.org/QEMU/1588501221-1205-1-git-send-email-che...@lemote.com/,
> > >> but I don't have such a failure...
> > >>
> > >> What I have done:
> > >> 1, "make check" on MIPS64 platform (distro is Fedora28 for Loongson);
> > >> 2, "make check" on X86_64 platform (distro is RHEL8);
> > >> 3, "make docker-test-quick@centos7 SHOW_ENV=1 NETWORK=1" on X86_64
> > >> platform (distro is RHEL8);
> > >> 4, "make docker-test-quick@centos7 SHOW_ENV=1 J=n NETWORK=1" on X86_64
> > >> platform (distro is RHEL8 and I've tried n=2,3,414);
> > >>
> > >> I always get the same result:
> > >> Not run: 259
> > >> Passed all 117 iotests
> > >>
> > >> And, it seems that my patchset doesn't touch anything about iotests,
> > >> so I don't know why the build test fails on iotests 192 (Maybe your
> > >> build test has the same problem without my patches).
> > >>
> > >
> > > From time to time, there is some instability in our automatic iotests. 
> > > You shouldn't bother too much about it, of course you retest in your 
> > > environments, that is good. But, in all likelyhood, your patchset doesn't 
> > > really have anything to do with the reported iotest failure.
> >
> > Thank you for your help, and here is another question: Could
> > "target/mips: Support variable page size" series be merged now? This
> > Loongson-3 series depend on variable page size logically.
> >
>
> Hi, Huacei.
>
> Please be patient. This is a significant series, and we don't do or
> have a "fast track" for series of such nature. It might or might not
> be that some of the patches will be accepted before the entire series,
> but certainly do not rush us. This is not the way to achieve your
> goal, let's put it that way. Focus on improving your series. Being
> careful with reviewing and upstreaming is actually in your interest.
Thank your very much. I know I should be patient, and I'm patient
actually. I mention "target/mips: Support variable page size" here
because I forget to add "for-5.1" in that series, I want to know
whether I should resend it.

>
> Yours,
> Aleksandar
>
> > >
> > > Truly yours,
> > > Aleksandar
> > >
> > >
> > >>
> > >> P.S.: I have found a problem that my patchset has a build failure with
> > >> CONFIG_KVM=n, but this is another problem and I will send V4 to fix it
> > >> (after collecting all problems in V3).
> > >>
> > >>
> > >> >
> > >> > > Loongson-3 lacks English documents. I've tried to translated them 
> > >> > > with
> > >> > > translate.google.com, and the machine translated documents (together
> > >> > > with their original Chinese versions) are available here.
> > >> > >
> > >> > > Loongson-3A R1 (Loongson-3A1000)
> > >> > > User Manual Part 1:
> > >> > > http://ftp.godson.ac.cn/lemote/3A1000_p1.pdf
> > >> > > http://ftp.godson.ac.cn/lemote/Loongson3A1000_processor_user_manual_P1.pdf
> > >> > >  (Chinese Version)
> > >> > > User Manual Part 2:
> > >> > > http://ftp.godson.ac.cn/lemote/3A1000_p2.pdf
> > >> > > http://ftp.godson.ac.cn/lemote/Loongson3A1000_processor_user_manual_P2.pdf
> > >> > >  (Chinese Version)
> > >> > >
> > >> > > Loongson-3A R2 (Loongson-3A2000)
> > >> > > User Manual Part 1:
> > >> > > http://ftp.godson.ac.cn/lemote/3A2000_p1.pdf

Re: [PATCH] target/ppc: Untabify excp_helper.c

[David Gibson]

On Thu, May 07, 2020 at 06:11:23PM +0200, Greg Kurz wrote:
> Some tabs crept in with a recent change.
> 
> Fixes: 6dc6b557913f "target/ppc: Improve syscall exception logging"
> Signed-off-by: Greg Kurz 

Applied, thanks.

Not quite sure why my pre-commit hook didn't catch this before I sent
the PR, but there you go.

> ---
>  target/ppc/excp_helper.c |   16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/target/ppc/excp_helper.c b/target/ppc/excp_helper.c
> index 639cac38f9c3..4db3d9ed9af5 100644
> --- a/target/ppc/excp_helper.c
> +++ b/target/ppc/excp_helper.c
> @@ -70,16 +70,16 @@ static inline void dump_syscall(CPUPPCState *env)
>  static inline void dump_hcall(CPUPPCState *env)
>  {
>  qemu_log_mask(CPU_LOG_INT, "hypercall r3=%016" PRIx64
> -   " r4=%016" PRIx64 " r5=%016" PRIx64 " r6=%016" PRIx64
> -   " r7=%016" PRIx64 " r8=%016" PRIx64 " r9=%016" PRIx64
> -   " r10=%016" PRIx64 " r11=%016" PRIx64 " r12=%016" PRIx64
> +  " r4=%016" PRIx64 " r5=%016" PRIx64 " r6=%016" PRIx64
> +  " r7=%016" PRIx64 " r8=%016" PRIx64 " r9=%016" PRIx64
> +  " r10=%016" PRIx64 " r11=%016" PRIx64 " r12=%016" PRIx64
>" nip=" TARGET_FMT_lx "\n",
>ppc_dump_gpr(env, 3), ppc_dump_gpr(env, 4),
> -   ppc_dump_gpr(env, 5), ppc_dump_gpr(env, 6),
> -   ppc_dump_gpr(env, 7), ppc_dump_gpr(env, 8),
> -   ppc_dump_gpr(env, 9), ppc_dump_gpr(env, 10),
> -   ppc_dump_gpr(env, 11), ppc_dump_gpr(env, 12),
> -   env->nip);
> +  ppc_dump_gpr(env, 5), ppc_dump_gpr(env, 6),
> +  ppc_dump_gpr(env, 7), ppc_dump_gpr(env, 8),
> +  ppc_dump_gpr(env, 9), ppc_dump_gpr(env, 10),
> +  ppc_dump_gpr(env, 11), ppc_dump_gpr(env, 12),
> +  env->nip);
>  }
>  
>  static int powerpc_reset_wakeup(CPUState *cs, CPUPPCState *env, int excp,
> 

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


signature.asc
Description: PGP signature

Re: [PATCH] ppc/spapr: add a POWER10 CPU model

[David Gibson]

On Thu, May 07, 2020 at 09:38:55AM +0200, Cédric Le Goater wrote:
> Signed-off-by: Cédric Le Goater 

Applied to ppc-for-5.1, thanks

> ---
>  hw/ppc/spapr_cpu_core.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/hw/ppc/spapr_cpu_core.c b/hw/ppc/spapr_cpu_core.c
> index ac1c10942771..9c7e0d225a0a 100644
> --- a/hw/ppc/spapr_cpu_core.c
> +++ b/hw/ppc/spapr_cpu_core.c
> @@ -410,6 +410,7 @@ static const TypeInfo spapr_cpu_core_type_infos[] = {
>  DEFINE_SPAPR_CPU_CORE_TYPE("power8nvl_v1.0"),
>  DEFINE_SPAPR_CPU_CORE_TYPE("power9_v1.0"),
>  DEFINE_SPAPR_CPU_CORE_TYPE("power9_v2.0"),
> +DEFINE_SPAPR_CPU_CORE_TYPE("power10_v1.0"),
>  #ifdef CONFIG_KVM
>  DEFINE_SPAPR_CPU_CORE_TYPE("host"),
>  #endif

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


signature.asc
Description: PGP signature

Re: [PATCH] ppc/pnv: Fix NMI system reset SRR1 value

[David Gibson]

On Thu, May 07, 2020 at 09:48:24PM +1000, Nicholas Piggin wrote:
> Commit a77fed5bd926 ("ppc/pnv: Add support for NMI interface") got the
> SRR1 setting wrong for sresets that hit outside of power-save states.
> 
> Fix this, better documenting the source for the bit definitions.
> 
> Fixes: a77fed5bd926 ("ppc/pnv: Add support for NMI interface") got the
> Cc: Cédric Le Goater 
> Cc: David Gibson 
> Signed-off-by: Nicholas Piggin 

Applied to ppc-for-5.1, thanks.
> ---
> 
> Thanks to Cedric for pointing out concerns with a previous MCE patch
> that unearthed this as well. Linux does not actually care what these
> SRR1[42:45] bits look like for non-powersave sresets, but we should
> follow documented behaviour as far as possible.
> 
>  hw/ppc/pnv.c | 26 --
>  1 file changed, 20 insertions(+), 6 deletions(-)
> 
> diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
> index a3b7a8d0ff..1b4748ce6d 100644
> --- a/hw/ppc/pnv.c
> +++ b/hw/ppc/pnv.c
> @@ -1986,12 +1986,26 @@ static void pnv_cpu_do_nmi_on_cpu(CPUState *cs, 
> run_on_cpu_data arg)
>  
>  cpu_synchronize_state(cs);
>  ppc_cpu_do_system_reset(cs);
> -/*
> - * SRR1[42:45] is set to 0100 which the ISA defines as implementation
> - * dependent. POWER processors use this for xscom triggered interrupts,
> - * which come from the BMC or NMI IPIs.
> - */
> -env->spr[SPR_SRR1] |= PPC_BIT(43);
> +if (env->spr[SPR_SRR1] & PPC_BITMASK(46, 47)) {
> +/*
> +  * Power-save wakeups, as indicated by non-zero SRR1[46:47] put the
> +  * wakeup reason in SRR1[42:45], system reset is indicated with 0b0100
> +  * (PPC_BIT(43)).
> +  */
> +if (!(env->spr[SPR_SRR1] & PPC_BIT(43))) {
> +warn_report("ppc_cpu_do_system_reset does not set system reset 
> wakeup reason");
> +env->spr[SPR_SRR1] |= PPC_BIT(43);
> +}
> +} else {
> +/*
> +  * For non-powersave system resets, SRR1[42:45] are defined to be
> +  * implementation-dependent. The POWER9 User Manual specifies that
> +  * an external (SCOM driven, which may come from a BMC nmi command or
> +  * another CPU requesting a NMI IPI) system reset exception should be
> +  * 0b0010 (PPC_BIT(44)).
> + */
> +env->spr[SPR_SRR1] |= PPC_BIT(44);
> +}
>  }
>  
>  static void pnv_nmi(NMIState *n, int cpu_index, Error **errp)

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


signature.asc
Description: PGP signature

[Bug 1805256] Re: qemu-img hangs on rcu_call_ready_event logic in Aarch64 when converting images

[dann frazier]

Ike's backport in
https://launchpad.net/~ikepanhc/+archive/ubuntu/lp1805256 tests well for
me on Cavium Sabre. One minor note is that the function
in_aio_context_home_thread() is being called in aio-win32.c, but that
function didn't exist in 2.11. We probably want to change that to
aio_context_in_iothread(). It was renamed in
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=d2b63ba8dd20c1091b3f1033e6a95ef95b18149d

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

Title:
  qemu-img hangs on rcu_call_ready_event logic in Aarch64 when
  converting images

Status in kunpeng920:
  Triaged
Status in kunpeng920 ubuntu-18.04 series:
  Triaged
Status in kunpeng920 ubuntu-18.04-hwe series:
  Triaged
Status in kunpeng920 ubuntu-19.10 series:
  Triaged
Status in kunpeng920 ubuntu-20.04 series:
  Triaged
Status in kunpeng920 upstream-kernel series:
  Fix Committed
Status in QEMU:
  Fix Released
Status in qemu package in Ubuntu:
  In Progress
Status in qemu source package in Bionic:
  In Progress
Status in qemu source package in Disco:
  In Progress
Status in qemu source package in Eoan:
  In Progress
Status in qemu source package in Focal:
  In Progress

Bug description:
  [Impact]

  * QEMU locking primitives might face a race condition in QEMU Async
  I/O bottom halves scheduling. This leads to a dead lock making either
  QEMU or one of its tools to hang indefinitely.

  [Test Case]

  * qemu-img convert -f qcow2 -O qcow2 ./disk01.qcow2 ./output.qcow2

  Hangs indefinitely approximately 30% of the runs in Aarch64.

  [Regression Potential]

  * This is a change to a core part of QEMU: The AIO scheduling. It
  works like a "kernel" scheduler, whereas kernel schedules OS tasks,
  the QEMU AIO code is responsible to schedule QEMU coroutines or event
  listeners callbacks.

  * There was a long discussion upstream about primitives and Aarch64.
  After quite sometime Paolo released this patch and it solves the
  issue. Tested platforms were: amd64 and aarch64 based on his commit
  log.

  * Christian suggests that this fix stay little longer in -proposed to
  make sure it won't cause any regressions.

  * dannf suggests we also check for performance regressions; e.g. how
  long it takes to convert a cloud image on high-core systems.

  [Other Info]

   * Original Description bellow:

  Command:

  qemu-img convert -f qcow2 -O qcow2 ./disk01.qcow2 ./output.qcow2

  Hangs indefinitely approximately 30% of the runs.

  

  Workaround:

  qemu-img convert -m 1 -f qcow2 -O qcow2 ./disk01.qcow2 ./output.qcow2

  Run "qemu-img convert" with "a single coroutine" to avoid this issue.

  

  (gdb) thread 1
  ...
  (gdb) bt
  #0 0xbf1ad81c in __GI_ppoll
  #1 0xaabcf73c in ppoll
  #2 qemu_poll_ns
  #3 0xaabd0764 in os_host_main_loop_wait
  #4 main_loop_wait
  ...

  (gdb) thread 2
  ...
  (gdb) bt
  #0 syscall ()
  #1 0xaabd41cc in qemu_futex_wait
  #2 qemu_event_wait (ev=ev@entry=0xaac86ce8 )
  #3 0xaabed05c in call_rcu_thread
  #4 0xaabd34c8 in qemu_thread_start
  #5 0xbf25c880 in start_thread
  #6 0xbf1b6b9c in thread_start ()

  (gdb) thread 3
  ...
  (gdb) bt
  #0 0xbf11aa20 in __GI___sigtimedwait
  #1 0xbf2671b4 in __sigwait
  #2 0xaabd1ddc in sigwait_compat
  #3 0xaabd34c8 in qemu_thread_start
  #4 0xbf25c880 in start_thread
  #5 0xbf1b6b9c in thread_start

  

  (gdb) run
  Starting program: /usr/bin/qemu-img convert -f qcow2 -O qcow2
  ./disk01.ext4.qcow2 ./output.qcow2

  [New Thread 0xbec5ad90 (LWP 72839)]
  [New Thread 0xbe459d90 (LWP 72840)]
  [New Thread 0xbdb57d90 (LWP 72841)]
  [New Thread 0xacac9d90 (LWP 72859)]
  [New Thread 0xa7ffed90 (LWP 72860)]
  [New Thread 0xa77fdd90 (LWP 72861)]
  [New Thread 0xa6ffcd90 (LWP 72862)]
  [New Thread 0xa67fbd90 (LWP 72863)]
  [New Thread 0xa5ffad90 (LWP 72864)]

  [Thread 0xa5ffad90 (LWP 72864) exited]
  [Thread 0xa6ffcd90 (LWP 72862) exited]
  [Thread 0xa77fdd90 (LWP 72861) exited]
  [Thread 0xbdb57d90 (LWP 72841) exited]
  [Thread 0xa67fbd90 (LWP 72863) exited]
  [Thread 0xacac9d90 (LWP 72859) exited]
  [Thread 0xa7ffed90 (LWP 72860) exited]

  
  """

  All the tasks left are blocked in a system call, so no task left to call
  qemu_futex_wake() to unblock thread #2 (in futex()), which would unblock
  thread #1 (doing poll() in a pipe with thread #2).

  Those 7 threads exit before disk conversion is complete (sometimes in
  the beginning, sometimes at the end).

  

  On the HiSilicon D06 system - a 96 core NUMA arm64 box - qemu-img
  frequently hangs (~50% of the time) with this command:

  qemu-img convert -f qcow2 -O qcow2 /tmp/cloudimg /tmp/cloudimg2

  Where "cloudimg" is a standard qcow2 Ubuntu cloud image. This
  qcow2->qcow2 conversion happens to be something uvtool does 

Re: [PATCH 00/10] exec: Shear 'exec/ram_addr.h' and make NVMe device target-agnostic

[Paolo Bonzini]

On 07/05/20 19:39, Philippe Mathieu-Daudé wrote:
> Stefan suggested to make qemu_ram_writeback() target agnostic,
> Paolo to add memory_region_msync(), and Peter to remove
> "exec/ram_addr.h" [*].
> 
> I let a single function in this file,
> cpu_physical_memory_sync_dirty_bitmap(), to let the maintainer
> have the pleasure to remove this header definitively himself :)

I don't think this is a good idea. :)

"exec/ram_addr.h" is a good place for functions that work on ram-addr_t
and/or RAMBlock data.  There should very few of these, since these are
mostly an internal concept that should only be used for live migration.
 You could:

- figure out which files actually need to include exec/ram_addr.h.
There's already very few of them.

- move the large functions to a new .c file, ramblock.c.  Figure out
which can be static, move the declarations for the others to ramblock.h

- kill ram_addr.h and include ramblock.h instead.

Not coincidentially, qemu_ram_writeback() takes a RAMBlock*, and it ends
up in ramblock.h.

Also, this is orthogonal to adding the wrapper memory_region_msync.

Thanks,

Paolo

Re: [PATCH v2] Fix parameter type in vhost migration log path

[Eric Blake]

On 5/7/20 4:37 PM, Raphael Norwitz wrote:

The ‘enable’ parameter to the vhost_migraion_log() function is given as


typo: migration

Presumably, the maintainer can fix this rather than needing you to send 
a v3...



an int, but "true"/"false" values are passed in wherever it is invoked.
Inside the function itself it is only ever compared with bool values.
Therefore the parameter value itself should be changed to bool.

Signed-off-by: Raphael Norwitz 
---
  hw/virtio/vhost.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Re: [PATCH v2] Fix parameter type in vhost migration log path

[Eric Blake]

On 5/7/20 4:37 PM, Raphael Norwitz wrote:

The ‘enable’ parameter to the vhost_migraion_log() function is given as
an int, but "true"/"false" values are passed in wherever it is invoked.
Inside the function itself it is only ever compared with bool values.
Therefore the parameter value itself should be changed to bool.

Signed-off-by: Raphael Norwitz 
---
  hw/virtio/vhost.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)



Reviewed-by: Eric Blake 


diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
index aff98a0..aa06a36 100644
--- a/hw/virtio/vhost.c
+++ b/hw/virtio/vhost.c
@@ -809,12 +809,12 @@ err_features:
  return r;
  }

-static int vhost_migration_log(MemoryListener *listener, int enable)
+static int vhost_migration_log(MemoryListener *listener, bool enable)
  {
  struct vhost_dev *dev = container_of(listener, struct vhost_dev,
   memory_listener);
  int r;
-if (!!enable == dev->log_enabled) {
+if (enable == dev->log_enabled) {
  return 0;
  }
  if (!dev->started) {
--
1.8.3.1



--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

[PATCH v2] Fix parameter type in vhost migration log path

[Raphael Norwitz]

The ‘enable’ parameter to the vhost_migraion_log() function is given as
an int, but "true"/"false" values are passed in wherever it is invoked.
Inside the function itself it is only ever compared with bool values.
Therefore the parameter value itself should be changed to bool.

Signed-off-by: Raphael Norwitz 
---
 hw/virtio/vhost.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
index aff98a0..aa06a36 100644
--- a/hw/virtio/vhost.c
+++ b/hw/virtio/vhost.c
@@ -809,12 +809,12 @@ err_features:
 return r;
 }

-static int vhost_migration_log(MemoryListener *listener, int enable)
+static int vhost_migration_log(MemoryListener *listener, bool enable)
 {
 struct vhost_dev *dev = container_of(listener, struct vhost_dev,
  memory_listener);
 int r;
-if (!!enable == dev->log_enabled) {
+if (enable == dev->log_enabled) {
 return 0;
 }
 if (!dev->started) {
--
1.8.3.1

[Bug 1857269] Re: Spanish keyboard from Spain (Europe) not found

[José Antonio López Cano]

Hello,

I thought that the not fully working problem on my laptop was originated
by the es keymap file, but it is not. I have edited that file and I
receive the same error. I believe that windows version of qemu has a
problem, at least, with laptops. A few months ago I get this error with
an asus laptop and nowdays I am even worse with a hp. I can not test the
windows version with a desktop computer.

I will download every new version and I shall comment if it works.

Thanks for your attention.


** Summary changed:

- Spanish keyboard from Spain (Europe) not found
+ Keyboard not fully working on Windows version

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

Title:
  Keyboard not fully working on Windows version

Status in QEMU:
  New

Bug description:
  Hello,

  I am working with windows qemu version:

  qemu-w64-setup-20190815

  I have installed a msdos virtual machine on qemu with sp keyboard
  layout (Spain at Europe). I have found that some keys do not work in
  the way they should. I believe that the problem is that es qemu
  spanish keyboard layout is the latin one, la in msdos sysytem.

  I ask you to create the Spain layout.


  Thanks in advance.

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

Re: Parameter 'driver' expects pluggable device type

[John Snow]

On 5/6/20 8:56 AM, Priyamvad Acharya wrote:
> 
> Hello developer community,
> I want to allow a *sysbus *type device to boot with kernel image(arm
> architecture) via Qemu command line .
> 
> When I run qemu arm system executable with *-device *option via qemu
> command line,I get following error message
> 
>> qemu-system-arm: -device pl061: Parameter 'driver' expects pluggable
> device type
> 
> So, how to allow a sysbus device via command line?
> Is there any working patch?

Hi, it looks like the pl061 device is not declared "user creatable" so
it is unavailable from the CLI. As a sysbus device, QEMU is not aware,
in the abstract, of how to "connect" the device to other devices.

See the sysbus class initialization code for more detail:
https://github.com/qemu/qemu/blob/master/hw/core/sysbus.c#L301


However, It looks like these boards/devices create such a device:

hw/arm/highbank
hw/arm/realview
hw/arm/sbsa-ref
hw/arm/stellaris
hw/arm/versatilepb
hw/arm/virt

If you want one on some other kind of machine, you'll need to write it
up yourself in the machine board code, but you didn't tell us what
version of QEMU you're using, what machine type you are trying to use, etc.

--js

Re: [PATCH] Fix erroneous double negation in conditional

[Michael S. Tsirkin]

On Tue, Apr 28, 2020 at 12:04:29AM -0400, Raphael Norwitz wrote:
> In vhost_migration_log() there is the following check:
> if(!!enable == dev->log_enabled) {
> return 0;
> }
> 
> The double negative “!!” is unnecessary and bad coding style.

It converts the value to bool.

> This
> change removes it.
> 
> Signed-off-by: Raphael Norwitz 
> ---
>  hw/virtio/vhost.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
> index aff98a0..83be0c8 100644
> --- a/hw/virtio/vhost.c
> +++ b/hw/virtio/vhost.c
> @@ -814,7 +814,7 @@ static int vhost_migration_log(MemoryListener *listener, 
> int enable)
>  struct vhost_dev *dev = container_of(listener, struct vhost_dev,
>   memory_listener);
>  int r;
> -if (!!enable == dev->log_enabled) {
> +if (enable == dev->log_enabled) {
>  return 0;
>  }
>  if (!dev->started) {
> -- 
> 1.8.3.1

Re: [PATCH] tests/acceptance/boot_linux: Skip slow Aarch64 'virt' machine TCG test

[Alex Bennée]

Peter Maydell  writes:

> On Thu, 7 May 2020 at 19:38, Alex Bennée  wrote:
>>
>>
>> Philippe Mathieu-Daudé  writes:
>>
>> > The BootLinuxAarch64.test_virt_tcg is reported to take >7min to run.
>> > Add a possibility to users to skip this particular test, by setting
>> > the AVOCADO_SKIP_SLOW_TESTS environment variable:
>> >
>> >   $ AVOCADO_SKIP_SLOW_TESTS=please make check-acceptance
>> >   ...
>> > (05/88) tests/acceptance/boot_linux.py:BootLinuxAarch64.test_virt_tcg: 
>> > SKIP: Test takes >7min
>> >   ...
>>
>> 7m = 420s - I'm seeing:
>>
>>   hyperfine "./tests/venv/bin/avocado run 
>> ./tests/acceptance/boot_linux.py:BootLinuxAarch64.test_virt_tcg"
>>   Benchmark #1: ./tests/venv/bin/avocado run 
>> ./tests/acceptance/boot_linux.py:BootLinuxAarch64.test_virt_tcg
>> Time (mean ± σ): 162.179 s ±  3.138 s[User: 204.726 s, System: 
>> 9.663 s]
>> Range (min … max):   158.651 s … 170.036 s10 runs
>>
>> Is this on very slow hardware?
>
> Intel(R) Xeon(R) W-2145 CPU @ 3.70GHz 16-core
> clang sanitizer build, which probably slows it down a bit.
>
> But even 200 seconds is an order of magnitude slower than any
> of the other tests that check-acceptance runs. I think we
> should be aiming for tests here to be ~30 seconds at most,
> or the whole thing will take forever by the time we have
> decent coverage of most machines.

I think we could say the same for a whole bunch of the tests that are
based on full distro downloads. What is this one running under the hood
anyway?


>
> thanks
> -- PMM


-- 
Alex Bennée

Re: [PATCH v16 QEMU 08/16] vfio: Register SaveVMHandlers for VFIO device

[Alex Williamson]

On Thu, 7 May 2020 01:00:05 +0530
Kirti Wankhede  wrote:

> On 5/6/2020 10:23 PM, Dr. David Alan Gilbert wrote:
> > * Cornelia Huck (coh...@redhat.com) wrote:  
> >> On Wed, 6 May 2020 02:38:46 -0400
> >> Yan Zhao  wrote:
> >>  
> >>> On Tue, May 05, 2020 at 12:37:26PM +0800, Alex Williamson wrote:  
>  It's been a long time, but that doesn't seem like what I was asking.
>  The sysfs version checking is used to select a target that is likely to
>  succeed, but the migration stream is still generated by a user and the
>  vendor driver is still ultimately responsible for validating that
>  stream.  I would hope that a vendor migration stream therefore starts
>  with information similar to that found in the sysfs interface, allowing
>  the receiving vendor driver to validate the source device and vendor
>  software version, such that we can fail an incoming migration that the
>  vendor driver deems incompatible.  Ideally the vendor driver might also
>  include consistency and sequence checking throughout the stream to
>  prevent a malicious user from exploiting the internal operation of the
>  vendor driver.  Thanks,  
> >>
> >> Some kind of somewhat standardized marker for driver/version seems like
> >> a good idea. Further checking is also a good idea, but I think the
> >> details of that need to be left to the individual drivers.  
> > 
> > Standardised markers like that would be useful; although the rules of
> > how to compare them might be a bit vendor specific; but still - it would
> > be good for us to be able to dump something out when it all goes wrong.
> >   
> 
> Such checking should already there in vendor driver. Vendor driver might 
> also support across version migration. I think checking in QEMU again 
> would be redundant. Let vendor driver handle version checks.
>
>   
> >>> maybe we can add a rw field migration_version in
> >>> struct vfio_device_migration_info besides sysfs interface ?
> >>>
> >>> when reading it in src, it gets the same string as that from sysfs;
> >>> when writing it in target, it returns success or not to check
> >>> compatibility and fails the migration early in setup phase.  
> >>
> >> Getting both populated from the same source seems like a good idea.
> >>
> >> Not sure if a string is the best value to put into a migration stream;
> >> maybe the sysfs interface can derive a human-readable string from a
> >> more compact value to be put into the migration region (and ultimately
> >> the stream)? Might be overengineering, just thinking out aloud here.  
> > 
> > A string might be OK fi you specify a little about it.

I think we've already hashed through that the version is represented by
a string, but interpretation of that string is reserved for the vendor
driver.  I believe this particular thread started out as a question of
whether QEMU is right to validate target compatibility by comparing the
migration region size versus the source, which I see as an overstep of
leaving the compatibility testing to the vendor driver.  A write
exceeding the migration region is clearly a protocol violation, but
unless we're going to scan the entire migration stream to look for that
violation, it's the vendor driver's business where and how it exposes
data within the region.  IOW, different migration region sizes might
suggest to be suspicious, but nothing in our specification requires
that the target region is at least as big as the source.

If we had a mechanism to report and test the migration version through
this migration API, using similar semantics to the sysfs interface,
what would we actually do with it?  The vendor driver's processing of
an incoming migration stream cannot rely on the user.  I initially
struggled with Kirti's use of "should" rather than "must" in describing
this checking, but I think that might actually be correct.  If a user
chooses to ignore the sysfs interface for compatibility testing, or
otherwise chooses to allow the data stream to be corrupted or
manipulated, I think the only requirement of the vendor driver is to
contain the damage to the user's device.  So, I think we're really
looking at whether it's a benefit to the user to be able to retrieve
the version and test it on the target through the migration API.  IOW,
is it sufficient for QEMU to presume that a well informed agent, that
has already tested the source and target device compatibility, has setup
this migration and that a well supported mdev vendor driver should fail
the migration gracefully if the versions are incompatible, or contain
the error within the user's device otherwise, or is there value to be
gained if QEMU performs a separate compatibility test?  Thanks,

Alex

Re: [PATCH] Fix erroneous double negation in conditional

[Eric Blake]

On 5/7/20 3:06 PM, Raphael Norwitz wrote:

In vhost_migration_log() there is the following check:
 if(!!enable == dev->log_enabled) {
 return 0;
 }

The double negative “!!” is unnecessary and bad coding style. This
change removes it.


!!int or !!ptr is not bad coding style - it is the shortest way to 
compare a non-bool against 0, and canonicalize the result back into bool 
(that is, convert all non-zero values into '1').  But !!bool is a waste 
of typing, since bool is already in the proper form.  Your patch as-is 
is incorrect; since the function declares 'int enable', this is using 
the !!int form which is not bad coding style.


On the other hand, looking at this function closer, we see that 
vhost_migration_log() is static, so all uses lie within this file.  And 
the callers are:


static void vhost_log_global_start(MemoryListener *listener)
r = vhost_migration_log(listener, true);
static void vhost_log_global_stop(MemoryListener *listener)
r = vhost_migration_log(listener, false);

and looking at struct vhost_dev, its log_enabled member is bool.

So the _real_ problem with this file is that it uses 'int enable' rather 
than 'bool enable'.  And once you fix the parameter type, then you are 
indeed correct that you would have a !!bool scenario worth cleaning up.


Looking forward to v2 along those lines.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

[PATCH] linux-user/arm: Reset CPSR_E when entering a signal handler

[Amanieu d'Antras]

This fixes signal handlers running with the wrong endianness if the
interrupted code used SETEND to dynamically switch endianness.

Signed-off-by: Amanieu d'Antras 
---
 linux-user/arm/signal.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/linux-user/arm/signal.c b/linux-user/arm/signal.c
index d96fc27ce1..8aca5f61b7 100644
--- a/linux-user/arm/signal.c
+++ b/linux-user/arm/signal.c
@@ -244,6 +244,12 @@ setup_return(CPUARMState *env, struct target_sigaction *ka,
 } else {
 cpsr &= ~CPSR_T;
 }
+cpsr &= ~CPSR_E;
+#ifdef TARGET_WORDS_BIGENDIAN
+if (env->cp15.sctlr_el[1] & SCTLR_E0E) {
+cpsr |= CPSR_E;
+}
+#endif
 
 if (ka->sa_flags & TARGET_SA_RESTORER) {
 if (is_fdpic) {
@@ -287,7 +293,8 @@ setup_return(CPUARMState *env, struct target_sigaction *ka,
 env->regs[13] = frame_addr;
 env->regs[14] = retcode;
 env->regs[15] = handler & (thumb ? ~1 : ~3);
-cpsr_write(env, cpsr, CPSR_IT | CPSR_T, CPSRWriteByInstr);
+cpsr_write(env, cpsr, CPSR_IT | CPSR_T | CPSR_E, CPSRWriteByInstr);
+arm_rebuild_hflags(env);
 
 return 0;
 }
-- 
2.26.2

Re: [RFC v4 0/6] hmp, qmp: Add some commands to introspect virtio devices

[no-reply]

Patchew URL: https://patchew.org/QEMU/20200507134800.10837-1-lviv...@redhat.com/



Hi,

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

Message-id: 20200507134800.10837-1-lviv...@redhat.com
Subject: [RFC v4 0/6] hmp,qmp: Add some commands to introspect virtio devices
Type: series

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

From https://github.com/patchew-project/qemu
   3c7adbc..1b8c458  master -> master
Switched to a new branch 'test'
e9975e2 hmp: add x-debug-virtio commands
5092215 qmp: add QMP command x-debug-virtio-queue-element
7572b3f qmp: add QMP command x-debug-virtio-queue-status
d7e8edc qmp: decode feature bits in virtio-status
ee6f64a qmp: add QMP command x-debug-virtio-status
09ea838 qmp: add QMP command x-debug-query-virtio

=== OUTPUT BEGIN ===
1/6 Checking commit 09ea838d52de (qmp: add QMP command x-debug-query-virtio)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#27: 
new file mode 100644

total: 0 errors, 1 warnings, 180 lines checked

Patch 1/6 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
2/6 Checking commit ee6f64a61066 (qmp: add QMP command x-debug-virtio-status)
3/6 Checking commit d7e8edc95598 (qmp: decode feature bits in virtio-status)
4/6 Checking commit 7572b3f9ba58 (qmp: add QMP command 
x-debug-virtio-queue-status)
5/6 Checking commit 50922154ae8c (qmp: add QMP command 
x-debug-virtio-queue-element)
6/6 Checking commit e9975e214541 (hmp: add x-debug-virtio commands)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#67: 
new file mode 100644

ERROR: spaces required around that '*' (ctx:WxV)
#346: FILE: hw/virtio/virtio.c:4097:
+type##FeatureList *list = features->device->u.field.data;  \
   ^

total: 1 errors, 1 warnings, 483 lines checked

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

=== OUTPUT END ===

Test command exited with code: 1


The full log is available at
http://patchew.org/logs/20200507134800.10837-1-lviv...@redhat.com/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

[PATCH] Fix erroneous double negation in conditional

[Raphael Norwitz]

In vhost_migration_log() there is the following check:
if(!!enable == dev->log_enabled) {
return 0;
}

The double negative “!!” is unnecessary and bad coding style. This
change removes it.

Signed-off-by: Raphael Norwitz 
---
 hw/virtio/vhost.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
index aff98a0..83be0c8 100644
--- a/hw/virtio/vhost.c
+++ b/hw/virtio/vhost.c
@@ -814,7 +814,7 @@ static int vhost_migration_log(MemoryListener
*listener, int enable)
 struct vhost_dev *dev = container_of(listener, struct vhost_dev,
  memory_listener);
 int r;
-if (!!enable == dev->log_enabled) {
+if (enable == dev->log_enabled) {
 return 0;
 }
 if (!dev->started) {
--
1.8.3.1

Re: [PATCH v2] Fix stack smashing when handling PR_GET_PDEATHSIG

[Laurent Vivier]

Le 07/05/2020 à 15:03, Stephen Long a écrit :
> The bug was triggered by the following code on aarch64-linux-user:
> 
> #include 
> #include 
> 
> int main(void)
> {
>   int PDeathSig = 0;
>   if (prctl(PR_GET_PDEATHSIG, ) == 0 && PDeathSig == SIGKILL)
> prctl(PR_GET_PDEATHSIG, 0);
>   return (PDeathSig == SIGKILL);
> }
> 
> Signed-off-by: Stephen Long 
> Signed-off-by: Ana Pazos 
> ---
> 
> I fixed the incorrect subject line. PR_GETDEATHSIG should be PR_GET_PDEATHSIG.
> Is there a test folder where I can include the code that triggered the bug?

Perhaps Alex Bennée knows?

> Also, I thought "int" can be 2 bytes on some machines.

According to my K, 4th edition, it could be on 16bit systems, like
PDP-11, but we don't support them ;)

Reviewed-by: Laurent Vivier 

> 
>  linux-user/syscall.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
> index 05f03919ff..91f91147ba 100644
> --- a/linux-user/syscall.c
> +++ b/linux-user/syscall.c
> @@ -10256,7 +10256,7 @@ static abi_long do_syscall1(void *cpu_env, int num, 
> abi_long arg1,
>  int deathsig;
>  ret = get_errno(prctl(arg1, , arg3, arg4, arg5));
>  if (!is_error(ret) && arg2
> -&& put_user_ual(deathsig, arg2)) {
> +&& put_user_s32(deathsig, arg2)) {
>  return -TARGET_EFAULT;
>  }
>  return ret;
> 

Re: [PATCH 3/5] virtio-iommu: Handle reserved regions in the translation process

[Peter Xu]

Hi, Eric,

On Thu, May 07, 2020 at 04:31:59PM +0200, Eric Auger wrote:
> @@ -640,6 +641,24 @@ static IOMMUTLBEntry 
> virtio_iommu_translate(IOMMUMemoryRegion *mr, hwaddr addr,
>  goto unlock;
>  }
>  
> +for (i = 0; i < s->nb_reserved_regions; i++) {
> +if (interval.low >= s->reserved_regions[i].low &&
> +interval.low <= s->reserved_regions[i].high) {

Should this be s/low/high/?

For this case (high==low+1) I guess maybe it's also easier to use "addr >= low
&& addr < high".

Thanks,

> +switch (s->reserved_regions[i].type) {
> +case VIRTIO_IOMMU_RESV_MEM_T_MSI:
> +entry.perm = flag;
> +break;
> +case VIRTIO_IOMMU_RESV_MEM_T_RESERVED:
> +default:
> +virtio_iommu_report_fault(s, VIRTIO_IOMMU_FAULT_R_MAPPING,
> +  VIRTIO_IOMMU_FAULT_F_ADDRESS,
> +  sid, addr);
> +break;
> +}
> +goto unlock;
> +}
> +}
> +
>  if (!ep->domain) {
>  if (!bypass_allowed) {
>  error_report_once("%s %02x:%02x.%01x not attached to any domain",
> -- 
> 2.20.1
> 

-- 
Peter Xu

Re: [PATCH 2/5] virtio-iommu: Implement RESV_MEM probe request

[Peter Xu]

Hi, Eric,

On Thu, May 07, 2020 at 04:31:58PM +0200, Eric Auger wrote:

[...]

> @@ -452,17 +520,33 @@ static void virtio_iommu_handle_command(VirtIODevice 
> *vdev, VirtQueue *vq)
>  case VIRTIO_IOMMU_T_UNMAP:
>  tail.status = virtio_iommu_handle_unmap(s, iov, iov_cnt);
>  break;
> +case VIRTIO_IOMMU_T_PROBE:
> +{
> +struct virtio_iommu_req_tail *ptail;
> +uint8_t *buf = g_malloc0(s->config.probe_size + sizeof(tail));
> +
> +ptail = (struct virtio_iommu_req_tail *)
> +(buf + s->config.probe_size);
> +ptail->status = virtio_iommu_handle_probe(s, iov, iov_cnt, buf);
> +
> +sz = iov_from_buf(elem->in_sg, elem->in_num, 0,
> +  buf, s->config.probe_size + sizeof(tail));
> +g_free(buf);
> +assert(sz == s->config.probe_size + sizeof(tail));
> +goto push;
> +}
>  default:
>  tail.status = VIRTIO_IOMMU_S_UNSUPP;
>  }
> -qemu_mutex_unlock(>mutex);
>  
>  out:
>  sz = iov_from_buf(elem->in_sg, elem->in_num, 0,
>, sizeof(tail));
>  assert(sz == sizeof(tail));
>  
> -virtqueue_push(vq, elem, sizeof(tail));
> +push:
> +qemu_mutex_unlock(>mutex);

I think we can't move this unlock to here because otherwise "goto out" could
potentially try to unlock it without locked first.  Thanks,

> +virtqueue_push(vq, elem, sz);
>  virtio_notify(vdev, vq);
>  g_free(elem);
>  }

-- 
Peter Xu

Re: backing chain & block status & filters

[Vladimir Sementsov-Ogievskiy]

07.05.2020 15:58, Max Reitz wrote:

On 28.04.20 16:51, Vladimir Sementsov-Ogievskiy wrote:

28.04.2020 14:08, Max Reitz wrote:

On 28.04.20 10:55, Vladimir Sementsov-Ogievskiy wrote:

Hi!

I wanted to resend my "[PATCH 0/4] fix & merge block_status_above and
is_allocated_above", and returned to all the inconsistencies about
block-status. I keep in mind Max's series about child-access functions,
and Andrey's work about using COR filter in block-stream, which depends
on Max's series (because, without them COR fitler with file child breaks
backing chains).. And, it seems that it's better to discuss some
questions before resending.

First, problems about block-status:

1. We consider ALLOCATED = ZERO | DATA, and documented as follows:

     * BDRV_BLOCK_DATA: allocation for data at offset is tied to this
layer
     * BDRV_BLOCK_ZERO: offset reads as zero
     * BDRV_BLOCK_OFFSET_VALID: an associated offset exists for accessing
raw data
     * BDRV_BLOCK_ALLOCATED: the content of the block is determined by
this
     *   layer rather than any backing, set by block
layer

This actually means, that we should always have BDRV_BLOCK_ALLOCATED for
formats which doesn't support backing. So, all such format drivers must
return ZERO or DATA (or both?), yes?. Seems file-posix does so, but, for
example, iscsi - doesn't.


Hm.  I could imagine that there are formats that have non-zero holes
(e.g. 0xff or just garbage).  It would be a bit wrong for them to return
ZERO or DATA then.

But OTOH we don’t care about such cases, do we?  We need to know whether
ranges are zero, data, or unallocated.  If they aren’t zero, we only
care about whether reading from it will return data from this layer or
not.

So I suppose that anything that doesn’t support backing files (or
filtered children) should always return ZERO and/or DATA.


2. ZERO. The meaning differs a bit for generic block_status and for
drivers.. I think, we at least should document it like this:

BDRV_BLOCK_DATA: allocation for data at offset is tied to this layer
BDRV_BLOCK_ZERO: if driver return ZERO, than the region is allocated at
this layer and read as ZERO. If generic block_status returns ZERO, it
only mean that it reads as zero, but the region may be allocated on
underlying level.


Hm.  What does that mean?

One of the problems is that “allocated” has two meanings:
(1) reading data returns data defined at this backing layer,
(2) actually allocated, i.e. takes up space on the file represented by
this BDS.

As far as I understand, we actually don’t care about (2) in the context
of block_status, but just about (1).

So if a layer returns ZERO, it is by definition (1)-allocated.  (It
isn’t necessarily (2)-allocated.)


3. bdi.unallocated_blocks_are_zero

I think it's very bad, that we have formats, that supports backing, but
doesn't report bdi.unallocated_blocks_are_zero as true. It means that
UNALLOCATED region reads as zero if we have short backing file, and not
as zero if we remove this short backing file.


What do you mean by “remove this short backing file”?  Because generally
one can’t just drop a backing file.

So maybe a case like block-stream?  Wouldn’t that be a bug in
block-stream them, i.e. shouldn’t it stream zeros after the end of the
backing file?


I can live with it but
this is weird logic. These bad drivers are qcow (not qcow2), parallels
and vmdk. I hope, they actually just forget to set
unallocated_blocks_are_zero to true.


qcow definitely sounds like it.


Next. But what about drivers which doesn't support backing? As we
considered above, they should always return ZERO or DATA, as everything
is allocated in this backing-chain level (last level, of course).. So
again unallocated_blocks_are_zero is meaningless. So, I think, that
driver which doesn't support backings, should be fixed to return always
ZERO or DATA, than we don't need this unallocated_blocks_are_zero at
all.


Agreed.


3.


The second 3.? :)


Short backing files in allocated_above: we must consider space after
EOF as ALLOCATED, if short backing file is inside requested
backing-chain part, as it produced exactly because of this short file
(and we never go to backing).


Sounds correct.


(current realization of allocated_above is
buggy, see my outdated series "[PATCH 0/4] fix & merge
block_status_above and is_allocated_above")

4. Long ago we've discussed problems about BDRV_BLOCK_RAW, when we have
a backing chain of non-backing child.. I just remember that we didn't
reach the consensus.


Possible? :)


5. Filters.. OK we have two functions for them:
bdrv_co_block_status_from_file and bdrv_co_block_status_from_backing. I
think both are wrong:

bdrv_co_block_status_from_file leads to problem [4], when we can report
UNALLOCATED, which refers not to the current backing chain, but to sub
backing chain of file child, which is inconsistent with
block_status_above and is_allocated_above iteration.

bdrv_co_block_status_from_backing is also is not consistent with

[PATCH v2 9/9] target/riscv: Use a smaller guess size for no-MMU PMP

[Alistair Francis]

Signed-off-by: Alistair Francis 
---
 target/riscv/pmp.c | 19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/target/riscv/pmp.c b/target/riscv/pmp.c
index 0e6b640fbd..5aba4d13ea 100644
--- a/target/riscv/pmp.c
+++ b/target/riscv/pmp.c
@@ -233,12 +233,21 @@ bool pmp_hart_has_privs(CPURISCVState *env, target_ulong 
addr,
 return true;
 }
 
-/*
- * if size is unknown (0), assume that all bytes
- * from addr to the end of the page will be accessed.
- */
 if (size == 0) {
-pmp_size = -(addr | TARGET_PAGE_MASK);
+if (!riscv_feature(env, RISCV_FEATURE_MMU)) {
+/*
+ * if size is unknown (0), assume that all bytes
+ * from addr to the end of the page will be accessed.
+ */
+pmp_size = -(addr | TARGET_PAGE_MASK);
+} else {
+/*
+ * If size is unknown (0) and we don't have an MMU,
+ * just guess the size as the xlen as we don't want to
+ * access an entire page worth.
+ */
+pmp_size = sizeof(target_ulong);
+}
 } else {
 pmp_size = size;
 }
-- 
2.26.2

[PATCH v2 6/9] hw/intc: Initial commit of lowRISC Ibex PLIC

[Alistair Francis]

The Ibex core contains a PLIC that although similar to the RISC-V spec
is not RISC-V spec compliant.

This patch implements a Ibex PLIC in a somewhat generic way.

As the current RISC-V PLIC needs tidying up, my hope is that as the Ibex
PLIC move towards spec compliance this PLIC implementation can be
updated until it can replace the current PLIC.

Signed-off-by: Alistair Francis 
---
 MAINTAINERS |   2 +
 hw/intc/Makefile.objs   |   1 +
 hw/intc/ibex_plic.c | 261 
 include/hw/intc/ibex_plic.h |  63 +
 4 files changed, 327 insertions(+)
 create mode 100644 hw/intc/ibex_plic.c
 create mode 100644 include/hw/intc/ibex_plic.h

diff --git a/MAINTAINERS b/MAINTAINERS
index d3d47564ce..f8c3cf6182 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1237,8 +1237,10 @@ L: qemu-ri...@nongnu.org
 S: Supported
 F: hw/riscv/opentitan.c
 F: hw/char/ibex_uart.c
+F: hw/intc/ibex_plic.c
 F: include/hw/riscv/opentitan.h
 F: include/hw/char/ibex_uart.h
+F: include/hw/intc/ibex_plic.h
 
 
 SH4 Machines
diff --git a/hw/intc/Makefile.objs b/hw/intc/Makefile.objs
index f726d87532..a61e6728fe 100644
--- a/hw/intc/Makefile.objs
+++ b/hw/intc/Makefile.objs
@@ -49,3 +49,4 @@ obj-$(CONFIG_ARM_GIC) += arm_gicv3_cpuif.o
 obj-$(CONFIG_MIPS_CPS) += mips_gic.o
 obj-$(CONFIG_NIOS2) += nios2_iic.o
 obj-$(CONFIG_OMPIC) += ompic.o
+obj-$(CONFIG_IBEX) += ibex_plic.o
diff --git a/hw/intc/ibex_plic.c b/hw/intc/ibex_plic.c
new file mode 100644
index 00..35c52d9d16
--- /dev/null
+++ b/hw/intc/ibex_plic.c
@@ -0,0 +1,261 @@
+/*
+ * QEMU RISC-V lowRISC Ibex PLIC
+ *
+ * Copyright (c) 2020 Western Digital
+ *
+ * Documentation avaliable: https://docs.opentitan.org/hw/ip/rv_plic/doc/
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2 or later, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/log.h"
+#include "hw/qdev-properties.h"
+#include "hw/core/cpu.h"
+#include "hw/boards.h"
+#include "hw/pci/msi.h"
+#include "target/riscv/cpu_bits.h"
+#include "target/riscv/cpu.h"
+#include "hw/intc/ibex_plic.h"
+
+static bool addr_between(uint32_t addr, uint32_t base, uint32_t num)
+{
+uint32_t end = base + (num * 0x04);
+
+if (addr >= base && addr < end) {
+return true;
+}
+
+return false;
+}
+
+static void ibex_plic_irqs_set_pending(IbexPlicState *s, int irq, bool level)
+{
+int pending_num = irq / 32;
+
+s->pending[pending_num] |= level << (irq % 32);
+}
+
+static bool ibex_plic_irqs_pending(IbexPlicState *s, uint32_t context)
+{
+int i;
+
+for (i = 0; i < s->pending_num; i++) {
+uint32_t irq_num = ctz64(s->pending[i]) + (i * 32);
+
+if (!(s->pending[i] & s->enable[i])) {
+/* No pending and enabled IRQ */
+continue;
+}
+
+if (s->priority[irq_num] > s->threshold) {
+if (!s->claim) {
+s->claim = irq_num;
+}
+return true;
+}
+}
+
+return 0;
+}
+
+static void ibex_plic_update(IbexPlicState *s)
+{
+CPUState *cpu;
+int level, i;
+
+for (i = 0; i < s->num_cpus; i++) {
+cpu = qemu_get_cpu(i);
+
+if (!cpu) {
+continue;
+}
+
+level = ibex_plic_irqs_pending(s, 0);
+
+riscv_cpu_update_mip(RISCV_CPU(cpu), MIP_MEIP, BOOL_TO_MASK(level));
+}
+}
+
+static void ibex_plic_reset(DeviceState *dev)
+{
+IbexPlicState *s = IBEX_PLIC(dev);
+
+s->threshold = 0x;
+s->claim = 0x;
+}
+
+static uint64_t ibex_plic_read(void *opaque, hwaddr addr,
+   unsigned int size)
+{
+IbexPlicState *s = opaque;
+int offset;
+uint32_t ret = 0;
+
+if (addr_between(addr, s->pending_base, s->pending_num)) {
+offset = (addr - s->pending_base) / 4;
+ret = s->pending[offset];
+} else if (addr_between(addr, s->source_base, s->source_num)) {
+qemu_log_mask(LOG_UNIMP,
+  "%s: Interrupt source mode not supported\n", __func__);
+} else if (addr_between(addr, s->priority_base, s->priority_num)) {
+offset = (addr - s->priority_base) / 4;
+ret = s->priority[offset];
+} else if (addr_between(addr, s->enable_base, s->enable_num)) {
+offset = (addr - s->enable_base) / 4;
+ret = s->enable[offset];
+} else if (addr_between(addr, s->threshold_base, 1)) {
+ret = s->threshold;
+} else if 

[PATCH v2 4/9] riscv: Initial commit of OpenTitan machine

[Alistair Francis]

This adds a barebone OpenTitan machine to QEMU.

Signed-off-by: Alistair Francis 
---
 MAINTAINERS |  10 ++
 default-configs/riscv32-softmmu.mak |   1 +
 default-configs/riscv64-softmmu.mak |  11 +-
 hw/riscv/Kconfig|   5 +
 hw/riscv/Makefile.objs  |   1 +
 hw/riscv/opentitan.c| 169 
 include/hw/riscv/opentitan.h|  63 +++
 7 files changed, 259 insertions(+), 1 deletion(-)
 create mode 100644 hw/riscv/opentitan.c
 create mode 100644 include/hw/riscv/opentitan.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 1f84e3ae2c..c3d77f0861 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1229,6 +1229,16 @@ F: pc-bios/canyonlands.dt[sb]
 F: pc-bios/u-boot-sam460ex-20100605.bin
 F: roms/u-boot-sam460ex
 
+RISC-V Machines
+-
+OpenTitan
+M: Alistair Francis 
+L: qemu-ri...@nongnu.org
+S: Supported
+F: hw/riscv/opentitan.c
+F: include/hw/riscv/opentitan.h
+
+
 SH4 Machines
 
 R2D
diff --git a/default-configs/riscv32-softmmu.mak 
b/default-configs/riscv32-softmmu.mak
index 1ae077ed87..94a236c9c2 100644
--- a/default-configs/riscv32-softmmu.mak
+++ b/default-configs/riscv32-softmmu.mak
@@ -10,3 +10,4 @@ CONFIG_SPIKE=y
 CONFIG_SIFIVE_E=y
 CONFIG_SIFIVE_U=y
 CONFIG_RISCV_VIRT=y
+CONFIG_OPENTITAN=y
diff --git a/default-configs/riscv64-softmmu.mak 
b/default-configs/riscv64-softmmu.mak
index 235c6f473f..aaf6d735bb 100644
--- a/default-configs/riscv64-softmmu.mak
+++ b/default-configs/riscv64-softmmu.mak
@@ -1,3 +1,12 @@
 # Default configuration for riscv64-softmmu
 
-include riscv32-softmmu.mak
+# Uncomment the following lines to disable these optional devices:
+#
+#CONFIG_PCI_DEVICES=n
+
+# Boards:
+#
+CONFIG_SPIKE=y
+CONFIG_SIFIVE_E=y
+CONFIG_SIFIVE_U=y
+CONFIG_RISCV_VIRT=y
diff --git a/hw/riscv/Kconfig b/hw/riscv/Kconfig
index ff9fbe958a..94d19571f7 100644
--- a/hw/riscv/Kconfig
+++ b/hw/riscv/Kconfig
@@ -27,6 +27,11 @@ config SPIKE
 select HTIF
 select SIFIVE
 
+config OPENTITAN
+bool
+select HART
+select UNIMP
+
 config RISCV_VIRT
 bool
 imply PCI_DEVICES
diff --git a/hw/riscv/Makefile.objs b/hw/riscv/Makefile.objs
index fc3c6dd7c8..57cc708f5d 100644
--- a/hw/riscv/Makefile.objs
+++ b/hw/riscv/Makefile.objs
@@ -1,6 +1,7 @@
 obj-y += boot.o
 obj-$(CONFIG_SPIKE) += riscv_htif.o
 obj-$(CONFIG_HART) += riscv_hart.o
+obj-$(CONFIG_OPENTITAN) += opentitan.o
 obj-$(CONFIG_SIFIVE_E) += sifive_e.o
 obj-$(CONFIG_SIFIVE_E) += sifive_e_prci.o
 obj-$(CONFIG_SIFIVE) += sifive_clint.o
diff --git a/hw/riscv/opentitan.c b/hw/riscv/opentitan.c
new file mode 100644
index 00..c00f0720ab
--- /dev/null
+++ b/hw/riscv/opentitan.c
@@ -0,0 +1,169 @@
+/*
+ * QEMU RISC-V Board Compatible with OpenTitan FPGA platform
+ *
+ * Copyright (c) 2020 Western Digital
+ *
+ * Provides a board compatible with the OpenTitan FPGA platform:
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2 or later, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include "qemu/osdep.h"
+#include "hw/riscv/opentitan.h"
+#include "qapi/error.h"
+#include "hw/boards.h"
+#include "hw/misc/unimp.h"
+#include "hw/riscv/boot.h"
+#include "exec/address-spaces.h"
+
+static const struct MemmapEntry {
+hwaddr base;
+hwaddr size;
+} ibex_memmap[] = {
+[IBEX_ROM] ={  0x8000,   0xc000 },
+[IBEX_RAM] ={  0x1000,  0x1 },
+[IBEX_FLASH] =  {  0x2000,  0x8 },
+[IBEX_UART] =   {  0x4000,  0x1 },
+[IBEX_GPIO] =   {  0x4001,  0x1 },
+[IBEX_SPI] ={  0x4002,  0x1 },
+[IBEX_FLASH_CTRL] = {  0x4003,  0x1 },
+[IBEX_PINMUX] = {  0x4007,  0x1 },
+[IBEX_RV_TIMER] =   {  0x4008,  0x1 },
+[IBEX_PLIC] =   {  0x4009,  0x1 },
+[IBEX_AES] ={  0x4011,  0x1 },
+[IBEX_HMAC] =   {  0x4012,  0x1 },
+[IBEX_ALERT_HANDLER] =  {  0x4013,  0x1 },
+[IBEX_USBDEV] = {  0x4015,  0x1 }
+};
+
+static void riscv_opentitan_init(MachineState *machine)
+{
+const struct MemmapEntry *memmap = ibex_memmap;
+OpenTitanState *s = g_new0(OpenTitanState, 1);
+MemoryRegion *sys_mem = get_system_memory();
+MemoryRegion *main_mem = g_new(MemoryRegion, 1);
+
+/* Initialize SoC */
+object_initialize_child(OBJECT(machine), "soc", >soc,
+

[PATCH v2 5/9] hw/char: Initial commit of Ibex UART

[Alistair Francis]

This is the initial commit of the Ibex UART device. Serial TX is
working, while RX has been implemeneted but untested.

This is based on the documentation from:
https://docs.opentitan.org/hw/ip/uart/doc/

Signed-off-by: Alistair Francis 
---
 MAINTAINERS |   2 +
 hw/char/Makefile.objs   |   1 +
 hw/char/ibex_uart.c | 490 
 hw/riscv/Kconfig|   4 +
 include/hw/char/ibex_uart.h | 110 
 5 files changed, 607 insertions(+)
 create mode 100644 hw/char/ibex_uart.c
 create mode 100644 include/hw/char/ibex_uart.h

diff --git a/MAINTAINERS b/MAINTAINERS
index c3d77f0861..d3d47564ce 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1236,7 +1236,9 @@ M: Alistair Francis 
 L: qemu-ri...@nongnu.org
 S: Supported
 F: hw/riscv/opentitan.c
+F: hw/char/ibex_uart.c
 F: include/hw/riscv/opentitan.h
+F: include/hw/char/ibex_uart.h
 
 
 SH4 Machines
diff --git a/hw/char/Makefile.objs b/hw/char/Makefile.objs
index 9e9a6c1aff..633996be5b 100644
--- a/hw/char/Makefile.objs
+++ b/hw/char/Makefile.objs
@@ -12,6 +12,7 @@ common-obj-$(CONFIG_VIRTIO_SERIAL) += virtio-console.o
 common-obj-$(CONFIG_XILINX) += xilinx_uartlite.o
 common-obj-$(CONFIG_XEN) += xen_console.o
 common-obj-$(CONFIG_CADENCE) += cadence_uart.o
+common-obj-$(CONFIG_IBEX) += ibex_uart.o
 
 common-obj-$(CONFIG_EXYNOS4) += exynos4210_uart.o
 common-obj-$(CONFIG_COLDFIRE) += mcf_uart.o
diff --git a/hw/char/ibex_uart.c b/hw/char/ibex_uart.c
new file mode 100644
index 00..f6215ae23d
--- /dev/null
+++ b/hw/char/ibex_uart.c
@@ -0,0 +1,490 @@
+/*
+ * QEMU lowRISC Ibex UART device
+ *
+ * Copyright (c) 2020 Western Digital
+ *
+ * For details check the documentation here:
+ *https://docs.opentitan.org/hw/ip/uart/doc/
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include "qemu/osdep.h"
+#include "hw/char/ibex_uart.h"
+#include "hw/irq.h"
+#include "hw/qdev-properties.h"
+#include "migration/vmstate.h"
+#include "qemu/log.h"
+#include "qemu/module.h"
+
+static void ibex_uart_update_irqs(IbexUartState *s)
+{
+if (s->uart_intr_state & s->uart_intr_enable & INTR_STATE_TX_WATERMARK) {
+qemu_set_irq(s->tx_watermark, 1);
+} else {
+qemu_set_irq(s->tx_watermark, 0);
+}
+
+if (s->uart_intr_state & s->uart_intr_enable & INTR_STATE_RX_WATERMARK) {
+qemu_set_irq(s->rx_watermark, 1);
+} else {
+qemu_set_irq(s->rx_watermark, 0);
+}
+
+if (s->uart_intr_state & s->uart_intr_enable & INTR_STATE_TX_EMPTY) {
+qemu_set_irq(s->tx_empty, 1);
+} else {
+qemu_set_irq(s->tx_empty, 0);
+}
+
+if (s->uart_intr_state & s->uart_intr_enable & INTR_STATE_RX_OVERFLOW) {
+qemu_set_irq(s->rx_overflow, 1);
+} else {
+qemu_set_irq(s->rx_overflow, 0);
+}
+}
+
+static int ibex_uart_can_receive(void *opaque)
+{
+IbexUartState *s = opaque;
+
+if (s->uart_ctrl & UART_CTRL_RX_ENABLE) {
+return 1;
+}
+
+return 0;
+}
+
+static void ibex_uart_receive(void *opaque, const uint8_t *buf, int size)
+{
+IbexUartState *s = opaque;
+uint8_t rx_fifo_level = (s->uart_fifo_ctrl & FIFO_CTRL_RXILVL)
+>> FIFO_CTRL_RXILVL_SHIFT;
+
+s->uart_rdata = *buf;
+
+s->uart_status &= ~UART_STATUS_RXIDLE;
+s->uart_status &= ~UART_STATUS_RXEMPTY;
+
+if (size > rx_fifo_level) {
+s->uart_intr_state |= INTR_STATE_RX_WATERMARK;
+}
+
+ibex_uart_update_irqs(s);
+}
+
+static gboolean ibex_uart_xmit(GIOChannel *chan, GIOCondition cond,
+   void *opaque)
+{
+IbexUartState *s = opaque;
+uint8_t tx_fifo_level = (s->uart_fifo_ctrl & FIFO_CTRL_TXILVL)
+>> FIFO_CTRL_TXILVL_SHIFT;
+int ret;
+
+/* instant drain the fifo when there's no back-end */
+if (!qemu_chr_fe_backend_connected(>chr)) {
+s->tx_level = 0;
+return FALSE;
+}
+
+if 

[PATCH v2 2/9] target/riscv: Don't overwrite the reset vector

[Alistair Francis]

If the reset vector is set in the init function don't set it again in
realise.

Signed-off-by: Alistair Francis 
---
 target/riscv/cpu.c | 20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 059d71f2c7..8f837edf8d 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -111,6 +111,14 @@ static void set_feature(CPURISCVState *env, int feature)
 env->features |= (1ULL << feature);
 }
 
+static int get_resetvec(CPURISCVState *env)
+{
+#ifndef CONFIG_USER_ONLY
+return env->resetvec;
+#endif
+return 0;
+}
+
 static void set_resetvec(CPURISCVState *env, int resetvec)
 {
 #ifndef CONFIG_USER_ONLY
@@ -123,7 +131,6 @@ static void riscv_any_cpu_init(Object *obj)
 CPURISCVState *env = _CPU(obj)->env;
 set_misa(env, RVXLEN | RVI | RVM | RVA | RVF | RVD | RVC | RVU);
 set_priv_version(env, PRIV_VERSION_1_11_0);
-set_resetvec(env, DEFAULT_RSTVEC);
 }
 
 #if defined(TARGET_RISCV32)
@@ -140,7 +147,6 @@ static void rv32gcsu_priv1_09_1_cpu_init(Object *obj)
 CPURISCVState *env = _CPU(obj)->env;
 set_misa(env, RV32 | RVI | RVM | RVA | RVF | RVD | RVC | RVS | RVU);
 set_priv_version(env, PRIV_VERSION_1_09_1);
-set_resetvec(env, DEFAULT_RSTVEC);
 set_feature(env, RISCV_FEATURE_MMU);
 set_feature(env, RISCV_FEATURE_PMP);
 }
@@ -150,7 +156,6 @@ static void rv32gcsu_priv1_10_0_cpu_init(Object *obj)
 CPURISCVState *env = _CPU(obj)->env;
 set_misa(env, RV32 | RVI | RVM | RVA | RVF | RVD | RVC | RVS | RVU);
 set_priv_version(env, PRIV_VERSION_1_10_0);
-set_resetvec(env, DEFAULT_RSTVEC);
 set_feature(env, RISCV_FEATURE_MMU);
 set_feature(env, RISCV_FEATURE_PMP);
 }
@@ -160,7 +165,6 @@ static void rv32imacu_nommu_cpu_init(Object *obj)
 CPURISCVState *env = _CPU(obj)->env;
 set_misa(env, RV32 | RVI | RVM | RVA | RVC | RVU);
 set_priv_version(env, PRIV_VERSION_1_10_0);
-set_resetvec(env, DEFAULT_RSTVEC);
 set_feature(env, RISCV_FEATURE_PMP);
 }
 
@@ -169,7 +173,6 @@ static void rv32imafcu_nommu_cpu_init(Object *obj)
 CPURISCVState *env = _CPU(obj)->env;
 set_misa(env, RV32 | RVI | RVM | RVA | RVF | RVC | RVU);
 set_priv_version(env, PRIV_VERSION_1_10_0);
-set_resetvec(env, DEFAULT_RSTVEC);
 set_feature(env, RISCV_FEATURE_PMP);
 }
 
@@ -187,7 +190,6 @@ static void rv64gcsu_priv1_09_1_cpu_init(Object *obj)
 CPURISCVState *env = _CPU(obj)->env;
 set_misa(env, RV64 | RVI | RVM | RVA | RVF | RVD | RVC | RVS | RVU);
 set_priv_version(env, PRIV_VERSION_1_09_1);
-set_resetvec(env, DEFAULT_RSTVEC);
 set_feature(env, RISCV_FEATURE_MMU);
 set_feature(env, RISCV_FEATURE_PMP);
 }
@@ -197,7 +199,6 @@ static void rv64gcsu_priv1_10_0_cpu_init(Object *obj)
 CPURISCVState *env = _CPU(obj)->env;
 set_misa(env, RV64 | RVI | RVM | RVA | RVF | RVD | RVC | RVS | RVU);
 set_priv_version(env, PRIV_VERSION_1_10_0);
-set_resetvec(env, DEFAULT_RSTVEC);
 set_feature(env, RISCV_FEATURE_MMU);
 set_feature(env, RISCV_FEATURE_PMP);
 }
@@ -207,7 +208,6 @@ static void rv64imacu_nommu_cpu_init(Object *obj)
 CPURISCVState *env = _CPU(obj)->env;
 set_misa(env, RV64 | RVI | RVM | RVA | RVC | RVU);
 set_priv_version(env, PRIV_VERSION_1_10_0);
-set_resetvec(env, DEFAULT_RSTVEC);
 set_feature(env, RISCV_FEATURE_PMP);
 }
 
@@ -399,7 +399,9 @@ static void riscv_cpu_realize(DeviceState *dev, Error 
**errp)
 }
 
 set_priv_version(env, priv_version);
-set_resetvec(env, DEFAULT_RSTVEC);
+if (!get_resetvec(env)) {
+set_resetvec(env, DEFAULT_RSTVEC);
+}
 
 if (cpu->cfg.mmu) {
 set_feature(env, RISCV_FEATURE_MMU);
-- 
2.26.2

[PATCH v2 1/9] riscv/boot: Add a missing header include

[Alistair Francis]

Signed-off-by: Alistair Francis 
---
 include/hw/riscv/boot.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/hw/riscv/boot.h b/include/hw/riscv/boot.h
index 474a940ad5..9daa98da08 100644
--- a/include/hw/riscv/boot.h
+++ b/include/hw/riscv/boot.h
@@ -21,6 +21,7 @@
 #define RISCV_BOOT_H
 
 #include "exec/cpu-defs.h"
+#include "hw/loader.h"
 
 void riscv_find_and_load_firmware(MachineState *machine,
   const char *default_machine_firmware,
-- 
2.26.2

[PATCH v2 8/9] riscv/opentitan: Connect the UART device

[Alistair Francis]

Signed-off-by: Alistair Francis 
---
 hw/riscv/opentitan.c | 24 ++--
 include/hw/riscv/opentitan.h | 13 +
 2 files changed, 35 insertions(+), 2 deletions(-)

diff --git a/hw/riscv/opentitan.c b/hw/riscv/opentitan.c
index 3926321d8c..a6c0b949ca 100644
--- a/hw/riscv/opentitan.c
+++ b/hw/riscv/opentitan.c
@@ -96,6 +96,9 @@ static void riscv_lowrisc_ibex_soc_init(Object *obj)
 
 sysbus_init_child_obj(obj, "plic", >plic,
   sizeof(s->plic), TYPE_IBEX_PLIC);
+
+sysbus_init_child_obj(obj, "uart", >uart,
+  sizeof(s->uart), TYPE_IBEX_UART);
 }
 
 static void riscv_lowrisc_ibex_soc_realize(DeviceState *dev_soc, Error **errp)
@@ -137,8 +140,25 @@ static void riscv_lowrisc_ibex_soc_realize(DeviceState 
*dev_soc, Error **errp)
 busdev = SYS_BUS_DEVICE(dev);
 sysbus_mmio_map(busdev, 0, memmap[IBEX_PLIC].base);
 
-create_unimplemented_device("riscv.lowrisc.ibex.uart",
-memmap[IBEX_UART].base, memmap[IBEX_UART].size);
+/* UART */
+dev = DEVICE(&(s->uart));
+qdev_prop_set_chr(dev, "chardev", serial_hd(0));
+object_property_set_bool(OBJECT(>uart), true, "realized", );
+if (err != NULL) {
+error_propagate(errp, err);
+return;
+}
+busdev = SYS_BUS_DEVICE(dev);
+sysbus_mmio_map(busdev, 0, memmap[IBEX_UART].base);
+sysbus_connect_irq(busdev, 0, qdev_get_gpio_in(DEVICE(>plic),
+   IBEX_UART_TX_WATERMARK_IRQ));
+sysbus_connect_irq(busdev, 1, qdev_get_gpio_in(DEVICE(>plic),
+   IBEX_UART_RX_WATERMARK_IRQ));
+sysbus_connect_irq(busdev, 2, qdev_get_gpio_in(DEVICE(>plic),
+   IBEX_UART_TX_EMPTY_IRQ));
+sysbus_connect_irq(busdev, 3, qdev_get_gpio_in(DEVICE(>plic),
+   IBEX_UART_RX_OVERFLOW_IRQ));
+
 create_unimplemented_device("riscv.lowrisc.ibex.gpio",
 memmap[IBEX_GPIO].base, memmap[IBEX_GPIO].size);
 create_unimplemented_device("riscv.lowrisc.ibex.spi",
diff --git a/include/hw/riscv/opentitan.h b/include/hw/riscv/opentitan.h
index 8d6a09b696..825a3610bc 100644
--- a/include/hw/riscv/opentitan.h
+++ b/include/hw/riscv/opentitan.h
@@ -21,6 +21,7 @@
 
 #include "hw/riscv/riscv_hart.h"
 #include "hw/intc/ibex_plic.h"
+#include "hw/char/ibex_uart.h"
 
 #define TYPE_RISCV_IBEX_SOC "riscv.lowrisc.ibex.soc"
 #define RISCV_IBEX_SOC(obj) \
@@ -33,6 +34,7 @@ typedef struct LowRISCIbexSoCState {
 /*< public >*/
 RISCVHartArrayState cpus;
 IbexPlicState plic;
+IbexUartState uart;
 
 MemoryRegion flash_mem;
 MemoryRegion rom;
@@ -63,4 +65,15 @@ enum {
 IBEX_USBDEV,
 };
 
+enum {
+IBEX_UART_RX_PARITY_ERR_IRQ = 0x28,
+IBEX_UART_RX_TIMEOUT_IRQ = 0x27,
+IBEX_UART_RX_BREAK_ERR_IRQ = 0x26,
+IBEX_UART_RX_FRAME_ERR_IRQ = 0x25,
+IBEX_UART_RX_OVERFLOW_IRQ = 0x24,
+IBEX_UART_TX_EMPTY_IRQ = 0x23,
+IBEX_UART_RX_WATERMARK_IRQ = 0x22,
+IBEX_UART_TX_WATERMARK_IRQ = 0x21
+};
+
 #endif
-- 
2.26.2

[PATCH v2 3/9] target/riscv: Add the lowRISC Ibex CPU

[Alistair Francis]

Signed-off-by: Alistair Francis 
---
 target/riscv/cpu.c | 10 ++
 target/riscv/cpu.h |  1 +
 2 files changed, 11 insertions(+)

diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 8f837edf8d..235101f685 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -160,6 +160,15 @@ static void rv32gcsu_priv1_10_0_cpu_init(Object *obj)
 set_feature(env, RISCV_FEATURE_PMP);
 }
 
+static void rv32imcu_nommu_cpu_init(Object *obj)
+{
+CPURISCVState *env = _CPU(obj)->env;
+set_misa(env, RV32 | RVI | RVM | RVC | RVU);
+set_priv_version(env, PRIV_VERSION_1_10_0);
+set_resetvec(env, 0x8088);
+set_feature(env, RISCV_FEATURE_PMP);
+}
+
 static void rv32imacu_nommu_cpu_init(Object *obj)
 {
 CPURISCVState *env = _CPU(obj)->env;
@@ -620,6 +629,7 @@ static const TypeInfo riscv_cpu_type_infos[] = {
 DEFINE_CPU(TYPE_RISCV_CPU_ANY,  riscv_any_cpu_init),
 #if defined(TARGET_RISCV32)
 DEFINE_CPU(TYPE_RISCV_CPU_BASE32,   riscv_base32_cpu_init),
+DEFINE_CPU(TYPE_RISCV_CPU_IBEX, rv32imcu_nommu_cpu_init),
 DEFINE_CPU(TYPE_RISCV_CPU_SIFIVE_E31,   rv32imacu_nommu_cpu_init),
 DEFINE_CPU(TYPE_RISCV_CPU_SIFIVE_E34,   rv32imafcu_nommu_cpu_init),
 DEFINE_CPU(TYPE_RISCV_CPU_SIFIVE_U34,   rv32gcsu_priv1_10_0_cpu_init),
diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index d0e7f5b9c5..8733d7467f 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -35,6 +35,7 @@
 #define TYPE_RISCV_CPU_ANY  RISCV_CPU_TYPE_NAME("any")
 #define TYPE_RISCV_CPU_BASE32   RISCV_CPU_TYPE_NAME("rv32")
 #define TYPE_RISCV_CPU_BASE64   RISCV_CPU_TYPE_NAME("rv64")
+#define TYPE_RISCV_CPU_IBEX RISCV_CPU_TYPE_NAME("lowrisc-ibex")
 #define TYPE_RISCV_CPU_SIFIVE_E31   RISCV_CPU_TYPE_NAME("sifive-e31")
 #define TYPE_RISCV_CPU_SIFIVE_E34   RISCV_CPU_TYPE_NAME("sifive-e34")
 #define TYPE_RISCV_CPU_SIFIVE_E51   RISCV_CPU_TYPE_NAME("sifive-e51")
-- 
2.26.2

[PATCH v2 7/9] riscv/opentitan: Connect the PLIC device

[Alistair Francis]

Signed-off-by: Alistair Francis 
---
 hw/riscv/opentitan.c | 19 +--
 include/hw/riscv/opentitan.h |  3 +++
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/hw/riscv/opentitan.c b/hw/riscv/opentitan.c
index c00f0720ab..3926321d8c 100644
--- a/hw/riscv/opentitan.c
+++ b/hw/riscv/opentitan.c
@@ -25,6 +25,7 @@
 #include "hw/misc/unimp.h"
 #include "hw/riscv/boot.h"
 #include "exec/address-spaces.h"
+#include "sysemu/sysemu.h"
 
 static const struct MemmapEntry {
 hwaddr base;
@@ -92,6 +93,9 @@ static void riscv_lowrisc_ibex_soc_init(Object *obj)
 object_initialize_child(obj, "cpus", >cpus,
 sizeof(s->cpus), TYPE_RISCV_HART_ARRAY,
 _abort, NULL);
+
+sysbus_init_child_obj(obj, "plic", >plic,
+  sizeof(s->plic), TYPE_IBEX_PLIC);
 }
 
 static void riscv_lowrisc_ibex_soc_realize(DeviceState *dev_soc, Error **errp)
@@ -100,6 +104,9 @@ static void riscv_lowrisc_ibex_soc_realize(DeviceState 
*dev_soc, Error **errp)
 MachineState *ms = MACHINE(qdev_get_machine());
 LowRISCIbexSoCState *s = RISCV_IBEX_SOC(dev_soc);
 MemoryRegion *sys_mem = get_system_memory();
+DeviceState *dev;
+SysBusDevice *busdev;
+Error *err = NULL;
 
 object_property_set_str(OBJECT(>cpus), ms->cpu_type, "cpu-type",
 _abort);
@@ -120,6 +127,16 @@ static void riscv_lowrisc_ibex_soc_realize(DeviceState 
*dev_soc, Error **errp)
 memory_region_add_subregion(sys_mem, memmap[IBEX_FLASH].base,
 >flash_mem);
 
+/* PLIC */
+dev = DEVICE(>plic);
+object_property_set_bool(OBJECT(>plic), true, "realized", );
+if (err != NULL) {
+error_propagate(errp, err);
+return;
+}
+busdev = SYS_BUS_DEVICE(dev);
+sysbus_mmio_map(busdev, 0, memmap[IBEX_PLIC].base);
+
 create_unimplemented_device("riscv.lowrisc.ibex.uart",
 memmap[IBEX_UART].base, memmap[IBEX_UART].size);
 create_unimplemented_device("riscv.lowrisc.ibex.gpio",
@@ -134,8 +151,6 @@ static void riscv_lowrisc_ibex_soc_realize(DeviceState 
*dev_soc, Error **errp)
 memmap[IBEX_AES].base, memmap[IBEX_AES].size);
 create_unimplemented_device("riscv.lowrisc.ibex.hmac",
 memmap[IBEX_HMAC].base, memmap[IBEX_HMAC].size);
-create_unimplemented_device("riscv.lowrisc.ibex.plic",
-memmap[IBEX_PLIC].base, memmap[IBEX_PLIC].size);
 create_unimplemented_device("riscv.lowrisc.ibex.pinmux",
 memmap[IBEX_PINMUX].base, memmap[IBEX_PINMUX].size);
 create_unimplemented_device("riscv.lowrisc.ibex.alert_handler",
diff --git a/include/hw/riscv/opentitan.h b/include/hw/riscv/opentitan.h
index 15a3d87ed0..8d6a09b696 100644
--- a/include/hw/riscv/opentitan.h
+++ b/include/hw/riscv/opentitan.h
@@ -20,6 +20,7 @@
 #define HW_OPENTITAN_H
 
 #include "hw/riscv/riscv_hart.h"
+#include "hw/intc/ibex_plic.h"
 
 #define TYPE_RISCV_IBEX_SOC "riscv.lowrisc.ibex.soc"
 #define RISCV_IBEX_SOC(obj) \
@@ -31,6 +32,8 @@ typedef struct LowRISCIbexSoCState {
 
 /*< public >*/
 RISCVHartArrayState cpus;
+IbexPlicState plic;
+
 MemoryRegion flash_mem;
 MemoryRegion rom;
 } LowRISCIbexSoCState;
-- 
2.26.2

[PATCH v2 0/9] RISC-V Add the OpenTitan Machine

[Alistair Francis]

OpenTitan is an open source silicon Root of Trust (RoT) project. This
series adds initial support for the OpenTitan machine to QEMU.

This series add the Ibex CPU to the QEMU RISC-V target. It then adds the
OpenTitan machine, the Ibex UART and the Ibex PLIC.

The UART has been tested sending and receiving data.

With this series QEMU can boot the OpenTitan ROM, Tock OS and a Tock
userspace app.

The Ibex PLIC is similar to the RISC-V PLIC (and is based on the QEMU
implementation) with some differences. The hope is that the Ibex PLIC
will converge to follow the RISC-V spec. As that happens I want to
update the QEMU Ibex PLIC and hopefully eventually replace the current
PLIC as the implementation is a little overlay complex.

For more details on OpenTitan, see here: https://docs.opentitan.org/

v2:
 - Rebase on master
 - Get uart receive working

Alistair Francis (9):
  riscv/boot: Add a missing header include
  target/riscv: Don't overwrite the reset vector
  target/riscv: Add the lowRISC Ibex CPU
  riscv: Initial commit of OpenTitan machine
  hw/char: Initial commit of Ibex UART
  hw/intc: Initial commit of lowRISC Ibex PLIC
  riscv/opentitan: Connect the PLIC device
  riscv/opentitan: Connect the UART device
  target/riscv: Use a smaller guess size for no-MMU PMP

 MAINTAINERS |  14 +
 default-configs/riscv32-softmmu.mak |   1 +
 default-configs/riscv64-softmmu.mak |  11 +-
 hw/char/Makefile.objs   |   1 +
 hw/char/ibex_uart.c | 490 
 hw/intc/Makefile.objs   |   1 +
 hw/intc/ibex_plic.c | 261 +++
 hw/riscv/Kconfig|   9 +
 hw/riscv/Makefile.objs  |   1 +
 hw/riscv/opentitan.c| 204 
 include/hw/char/ibex_uart.h | 110 +++
 include/hw/intc/ibex_plic.h |  63 
 include/hw/riscv/boot.h |   1 +
 include/hw/riscv/opentitan.h|  79 +
 target/riscv/cpu.c  |  30 +-
 target/riscv/cpu.h  |   1 +
 target/riscv/pmp.c  |  19 +-
 17 files changed, 1281 insertions(+), 15 deletions(-)
 create mode 100644 hw/char/ibex_uart.c
 create mode 100644 hw/intc/ibex_plic.c
 create mode 100644 hw/riscv/opentitan.c
 create mode 100644 include/hw/char/ibex_uart.h
 create mode 100644 include/hw/intc/ibex_plic.h
 create mode 100644 include/hw/riscv/opentitan.h

-- 
2.26.2

[PATCH v2 3/3] target/riscv: Drop support for ISA spec version 1.09.1

[Alistair Francis]

The RISC-V ISA spec version 1.09.1 has been deprecated in QEMU since
4.1. It's not commonly used so let's remove support for it.

Signed-off-by: Alistair Francis 
---
 target/riscv/cpu.c|  2 -
 target/riscv/cpu.h|  1 -
 target/riscv/csr.c| 82 ---
 .../riscv/insn_trans/trans_privileged.inc.c   |  6 --
 4 files changed, 17 insertions(+), 74 deletions(-)

diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 112f2e3a2f..eeb91f8513 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -368,8 +368,6 @@ static void riscv_cpu_realize(DeviceState *dev, Error 
**errp)
 priv_version = PRIV_VERSION_1_11_0;
 } else if (!g_strcmp0(cpu->cfg.priv_spec, "v1.10.0")) {
 priv_version = PRIV_VERSION_1_10_0;
-} else if (!g_strcmp0(cpu->cfg.priv_spec, "v1.9.1")) {
-priv_version = PRIV_VERSION_1_09_1;
 } else {
 error_setg(errp,
"Unsupported privilege spec version '%s'",
diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index 76b98d7a33..c022539012 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -73,7 +73,6 @@ enum {
 RISCV_FEATURE_MISA
 };
 
-#define PRIV_VERSION_1_09_1 0x00010901
 #define PRIV_VERSION_1_10_0 0x00011000
 #define PRIV_VERSION_1_11_0 0x00011100
 
diff --git a/target/riscv/csr.c b/target/riscv/csr.c
index 11d184cd16..df3498b24f 100644
--- a/target/riscv/csr.c
+++ b/target/riscv/csr.c
@@ -58,31 +58,11 @@ static int ctr(CPURISCVState *env, int csrno)
 #if !defined(CONFIG_USER_ONLY)
 CPUState *cs = env_cpu(env);
 RISCVCPU *cpu = RISCV_CPU(cs);
-uint32_t ctr_en = ~0u;
 
 if (!cpu->cfg.ext_counters) {
 /* The Counters extensions is not enabled */
 return -1;
 }
-
-/*
- * The counters are always enabled at run time on newer priv specs, as the
- * CSR has changed from controlling that the counters can be read to
- * controlling that the counters increment.
- */
-if (env->priv_ver > PRIV_VERSION_1_09_1) {
-return 0;
-}
-
-if (env->priv < PRV_M) {
-ctr_en &= env->mcounteren;
-}
-if (env->priv < PRV_S) {
-ctr_en &= env->scounteren;
-}
-if (!(ctr_en & (1u << (csrno & 31 {
-return -1;
-}
 #endif
 return 0;
 }
@@ -358,34 +338,21 @@ static int write_mstatus(CPURISCVState *env, int csrno, 
target_ulong val)
 int dirty;
 
 /* flush tlb on mstatus fields that affect VM */
-if (env->priv_ver <= PRIV_VERSION_1_09_1) {
-if ((val ^ mstatus) & (MSTATUS_MXR | MSTATUS_MPP |
-MSTATUS_MPRV | MSTATUS_SUM | MSTATUS_VM)) {
-tlb_flush(env_cpu(env));
-}
-mask = MSTATUS_SIE | MSTATUS_SPIE | MSTATUS_MIE | MSTATUS_MPIE |
-MSTATUS_SPP | MSTATUS_FS | MSTATUS_MPRV | MSTATUS_SUM |
-MSTATUS_MPP | MSTATUS_MXR |
-(validate_vm(env, get_field(val, MSTATUS_VM)) ?
-MSTATUS_VM : 0);
+if ((val ^ mstatus) & (MSTATUS_MXR | MSTATUS_MPP | MSTATUS_MPV |
+MSTATUS_MPRV | MSTATUS_SUM)) {
+tlb_flush(env_cpu(env));
 }
-if (env->priv_ver >= PRIV_VERSION_1_10_0) {
-if ((val ^ mstatus) & (MSTATUS_MXR | MSTATUS_MPP | MSTATUS_MPV |
-MSTATUS_MPRV | MSTATUS_SUM)) {
-tlb_flush(env_cpu(env));
-}
-mask = MSTATUS_SIE | MSTATUS_SPIE | MSTATUS_MIE | MSTATUS_MPIE |
-MSTATUS_SPP | MSTATUS_FS | MSTATUS_MPRV | MSTATUS_SUM |
-MSTATUS_MPP | MSTATUS_MXR | MSTATUS_TVM | MSTATUS_TSR |
-MSTATUS_TW;
+mask = MSTATUS_SIE | MSTATUS_SPIE | MSTATUS_MIE | MSTATUS_MPIE |
+MSTATUS_SPP | MSTATUS_FS | MSTATUS_MPRV | MSTATUS_SUM |
+MSTATUS_MPP | MSTATUS_MXR | MSTATUS_TVM | MSTATUS_TSR |
+MSTATUS_TW;
 #if defined(TARGET_RISCV64)
-/*
- * RV32: MPV and MTL are not in mstatus. The current plan is to
- * add them to mstatush. For now, we just don't support it.
- */
-mask |= MSTATUS_MTL | MSTATUS_MPV;
+/*
+ * RV32: MPV and MTL are not in mstatus. The current plan is to
+ * add them to mstatush. For now, we just don't support it.
+ */
+mask |= MSTATUS_MTL | MSTATUS_MPV;
 #endif
-}
 
 mstatus = (mstatus & ~mask) | (val & mask);
 
@@ -553,8 +520,7 @@ static int write_mcounteren(CPURISCVState *env, int csrno, 
target_ulong val)
 /* This regiser is replaced with CSR_MCOUNTINHIBIT in 1.11.0 */
 static int read_mscounteren(CPURISCVState *env, int csrno, target_ulong *val)
 {
-if (env->priv_ver > PRIV_VERSION_1_09_1
-&& env->priv_ver < PRIV_VERSION_1_11_0) {
+if (env->priv_ver < PRIV_VERSION_1_11_0) {
 return -1;
 }
 *val = env->mcounteren;
@@ -564,8 +530,7 @@ static int read_mscounteren(CPURISCVState *env, int csrno, 
target_ulong *val)
 /* This regiser is replaced with 

Re: [PATCH v1 2/2] target/riscv: Drop support for ISA spec version 1.09.1

[Alistair Francis]

On Wed, May 6, 2020 at 5:11 AM Philippe Mathieu-Daudé  wrote:
>
> Hi Alistair,
>
> On 5/6/20 3:12 AM, Alistair Francis wrote:
> > The RISC-V ISA spec version 1.09.1 has been deprecated in QEMU since
> > 4.1. It's not commonly used so let's remove support for it.
> >
> > Signed-off-by: Alistair Francis 
> > ---
> >   target/riscv/cpu.c| 30 ---
> >   target/riscv/cpu.h|  8 --
> >   target/riscv/csr.c| 82 ---
> >   .../riscv/insn_trans/trans_privileged.inc.c   |  6 --
> >   tests/qtest/machine-none-test.c   |  4 +-
> >   5 files changed, 19 insertions(+), 111 deletions(-)
> >
> > diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> > index 059d71f2c7..eeb91f8513 100644
> > --- a/target/riscv/cpu.c
> > +++ b/target/riscv/cpu.c
> > @@ -135,16 +135,6 @@ static void riscv_base32_cpu_init(Object *obj)
> >   set_misa(env, 0);
> >   }
> >
> > -static void rv32gcsu_priv1_09_1_cpu_init(Object *obj)
> > -{
> > -CPURISCVState *env = _CPU(obj)->env;
> > -set_misa(env, RV32 | RVI | RVM | RVA | RVF | RVD | RVC | RVS | RVU);
> > -set_priv_version(env, PRIV_VERSION_1_09_1);
> > -set_resetvec(env, DEFAULT_RSTVEC);
> > -set_feature(env, RISCV_FEATURE_MMU);
> > -set_feature(env, RISCV_FEATURE_PMP);
> > -}
> > -
> >   static void rv32gcsu_priv1_10_0_cpu_init(Object *obj)
> >   {
> >   CPURISCVState *env = _CPU(obj)->env;
> > @@ -182,16 +172,6 @@ static void riscv_base64_cpu_init(Object *obj)
> >   set_misa(env, 0);
> >   }
> >
> > -static void rv64gcsu_priv1_09_1_cpu_init(Object *obj)
> > -{
> > -CPURISCVState *env = _CPU(obj)->env;
> > -set_misa(env, RV64 | RVI | RVM | RVA | RVF | RVD | RVC | RVS | RVU);
> > -set_priv_version(env, PRIV_VERSION_1_09_1);
> > -set_resetvec(env, DEFAULT_RSTVEC);
> > -set_feature(env, RISCV_FEATURE_MMU);
> > -set_feature(env, RISCV_FEATURE_PMP);
> > -}
> > -
> >   static void rv64gcsu_priv1_10_0_cpu_init(Object *obj)
> >   {
> >   CPURISCVState *env = _CPU(obj)->env;
> > @@ -388,8 +368,6 @@ static void riscv_cpu_realize(DeviceState *dev, Error 
> > **errp)
> >   priv_version = PRIV_VERSION_1_11_0;
> >   } else if (!g_strcmp0(cpu->cfg.priv_spec, "v1.10.0")) {
> >   priv_version = PRIV_VERSION_1_10_0;
> > -} else if (!g_strcmp0(cpu->cfg.priv_spec, "v1.9.1")) {
> > -priv_version = PRIV_VERSION_1_09_1;
> >   } else {
> >   error_setg(errp,
> >  "Unsupported privilege spec version '%s'",
> > @@ -621,18 +599,10 @@ static const TypeInfo riscv_cpu_type_infos[] = {
> >   DEFINE_CPU(TYPE_RISCV_CPU_SIFIVE_E31,   rv32imacu_nommu_cpu_init),
> >   DEFINE_CPU(TYPE_RISCV_CPU_SIFIVE_E34,   
> > rv32imafcu_nommu_cpu_init),
> >   DEFINE_CPU(TYPE_RISCV_CPU_SIFIVE_U34,   
> > rv32gcsu_priv1_10_0_cpu_init),
> > -/* Depreacted */
> > -DEFINE_CPU(TYPE_RISCV_CPU_RV32IMACU_NOMMU,  rv32imacu_nommu_cpu_init),
> > -DEFINE_CPU(TYPE_RISCV_CPU_RV32GCSU_V1_09_1, 
> > rv32gcsu_priv1_09_1_cpu_init),
> > -DEFINE_CPU(TYPE_RISCV_CPU_RV32GCSU_V1_10_0, 
> > rv32gcsu_priv1_10_0_cpu_init)
>
> Shouldn't you let TYPE_RISCV_CPU_RV32GCSU_V1_10_0 until you remove v1.10.0?
>
> Or remove TYPE_RISCV_CPU_RV32GCSU_V1_10_0 &
> TYPE_RISCV_CPU_RV64GCSU_V1_10_0 in another patch after this one
> (restricted to 1.09.1).

Fixed in v2, I have split this patch into 2.

Alistair

>
> >   #elif defined(TARGET_RISCV64)
> >   DEFINE_CPU(TYPE_RISCV_CPU_BASE64,   riscv_base64_cpu_init),
> >   DEFINE_CPU(TYPE_RISCV_CPU_SIFIVE_E51,   rv64imacu_nommu_cpu_init),
> >   DEFINE_CPU(TYPE_RISCV_CPU_SIFIVE_U54,   
> > rv64gcsu_priv1_10_0_cpu_init),
> > -/* Deprecated */
> > -DEFINE_CPU(TYPE_RISCV_CPU_RV64IMACU_NOMMU,  rv64imacu_nommu_cpu_init),
> > -DEFINE_CPU(TYPE_RISCV_CPU_RV64GCSU_V1_09_1, 
> > rv64gcsu_priv1_09_1_cpu_init),
> > -DEFINE_CPU(TYPE_RISCV_CPU_RV64GCSU_V1_10_0, 
> > rv64gcsu_priv1_10_0_cpu_init)
>
> Ditto.
>
> >   #endif
> >   };
> >
> > diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
> > index d0e7f5b9c5..c022539012 100644
> > --- a/target/riscv/cpu.h
> > +++ b/target/riscv/cpu.h
> > @@ -40,13 +40,6 @@
> >   #define TYPE_RISCV_CPU_SIFIVE_E51   RISCV_CPU_TYPE_NAME("sifive-e51")
> >   #define TYPE_RISCV_CPU_SIFIVE_U34   RISCV_CPU_TYPE_NAME("sifive-u34")
> >   #define TYPE_RISCV_CPU_SIFIVE_U54   RISCV_CPU_TYPE_NAME("sifive-u54")
> > -/* Deprecated */
> > -#define TYPE_RISCV_CPU_RV32IMACU_NOMMU  
> > RISCV_CPU_TYPE_NAME("rv32imacu-nommu")
> > -#define TYPE_RISCV_CPU_RV32GCSU_V1_09_1 
> > RISCV_CPU_TYPE_NAME("rv32gcsu-v1.9.1")
> > -#define TYPE_RISCV_CPU_RV32GCSU_V1_10_0 
> > RISCV_CPU_TYPE_NAME("rv32gcsu-v1.10.0")
>
> Ditto.
>
> > -#define TYPE_RISCV_CPU_RV64IMACU_NOMMU  
> > RISCV_CPU_TYPE_NAME("rv64imacu-nommu")
> > -#define TYPE_RISCV_CPU_RV64GCSU_V1_09_1 
> > 

[PATCH v2 1/3] hw/riscv: spike: Remove deprecated ISA specific machines

[Alistair Francis]

The ISA specific Spike machines have  been deprecated in QEMU since 4.1,
let's finally remove them.

Signed-off-by: Alistair Francis 
Reviewed-by: Philippe Mathieu-Daudé 
---
 hw/riscv/spike.c | 217 ---
 include/hw/riscv/spike.h |   6 +-
 2 files changed, 2 insertions(+), 221 deletions(-)

diff --git a/hw/riscv/spike.c b/hw/riscv/spike.c
index d0c4843712..7bbbdb5036 100644
--- a/hw/riscv/spike.c
+++ b/hw/riscv/spike.c
@@ -257,221 +257,6 @@ static void spike_board_init(MachineState *machine)
 false);
 }
 
-static void spike_v1_10_0_board_init(MachineState *machine)
-{
-const struct MemmapEntry *memmap = spike_memmap;
-
-SpikeState *s = g_new0(SpikeState, 1);
-MemoryRegion *system_memory = get_system_memory();
-MemoryRegion *main_mem = g_new(MemoryRegion, 1);
-MemoryRegion *mask_rom = g_new(MemoryRegion, 1);
-int i;
-unsigned int smp_cpus = machine->smp.cpus;
-
-if (!qtest_enabled()) {
-info_report("The Spike v1.10.0 machine has been deprecated. "
-"Please use the generic spike machine and specify the ISA "
-"versions using -cpu.");
-}
-
-/* Initialize SOC */
-object_initialize_child(OBJECT(machine), "soc", >soc, sizeof(s->soc),
-TYPE_RISCV_HART_ARRAY, _abort, NULL);
-object_property_set_str(OBJECT(>soc), SPIKE_V1_10_0_CPU, "cpu-type",
-_abort);
-object_property_set_int(OBJECT(>soc), smp_cpus, "num-harts",
-_abort);
-object_property_set_bool(OBJECT(>soc), true, "realized",
-_abort);
-
-/* register system main memory (actual RAM) */
-memory_region_init_ram(main_mem, NULL, "riscv.spike.ram",
-   machine->ram_size, _fatal);
-memory_region_add_subregion(system_memory, memmap[SPIKE_DRAM].base,
-main_mem);
-
-/* create device tree */
-create_fdt(s, memmap, machine->ram_size, machine->kernel_cmdline);
-
-/* boot rom */
-memory_region_init_rom(mask_rom, NULL, "riscv.spike.mrom",
-   memmap[SPIKE_MROM].size, _fatal);
-memory_region_add_subregion(system_memory, memmap[SPIKE_MROM].base,
-mask_rom);
-
-if (machine->kernel_filename) {
-riscv_load_kernel(machine->kernel_filename, htif_symbol_callback);
-}
-
-/* reset vector */
-uint32_t reset_vec[8] = {
-0x0297,  /* 1:  auipc  t0, %pcrel_hi(dtb) */
-0x02028593,  /* addi   a1, t0, %pcrel_lo(1b) */
-0xf1402573,  /* csrr   a0, mhartid  */
-#if defined(TARGET_RISCV32)
-0x0182a283,  /* lw t0, 24(t0) */
-#elif defined(TARGET_RISCV64)
-0x0182b283,  /* ld t0, 24(t0) */
-#endif
-0x00028067,  /* jr t0 */
-0x,
-memmap[SPIKE_DRAM].base, /* start: .dword DRAM_BASE */
-0x,
- /* dtb: */
-};
-
-/* copy in the reset vector in little_endian byte order */
-for (i = 0; i < sizeof(reset_vec) >> 2; i++) {
-reset_vec[i] = cpu_to_le32(reset_vec[i]);
-}
-rom_add_blob_fixed_as("mrom.reset", reset_vec, sizeof(reset_vec),
-  memmap[SPIKE_MROM].base, _space_memory);
-
-/* copy in the device tree */
-if (fdt_pack(s->fdt) || fdt_totalsize(s->fdt) >
-memmap[SPIKE_MROM].size - sizeof(reset_vec)) {
-error_report("not enough space to store device-tree");
-exit(1);
-}
-qemu_fdt_dumpdtb(s->fdt, fdt_totalsize(s->fdt));
-rom_add_blob_fixed_as("mrom.fdt", s->fdt, fdt_totalsize(s->fdt),
-  memmap[SPIKE_MROM].base + sizeof(reset_vec),
-  _space_memory);
-
-/* initialize HTIF using symbols found in load_kernel */
-htif_mm_init(system_memory, mask_rom, >soc.harts[0].env, serial_hd(0));
-
-/* Core Local Interruptor (timer and IPI) */
-sifive_clint_create(memmap[SPIKE_CLINT].base, memmap[SPIKE_CLINT].size,
-smp_cpus, SIFIVE_SIP_BASE, SIFIVE_TIMECMP_BASE, SIFIVE_TIME_BASE,
-false);
-}
-
-static void spike_v1_09_1_board_init(MachineState *machine)
-{
-const struct MemmapEntry *memmap = spike_memmap;
-
-SpikeState *s = g_new0(SpikeState, 1);
-MemoryRegion *system_memory = get_system_memory();
-MemoryRegion *main_mem = g_new(MemoryRegion, 1);
-MemoryRegion *mask_rom = g_new(MemoryRegion, 1);
-int i;
-unsigned int smp_cpus = machine->smp.cpus;
-
-if (!qtest_enabled()) {
-info_report("The Spike v1.09.1 machine has been deprecated. "
-"Please use the generic spike machine and specify the ISA "
-"versions using -cpu.");
-}
-
-/* Initialize SOC */
-object_initialize_child(OBJECT(machine), "soc", 

[PATCH v2 2/3] target/riscv: Remove the deprecated CPUs

[Alistair Francis]

Signed-off-by: Alistair Francis 
---
 target/riscv/cpu.c  | 28 
 target/riscv/cpu.h  |  7 ---
 tests/qtest/machine-none-test.c |  4 ++--
 3 files changed, 2 insertions(+), 37 deletions(-)

diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 059d71f2c7..112f2e3a2f 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -135,16 +135,6 @@ static void riscv_base32_cpu_init(Object *obj)
 set_misa(env, 0);
 }
 
-static void rv32gcsu_priv1_09_1_cpu_init(Object *obj)
-{
-CPURISCVState *env = _CPU(obj)->env;
-set_misa(env, RV32 | RVI | RVM | RVA | RVF | RVD | RVC | RVS | RVU);
-set_priv_version(env, PRIV_VERSION_1_09_1);
-set_resetvec(env, DEFAULT_RSTVEC);
-set_feature(env, RISCV_FEATURE_MMU);
-set_feature(env, RISCV_FEATURE_PMP);
-}
-
 static void rv32gcsu_priv1_10_0_cpu_init(Object *obj)
 {
 CPURISCVState *env = _CPU(obj)->env;
@@ -182,16 +172,6 @@ static void riscv_base64_cpu_init(Object *obj)
 set_misa(env, 0);
 }
 
-static void rv64gcsu_priv1_09_1_cpu_init(Object *obj)
-{
-CPURISCVState *env = _CPU(obj)->env;
-set_misa(env, RV64 | RVI | RVM | RVA | RVF | RVD | RVC | RVS | RVU);
-set_priv_version(env, PRIV_VERSION_1_09_1);
-set_resetvec(env, DEFAULT_RSTVEC);
-set_feature(env, RISCV_FEATURE_MMU);
-set_feature(env, RISCV_FEATURE_PMP);
-}
-
 static void rv64gcsu_priv1_10_0_cpu_init(Object *obj)
 {
 CPURISCVState *env = _CPU(obj)->env;
@@ -621,18 +601,10 @@ static const TypeInfo riscv_cpu_type_infos[] = {
 DEFINE_CPU(TYPE_RISCV_CPU_SIFIVE_E31,   rv32imacu_nommu_cpu_init),
 DEFINE_CPU(TYPE_RISCV_CPU_SIFIVE_E34,   rv32imafcu_nommu_cpu_init),
 DEFINE_CPU(TYPE_RISCV_CPU_SIFIVE_U34,   rv32gcsu_priv1_10_0_cpu_init),
-/* Depreacted */
-DEFINE_CPU(TYPE_RISCV_CPU_RV32IMACU_NOMMU,  rv32imacu_nommu_cpu_init),
-DEFINE_CPU(TYPE_RISCV_CPU_RV32GCSU_V1_09_1, rv32gcsu_priv1_09_1_cpu_init),
-DEFINE_CPU(TYPE_RISCV_CPU_RV32GCSU_V1_10_0, rv32gcsu_priv1_10_0_cpu_init)
 #elif defined(TARGET_RISCV64)
 DEFINE_CPU(TYPE_RISCV_CPU_BASE64,   riscv_base64_cpu_init),
 DEFINE_CPU(TYPE_RISCV_CPU_SIFIVE_E51,   rv64imacu_nommu_cpu_init),
 DEFINE_CPU(TYPE_RISCV_CPU_SIFIVE_U54,   rv64gcsu_priv1_10_0_cpu_init),
-/* Deprecated */
-DEFINE_CPU(TYPE_RISCV_CPU_RV64IMACU_NOMMU,  rv64imacu_nommu_cpu_init),
-DEFINE_CPU(TYPE_RISCV_CPU_RV64GCSU_V1_09_1, rv64gcsu_priv1_09_1_cpu_init),
-DEFINE_CPU(TYPE_RISCV_CPU_RV64GCSU_V1_10_0, rv64gcsu_priv1_10_0_cpu_init)
 #endif
 };
 
diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index d0e7f5b9c5..76b98d7a33 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -40,13 +40,6 @@
 #define TYPE_RISCV_CPU_SIFIVE_E51   RISCV_CPU_TYPE_NAME("sifive-e51")
 #define TYPE_RISCV_CPU_SIFIVE_U34   RISCV_CPU_TYPE_NAME("sifive-u34")
 #define TYPE_RISCV_CPU_SIFIVE_U54   RISCV_CPU_TYPE_NAME("sifive-u54")
-/* Deprecated */
-#define TYPE_RISCV_CPU_RV32IMACU_NOMMU  RISCV_CPU_TYPE_NAME("rv32imacu-nommu")
-#define TYPE_RISCV_CPU_RV32GCSU_V1_09_1 RISCV_CPU_TYPE_NAME("rv32gcsu-v1.9.1")
-#define TYPE_RISCV_CPU_RV32GCSU_V1_10_0 RISCV_CPU_TYPE_NAME("rv32gcsu-v1.10.0")
-#define TYPE_RISCV_CPU_RV64IMACU_NOMMU  RISCV_CPU_TYPE_NAME("rv64imacu-nommu")
-#define TYPE_RISCV_CPU_RV64GCSU_V1_09_1 RISCV_CPU_TYPE_NAME("rv64gcsu-v1.9.1")
-#define TYPE_RISCV_CPU_RV64GCSU_V1_10_0 RISCV_CPU_TYPE_NAME("rv64gcsu-v1.10.0")
 
 #define RV32 ((target_ulong)1 << (TARGET_LONG_BITS - 2))
 #define RV64 ((target_ulong)2 << (TARGET_LONG_BITS - 2))
diff --git a/tests/qtest/machine-none-test.c b/tests/qtest/machine-none-test.c
index 8bb54a6360..b52311ec2e 100644
--- a/tests/qtest/machine-none-test.c
+++ b/tests/qtest/machine-none-test.c
@@ -54,8 +54,8 @@ static struct arch2cpu cpus_map[] = {
 { "xtensa", "dc233c" },
 { "xtensaeb", "fsf" },
 { "hppa", "hppa" },
-{ "riscv64", "rv64gcsu-v1.10.0" },
-{ "riscv32", "rv32gcsu-v1.9.1" },
+{ "riscv64", "sifive-u54" },
+{ "riscv32", "sifive-u34" },
 { "rx", "rx62n" },
 };
 
-- 
2.26.2

[PATCH v2 0/3] RTISC-V: Remove deprecated ISA, CPUs and machines

[Alistair Francis]

v2:
 - Remove the CPUs and ISA seperatley

Alistair Francis (3):
  hw/riscv: spike: Remove deprecated ISA specific machines
  target/riscv: Remove the deprecated CPUs
  target/riscv: Drop support for ISA spec version 1.09.1

 hw/riscv/spike.c  | 217 --
 include/hw/riscv/spike.h  |   6 +-
 target/riscv/cpu.c|  30 ---
 target/riscv/cpu.h|   8 -
 target/riscv/csr.c|  82 ++-
 .../riscv/insn_trans/trans_privileged.inc.c   |   6 -
 tests/qtest/machine-none-test.c   |   4 +-
 7 files changed, 21 insertions(+), 332 deletions(-)

-- 
2.26.2

Re: [PATCH v5 01/14] qcrypto/core: add generic infrastructure for crypto options amendment

[Maxim Levitsky]

On Thu, 2020-05-07 at 11:09 -0500, Eric Blake wrote:
> On 5/7/20 7:54 AM, Maxim Levitsky wrote:
> > This will be used first to implement luks keyslot management.
> > 
> > block_crypto_amend_opts_init will be used to convert
> > qemu-img cmdline to QCryptoBlockAmendOptions
> > 
> > Signed-off-by: Maxim Levitsky 
> > Reviewed-by: Daniel P. Berrangé 
> > ---
> > +++ b/qapi/crypto.json
> > @@ -309,3 +309,19 @@
> > 'base': 'QCryptoBlockInfoBase',
> > 'discriminator': 'format',
> > 'data': { 'luks': 'QCryptoBlockInfoLUKS' } }
> > +
> > +
> > +
> > +##
> > +# @QCryptoBlockAmendOptions:
> > +#
> > +# The options that are available for all encryption formats
> > +# when amending encryption settings
> > +#
> > +# Since: 5.0
> 
> Looks like our mail crossed, my v4 review landed after you sent v5. 
> We'll still have to scrub this series for s/5.0/5.1/

Yea, I totally forgot about this :-(
I''l do this now.

Best regards,
Maxim Levitsky

> 
> > +##
> > +{ 'union': 'QCryptoBlockAmendOptions',
> > +  'base': 'QCryptoBlockOptionsBase',
> > +  'discriminator': 'format',
> > +  'data': {
> > +} }
> > 
> 
> 

Re: [PATCH v4 09/13] migration/ram: Consolidate variable reset after placement in ram_load_postcopy()

[Dr. David Alan Gilbert]

* David Hildenbrand (da...@redhat.com) wrote:
> On 07.05.20 17:42, Dr. David Alan Gilbert wrote:
> > * Dr. David Alan Gilbert (dgilb...@redhat.com) wrote:
> >> * David Hildenbrand (da...@redhat.com) wrote:
> >>> Let's consolidate resetting the variables.
> >>>
> >>> Cc: "Dr. David Alan Gilbert" 
> >>> Cc: Juan Quintela 
> >>> Cc: Peter Xu 
> >>> Signed-off-by: David Hildenbrand 
> >>
> >> Reviewed-by: Dr. David Alan Gilbert 
> > 
> > Queued this one only; I had to do manual patch application due to some
> > renaming in 91ba442; but I think it's still OK.
> 
> Thanks, how to best proceed with the other 12 patches in this series?

Yeh I need to look at some of them; but they're buried in the other ~200
outstanding mails in my inbox.

Dave

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

[PATCH 0/1] hw/net: Added basic IPv6 fragmentation. Fixed IPv6 payload length. Fixed CSO for IPv6.

[andrew]

From: Andrew Melnychenko 

Compare to previous patch - fixed issue with compilation in docker fedora test.

Andrew Melnychenko (1):
  hw/net: Added basic IPv6 fragmentation. Fixed IPv6 payload length.
Fixed CSO for IPv6.

 hw/net/net_tx_pkt.c | 54 ---
 hw/net/net_tx_pkt.h |  7 
 include/net/eth.h   | 15 ++--
 net/eth.c   | 89 ++---
 4 files changed, 151 insertions(+), 14 deletions(-)

-- 
2.24.1

[PATCH 1/1] hw/net: Added basic IPv6 fragmentation. Fixed IPv6 payload length. Fixed CSO for IPv6.

[andrew]

From: Andrew Melnychenko 

Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1708065
Overall, there was an issue that big frames of IPv6 doesn't sent.
With network backend with 'virtual header' - there was an issue
in 'plen' field. Overall, during TSO, 'plen' would be changed,
but with 'vheader' this field should be set to the size of the
payload itself instead of '0'.
For software offload - there is added basic IPv6 fragmentation.
Also fixed checksum offload for IPv6.
The basic IPv6 fragmentation - adding 'frag' extension to
the packet, overall shares some logic with IPv4. It works,
but there are still issues with a combination of
extensions - in the future, it would require refactoring
work to implement workflow with IPv6 and extension.
e1000e driver doesn't set the 'plen' field for IPv6 for big packets
if TSO is enabled. "Jumbo option" isn't added yet, until
qemu supports packets greater than 64K.

Signed-off-by: Andrew Melnychenko 
---
 hw/net/net_tx_pkt.c | 54 ---
 hw/net/net_tx_pkt.h |  7 
 include/net/eth.h   | 15 ++--
 net/eth.c   | 89 ++---
 4 files changed, 151 insertions(+), 14 deletions(-)

diff --git a/hw/net/net_tx_pkt.c b/hw/net/net_tx_pkt.c
index 162f802dd7..895effecb9 100644
--- a/hw/net/net_tx_pkt.c
+++ b/hw/net/net_tx_pkt.c
@@ -468,8 +468,8 @@ static void net_tx_pkt_do_sw_csum(struct NetTxPkt *pkt)
 /* num of iovec without vhdr */
 uint32_t iov_len = pkt->payload_frags + NET_TX_PKT_PL_START_FRAG - 1;
 uint16_t csl;
-struct ip_header *iphdr;
 size_t csum_offset = pkt->virt_hdr.csum_start + pkt->virt_hdr.csum_offset;
+uint16_t l3_proto = eth_get_l3_proto(iov, 1, iov->iov_len);
 
 /* Put zero to checksum field */
 iov_from_buf(iov, iov_len, csum_offset, , sizeof csum);
@@ -477,9 +477,18 @@ static void net_tx_pkt_do_sw_csum(struct NetTxPkt *pkt)
 /* Calculate L4 TCP/UDP checksum */
 csl = pkt->payload_len;
 
+csum_cntr = 0;
+cso = 0;
 /* add pseudo header to csum */
-iphdr = pkt->vec[NET_TX_PKT_L3HDR_FRAG].iov_base;
-csum_cntr = eth_calc_ip4_pseudo_hdr_csum(iphdr, csl, );
+if (l3_proto == ETH_P_IP) {
+csum_cntr = eth_calc_ip4_pseudo_hdr_csum(
+pkt->vec[NET_TX_PKT_L3HDR_FRAG].iov_base,
+csl, );
+} else if (l3_proto == ETH_P_IPV6) {
+csum_cntr = eth_calc_ip6_pseudo_hdr_csum(
+pkt->vec[NET_TX_PKT_L3HDR_FRAG].iov_base,
+csl, pkt->l4proto, );
+}
 
 /* data checksum */
 csum_cntr +=
@@ -580,10 +589,11 @@ static bool net_tx_pkt_do_sw_fragmentation(struct 
NetTxPkt *pkt,
 
 more_frags = (fragment_offset + fragment_len < pkt->payload_len);
 
-eth_setup_ip4_fragmentation(l2_iov_base, l2_iov_len, l3_iov_base,
-l3_iov_len, fragment_len, fragment_offset, more_frags);
+eth_setup_ip_fragmentation(l2_iov_base, l2_iov_len, l3_iov_base,
+_iov_len, ETH_MAX_IP_DGRAM_LEN,
+fragment_len, fragment_offset, more_frags);
 
-eth_fix_ip4_checksum(l3_iov_base, l3_iov_len);
+fragment[NET_TX_PKT_FRAGMENT_L3_HDR_POS].iov_len = l3_iov_len;
 
 net_tx_pkt_sendv(pkt, nc, fragment, dst_idx);
 
@@ -617,6 +627,7 @@ bool net_tx_pkt_send(struct NetTxPkt *pkt, NetClientState 
*nc)
 
 if (pkt->has_virt_hdr ||
 pkt->virt_hdr.gso_type == VIRTIO_NET_HDR_GSO_NONE) {
+net_tx_pkt_fix_ip6_payload_len(pkt);
 net_tx_pkt_sendv(pkt, nc, pkt->vec,
 pkt->payload_frags + NET_TX_PKT_PL_START_FRAG);
 return true;
@@ -635,3 +646,34 @@ bool net_tx_pkt_send_loopback(struct NetTxPkt *pkt, 
NetClientState *nc)
 
 return res;
 }
+
+void net_tx_pkt_fix_ip6_payload_len(struct NetTxPkt *pkt)
+{
+/*
+ * If ipv6 payload length field is 0 - then there should be Hop-by-Hop
+ * option for packets greater than 65,535.
+ * For packets with payload less than 65,535: fix 'plen' field.
+ * For now, qemu drops every packet with size greater 64K
+ * (see net_tx_pkt_send()) so, there is no reason to add jumbo option to 
ip6
+ * hop-by-hop extension if it's missed
+ */
+
+struct iovec *l2 = >vec[NET_TX_PKT_L2HDR_FRAG];
+if (eth_get_l3_proto(l2, 1, l2->iov_len) == ETH_P_IPV6) {
+struct ip6_header *ip6 = (struct ip6_header *) pkt->l3_hdr;
+/*
+ * TODO: if qemu would support >64K packets - add jumbo option check
+ * something like that:
+ * 'if (ip6->ip6_plen == 0 && !has_jumbo_option(ip6)) {'
+ */
+if (ip6->ip6_plen == 0) {
+if (pkt->payload_len <= ETH_MAX_IP_DGRAM_LEN) {
+ip6->ip6_plen = htons(pkt->payload_len);
+}
+/*
+ * TODO: if qemu would support >64K packets
+ * add jumbo option for packets greater then 65,535 bytes
+ */
+}
+}
+}
diff --git a/hw/net/net_tx_pkt.h b/hw/net/net_tx_pkt.h
index 

Re: Emulating Solaris 10 on SPARC64 sun4u

[BALATON Zoltan]

On Thu, 7 May 2020, jasper.low...@bt.com wrote:

I've started work on emulating the SAB 82532 ESSC2 but it's
unfortunately way more complex than than the 16550A. For instance, it's


I don't know anything about this chip so don't know if it helps but if 
it's any way similar to ESCC (and the ESCC2 name is not just marketing) 
then there's some emulation of that in hw/char/escc.c that you may want to 
look at.



possible to configure different baudrates for receiving and
transmitting. QEMU's chardev interface doesn't appear to handle that.
QEMUSerialSetParams has a single speed value that is passed to
cfsetispeed and cfsetospeed. The chip also has support for stick parity
, which aren't valid options right now either. If I'm wrong on either
of those points please correct me. Unless there is an alternative,
changes to the interface may need to be made if adding this device is
to be considered.


Maybe you can get away with setting these to the values the driver would 
set and hard coding it for now just to get some output. Then you can 
ignore the corresponding registers which could simplify initial device 
model.


Regards,
BALATON Zoltan

Re: [PATCH] block/block-copy: fix use-after-free of task pointer

[Eric Blake]

On 5/7/20 1:38 PM, Vladimir Sementsov-Ogievskiy wrote:

Obviously, we should g_free the task after trace point and offset
update.

Reported-by: Coverity
Fixes: 4ce5dd3e9b5ee0fac18625860eb3727399ee965e
Signed-off-by: Vladimir Sementsov-Ogievskiy 
---

Be free to add Coverity number to the commit message, I don't know it.

  block/block-copy.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)


Reviewed-by: Eric Blake 

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Re: [PULL 00/12] migration queue

[Peter Maydell]

On Thu, 7 May 2020 at 18:04, Dr. David Alan Gilbert (git)
 wrote:
>
> From: "Dr. David Alan Gilbert" 
>
> The following changes since commit 3c7adbc67d9a5c3e992a4dd13b8704464daaad5b:
>
>   Merge remote-tracking branch 
> 'remotes/berrange/tags/qcrypto-next-pull-request' into staging (2020-05-07 
> 14:30:12 +0100)
>
> are available in the Git repository at:
>
>   git://github.com/dagrh/qemu.git tags/pull-migration-20200507a
>
> for you to fetch changes up to 13f2cb21e5fb33e9f8d7db8eee48edc1c67b812f:
>
>   migration/multifd: Do error_free after migrate_set_error to avoid memleaks 
> (2020-05-07 17:40:24 +0100)
>
> 
> Migration pull 2020-05-07
>
> Mostly tidy-ups, but two new features:
>   cpu-throttle-tailslow for making a gentler throttle
>   xbzrle encoding rate measurement for getting a feal for xbzrle
> performance.
>


Applied, thanks.

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

-- PMM

Re: [PATCH] tests/acceptance/boot_linux: Skip slow Aarch64 'virt' machine TCG test

[Peter Maydell]

On Thu, 7 May 2020 at 19:38, Alex Bennée  wrote:
>
>
> Philippe Mathieu-Daudé  writes:
>
> > The BootLinuxAarch64.test_virt_tcg is reported to take >7min to run.
> > Add a possibility to users to skip this particular test, by setting
> > the AVOCADO_SKIP_SLOW_TESTS environment variable:
> >
> >   $ AVOCADO_SKIP_SLOW_TESTS=please make check-acceptance
> >   ...
> > (05/88) tests/acceptance/boot_linux.py:BootLinuxAarch64.test_virt_tcg: 
> > SKIP: Test takes >7min
> >   ...
>
> 7m = 420s - I'm seeing:
>
>   hyperfine "./tests/venv/bin/avocado run 
> ./tests/acceptance/boot_linux.py:BootLinuxAarch64.test_virt_tcg"
>   Benchmark #1: ./tests/venv/bin/avocado run 
> ./tests/acceptance/boot_linux.py:BootLinuxAarch64.test_virt_tcg
> Time (mean ± σ): 162.179 s ±  3.138 s[User: 204.726 s, System: 
> 9.663 s]
> Range (min … max):   158.651 s … 170.036 s10 runs
>
> Is this on very slow hardware?

Intel(R) Xeon(R) W-2145 CPU @ 3.70GHz 16-core
clang sanitizer build, which probably slows it down a bit.

But even 200 seconds is an order of magnitude slower than any
of the other tests that check-acceptance runs. I think we
should be aiming for tests here to be ~30 seconds at most,
or the whole thing will take forever by the time we have
decent coverage of most machines.

thanks
-- PMM

Re: [PATCH v1 2/2] Sample mtty: Add migration capability to mtty module

[Dr. David Alan Gilbert]

* Kirti Wankhede (kwankh...@nvidia.com) wrote:
> This patch makes mtty device migration capable. Purpose od this code is
> to test migration interface. Only stop-and-copy phase is implemented.
> Postcopy migration is not supported.
> 
> Actual data for mtty device migration is very less. Appended dummy data to
> migration data stream, default 100 Mbytes. Added sysfs file
> 'dummy_data_size_MB' to get dummy data size from user which can be used
> to check performance of based of data size. During resuming dummy data is
> read and discarded.
> 
> Signed-off-by: Kirti Wankhede 
> ---
>  samples/vfio-mdev/mtty.c | 602 
> ---
>  1 file changed, 574 insertions(+), 28 deletions(-)
> 
> diff --git a/samples/vfio-mdev/mtty.c b/samples/vfio-mdev/mtty.c
> index bf666cce5bb7..f9194234fc6a 100644
> --- a/samples/vfio-mdev/mtty.c
> +++ b/samples/vfio-mdev/mtty.c
> @@ -44,9 +44,23 @@
>  
>  #define MTTY_STRING_LEN  16
>  
> -#define MTTY_CONFIG_SPACE_SIZE  0xff
> -#define MTTY_IO_BAR_SIZE0x8
> -#define MTTY_MMIO_BAR_SIZE  0x10
> +#define MTTY_CONFIG_SPACE_SIZE   0xff
> +#define MTTY_IO_BAR_SIZE 0x8
> +#define MTTY_MMIO_BAR_SIZE   0x10
> +#define MTTY_MIGRATION_REGION_SIZE   0x100   // 16M
> +
> +#define MTTY_MIGRATION_REGION_INDEX  VFIO_PCI_NUM_REGIONS
> +#define MTTY_REGIONS_MAX (MTTY_MIGRATION_REGION_INDEX + 1)
> +
> +/* Data section start from page aligned offset */
> +#define MTTY_MIGRATION_REGION_DATA_OFFSET(0x1000)
> +
> +/* First page is used for struct vfio_device_migration_info */
> +#define MTTY_MIGRATION_REGION_SIZE_MMAP \
> + (MTTY_MIGRATION_REGION_SIZE - MTTY_MIGRATION_REGION_DATA_OFFSET)
> +
> +#define MIGRATION_INFO_OFFSET(MEMBER)\
> + offsetof(struct vfio_device_migration_info, MEMBER)
>  
>  #define STORE_LE16(addr, val)   (*(u16 *)addr = val)
>  #define STORE_LE32(addr, val)   (*(u32 *)addr = val)
> @@ -129,6 +143,28 @@ struct serial_port {
>   u8 intr_trigger_level;  /* interrupt trigger level */
>  };
>  
> +/* Migration packet */
> +#define PACKET_ID(u16)(0xfeedbaba)
> +
> +#define PACKET_FLAGS_ACTUAL_DATA (1 << 0)
> +#define PACKET_FLAGS_DUMMY_DATA  (1 << 1)
> +
> +#define PACKET_DATA_SIZE_MAX (8 * 1024 * 1024)
> +
> +struct packet {
> + u16 id;
> + u16 flags;
> + u32 data_size;
> + u8 data[];
> +};
> +
> +enum {
> + PACKET_STATE_NONE = 0,
> + PACKET_STATE_PREPARED,
> + PACKET_STATE_COPIED,
> + PACKET_STATE_LAST,
> +};
> +
>  /* State of each mdev device */
>  struct mdev_state {
>   int irq_fd;
> @@ -138,22 +174,37 @@ struct mdev_state {
>   u8 *vconfig;
>   struct mutex ops_lock;
>   struct mdev_device *mdev;
> - struct mdev_region_info region_info[VFIO_PCI_NUM_REGIONS];
> - u32 bar_mask[VFIO_PCI_NUM_REGIONS];
> + struct mdev_region_info region_info[MTTY_REGIONS_MAX];
> + u32 bar_mask[MTTY_REGIONS_MAX];
>   struct list_head next;
>   struct serial_port s[2];
>   struct mutex rxtx_lock;
>   struct vfio_device_info dev_info;
> - int nr_ports;
> + u32 nr_ports;
>  
>   /* List of pinned gpfns, gpfn as index and content is translated hpfn */
>   unsigned long *gpfn_to_hpfn;
>   struct notifier_block nb;
> +
> + u32 device_state;
> + u64 saved_size;
> + void *mig_region_base;
> + bool is_actual_data_sent;
> + struct packet *pkt;
> + u32 packet_state;
> + u64 dummy_data_size;
>  };
>  
>  static struct mutex mdev_list_lock;
>  static struct list_head mdev_devices_list;
>  
> +/*
> + * Default dummy data size set to 100 MB. To change value of dummy data size 
> at
> + * runtime but before migration write size in MB to sysfs file
> + * dummy_data_size_MB
> + */
> +static unsigned long user_dummy_data_size = (100 * 1024 * 1024);
> +
>  static const struct file_operations vd_fops = {
>   .owner  = THIS_MODULE,
>  };
> @@ -639,6 +690,288 @@ static void mdev_read_base(struct mdev_state 
> *mdev_state)
>   }
>  }
>  
> +static int save_setup(struct mdev_state *mdev_state)
> +{
> + mdev_state->is_actual_data_sent = false;
> +
> + memset(mdev_state->pkt, 0, sizeof(struct packet) +
> +PACKET_DATA_SIZE_MAX);
> +
> + return 0;
> +}
> +
> +static int set_device_state(struct mdev_state *mdev_state, u32 device_state)
> +{
> + int ret = 0;
> +
> + if (mdev_state->device_state == device_state)
> + return 0;
> +
> + if (device_state & VFIO_DEVICE_STATE_RUNNING) {
> +#if defined(DEBUG)
> + if (device_state & VFIO_DEVICE_STATE_SAVING) {
> + pr_info("%s: %s Pre-copy\n", __func__,
> + dev_name(mdev_dev(mdev_state->mdev)));
> + } else
> + pr_info("%s: %s Running\n", __func__,
> + 

Re: [PATCH] tests/acceptance/boot_linux: Skip slow Aarch64 'virt' machine TCG test

[Alex Bennée]

Philippe Mathieu-Daudé  writes:

> The BootLinuxAarch64.test_virt_tcg is reported to take >7min to run.
> Add a possibility to users to skip this particular test, by setting
> the AVOCADO_SKIP_SLOW_TESTS environment variable:
>
>   $ AVOCADO_SKIP_SLOW_TESTS=please make check-acceptance
>   ...
> (05/88) tests/acceptance/boot_linux.py:BootLinuxAarch64.test_virt_tcg: 
> SKIP: Test takes >7min
>   ...

7m = 420s - I'm seeing:

  hyperfine "./tests/venv/bin/avocado run 
./tests/acceptance/boot_linux.py:BootLinuxAarch64.test_virt_tcg"
  Benchmark #1: ./tests/venv/bin/avocado run 
./tests/acceptance/boot_linux.py:BootLinuxAarch64.test_virt_tcg
Time (mean ± σ): 162.179 s ±  3.138 s[User: 204.726 s, System: 
9.663 s]
Range (min … max):   158.651 s … 170.036 s10 runs

Is this on very slow hardware?


>
> Reported-by: Peter Maydell 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  tests/acceptance/boot_linux.py | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/tests/acceptance/boot_linux.py b/tests/acceptance/boot_linux.py
> index 075a386300..a8df50d769 100644
> --- a/tests/acceptance/boot_linux.py
> +++ b/tests/acceptance/boot_linux.py
> @@ -15,6 +15,7 @@
>  from qemu.accel import kvm_available
>  from qemu.accel import tcg_available
>  
> +from avocado import skipIf
>  from avocado.utils import cloudinit
>  from avocado.utils import network
>  from avocado.utils import vmimage
> @@ -159,6 +160,7 @@ def add_common_args(self):
>  self.vm.add_args('-device', 'virtio-rng-pci,rng=rng0')
>  self.vm.add_args('-object', 
> 'rng-random,id=rng0,filename=/dev/urandom')
>  
> +@skipIf(os.getenv('AVOCADO_SKIP_SLOW_TESTS'), 'Test takes >7min')
>  def test_virt_tcg(self):
>  """
>  :avocado: tags=accel:tcg


-- 
Alex Bennée

[PATCH] block/block-copy: fix use-after-free of task pointer

[Vladimir Sementsov-Ogievskiy]

Obviously, we should g_free the task after trace point and offset
update.

Reported-by: Coverity
Fixes: 4ce5dd3e9b5ee0fac18625860eb3727399ee965e
Signed-off-by: Vladimir Sementsov-Ogievskiy 
---

Be free to add Coverity number to the commit message, I don't know it.

 block/block-copy.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/block/block-copy.c b/block/block-copy.c
index 03500680f7..4713c8f2a3 100644
--- a/block/block-copy.c
+++ b/block/block-copy.c
@@ -591,13 +591,13 @@ static int coroutine_fn 
block_copy_dirty_clusters(BlockCopyState *s,
 }
 if (s->skip_unallocated && !(ret & BDRV_BLOCK_ALLOCATED)) {
 block_copy_task_end(task, 0);
-g_free(task);
 progress_set_remaining(s->progress,
bdrv_get_dirty_count(s->copy_bitmap) +
s->in_flight_bytes);
 trace_block_copy_skip_range(s, task->offset, task->bytes);
 offset = task_end(task);
 bytes = end - offset;
+g_free(task);
 continue;
 }
 task->zeroes = ret & BDRV_BLOCK_ZERO;
-- 
2.21.0

Re: [PATCH v4 5/5] block/block-copy: use aio-task-pool API

[Vladimir Sementsov-Ogievskiy]

07.05.2020 18:53, Kevin Wolf wrote:

Am 29.04.2020 um 15:08 hat Vladimir Sementsov-Ogievskiy geschrieben:

Run block_copy iterations in parallel in aio tasks.

Changes:
   - BlockCopyTask becomes aio task structure. Add zeroes field to pass
 it to block_copy_do_copy
   - add call state - it's a state of one call of block_copy(), shared
 between parallel tasks. For now used only to keep information about
 first error: is it read or not.
   - convert block_copy_dirty_clusters to aio-task loop.

Signed-off-by: Vladimir Sementsov-Ogievskiy 



@@ -519,6 +591,7 @@ static int coroutine_fn 
block_copy_dirty_clusters(BlockCopyState *s,
  }
  if (s->skip_unallocated && !(ret & BDRV_BLOCK_ALLOCATED)) {
  block_copy_task_end(task, 0);
+g_free(task);
  progress_set_remaining(s->progress,
 bdrv_get_dirty_count(s->copy_bitmap) +
 s->in_flight_bytes);
  trace_block_copy_skip_range(s, task->offset, task->bytes);
  offset = task_end(task);
  bytes = end - offset;


Coverity found this use after free for task. Please fix.



Oops. Done. Sorry for that :(


--
Best regards,
Vladimir

Re: [PATCH] linux-user/sparc64: Translate flushw opcode

[Richard Henderson]

On 4/10/20 2:14 PM, LemonBoy wrote:
> From 11d0cfe58d12e0f191b435ade88622cfceb2098a Mon Sep 17 00:00:00 2001
> From: LemonBoy 
> Date: Fri, 10 Apr 2020 22:55:26 +0200
> Subject: [PATCH] linux-user/sparc64: Translate flushw opcode
> 
> The ifdef logic should unconditionally compile in the `xop == 0x2b` case
> when targeting sparc64.
> 
> Fix the handling of window spill traps by keeping cansave into account
> when calculating the new CWP.

This is two separate fixes and should be two separate patches.

>  bsd-user/main.c | 4 +++-
>  linux-user/sparc/cpu_loop.c | 4 +++-

First patch,

>  target/sparc/translate.c| 2 ++
>  3 files changed, 8 insertions(+), 2 deletions(-)

Second patch.

> +/* cansave is zero if the spill trap handler is triggered by `save` and 
> */
> +/* nonzero if triggered by a `flushw` */

Format the comment like so:

/*
 * cansave is zero...
 * nonzero if ...
 */

> +save_window_offset(env, cpu_cwp_dec(env, env->cwp - env->cansave - 2));

But this does match the implementation in sparc_cpu_do_interrupt, so the change
is good.

> diff --git a/target/sparc/translate.c b/target/sparc/translate.c
> index 9416a551cf..1a4efd4ed6 100644
> --- a/target/sparc/translate.c
> +++ b/target/sparc/translate.c
> @@ -3663,6 +3663,8 @@ static void disas_sparc_insn(DisasContext * dc, 
> unsigned int insn)
>  #endif
>  gen_store_gpr(dc, rd, cpu_tmp0);
>  break;
> +#endif
> +#if defined(TARGET_SPARC64) || !defined(CONFIG_USER_ONLY)
>  } else if (xop == 0x2b) { /* rdtbr / V9 flushw */
>  #ifdef TARGET_SPARC64
>  gen_helper_flushw(cpu_env);

Look ok here too.


r~

Re: [PATCH v2 10/9] qed: Simplify backing reads

[Vladimir Sementsov-Ogievskiy]

07.05.2020 17:45, Eric Blake wrote:

The other four drivers that support backing files (qcow, qcow2,
parallels, vmdk) all rely on the block layer to populate zeroes when
reading beyond EOF of a short backing file.  We can simplify the qed
code by doing likewise.

Signed-off-by: Eric Blake 


Reviewed-by: Vladimir Sementsov-Ogievskiy 

--
Best regards,
Vladimir

Re: [PATCH Kernel v18 4/7] vfio iommu: Implementation of ioctl for dirty pages tracking.

[Alex Williamson]

On Thu, 7 May 2020 01:12:25 +0530
Kirti Wankhede  wrote:

> On 5/6/2020 1:45 PM, Yan Zhao wrote:
> > On Mon, May 04, 2020 at 11:58:56PM +0800, Kirti Wankhede wrote:  
> 
> 
> 
> >>   /*
> >>* Helper Functions for host iova-pfn list
> >>*/
> >> @@ -567,6 +654,18 @@ static int vfio_iommu_type1_pin_pages(void 
> >> *iommu_data,
> >>vfio_unpin_page_external(dma, iova, do_accounting);
> >>goto pin_unwind;
> >>}
> >> +
> >> +  if (iommu->dirty_page_tracking) {
> >> +  unsigned long pgshift =
> >> +   __ffs(vfio_pgsize_bitmap(iommu));
> >> +  
> > hi Kirti,
> > may I know if there's any vfio_pin_pages() happpening during NVidia's vGPU 
> > migration?
> > the code would enter into deadlock as I reported in last version.
> >   
> 
> Hm, you are right and same is the case in vfio_iommu_type1_dma_rw_chunk().
> 
> Instead of calling vfio_pgsize_bitmap() from lots of places, I'm 
> thinking of saving pgsize_bitmap in struct vfio_iommu, which should be 
> populated whenever domain_list is updated. Alex, will that be fine?

I've wondered why we don't already cache this, so yes, that's fine, but
the cached value will only be valid when evaluated under iommu->lock.
Thanks,

Alex

Re: [PATCH v16 QEMU 04/16] vfio: Add save and load functions for VFIO PCI devices

[Alex Williamson]

On Thu, 7 May 2020 11:10:40 +0530
Kirti Wankhede  wrote:

> On 5/7/2020 1:33 AM, Alex Williamson wrote:
> > On Thu, 7 May 2020 01:18:19 +0530
> > Kirti Wankhede  wrote:
> >   
> >> On 5/6/2020 11:41 AM, Yan Zhao wrote:  
> >>> On Tue, May 05, 2020 at 12:37:11PM +0800, Alex Williamson wrote:  
>  On Tue, 5 May 2020 04:48:37 +0530
>  Kirti Wankhede  wrote:
>  
> > On 3/26/2020 1:26 AM, Alex Williamson wrote:  
> >> On Wed, 25 Mar 2020 02:39:02 +0530
> >> Kirti Wankhede  wrote:
> >> 
> >>> These functions save and restore PCI device specific data - config
> >>> space of PCI device.
> >>> Tested save and restore with MSI and MSIX type.
> >>>
> >>> Signed-off-by: Kirti Wankhede 
> >>> Reviewed-by: Neo Jia 
> >>> ---
> >>> hw/vfio/pci.c | 163 
> >>> ++
> >>> include/hw/vfio/vfio-common.h |   2 +
> >>> 2 files changed, 165 insertions(+)
> >>>
> >>> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
> >>> index 6c77c12e44b9..8deb11e87ef7 100644
> >>> --- a/hw/vfio/pci.c
> >>> +++ b/hw/vfio/pci.c
> >>> @@ -41,6 +41,7 @@
> >>> #include "trace.h"
> >>> #include "qapi/error.h"
> >>> #include "migration/blocker.h"
> >>> +#include "migration/qemu-file.h"
> >>> 
> >>> #define TYPE_VFIO_PCI "vfio-pci"
> >>> #define PCI_VFIO(obj)OBJECT_CHECK(VFIOPCIDevice, obj, 
> >>> TYPE_VFIO_PCI)
> >>> @@ -1632,6 +1633,50 @@ static void vfio_bars_prepare(VFIOPCIDevice 
> >>> *vdev)
> >>> }
> >>> }
> >>> 
> >>> +static int vfio_bar_validate(VFIOPCIDevice *vdev, int nr)
> >>> +{
> >>> +PCIDevice *pdev = >pdev;
> >>> +VFIOBAR *bar = >bars[nr];
> >>> +uint64_t addr;
> >>> +uint32_t addr_lo, addr_hi = 0;
> >>> +
> >>> +/* Skip unimplemented BARs and the upper half of 64bit BARS. */
> >>> +if (!bar->size) {
> >>> +return 0;
> >>> +}
> >>> +
> >>> +addr_lo = pci_default_read_config(pdev, PCI_BASE_ADDRESS_0 + nr 
> >>> * 4, 4);
> >>> +
> >>> +addr_lo = addr_lo & (bar->ioport ? PCI_BASE_ADDRESS_IO_MASK :
> >>> +   PCI_BASE_ADDRESS_MEM_MASK);  
> >>
> >> Nit, &= or combine with previous set.
> >> 
> >>> +if (bar->type == PCI_BASE_ADDRESS_MEM_TYPE_64) {
> >>> +addr_hi = pci_default_read_config(pdev,
> >>> + PCI_BASE_ADDRESS_0 + (nr + 
> >>> 1) * 4, 4);
> >>> +}
> >>> +
> >>> +addr = ((uint64_t)addr_hi << 32) | addr_lo;  
> >>
> >> Could we use a union?
> >> 
> >>> +
> >>> +if (!QEMU_IS_ALIGNED(addr, bar->size)) {
> >>> +return -EINVAL;
> >>> +}  
> >>
> >> What specifically are we validating here?  This should be true no
> >> matter what we wrote to the BAR or else BAR emulation is broken.  The
> >> bits that could make this unaligned are not implemented in the BAR.
> >> 
> >>> +
> >>> +return 0;
> >>> +}
> >>> +
> >>> +static int vfio_bars_validate(VFIOPCIDevice *vdev)
> >>> +{
> >>> +int i, ret;
> >>> +
> >>> +for (i = 0; i < PCI_ROM_SLOT; i++) {
> >>> +ret = vfio_bar_validate(vdev, i);
> >>> +if (ret) {
> >>> +error_report("vfio: BAR address %d validation failed", 
> >>> i);
> >>> +return ret;
> >>> +}
> >>> +}
> >>> +return 0;
> >>> +}
> >>> +
> >>> static void vfio_bar_register(VFIOPCIDevice *vdev, int nr)
> >>> {
> >>> VFIOBAR *bar = >bars[nr];
> >>> @@ -2414,11 +2459,129 @@ static Object 
> >>> *vfio_pci_get_object(VFIODevice *vbasedev)
> >>> return OBJECT(vdev);
> >>> }
> >>> 
> >>> +static void vfio_pci_save_config(VFIODevice *vbasedev, QEMUFile *f)
> >>> +{
> >>> +VFIOPCIDevice *vdev = container_of(vbasedev, VFIOPCIDevice, 
> >>> vbasedev);
> >>> +PCIDevice *pdev = >pdev;
> >>> +uint16_t pci_cmd;
> >>> +int i;
> >>> +
> >>> +for (i = 0; i < PCI_ROM_SLOT; i++) {
> >>> +uint32_t bar;
> >>> +
> >>> +bar = pci_default_read_config(pdev, PCI_BASE_ADDRESS_0 + i * 
> >>> 4, 4);
> >>> +qemu_put_be32(f, bar);
> >>> +}
> >>> +
> >>> +qemu_put_be32(f, vdev->interrupt);
> >>> +if (vdev->interrupt == VFIO_INT_MSI) {
> >>> +uint32_t msi_flags, msi_addr_lo, msi_addr_hi = 0, msi_data;
> >>> +bool msi_64bit;
> >>> +
> >>> +msi_flags = pci_default_read_config(pdev, pdev->msi_cap + 
> >>> PCI_MSI_FLAGS,
> >>> +2);
> >>> +msi_64bit = 

Re: [PATCH v2 4/4] target/arm: Fix tcg_gen_gvec_dup_imm vs DUP (indexed)

[Laurent Desnogues]

On Thu, May 7, 2020 at 7:23 PM Richard Henderson
 wrote:
>
> DUP (indexed) can duplicate 128-bit elements, so using esz
> unconditionally can assert in tcg_gen_gvec_dup_imm.
>
> Fixes: 8711e71f9cbb
> Reported-by: Laurent Desnogues 
> Signed-off-by: Richard Henderson 

Reviewed-by: Laurent Desnogues 
Tested-by: Laurent Desnogues 

I had the same fix locally.

Thanks,

Laurent


> ---
>  target/arm/translate-sve.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/target/arm/translate-sve.c b/target/arm/translate-sve.c
> index c8649283be..83614e9e70 100644
> --- a/target/arm/translate-sve.c
> +++ b/target/arm/translate-sve.c
> @@ -2044,7 +2044,11 @@ static bool trans_DUP_x(DisasContext *s, arg_DUP_x *a)
>  unsigned nofs = vec_reg_offset(s, a->rn, index, esz);
>  tcg_gen_gvec_dup_mem(esz, dofs, nofs, vsz, vsz);
>  } else {
> -tcg_gen_gvec_dup_imm(esz, dofs, vsz, vsz, 0);
> +/*
> + * While dup_mem handles 128-bit elements, dup_imm does not.
> + * Thankfully element size doesn't matter for splatting zero.
> + */
> +tcg_gen_gvec_dup_imm(MO_64, dofs, vsz, vsz, 0);
>  }
>  }
>  return true;
> --
> 2.20.1
>

Re: [PATCH] target/ppc: Untabify excp_helper.c

[Philippe Mathieu-Daudé]

On 5/7/20 6:11 PM, Greg Kurz wrote:

Some tabs crept in with a recent change.

Fixes: 6dc6b557913f "target/ppc: Improve syscall exception logging"
Signed-off-by: Greg Kurz 


Reviewed-by: Philippe Mathieu-Daudé 
using `git-diff --ignore-space-change`.


---
  target/ppc/excp_helper.c |   16 
  1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/target/ppc/excp_helper.c b/target/ppc/excp_helper.c
index 639cac38f9c3..4db3d9ed9af5 100644
--- a/target/ppc/excp_helper.c
+++ b/target/ppc/excp_helper.c
@@ -70,16 +70,16 @@ static inline void dump_syscall(CPUPPCState *env)
  static inline void dump_hcall(CPUPPCState *env)
  {
  qemu_log_mask(CPU_LOG_INT, "hypercall r3=%016" PRIx64
- " r4=%016" PRIx64 " r5=%016" PRIx64 " r6=%016" PRIx64
- " r7=%016" PRIx64 " r8=%016" PRIx64 " r9=%016" PRIx64
- " r10=%016" PRIx64 " r11=%016" PRIx64 " r12=%016" PRIx64
+  " r4=%016" PRIx64 " r5=%016" PRIx64 " r6=%016" PRIx64
+  " r7=%016" PRIx64 " r8=%016" PRIx64 " r9=%016" PRIx64
+  " r10=%016" PRIx64 " r11=%016" PRIx64 " r12=%016" PRIx64
" nip=" TARGET_FMT_lx "\n",
ppc_dump_gpr(env, 3), ppc_dump_gpr(env, 4),
- ppc_dump_gpr(env, 5), ppc_dump_gpr(env, 6),
- ppc_dump_gpr(env, 7), ppc_dump_gpr(env, 8),
- ppc_dump_gpr(env, 9), ppc_dump_gpr(env, 10),
- ppc_dump_gpr(env, 11), ppc_dump_gpr(env, 12),
- env->nip);
+  ppc_dump_gpr(env, 5), ppc_dump_gpr(env, 6),
+  ppc_dump_gpr(env, 7), ppc_dump_gpr(env, 8),
+  ppc_dump_gpr(env, 9), ppc_dump_gpr(env, 10),
+  ppc_dump_gpr(env, 11), ppc_dump_gpr(env, 12),
+  env->nip);
  }
  
  static int powerpc_reset_wakeup(CPUState *cs, CPUPPCState *env, int excp,

Re: [PATCH v3 06/10] iotests: add testfinder.py

[Vladimir Sementsov-Ogievskiy]

21.04.2020 19:56, Kevin Wolf wrote:

Am 21.04.2020 um 09:35 hat Vladimir Sementsov-Ogievskiy geschrieben:

Add python script with new logic of searching for tests:

Current ./check behavior:
  - tests are named [0-9][0-9][0-9]
  - tests must be registered in group file (even if test doesn't belong
to any group, like 142)

Behavior of new test:
  - group file is dropped
  - tests are searched by file-name instead of group file, so it's not
needed more to "register the test", just create it with name
*-test. Old names like [0-9][0-9][0-9] are supported too, but not
recommended for new tests


I wonder if a tests/ subdirectory instead of the -test suffix would
organise things a bit better.



It will make more difficult to import iotests.py.. Calling common.rc from
bash tests will need to be modified too.

So, we'll need additional line in all python tests:

sys.path.append(os.path.join(os.path.dirname(__file__), '..'))

which doesn't seem to be good practice.. So, instead we'd better call tests 
with PYTHONPATH set appropriately..

and modify bash tests to do
. ../common.rc
. ../common.filter


or again, better to export BASH_TEST_LIB directory.

Is it worth doing?

I think, there are two variants:

1) keep as is: all in one directory, add *-test notation

2) go further and restructure to something like:

iotests/
iotests/tests/
iotests/lib/python/iotests.py
iotests/lib/bash/

And then, check script will export PYTHONPATH and BASH_TEST_LIB variables.

In case of [2], I definitely prefer to split directory tree refactoring to the 
separate series. So this series just rewrite check into python and get rid of 
group file.

What do you prefer?

--
Best regards,
Vladimir

Re: [PATCH 08/10] hw/block: Let the NVMe emulated device be target-agnostic

[Philippe Mathieu-Daudé]

On 5/7/20 7:39 PM, Philippe Mathieu-Daudé wrote:

Now than qemu_ram_msync() has been ...


Oops =)

"Now than qemu_ram_msync() is no more target-specific, we can
make this device-generic."



Signed-off-by: Philippe Mathieu-Daudé 
---
  hw/block/Makefile.objs | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/block/Makefile.objs b/hw/block/Makefile.objs
index 47960b5f0d..8855c22656 100644
--- a/hw/block/Makefile.objs
+++ b/hw/block/Makefile.objs
@@ -13,6 +13,6 @@ common-obj-$(CONFIG_SH4) += tc58128.o
  
  obj-$(CONFIG_VIRTIO_BLK) += virtio-blk.o

  obj-$(CONFIG_VHOST_USER_BLK) += vhost-user-blk.o
-obj-$(CONFIG_NVME_PCI) += nvme.o
+common-obj-$(CONFIG_NVME_PCI) += nvme.o
  
  obj-y += dataplane/

[PATCH 10/10] exec: Move cpu_physical_memory_* functions to 'exec/memory-internal.h'

[Philippe Mathieu-Daudé]

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/exec/memory-internal.h | 305 -
 include/exec/ram_addr.h| 303 +---
 accel/tcg/cputlb.c |   1 -
 hw/ppc/spapr.c |   1 -
 hw/ppc/spapr_pci.c |   1 -
 memory.c   |   1 -
 6 files changed, 305 insertions(+), 307 deletions(-)

diff --git a/include/exec/memory-internal.h b/include/exec/memory-internal.h
index b2b7c1e78a..4abb3bbd85 100644
--- a/include/exec/memory-internal.h
+++ b/include/exec/memory-internal.h
@@ -21,8 +21,13 @@
 #define MEMORY_INTERNAL_H
 
 #include "cpu.h"
+#include "sysemu/tcg.h"
+#include "sysemu/xen.h"
+#include "exec/ramlist.h"
+#include "exec/ramblock.h"
 
 #ifdef CONFIG_SOFTMMU
+
 static inline AddressSpaceDispatch *flatview_to_dispatch(FlatView *fv)
 {
 return fv->dispatch;
@@ -49,5 +54,303 @@ void address_space_dispatch_free(AddressSpaceDispatch *d);
 
 void mtree_print_dispatch(struct AddressSpaceDispatch *d,
   MemoryRegion *root);
-#endif
+
+#define DIRTY_CLIENTS_ALL ((1 << DIRTY_MEMORY_NUM) - 1)
+#define DIRTY_CLIENTS_NOCODE  (DIRTY_CLIENTS_ALL & ~(1 << DIRTY_MEMORY_CODE))
+
+static inline bool cpu_physical_memory_get_dirty(ram_addr_t start,
+ ram_addr_t length,
+ unsigned client)
+{
+DirtyMemoryBlocks *blocks;
+unsigned long end, page;
+unsigned long idx, offset, base;
+bool dirty = false;
+
+assert(client < DIRTY_MEMORY_NUM);
+
+end = TARGET_PAGE_ALIGN(start + length) >> TARGET_PAGE_BITS;
+page = start >> TARGET_PAGE_BITS;
+
+WITH_RCU_READ_LOCK_GUARD() {
+blocks = atomic_rcu_read(_list.dirty_memory[client]);
+
+idx = page / DIRTY_MEMORY_BLOCK_SIZE;
+offset = page % DIRTY_MEMORY_BLOCK_SIZE;
+base = page - offset;
+while (page < end) {
+unsigned long next = MIN(end, base + DIRTY_MEMORY_BLOCK_SIZE);
+unsigned long num = next - base;
+unsigned long found = find_next_bit(blocks->blocks[idx],
+num, offset);
+if (found < num) {
+dirty = true;
+break;
+}
+
+page = next;
+idx++;
+offset = 0;
+base += DIRTY_MEMORY_BLOCK_SIZE;
+}
+}
+
+return dirty;
+}
+
+static inline bool cpu_physical_memory_all_dirty(ram_addr_t start,
+ ram_addr_t length,
+ unsigned client)
+{
+DirtyMemoryBlocks *blocks;
+unsigned long end, page;
+unsigned long idx, offset, base;
+bool dirty = true;
+
+assert(client < DIRTY_MEMORY_NUM);
+
+end = TARGET_PAGE_ALIGN(start + length) >> TARGET_PAGE_BITS;
+page = start >> TARGET_PAGE_BITS;
+
+RCU_READ_LOCK_GUARD();
+
+blocks = atomic_rcu_read(_list.dirty_memory[client]);
+
+idx = page / DIRTY_MEMORY_BLOCK_SIZE;
+offset = page % DIRTY_MEMORY_BLOCK_SIZE;
+base = page - offset;
+while (page < end) {
+unsigned long next = MIN(end, base + DIRTY_MEMORY_BLOCK_SIZE);
+unsigned long num = next - base;
+unsigned long found = find_next_zero_bit(blocks->blocks[idx],
+ num, offset);
+if (found < num) {
+dirty = false;
+break;
+}
+
+page = next;
+idx++;
+offset = 0;
+base += DIRTY_MEMORY_BLOCK_SIZE;
+}
+
+return dirty;
+}
+
+static inline bool cpu_physical_memory_get_dirty_flag(ram_addr_t addr,
+  unsigned client)
+{
+return cpu_physical_memory_get_dirty(addr, 1, client);
+}
+
+static inline bool cpu_physical_memory_is_clean(ram_addr_t addr)
+{
+bool vga = cpu_physical_memory_get_dirty_flag(addr, DIRTY_MEMORY_VGA);
+bool code = cpu_physical_memory_get_dirty_flag(addr, DIRTY_MEMORY_CODE);
+bool migration = cpu_physical_memory_get_dirty_flag(addr,
+
DIRTY_MEMORY_MIGRATION);
+return !(vga && code && migration);
+}
+
+static inline uint8_t cpu_physical_memory_range_includes_clean(ram_addr_t 
start,
+ram_addr_t length,
+uint8_t mask)
+{
+uint8_t ret = 0;
+
+if (mask & (1 << DIRTY_MEMORY_VGA) &&
+!cpu_physical_memory_all_dirty(start, length, DIRTY_MEMORY_VGA)) {
+ret |= (1 << DIRTY_MEMORY_VGA);
+}
+if (mask & (1 << DIRTY_MEMORY_CODE) &&
+!cpu_physical_memory_all_dirty(start, length, DIRTY_MEMORY_CODE)) {
+ret |= (1 << DIRTY_MEMORY_CODE);
+}
+if (mask & (1 << DIRTY_MEMORY_MIGRATION) &&
+!cpu_physical_memory_all_dirty(start, 

[PATCH 09/10] exec: Update coding style to make checkpatch.pl happy

[Philippe Mathieu-Daudé]

We will move this code in the next commit. Clean it up
first to avoid checkpatch.pl errors.

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/exec/ram_addr.h | 24 +++-
 1 file changed, 15 insertions(+), 9 deletions(-)

diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h
index 0deffad66f..6acde47a0f 100644
--- a/include/exec/ram_addr.h
+++ b/include/exec/ram_addr.h
@@ -95,7 +95,8 @@ static inline bool cpu_physical_memory_all_dirty(ram_addr_t 
start,
 while (page < end) {
 unsigned long next = MIN(end, base + DIRTY_MEMORY_BLOCK_SIZE);
 unsigned long num = next - base;
-unsigned long found = find_next_zero_bit(blocks->blocks[idx], num, 
offset);
+unsigned long found = find_next_zero_bit(blocks->blocks[idx],
+ num, offset);
 if (found < num) {
 dirty = false;
 break;
@@ -120,14 +121,14 @@ static inline bool 
cpu_physical_memory_is_clean(ram_addr_t addr)
 {
 bool vga = cpu_physical_memory_get_dirty_flag(addr, DIRTY_MEMORY_VGA);
 bool code = cpu_physical_memory_get_dirty_flag(addr, DIRTY_MEMORY_CODE);
-bool migration =
-cpu_physical_memory_get_dirty_flag(addr, DIRTY_MEMORY_MIGRATION);
+bool migration = cpu_physical_memory_get_dirty_flag(addr,
+
DIRTY_MEMORY_MIGRATION);
 return !(vga && code && migration);
 }
 
 static inline uint8_t cpu_physical_memory_range_includes_clean(ram_addr_t 
start,
-   ram_addr_t 
length,
-   uint8_t mask)
+ram_addr_t length,
+uint8_t mask)
 {
 uint8_t ret = 0;
 
@@ -272,7 +273,8 @@ static inline void 
cpu_physical_memory_set_dirty_lebitmap(unsigned long *bitmap,
 
 xen_hvm_modified_memory(start, pages << TARGET_PAGE_BITS);
 } else {
-uint8_t clients = tcg_enabled() ? DIRTY_CLIENTS_ALL : 
DIRTY_CLIENTS_NOCODE;
+uint8_t clients = tcg_enabled()
+  ? DIRTY_CLIENTS_ALL : DIRTY_CLIENTS_NOCODE;
 
 if (!global_dirty_log) {
 clients &= ~(1 << DIRTY_MEMORY_MIGRATION);
@@ -304,8 +306,11 @@ bool cpu_physical_memory_test_and_clear_dirty(ram_addr_t 
start,
   ram_addr_t length,
   unsigned client);
 
-DirtyBitmapSnapshot *cpu_physical_memory_snapshot_and_clear_dirty
-(MemoryRegion *mr, hwaddr offset, hwaddr length, unsigned client);
+DirtyBitmapSnapshot *cpu_physical_memory_snapshot_and_clear_dirty(
+MemoryRegion *mr,
+hwaddr offset,
+hwaddr length,
+unsigned client);
 
 bool cpu_physical_memory_snapshot_get_dirty(DirtyBitmapSnapshot *snap,
 ram_addr_t start,
@@ -314,7 +319,8 @@ bool 
cpu_physical_memory_snapshot_get_dirty(DirtyBitmapSnapshot *snap,
 static inline void cpu_physical_memory_clear_dirty_range(ram_addr_t start,
  ram_addr_t length)
 {
-cpu_physical_memory_test_and_clear_dirty(start, length, 
DIRTY_MEMORY_MIGRATION);
+cpu_physical_memory_test_and_clear_dirty(start, length,
+ DIRTY_MEMORY_MIGRATION);
 cpu_physical_memory_test_and_clear_dirty(start, length, DIRTY_MEMORY_VGA);
 cpu_physical_memory_test_and_clear_dirty(start, length, DIRTY_MEMORY_CODE);
 }
-- 
2.21.3

[PATCH 06/10] exec: Move ramblock_recv_bitmap_offset() to migration/ram.c

[Philippe Mathieu-Daudé]

The ramblock_recv_bitmap_offset() function is only used once
in migration/ram.c, move it there.

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/exec/ram_addr.h | 8 
 migration/ram.c | 8 
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h
index 195b67d3c8..c61d5188f7 100644
--- a/include/exec/ram_addr.h
+++ b/include/exec/ram_addr.h
@@ -83,14 +83,6 @@ static inline void *ramblock_ptr(RAMBlock *block, ram_addr_t 
offset)
 return (char *)block->host + offset;
 }
 
-static inline unsigned long int ramblock_recv_bitmap_offset(void *host_addr,
-RAMBlock *rb)
-{
-uint64_t host_addr_offset =
-(uint64_t)(uintptr_t)(host_addr - (void *)rb->host);
-return host_addr_offset >> TARGET_PAGE_BITS;
-}
-
 bool ramblock_is_pmem(RAMBlock *rb);
 
 /**
diff --git a/migration/ram.c b/migration/ram.c
index 53166fc279..0cd16d0519 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -190,6 +190,14 @@ int foreach_not_ignored_block(RAMBlockIterFunc func, void 
*opaque)
 return ret;
 }
 
+static inline unsigned long int ramblock_recv_bitmap_offset(void *host_addr,
+RAMBlock *rb)
+{
+uint64_t host_addr_offset =
+(uint64_t)(uintptr_t)(host_addr - (void *)rb->host);
+return host_addr_offset >> TARGET_PAGE_BITS;
+}
+
 static void ramblock_recv_map_init(void)
 {
 RAMBlock *rb;
-- 
2.21.3

[PATCH 04/10] exec/memory-internal: Check CONFIG_SOFTMMU instead of CONFIG_USER_ONLY

[Philippe Mathieu-Daudé]

The CONFIG_SOFTMMU definition is poisoned in "exec/poison.h".
As this header is internal, check for poisoned CONFIG_SOFTMMU
instead of CONFIG_USER_ONLY to make this include harder to use.

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/exec/memory-internal.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/exec/memory-internal.h b/include/exec/memory-internal.h
index 9fcc2af25c..b2b7c1e78a 100644
--- a/include/exec/memory-internal.h
+++ b/include/exec/memory-internal.h
@@ -22,7 +22,7 @@
 
 #include "cpu.h"
 
-#ifndef CONFIG_USER_ONLY
+#ifdef CONFIG_SOFTMMU
 static inline AddressSpaceDispatch *flatview_to_dispatch(FlatView *fv)
 {
 return fv->dispatch;
-- 
2.21.3

RE: [PATCH] accel: Move Xen accelerator code under accel/xen/

[Paul Durrant]

> -Original Message-
> From: Philippe Mathieu-Daudé 
> Sent: 07 May 2020 16:58
> To: qemu-devel@nongnu.org
> Cc: Philippe Mathieu-Daudé ; 
> xen-de...@lists.xenproject.org; Stefano Stabellini
> ; Aleksandar Markovic 
> ; Aurelien Jarno
> ; Paolo Bonzini ; Igor Mammedov 
> ;
> Eduardo Habkost ; Richard Henderson ; 
> Marcel Apfelbaum
> ; Dr. David Alan Gilbert ; 
> Juan Quintela
> ; Michael S. Tsirkin ; Paul Durrant 
> ; Anthony
> Perard 
> Subject: [PATCH] accel: Move Xen accelerator code under accel/xen/
> 
> This code is not related to hardware emulation.
> Move it under accel/ with the other hypervisors.
> 
> Signed-off-by: Philippe Mathieu-Daudé 

Reviewed-by: Paul Durrant 

[PATCH 08/10] hw/block: Let the NVMe emulated device be target-agnostic

[Philippe Mathieu-Daudé]

Now than qemu_ram_msync() has been ...

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/block/Makefile.objs | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/block/Makefile.objs b/hw/block/Makefile.objs
index 47960b5f0d..8855c22656 100644
--- a/hw/block/Makefile.objs
+++ b/hw/block/Makefile.objs
@@ -13,6 +13,6 @@ common-obj-$(CONFIG_SH4) += tc58128.o
 
 obj-$(CONFIG_VIRTIO_BLK) += virtio-blk.o
 obj-$(CONFIG_VHOST_USER_BLK) += vhost-user-blk.o
-obj-$(CONFIG_NVME_PCI) += nvme.o
+common-obj-$(CONFIG_NVME_PCI) += nvme.o
 
 obj-y += dataplane/
-- 
2.21.3

[PATCH 02/10] exec/ramblock: Add missing 'qemu/rcu.h' include

[Philippe Mathieu-Daudé]

The first field of RAMBlock is a rcu_head structure.
We need to include the "qemu/rcu.h" to avoid errors when
including "exec/ramblock.h" without "qemu/rcu.h":

  include/exec/ramblock.h:27:21: error: field ‘rcu’ has incomplete type
 27 | struct rcu_head rcu;
| ^~~
  include/exec/ramblock.h:39:5: error: expected specifier-qualifier-list before 
‘QLIST_ENTRY’
 39 | QLIST_ENTRY(RAMBlock) next;
| ^~~

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/exec/ramblock.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/exec/ramblock.h b/include/exec/ramblock.h
index 07d50864d8..6ac0aa7a89 100644
--- a/include/exec/ramblock.h
+++ b/include/exec/ramblock.h
@@ -21,6 +21,7 @@
 
 #ifndef CONFIG_USER_ONLY
 #include "cpu-common.h"
+#include "qemu/rcu.h"
 
 struct RAMBlock {
 struct rcu_head rcu;
-- 
2.21.3

[PATCH 03/10] exec: Move tb_invalidate_phys_range() to 'exec/exec-all.h'

[Philippe Mathieu-Daudé]

Move tb_invalidate_phys_range() to "exec/exec-all.h" with the
other TranslationBlock invalidate functions. Move all these
functions altogether. Check for the CONFIG_SOFTMMU definition
which is more explicit than CONFIG_USER_ONLY.

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/exec/exec-all.h | 14 --
 include/exec/ram_addr.h |  2 --
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/include/exec/exec-all.h b/include/exec/exec-all.h
index 350c4b451b..f1a9b8a576 100644
--- a/include/exec/exec-all.h
+++ b/include/exec/exec-all.h
@@ -454,12 +454,15 @@ static inline uint32_t curr_cflags(void)
 }
 
 /* TranslationBlock invalidate API */
-#if defined(CONFIG_USER_ONLY)
+#ifdef CONFIG_SOFTMMU
+void tb_invalidate_phys_addr(AddressSpace *as, hwaddr addr, MemTxAttrs attrs);
+void tb_invalidate_phys_range(ram_addr_t start, ram_addr_t end);
+void tb_flush_jmp_cache(CPUState *cpu, target_ulong addr);
+#else
 void tb_invalidate_phys_addr(target_ulong addr);
 void tb_invalidate_phys_range(target_ulong start, target_ulong end);
-#else
-void tb_invalidate_phys_addr(AddressSpace *as, hwaddr addr, MemTxAttrs attrs);
-#endif
+#endif /* CONFIG_SOFTMMU */
+
 void tb_flush(CPUState *cpu);
 void tb_phys_invalidate(TranslationBlock *tb, tb_page_addr_t page_addr);
 TranslationBlock *tb_htable_lookup(CPUState *cpu, target_ulong pc,
@@ -583,7 +586,6 @@ void tlb_reset_dirty(CPUState *cpu, ram_addr_t start1, 
ram_addr_t length);
 void tlb_set_dirty(CPUState *cpu, target_ulong vaddr);
 
 /* exec.c */
-void tb_flush_jmp_cache(CPUState *cpu, target_ulong addr);
 
 MemoryRegionSection *
 address_space_translate_for_iotlb(CPUState *cpu, int asidx, hwaddr addr,
@@ -591,7 +593,7 @@ address_space_translate_for_iotlb(CPUState *cpu, int asidx, 
hwaddr addr,
   MemTxAttrs attrs, int *prot);
 hwaddr memory_region_section_get_iotlb(CPUState *cpu,
MemoryRegionSection *section);
-#endif
+#endif /* CONFIG_USER_ONLY */
 
 /* vl.c */
 extern int singlestep;
diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h
index 7b5c24e928..06096e8c6a 100644
--- a/include/exec/ram_addr.h
+++ b/include/exec/ram_addr.h
@@ -147,8 +147,6 @@ static inline void qemu_ram_block_writeback(RAMBlock *block)
 #define DIRTY_CLIENTS_ALL ((1 << DIRTY_MEMORY_NUM) - 1)
 #define DIRTY_CLIENTS_NOCODE  (DIRTY_CLIENTS_ALL & ~(1 << DIRTY_MEMORY_CODE))
 
-void tb_invalidate_phys_range(ram_addr_t start, ram_addr_t end);
-
 static inline bool cpu_physical_memory_get_dirty(ram_addr_t start,
  ram_addr_t length,
  unsigned client)
-- 
2.21.3