[PATCH 1/2] migration/rdma: Try to register On-Demand Paging memory region
Previously, for the fsdax mem-backend-file, it will register failed with
Operation not supported. In this case, we can try to register it with
On-Demand Paging[1] like what rpma_mr_reg() does on rpma[2].
[1]:
https://community.mellanox.com/s/article/understanding-on-demand-paging--odp-x
[2]: http://pmem.io/rpma/manpages/v0.9.0/rpma_mr_reg.3
Signed-off-by: Li Zhijian
---
migration/rdma.c | 27 ++-
migration/trace-events | 1 +
2 files changed, 19 insertions(+), 9 deletions(-)
diff --git a/migration/rdma.c b/migration/rdma.c
index 5c2d113aa94..8784b5f22a6 100644
--- a/migration/rdma.c
+++ b/migration/rdma.c
@@ -1123,15 +1123,21 @@ static int qemu_rdma_reg_whole_ram_blocks(RDMAContext
*rdma)
RDMALocalBlocks *local = &rdma->local_ram_blocks;
for (i = 0; i < local->nb_blocks; i++) {
+int access = IBV_ACCESS_LOCAL_WRITE | IBV_ACCESS_REMOTE_WRITE;
+
+on_demand:
local->block[i].mr =
ibv_reg_mr(rdma->pd,
local->block[i].local_host_addr,
-local->block[i].length,
-IBV_ACCESS_LOCAL_WRITE |
-IBV_ACCESS_REMOTE_WRITE
+local->block[i].length, access
);
if (!local->block[i].mr) {
-perror("Failed to register local dest ram block!");
+if (!(access & IBV_ACCESS_ON_DEMAND) && errno == ENOTSUP) {
+access |= IBV_ACCESS_ON_DEMAND;
+trace_qemu_rdma_register_odp_mr(local->block[i].block_name);
+goto on_demand;
+}
+perror("Failed to register local dest ram block!\n");
break;
}
rdma->total_registrations++;
@@ -1215,15 +1221,18 @@ static int qemu_rdma_register_and_get_keys(RDMAContext
*rdma,
*/
if (!block->pmr[chunk]) {
uint64_t len = chunk_end - chunk_start;
+int access = rkey ? IBV_ACCESS_LOCAL_WRITE | IBV_ACCESS_REMOTE_WRITE :
0;
trace_qemu_rdma_register_and_get_keys(len, chunk_start);
-block->pmr[chunk] = ibv_reg_mr(rdma->pd,
-chunk_start, len,
-(rkey ? (IBV_ACCESS_LOCAL_WRITE |
-IBV_ACCESS_REMOTE_WRITE) : 0));
-
+on_demand:
+block->pmr[chunk] = ibv_reg_mr(rdma->pd, chunk_start, len, access);
if (!block->pmr[chunk]) {
+if (!(access & IBV_ACCESS_ON_DEMAND) && errno == ENOTSUP) {
+access |= IBV_ACCESS_ON_DEMAND;
+trace_qemu_rdma_register_odp_mr(block->block_name);
+goto on_demand;
+}
perror("Failed to register chunk!");
fprintf(stderr, "Chunk details: block: %d chunk index %d"
" start %" PRIuPTR " end %" PRIuPTR
diff --git a/migration/trace-events b/migration/trace-events
index a1c0f034ab8..5f6aa580def 100644
--- a/migration/trace-events
+++ b/migration/trace-events
@@ -212,6 +212,7 @@ qemu_rdma_poll_write(const char *compstr, int64_t comp, int
left, uint64_t block
qemu_rdma_poll_other(const char *compstr, int64_t comp, int left) "other
completion %s (%" PRId64 ") received left %d"
qemu_rdma_post_send_control(const char *desc) "CONTROL: sending %s.."
qemu_rdma_register_and_get_keys(uint64_t len, void *start) "Registering %"
PRIu64 " bytes @ %p"
+qemu_rdma_register_odp_mr(const char *name) "Try to register On-Demand Paging
memory region: %s"
qemu_rdma_registration_handle_compress(int64_t length, int index, int64_t
offset) "Zapping zero chunk: %" PRId64 " bytes, index %d, offset %" PRId64
qemu_rdma_registration_handle_finished(void) ""
qemu_rdma_registration_handle_ram_blocks(void) ""
--
2.31.1
[PATCH 0/2] enable fsdax rdma migration
Previous qemu face 2 problems when migrating a fsdax memory backend with RDMA protocol. (1) ibv_reg_mr failed with Operation not supported (2) requester(source) side could receive RNR NAK. For the (1), we can try to register memory region with ODP feature which has already been implemented in some modern HCA hardware/drivers. For the (2), IB provides advise API to prefetch pages in specific memory region. It can help driver reduce the page fault on responder(destination) side during RDMA_WRITE. Li Zhijian (2): migration/rdma: Try to register On-Demand Paging memory region migration/rdma: advise prefetch write for ODP region migration/rdma.c | 67 -- migration/trace-events | 2 ++ 2 files changed, 60 insertions(+), 9 deletions(-) -- 2.31.1
[PATCH 2/2] migration/rdma: advise prefetch write for ODP region
The responder mr registering with ODP will sent RNR NAK back to
the requester in the face of the page fault.
-
ibv_poll_cq wc.status=13 RNR retry counter exceeded!
ibv_poll_cq wrid=WRITE RDMA!
-
ibv_advise_mr(3) helps to make pages present before the actual IO is
conducted so that the responder does page fault as little as possible.
Signed-off-by: Li Zhijian
---
migration/rdma.c | 40
migration/trace-events | 1 +
2 files changed, 41 insertions(+)
diff --git a/migration/rdma.c b/migration/rdma.c
index 8784b5f22a6..a2ad00d665f 100644
--- a/migration/rdma.c
+++ b/migration/rdma.c
@@ -1117,6 +1117,30 @@ static int qemu_rdma_alloc_qp(RDMAContext *rdma)
return 0;
}
+/*
+ * ibv_advise_mr to avoid RNR NAK error as far as possible.
+ * The responder mr registering with ODP will sent RNR NAK back to
+ * the requester in the face of the page fault.
+ */
+static void qemu_rdma_advise_prefetch_write_mr(struct ibv_pd *pd, uint64_t
addr,
+ uint32_t len, uint32_t lkey,
+ const char *name, bool wr)
+{
+int ret;
+int advice = wr ? IBV_ADVISE_MR_ADVICE_PREFETCH_WRITE :
+ IBV_ADVISE_MR_ADVICE_PREFETCH;
+struct ibv_sge sg_list = {.lkey = lkey, .addr = addr, .length = len};
+
+ret = ibv_advise_mr(pd, advice,
+IB_UVERBS_ADVISE_MR_FLAG_FLUSH, &sg_list, 1);
+/* ignore the error */
+if (ret) {
+trace_qemu_rdma_advise_mr(name, len, addr, strerror(errno));
+} else {
+trace_qemu_rdma_advise_mr(name, len, addr, "successed");
+}
+}
+
static int qemu_rdma_reg_whole_ram_blocks(RDMAContext *rdma)
{
int i;
@@ -1140,6 +1164,17 @@ on_demand:
perror("Failed to register local dest ram block!\n");
break;
}
+
+if (access & IBV_ACCESS_ON_DEMAND) {
+qemu_rdma_advise_prefetch_write_mr(rdma->pd,
+ (uintptr_t)
+ local->block[i].local_host_addr,
+ local->block[i].length,
+ local->block[i].mr->lkey,
+ local->block[i].block_name,
+ true);
+}
+
rdma->total_registrations++;
}
@@ -1244,6 +1279,11 @@ on_demand:
rdma->total_registrations);
return -1;
}
+if (access & IBV_ACCESS_ON_DEMAND) {
+qemu_rdma_advise_prefetch_write_mr(rdma->pd,
(uintptr_t)chunk_start,
+ len, block->pmr[chunk]->lkey,
+ block->block_name, rkey);
+}
rdma->total_registrations++;
}
diff --git a/migration/trace-events b/migration/trace-events
index 5f6aa580def..901c1d54c12 100644
--- a/migration/trace-events
+++ b/migration/trace-events
@@ -213,6 +213,7 @@ qemu_rdma_poll_other(const char *compstr, int64_t comp, int
left) "other complet
qemu_rdma_post_send_control(const char *desc) "CONTROL: sending %s.."
qemu_rdma_register_and_get_keys(uint64_t len, void *start) "Registering %"
PRIu64 " bytes @ %p"
qemu_rdma_register_odp_mr(const char *name) "Try to register On-Demand Paging
memory region: %s"
+qemu_rdma_advise_mr(const char *name, uint32_t len, uint64_t addr, const char
*res) "Try to advise block %s prefetch write at %" PRIu32 "@0x%" PRIx64 ": %s"
qemu_rdma_registration_handle_compress(int64_t length, int index, int64_t
offset) "Zapping zero chunk: %" PRId64 " bytes, index %d, offset %" PRId64
qemu_rdma_registration_handle_finished(void) ""
qemu_rdma_registration_handle_ram_blocks(void) ""
--
2.31.1
[PATCH v2 2/2] migration: allow enabling mutilfd for specific protocol only
And change the default to true so that in '-incoming defer' case, user is able
to change multifd capability.
Signed-off-by: Li Zhijian
---
migration/migration.c | 8
migration/multifd.c | 2 +-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/migration/migration.c b/migration/migration.c
index 212314541f1..b4d0e66cf7b 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -1249,6 +1249,14 @@ static bool migrate_caps_check(bool *cap_list,
}
}
+/* incoming side only */
+if (runstate_check(RUN_STATE_INMIGRATE) &&
+!migrate_multifd_is_allowed() &&
+cap_list[MIGRATION_CAPABILITY_MULTIFD]) {
+error_setg(errp, "multifd is not supported by current protocol");
+return false;
+}
+
return true;
}
diff --git a/migration/multifd.c b/migration/multifd.c
index 4a4d16d3888..4643b25c9db 100644
--- a/migration/multifd.c
+++ b/migration/multifd.c
@@ -864,7 +864,7 @@ cleanup:
multifd_new_send_channel_cleanup(p, sioc, local_err);
}
-static bool migrate_allow_multifd;
+static bool migrate_allow_multifd = true;
void migrate_protocol_allow_multifd(bool allow)
{
migrate_allow_multifd = allow;
--
2.31.1
[PATCH v2 1/2] migration: allow multifd for socket protocol only
multifd with unsupported protocol will cause a segment fault.
(gdb) bt
#0 0x563b4a93faf8 in socket_connect (addr=0x0, errp=0x7f7f02675410) at
../util/qemu-sockets.c:1190
#1 0x563b4a797a03 in qio_channel_socket_connect_sync (ioc=0x563b4d16e8c0,
addr=0x0, errp=0x7f7f02675410) at ../io/channel-socket.c:145
#2 0x563b4a797abf in qio_channel_socket_connect_worker
(task=0x563b4cd86c30, opaque=0x0) at ../io/channel-socket.c:168
#3 0x563b4a792631 in qio_task_thread_worker (opaque=0x563b4cd86c30) at
../io/task.c:124
#4 0x563b4a91da69 in qemu_thread_start (args=0x563b4c44bb80) at
../util/qemu-thread-posix.c:541
#5 0x7f7fe9b5b3f9 in ?? ()
#6 0x in ?? ()
It's enough to check migrate_multifd_is_allowed() in multifd cleanup() and
multifd setup() though there are so many other places using
migrate_use_multifd().
Signed-off-by: Li Zhijian
---
migration/migration.c | 4
migration/multifd.c | 24 ++--
migration/multifd.h | 2 ++
3 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/migration/migration.c b/migration/migration.c
index 2d306582ebf..212314541f1 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -456,10 +456,12 @@ static void qemu_start_incoming_migration(const char
*uri, Error **errp)
{
const char *p = NULL;
+migrate_protocol_allow_multifd(false); /* reset it anyway */
qapi_event_send_migration(MIGRATION_STATUS_SETUP);
if (strstart(uri, "tcp:", &p) ||
strstart(uri, "unix:", NULL) ||
strstart(uri, "vsock:", NULL)) {
+migrate_protocol_allow_multifd(true);
socket_start_incoming_migration(p ? p : uri, errp);
#ifdef CONFIG_RDMA
} else if (strstart(uri, "rdma:", &p)) {
@@ -2289,9 +2291,11 @@ void qmp_migrate(const char *uri, bool has_blk, bool blk,
}
}
+migrate_protocol_allow_multifd(false);
if (strstart(uri, "tcp:", &p) ||
strstart(uri, "unix:", NULL) ||
strstart(uri, "vsock:", NULL)) {
+migrate_protocol_allow_multifd(true);
socket_start_outgoing_migration(s, p ? p : uri, &local_err);
#ifdef CONFIG_RDMA
} else if (strstart(uri, "rdma:", &p)) {
diff --git a/migration/multifd.c b/migration/multifd.c
index ab41590e714..4a4d16d3888 100644
--- a/migration/multifd.c
+++ b/migration/multifd.c
@@ -531,7 +531,7 @@ void multifd_save_cleanup(void)
{
int i;
-if (!migrate_use_multifd()) {
+if (!migrate_use_multifd() || !migrate_multifd_is_allowed()) {
return;
}
multifd_send_terminate_threads(NULL);
@@ -864,6 +864,17 @@ cleanup:
multifd_new_send_channel_cleanup(p, sioc, local_err);
}
+static bool migrate_allow_multifd;
+void migrate_protocol_allow_multifd(bool allow)
+{
+migrate_allow_multifd = allow;
+}
+
+bool migrate_multifd_is_allowed(void)
+{
+return migrate_allow_multifd;
+}
+
int multifd_save_setup(Error **errp)
{
int thread_count;
@@ -874,6 +885,11 @@ int multifd_save_setup(Error **errp)
if (!migrate_use_multifd()) {
return 0;
}
+if (!migrate_multifd_is_allowed()) {
+error_setg(errp, "multifd is not supported by current protocol");
+return -1;
+}
+
s = migrate_get_current();
thread_count = migrate_multifd_channels();
multifd_send_state = g_malloc0(sizeof(*multifd_send_state));
@@ -967,7 +983,7 @@ int multifd_load_cleanup(Error **errp)
{
int i;
-if (!migrate_use_multifd()) {
+if (!migrate_use_multifd() || !migrate_multifd_is_allowed()) {
return 0;
}
multifd_recv_terminate_threads(NULL);
@@ -1123,6 +1139,10 @@ int multifd_load_setup(Error **errp)
if (!migrate_use_multifd()) {
return 0;
}
+if (!migrate_multifd_is_allowed()) {
+error_setg(errp, "multifd is not supported by current protocol");
+return -1;
+}
thread_count = migrate_multifd_channels();
multifd_recv_state = g_malloc0(sizeof(*multifd_recv_state));
multifd_recv_state->params = g_new0(MultiFDRecvParams, thread_count);
diff --git a/migration/multifd.h b/migration/multifd.h
index 8d6751f5ed8..f62a1becd0b 100644
--- a/migration/multifd.h
+++ b/migration/multifd.h
@@ -13,6 +13,8 @@
#ifndef QEMU_MIGRATION_MULTIFD_H
#define QEMU_MIGRATION_MULTIFD_H
+bool migrate_multifd_is_allowed(void);
+void migrate_protocol_allow_multifd(bool allow);
int multifd_save_setup(Error **errp);
void multifd_save_cleanup(void);
int multifd_load_setup(Error **errp);
--
2.31.1
[PATCH-for-6.1?] target/mips: Remove MOVZ/MOVN opcodes from Loongson 2E
Per the "Godson-2E User Manual v0.6", the Loongson 2E processor
does not implement the MOVZ/MOVN instructions
However it's enhanced version, the STLS2F01 processor, does.
See STLS2F01 User Manual (rev 1), chapter 13.1 "The compliance
overview":
The STLS2F01 processor implements several special MIPS IV
instructions as the supplement to the MIPS III instructions.
These instructions include two MIPS IV instructions (i.e. MOVZ
and MOVNZ) ...
Fixes: aa8f40090ab ("target-mips: enable movn/movz on loongson 2E & 2F")
Signed-off-by: Philippe Mathieu-Daudé
---
target/mips/tcg/translate.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/target/mips/tcg/translate.c b/target/mips/tcg/translate.c
index bf71724f3f0..34a96159d15 100644
--- a/target/mips/tcg/translate.c
+++ b/target/mips/tcg/translate.c
@@ -14156,8 +14156,7 @@ static void decode_opc_special_legacy(CPUMIPSState
*env, DisasContext *ctx)
switch (op1) {
case OPC_MOVN: /* Conditional move */
case OPC_MOVZ:
-check_insn(ctx, ISA_MIPS4 | ISA_MIPS_R1 |
- INSN_LOONGSON2E | INSN_LOONGSON2F);
+check_insn(ctx, ISA_MIPS4 | ISA_MIPS_R1 | INSN_LOONGSON2F);
gen_cond_move(ctx, op1, rd, rs, rt);
break;
case OPC_MFHI: /* Move from HI/LO */
--
2.31.1
Re: [PATCH v2 0/2] coverity-scan: Add accelerator and sysemu components
ping^2? On 7/22/21 6:08 PM, Philippe Mathieu-Daudé wrote: > ping? > > On 7/8/21 5:57 PM, Philippe Mathieu-Daudé wrote: >> Add 'sysemu' component for issues not related to TCG. >> >> Since v1: >> - add accelerator components (Peter) >> >> Supersedes: <20210619091342.3660495-1-f4...@amsat.org> >> >> Philippe Mathieu-Daudé (2): >> coverity-scan: Add a component for each accelerator >> coverity-scan: Add 'sysemu' component >> >> scripts/coverity-scan/COMPONENTS.md | 17 + >> 1 file changed, 13 insertions(+), 4 deletions(-) >> >
Please help me understand VIRTIO_F_IOMMU_PLATFORM
Hey folks —
I’d like to be able to use VirtIO with qemu-system-alpha but, at least on a
NetBSD x86_64 host, it does not currently work. This is because
virtio_bus_device_plugged() in hw/virtio/virtio-bus.c ends up picking
address_space_memory as the DMA address space for the VirtIODevice. This does
not work for alpha because the CPU and PCI have different views of system
memory. All that’s needed to fix it is for virtio_bus_device_plugged() to call
klass->get_dma_as(qbus->parent), but the code only does that if:
bool has_iommu = virtio_host_has_feature(vdev,
VIRTIO_F_IOMMU_PLATFORM);
So, obviously, VIRTIO_F_IOMMU_PLATFORM is not getting set for an emulated alpha
system, despite the alpha platform having one[*]. But it’s not clear to me
that it’s appropriate for alpha to use VIRTIO_F_IOMMU_PLATFORM, at least from
my reading of how it’s used.
In any case, the following extremely simple change allows me to use VirtIO
devices in qemu-system-alpha with a NetBSD/alpha guest (and I’m told this also
fixes using VirtIO devices in qemu-system-sparc64 for a NetBSD/sparc64 guest):
diff --git a/hw/virtio/virtio-bus.c b/hw/virtio/virtio-bus.c
index 859978d248..c083e8d737 100644
--- a/hw/virtio/virtio-bus.c
+++ b/hw/virtio/virtio-bus.c
@@ -85,6 +85,8 @@ void virtio_bus_device_plugged(VirtIODevice *vdev, Error
**errp)
if (klass->get_dma_as != NULL && has_iommu) {
virtio_add_feature(&vdev->host_features, VIRTIO_F_IOMMU_PLATFORM);
vdev->dma_as = klass->get_dma_as(qbus->parent);
+} else if (klass->get_dma_as != NULL) {
+vdev->dma_as = klass->get_dma_as(qbus->parent);
} else {
vdev->dma_as = &address_space_memory;
}
So, VirtIO experts, please weigh in on the correctness of this change… if it
is, I’ll post the patch formally.
[*] The way the alpha platform works is that the IOMMU is used if the PCI
device performs a memory access to a DMA window where SGMAPs are enabled. If
SGMAPs are not enabled in the DMA window the PCI device is accessing, the
translation is performed directly by subtracting the address from the window’s
Window Base and appending the result to the window’s Translated Base. A
typical alpha PCI platform has a 1GB DMA window at 1GB from the PCI’s
perspective, which maps to 0-1GB in the system address map, and an alpha system
with 1GB or less of RAM would thus not need to use the IOMMU, but the
translation take place regardless.
-- thorpej
Re: "make check-acceptance" takes way too long
On Sat, Jul 31, 2021 at 2:40 AM Thomas Huth wrote: > > On 31/07/2021 00.04, Cleber Rosa wrote: > > On Fri, Jul 30, 2021 at 11:43 AM Peter Maydell > > wrote: > >> > >> On Fri, 30 Jul 2021 at 16:12, Peter Maydell > >> wrote: > >>> > >>> "make check-acceptance" takes way way too long. I just did a run > >>> on an arm-and-aarch64-targets-only debug build and it took over > >>> half an hour, and this despite it skipping or cancelling 26 out > >>> of 58 tests! > >>> > >>> I think that ~10 minutes runtime is reasonable. 30 is not; > >>> ideally no individual test would take more than a minute or so. > >> > >> Side note, can check-acceptance run multiple tests in parallel? > > > > Yes, it can, but it's not currently enabled to do so, but I'm planning > > to. As a matter of fact, Yesterday I was trying out Avocado's > > parallel capable runner on a GitLab CI pipeline[1] and it went well. > > Was this one of the shared gitlab CI runners? ... well, those feature only a > single CPU, so the run was likely not very different compared to a single run. > Yes, the two pipeline executions I referred to were run in the shared GitLab CI runners. I was testing two things: 1. Possible caveats/issues with the parallel Avocado runner (AKA "nrunner") and the Acceptance tests (first pipeline linked, with "max parallel tasks" set to 1) 2. Any possible gains/losses with running with "max parallel tasks" set to 2 (second pipeline linked) > > But the environment on GitLab CI is fluid, and I bet there's already > > some level of overcommit of (at least) CPUs there. The only pipeline > > I ran there with tests running in parallel, resulted in some jobs with > > improvements, and others with regressions in runtime. Additionally, > > lack of adequate resources can make more tests time out, and thus give > > out false negatives. > > It certainly does not make sense to enable parallel tests for the shared > runners there. > > Thomas > > There could be gains on scenario #2 if there's considerable I/O wait on some tests. That's why I mention that previous experiences mixing the acceptance tests with the iotests were very interesting. But you're right, with only acceptance tests, mostly CPU bound, there was no clear gain. Best, - Cleber.
Re: "make check-acceptance" takes way too long
Peter Maydell writes: > "make check-acceptance" takes way way too long. I just did a run > on an arm-and-aarch64-targets-only debug build and it took over > half an hour, and this despite it skipping or cancelling 26 out > of 58 tests! > > I think that ~10 minutes runtime is reasonable. 30 is not; > ideally no individual test would take more than a minute or so. > > Output saying where the time went. The first two tests take > more than 10 minutes *each*. I think a good start would be to find > a way of testing what they're testing that is less heavyweight. > > (01/58) tests/acceptance/boot_linux.py:BootLinuxAarch64.test_virt_tcg_gicv2: > PASS (629.74 s) > (02/58) tests/acceptance/boot_linux.py:BootLinuxAarch64.test_virt_tcg_gicv3: > PASS (628.75 s) > (03/58) tests/acceptance/boot_linux.py:BootLinuxAarch64.test_virt_kvm: > CANCEL: kvm accelerator does not seem to be available (1.18 s) For these tests which purport to exercise the various GIC configurations I think we would be much better served by running kvm-unit-tests which at least try and exercise all the features rather than rely on the side effect of booting an entire OS. > (04/58) > tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_aarch64_virt: > PASS (3.53 s) > (05/58) > tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_aarch64_xlnx_versal_virt: > PASS (41.13 s) > (06/58) > tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_virt: > PASS (5.22 s) > (07/58) > tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_emcraft_sf2: > PASS (18.88 s) > (08/58) > tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_raspi2_uart0: > PASS (11.30 s) > (09/58) > tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_raspi2_initrd: > PASS (22.66 s) > (10/58) > tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_exynos4210_initrd: > PASS (31.89 s) > (11/58) > tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_cubieboard_initrd: > PASS (27.86 s) > (12/58) > tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_cubieboard_sata: > PASS (27.19 s) > (13/58) > tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_quanta_gsj: > SKIP: Test might timeout > (14/58) > tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_quanta_gsj_initrd: > PASS (22.53 s) > (15/58) > tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_orangepi: > PASS (4.86 s) > (16/58) > tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_orangepi_initrd: > PASS (39.85 s) > (17/58) > tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_orangepi_sd: > PASS (53.57 s) > (18/58) > tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_orangepi_bionic_20_08: > SKIP: storage limited > (19/58) > tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_orangepi_uboot_netbsd9: > SKIP: storage limited > (20/58) > tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_aarch64_raspi3_atf: > PASS (1.50 s) > (21/58) > tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_vexpressa9: > PASS (10.74 s) > (22/58) > tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_ast2400_palmetto_openbmc_v2_9_0: > PASS (39.43 s) > (23/58) > tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_ast2500_romulus_openbmc_v2_9_0: > PASS (54.01 s) > (24/58) > tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_ast2600_debian: > PASS (40.60 s) > (25/58) tests/acceptance/boot_xen.py:BootXen.test_arm64_xen_411_and_dom0: > PASS (20.22 s) > (26/58) tests/acceptance/boot_xen.py:BootXen.test_arm64_xen_414_and_dom0: > PASS (17.37 s) > (27/58) tests/acceptance/boot_xen.py:BootXen.test_arm64_xen_415_and_dom0: > PASS (23.82 s) > (28/58) tests/acceptance/empty_cpu_model.py:EmptyCPUModel.test: > CANCEL: No QEMU binary defined or found in the build tree (0.00 s) > (29/58) tests/acceptance/info_usernet.py:InfoUsernet.test_hostfwd: > CANCEL: No QEMU binary defined or found in the build tree (0.00 s) > (30/58) > tests/acceptance/machine_arm_canona1100.py:CanonA1100Machine.test_arm_canona1100: > PASS (0.20 s) > (31/58) > tests/acceptance/machine_arm_integratorcp.py:IntegratorMachine.test_integratorcp_console: > SKIP: untrusted code > (32/58) > tests/acceptance/machine_arm_integratorcp.py:IntegratorMachine.test_framebuffer_tux_logo: > SKIP: Python NumPy not installed > (33/58) tests/acceptance/machine_arm_n8x0.py:N8x0Machine.test_n800: > SKIP: untrusted code > (34/58) tests/acceptance/machine_arm_n8x0.py:N8x0Machine.test_n810: > SKIP: untrusted code > (35/58) > tests/acceptance/migration.py:Migration.test_migration_with_tcp_localhost: > CANCEL: No QEMU binary defined or found in the build tree (0.00 s) > (36/58) tests/acceptance/migration.py:Migration.test_migration_with_unix: > CANCEL: No QEMU binary defined or found in the build tree (0.00 s) > (37/58) tests/ac
[PATCH] hw/char: Add config for shakti uart
Use a dedicated UART config(CONFIG_SHAKTI_UART) to select
shakti uart.
Signed-off-by: Vijai Kumar K
---
hw/char/Kconfig | 3 +++
hw/char/meson.build | 2 +-
hw/riscv/Kconfig| 5 +
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/hw/char/Kconfig b/hw/char/Kconfig
index 2e4f620b13..6b6cf2fc1d 100644
--- a/hw/char/Kconfig
+++ b/hw/char/Kconfig
@@ -68,3 +68,6 @@ config SIFIVE_UART
config GOLDFISH_TTY
bool
+
+config SHAKTI_UART
+bool
diff --git a/hw/char/meson.build b/hw/char/meson.build
index 8361d0ab28..7b594f51b8 100644
--- a/hw/char/meson.build
+++ b/hw/char/meson.build
@@ -16,7 +16,7 @@ softmmu_ss.add(when: 'CONFIG_SERIAL', if_true:
files('serial.c'))
softmmu_ss.add(when: 'CONFIG_SERIAL_ISA', if_true: files('serial-isa.c'))
softmmu_ss.add(when: 'CONFIG_SERIAL_PCI', if_true: files('serial-pci.c'))
softmmu_ss.add(when: 'CONFIG_SERIAL_PCI_MULTI', if_true:
files('serial-pci-multi.c'))
-softmmu_ss.add(when: 'CONFIG_SHAKTI', if_true: files('shakti_uart.c'))
+softmmu_ss.add(when: 'CONFIG_SHAKTI_UART', if_true: files('shakti_uart.c'))
softmmu_ss.add(when: 'CONFIG_VIRTIO_SERIAL', if_true:
files('virtio-console.c'))
softmmu_ss.add(when: 'CONFIG_XEN', if_true: files('xen_console.c'))
softmmu_ss.add(when: 'CONFIG_XILINX', if_true: files('xilinx_uartlite.c'))
diff --git a/hw/riscv/Kconfig b/hw/riscv/Kconfig
index 0590f443fd..ff75add6f3 100644
--- a/hw/riscv/Kconfig
+++ b/hw/riscv/Kconfig
@@ -22,13 +22,10 @@ config OPENTITAN
select IBEX
select UNIMP
-config SHAKTI
-bool
-
config SHAKTI_C
bool
select UNIMP
-select SHAKTI
+select SHAKTI_UART
select SIFIVE_CLINT
select SIFIVE_PLIC
--
2.25.1
Re: [PATCH] target/mips: Remove JR opcode unused arguments
On 7/30/21 12:55 PM, Philippe Mathieu-Daudé wrote: case OPC_JR: -gen_compute_branch(ctx, op1, 4, rs, rd, sa, 4); +gen_compute_branch(ctx, op1, 4, rs, 0, 0, 4); Reviewed-by: Richard Henderson r~
Re: "make check-acceptance" takes way too long
On Sat, 31 Jul 2021 at 19:43, Alex Bennée wrote: > > > Peter Maydell writes: > > > "make check-acceptance" takes way way too long. I just did a run > > on an arm-and-aarch64-targets-only debug build and it took over > > half an hour, and this despite it skipping or cancelling 26 out > > of 58 tests! > > > > I think that ~10 minutes runtime is reasonable. 30 is not; > > ideally no individual test would take more than a minute or so. > > > > Output saying where the time went. The first two tests take > > more than 10 minutes *each*. I think a good start would be to find > > a way of testing what they're testing that is less heavyweight. > > > > (01/58) > > tests/acceptance/boot_linux.py:BootLinuxAarch64.test_virt_tcg_gicv2: > > PASS (629.74 s) > > (02/58) > > tests/acceptance/boot_linux.py:BootLinuxAarch64.test_virt_tcg_gicv3: > > PASS (628.75 s) > > (03/58) tests/acceptance/boot_linux.py:BootLinuxAarch64.test_virt_kvm: > > CANCEL: kvm accelerator does not seem to be available (1.18 s) > > For these tests which purport to exercise the various GIC configurations > I think we would be much better served by running kvm-unit-tests which > at least try and exercise all the features rather than rely on the side > effect of booting an entire OS. I think "can we boot Linux via UEFI?" is worth testing, as is "can we boot Linux and do at least some stuff in userspace?" (there's a lot of TCG that doesn't get exercised by pure kernel boot). We just need to find a guest OS that isn't so overweight it takes 10 minutes... -- PMM
[PATCH] target/i386: cmpxchg should not touch accumulator
Signed-off-by: Daniele Ahmed
---
target/i386/tcg/translate.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/target/i386/tcg/translate.c b/target/i386/tcg/translate.c
index aacb605..41386dd 100644
--- a/target/i386/tcg/translate.c
+++ b/target/i386/tcg/translate.c
@@ -5366,7 +5366,6 @@ static target_ulong disas_insn(DisasContext *s, CPUState
*cpu)
gen_lea_modrm(env, s, modrm);
tcg_gen_atomic_cmpxchg_tl(oldv, s->A0, cmpv, newv,
s->mem_index, ot | MO_LE);
-gen_op_mov_reg_v(s, ot, R_EAX, oldv);
} else {
if (mod == 3) {
rm = (modrm & 7) | REX_B(s);
@@ -5381,15 +5380,7 @@ static target_ulong disas_insn(DisasContext *s, CPUState
*cpu)
/* store value = (old == cmp ? new : old); */
tcg_gen_movcond_tl(TCG_COND_EQ, newv, oldv, cmpv, newv, oldv);
if (mod == 3) {
-gen_op_mov_reg_v(s, ot, R_EAX, oldv);
gen_op_mov_reg_v(s, ot, rm, newv);
-} else {
-/* Perform an unconditional store cycle like physical cpu;
- must be before changing accumulator to ensure
- idempotency if the store faults and the instruction
- is restarted */
-gen_op_st_v(s, ot, newv, s->A0);
-gen_op_mov_reg_v(s, ot, R_EAX, oldv);
}
}
tcg_gen_mov_tl(cpu_cc_src, oldv);
--
2.26.3
Windows on ARM64 not able to use attached TPM 2
Hello! I maintain the TPM support in QEMU and the TPM emulator (swtpm). I have a report from a user who would like to use QEMU on ARM64 (aarch64) with EDK2 and use an attached TPM 2 but it doesn't seem to work for him. We know that Windows on x86_64 works with EDK2 and can use an attached TPM 2 (using swtpm). I don't have an aarch64 host myself nor a Microsoft account to be able to access the Windows ARM64 version, so maybe someone here has the necessary background, credentials, and hardware to run QEMU on using kvm to investigate what the problems may be due to on that platform. https://github.com/stefanberger/swtpm/issues/493 On Linux it seems to access the TPM emulator with the normal tpm_tis driver. Regards, Stefan
Re: [PATCH for-6.2 7/8] arch_init.h: Don't include arch_init.h unnecessarily
On Fri, Jul 30, 2021 at 9:04 PM Peter Maydell wrote:
>
> arch_init.h only defines the QEMU_ARCH_* enumeration and the
> arch_type global. Don't include it in files that don't use those.
>
> Signed-off-by: Peter Maydell
Reviewed-by: Alistair Francis
Alistair
> ---
> blockdev.c| 1 -
> hw/i386/pc.c | 1 -
> hw/i386/pc_piix.c | 1 -
> hw/i386/pc_q35.c | 1 -
> hw/mips/jazz.c| 1 -
> hw/mips/malta.c | 1 -
> hw/ppc/prep.c | 1 -
> hw/riscv/sifive_e.c | 1 -
> hw/riscv/sifive_u.c | 1 -
> hw/riscv/spike.c | 1 -
> hw/riscv/virt.c | 1 -
> monitor/qmp-cmds.c| 1 -
> target/ppc/cpu_init.c | 1 -
> target/s390x/cpu-sysemu.c | 1 -
> 14 files changed, 14 deletions(-)
>
> diff --git a/blockdev.c b/blockdev.c
> index 3d8ac368a19..e79c5f3b5e8 100644
> --- a/blockdev.c
> +++ b/blockdev.c
> @@ -56,7 +56,6 @@
> #include "sysemu/iothread.h"
> #include "block/block_int.h"
> #include "block/trace.h"
> -#include "sysemu/arch_init.h"
> #include "sysemu/runstate.h"
> #include "sysemu/replay.h"
> #include "qemu/cutils.h"
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index c2b9d62a358..102b2239468 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -65,7 +65,6 @@
> #include "hw/xen/start_info.h"
> #include "ui/qemu-spice.h"
> #include "exec/memory.h"
> -#include "sysemu/arch_init.h"
> #include "qemu/bitmap.h"
> #include "qemu/config-file.h"
> #include "qemu/error-report.h"
> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> index 30b8bd6ea92..1bc30167acc 100644
> --- a/hw/i386/pc_piix.c
> +++ b/hw/i386/pc_piix.c
> @@ -43,7 +43,6 @@
> #include "sysemu/kvm.h"
> #include "hw/kvm/clock.h"
> #include "hw/sysbus.h"
> -#include "sysemu/arch_init.h"
> #include "hw/i2c/smbus_eeprom.h"
> #include "hw/xen/xen-x86.h"
> #include "exec/memory.h"
> diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
> index 04b4a4788d7..eeb0b185b11 100644
> --- a/hw/i386/pc_q35.c
> +++ b/hw/i386/pc_q35.c
> @@ -31,7 +31,6 @@
> #include "qemu/osdep.h"
> #include "qemu/units.h"
> #include "hw/loader.h"
> -#include "sysemu/arch_init.h"
> #include "hw/i2c/smbus_eeprom.h"
> #include "hw/rtc/mc146818rtc.h"
> #include "sysemu/kvm.h"
> diff --git a/hw/mips/jazz.c b/hw/mips/jazz.c
> index d6183e18821..f5a26e174d5 100644
> --- a/hw/mips/jazz.c
> +++ b/hw/mips/jazz.c
> @@ -35,7 +35,6 @@
> #include "hw/isa/isa.h"
> #include "hw/block/fdc.h"
> #include "sysemu/sysemu.h"
> -#include "sysemu/arch_init.h"
> #include "hw/boards.h"
> #include "net/net.h"
> #include "hw/scsi/esp.h"
> diff --git a/hw/mips/malta.c b/hw/mips/malta.c
> index 7dcf175d726..b770b8d3671 100644
> --- a/hw/mips/malta.c
> +++ b/hw/mips/malta.c
> @@ -38,7 +38,6 @@
> #include "hw/mips/mips.h"
> #include "hw/mips/cpudevs.h"
> #include "hw/pci/pci.h"
> -#include "sysemu/arch_init.h"
> #include "qemu/log.h"
> #include "hw/mips/bios.h"
> #include "hw/ide.h"
> diff --git a/hw/ppc/prep.c b/hw/ppc/prep.c
> index acfc2a91d8e..25a2e86b421 100644
> --- a/hw/ppc/prep.c
> +++ b/hw/ppc/prep.c
> @@ -40,7 +40,6 @@
> #include "hw/rtc/mc146818rtc.h"
> #include "hw/isa/pc87312.h"
> #include "hw/qdev-properties.h"
> -#include "sysemu/arch_init.h"
> #include "sysemu/kvm.h"
> #include "sysemu/reset.h"
> #include "trace.h"
> diff --git a/hw/riscv/sifive_e.c b/hw/riscv/sifive_e.c
> index ddc658c8d68..5b7b245e1f3 100644
> --- a/hw/riscv/sifive_e.c
> +++ b/hw/riscv/sifive_e.c
> @@ -45,7 +45,6 @@
> #include "hw/intc/sifive_plic.h"
> #include "hw/misc/sifive_e_prci.h"
> #include "chardev/char.h"
> -#include "sysemu/arch_init.h"
> #include "sysemu/sysemu.h"
>
> static const MemMapEntry sifive_e_memmap[] = {
> diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c
> index 87bbd10b211..6cc1a62b0f7 100644
> --- a/hw/riscv/sifive_u.c
> +++ b/hw/riscv/sifive_u.c
> @@ -55,7 +55,6 @@
> #include "hw/intc/sifive_plic.h"
> #include "chardev/char.h"
> #include "net/eth.h"
> -#include "sysemu/arch_init.h"
> #include "sysemu/device_tree.h"
> #include "sysemu/runstate.h"
> #include "sysemu/sysemu.h"
> diff --git a/hw/riscv/spike.c b/hw/riscv/spike.c
> index fead77f0c48..aae36f2cb4d 100644
> --- a/hw/riscv/spike.c
> +++ b/hw/riscv/spike.c
> @@ -37,7 +37,6 @@
> #include "hw/char/riscv_htif.h"
> #include "hw/intc/sifive_clint.h"
> #include "chardev/char.h"
> -#include "sysemu/arch_init.h"
> #include "sysemu/device_tree.h"
> #include "sysemu/sysemu.h"
>
> diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
> index 4a3cd2599a5..0e55411045a 100644
> --- a/hw/riscv/virt.c
> +++ b/hw/riscv/virt.c
> @@ -36,7 +36,6 @@
> #include "hw/intc/sifive_plic.h"
> #include "hw/misc/sifive_test.h"
> #include "chardev/char.h"
> -#include "sysemu/arch_init.h"
> #include "sysemu/device_tree.h"
> #include "sysemu/sysemu.h"
> #include "hw/pci/pci.h"
> diff --git a/monitor/qmp-cmds.c b/monitor/qmp-cmds.c
> index 9ddb9352e65..5c0d5e116b9 100644
> --- a/monitor/qmp-cmds.c
> +++ b/monitor/qmp-
