Re: [Qemu-devel] [PULL 00/40] target/xtensa queue
On Mon, 25 Feb 2019 at 20:32, Max Filippov wrote: > > Hi Peter, > > please pull the following batch of target/xtensa updates: > > The following changes since commit 1c3d45df5e94042d5fb2bb31416072563ab30e49: > > Merge remote-tracking branch 'remotes/ericb/tags/pull-nbd-2019-02-04' into > staging (2019-02-05 12:46:18 +) > > are available in the git repository at: > > git://github.com/OSLL/qemu-xtensa.git tags/20190225-xtensa > > for you to fetch changes up to 116f9089402081231ebc6d0012e4e029f21f63af: > > tests/tcg/xtensa: add FPU2000 coprocessor tests (2019-02-18 22:09:10 -0800) > > > target/xtensa: FLIX support, various fixes and test improvements > > - add FLIX (flexible length instructions extension) support; > - make testsuite runnable on wider range of xtensa cores; > - add floating point opcode tests; > - don't add duplicate 'static' in import_core.sh script; > - fix undefined opcodes detection in test_mmuhifi_c3 overlay. > Hi -- I'm afraid this fails to build on some clang compilers: /Users/pm215/src/qemu-for-merges/target/xtensa/translate.c:967:14: error: result of comparison of constant 256 with expression of type 'enum resource_type' is always true [-Werror,-Wtautological-constant-out-of-range-compare] assert(r < 256 && g < 256 && n < 65536); ~ ^ ~~~ /usr/include/assert.h:93:25: note: expanded from macro 'assert' (__builtin_expect(!(e), 0) ? __assert_rtn(__func__, __FILE__, __LINE__, #e) : (void)0) ^ Here r is of type 'enum resource_type', so the compiler is allowed to pick any type to represent it that will fit all the values in the enum. In this case the compiler has picked a char type. Asserting that r is either RES_REGFILE or RES_STATE would probably work better. thanks -- PMM
[Qemu-devel] sorecvfrom freezes guest
Hi,
I am having a guest freeze issue (win10), and through debugging I found out
that sometimes sorecvfrom() is called from slirp.c because revents ==
G_IO_IN, however inside sorecvfrom() function, ioctlsocket() returns 0
bytes available and recvfrom could be blocking indefinitely. I am not sure
the root cause of the situation, but I added a non-blocking check to
recvfrom and it fixed my issue. My patch is as attached. Please check if
this is a right fix.
From 11dfa3402eacac9a05f12934fd322f37c8e0ce37 Mon Sep 17 00:00:00 2001
From: Vic Lee
Date: Thu, 28 Feb 2019 18:23:24 +0800
Subject: [PATCH] socket: fix blocking udp recvfrom.
---
slirp/socket.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/slirp/socket.c b/slirp/socket.c
index c01d8696af..ea30478ce6 100644
--- a/slirp/socket.c
+++ b/slirp/socket.c
@@ -581,7 +581,7 @@ sorecvfrom(struct socket *so)
}
/* } */
- m->m_len = recvfrom(so->s, m->m_data, len, 0,
+ m->m_len = recvfrom(so->s, m->m_data, len, MSG_DONTWAIT,
(struct sockaddr *), );
DEBUG_MISC((dfd, " did recvfrom %d, errno = %d-%s\n",
m->m_len, errno,strerror(errno)));
@@ -618,6 +618,8 @@ sorecvfrom(struct socket *so)
break;
}
m_free(m);
+ } else if (m->m_len==0) {
+ m_free(m);
} else {
/*
* Hack: domain name lookup will be used the most for UDP,
--
2.20.1
[Qemu-devel] [PATCH v2 2/3] qdev: Let machine hotplug handler to override bus hotplug handler
From: Igor Mammedov
it will allow to return another hotplug handler than the default
one for a specific bus based device type. Which is needed to handle
non trivial plug/unplug sequences that need the access to resources
configured outside of bus where device is attached.
That will allow for returned hotplug handler to orchestrate wiring
in arbitrary order, by chaining other hotplug handlers when
it's needed.
PS:
It could be used for hybrid virtio-mem and virtio-pmem devices
where it will return machine as hotplug handler which will do
necessary wiring at machine level and then pass control down
the chain to bus specific hotplug handler.
Example of top level hotplug handler override and custom plug sequence:
some_machine_get_hotplug_handler(machine){
if (object_dynamic_cast(OBJECT(dev), TYPE_SOME_BUS_DEVICE)) {
return HOTPLUG_HANDLER(machine);
}
return NULL;
}
some_machine_device_plug(hotplug_dev, dev) {
if (object_dynamic_cast(OBJECT(dev), TYPE_SOME_BUS_DEVICE)) {
/* do machine specific initialization */
some_machine_init_special_device(dev)
/* pass control to bus specific handler */
hotplug_handler_plug(dev->parent_bus->hotplug_handler, dev)
}
}
Reviewed-by: David Gibson
Signed-off-by: Igor Mammedov
Signed-off-by: David Hildenbrand
---
hw/core/qdev.c | 6 ++
include/hw/qdev-core.h | 11 +++
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index 278cc094ec..7ad45c0bd6 100644
--- a/hw/core/qdev.c
+++ b/hw/core/qdev.c
@@ -235,12 +235,10 @@ HotplugHandler
*qdev_get_machine_hotplug_handler(DeviceState *dev)
HotplugHandler *qdev_get_hotplug_handler(DeviceState *dev)
{
-HotplugHandler *hotplug_ctrl;
+HotplugHandler *hotplug_ctrl = qdev_get_machine_hotplug_handler(dev);
-if (dev->parent_bus && dev->parent_bus->hotplug_handler) {
+if (hotplug_ctrl == NULL && dev->parent_bus) {
hotplug_ctrl = dev->parent_bus->hotplug_handler;
-} else {
-hotplug_ctrl = qdev_get_machine_hotplug_handler(dev);
}
return hotplug_ctrl;
}
diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
index e70a4bfa49..52562555cd 100644
--- a/include/hw/qdev-core.h
+++ b/include/hw/qdev-core.h
@@ -281,6 +281,17 @@ void qdev_init_nofail(DeviceState *dev);
void qdev_set_legacy_instance_id(DeviceState *dev, int alias_id,
int required_for_version);
HotplugHandler *qdev_get_machine_hotplug_handler(DeviceState *dev);
+/**
+ * qdev_get_hotplug_handler: Get handler responsible for device wiring
+ *
+ * Find HOTPLUG_HANDLER for @dev that provides [pre|un]plug callbacks for it.
+ *
+ * Note: in case @dev has a parent bus, it will be returned as handler unless
+ * machine handler overrides it.
+ *
+ * Returns: pointer to object that implements TYPE_HOTPLUG_HANDLER interface
+ * or NULL if there aren't any.
+ */
HotplugHandler *qdev_get_hotplug_handler(DeviceState *dev);
void qdev_unplug(DeviceState *dev, Error **errp);
void qdev_simple_device_unplug_cb(HotplugHandler *hotplug_dev,
--
2.17.2
Re: [Qemu-devel] [PATCH 0/5] Improve balloon handling of pagesizes other than 4kiB
On Thu, Feb 14, 2019 at 03:39:11PM +1100, David Gibson wrote: > I posted some RFCs for this back in December, but didn't wrap it up in > time for 3.1. Posting again for inclusion in 4.0. > > The virtio-balloon devices was never really thought out for cases > other than 4kiB pagesize on both guest and host. It works in some > cases, but in others can be ineffectual or even cause guest memory > corruption. > > This series makes a handful of preliminary cleanups, then makes a > change to safely, though not perfectly, handle cases with non 4kiB > pagesizes. I'd like to see a version of this that does not depend on patch 1 which is not a cleanup nor a bugfix. Could you look into this please? We can then debate merits of patch 1 separately. > Changes since RFC: > * Further refinement of when to issue warnings in 5/5 > > David Gibson (5): > virtio-balloon: Remove unnecessary MADV_WILLNEED on deflate > virtio-balloon: Corrections to address verification > virtio-balloon: Rework ballon_page() interface > virtio-balloon: Use ram_block_discard_range() instead of raw madvise() > virtio-balloon: Safely handle BALLOON_PAGE_SIZE < host page size > > hw/virtio/virtio-balloon.c | 102 - > include/hw/virtio/virtio-balloon.h | 3 + > 2 files changed, 89 insertions(+), 16 deletions(-) > > -- > 2.20.1
Re: [Qemu-devel] [PATCH v3 4/9] {monitor, hw/pvrdma}: Expose device internals via monitor interface
On 2/28/19 11:01 AM, Yuval Shaia wrote:
On Thu, Feb 28, 2019 at 10:35:38AM +0200, Marcel Apfelbaum wrote:
Hi Yuval,
On 2/27/19 4:06 PM, Yuval Shaia wrote:
Allow interrogating device internals through HMP interface.
The exposed indicators can be used for troubleshooting by developers or
sysadmin.
There is no need to expose these attributes to a management system (e.x.
libvirt) because (1) most of them are not "device-management' related
info and (2) there is no guarantee the interface is stable.
Signed-off-by: Yuval Shaia
---
hmp-commands-info.hx | 16
hw/rdma/rdma_backend.c| 70 ++-
hw/rdma/rdma_rm.c | 7
hw/rdma/rdma_rm_defs.h| 27 +-
hw/rdma/vmw/pvrdma.h | 5 +++
hw/rdma/vmw/pvrdma_hmp.h | 21 +++
hw/rdma/vmw/pvrdma_main.c | 77 +++
monitor.c | 10 +
8 files changed, 215 insertions(+), 18 deletions(-)
create mode 100644 hw/rdma/vmw/pvrdma_hmp.h
diff --git a/hmp-commands-info.hx b/hmp-commands-info.hx
index cbee8b944d..9153c33974 100644
--- a/hmp-commands-info.hx
+++ b/hmp-commands-info.hx
@@ -524,6 +524,22 @@ STEXI
Show CPU statistics.
ETEXI
+#if defined(CONFIG_PVRDMA)
+{
+.name = "pvrdmacounters",
+.args_type = "",
+.params = "",
+.help = "show pvrdma device counters",
+.cmd= hmp_info_pvrdmacounters,
+},
+
+STEXI
+@item info pvrdmacounters
+@findex info pvrdmacounters
+Show pvrdma device counters.
+ETEXI
+#endif
+
#if defined(CONFIG_SLIRP)
{
.name = "usernet",
diff --git a/hw/rdma/rdma_backend.c b/hw/rdma/rdma_backend.c
index 9679b842d1..bc2fefcf93 100644
--- a/hw/rdma/rdma_backend.c
+++ b/hw/rdma/rdma_backend.c
@@ -64,9 +64,9 @@ static inline void complete_work(enum ibv_wc_status status,
uint32_t vendor_err,
comp_handler(ctx, );
}
-static void rdma_poll_cq(RdmaDeviceResources *rdma_dev_res, struct ibv_cq
*ibcq)
+static int rdma_poll_cq(RdmaDeviceResources *rdma_dev_res, struct ibv_cq *ibcq)
{
-int i, ne;
+int i, ne, total_ne = 0;
BackendCtx *bctx;
struct ibv_wc wc[2];
@@ -89,12 +89,18 @@ static void rdma_poll_cq(RdmaDeviceResources *rdma_dev_res,
struct ibv_cq *ibcq)
rdma_rm_dealloc_cqe_ctx(rdma_dev_res, wc[i].wr_id);
g_free(bctx);
}
+total_ne += ne;
} while (ne > 0);
+atomic_sub(_dev_res->stats.missing_cqe, total_ne);
qemu_mutex_unlock(_dev_res->lock);
if (ne < 0) {
rdma_error_report("ibv_poll_cq fail, rc=%d, errno=%d", ne, errno);
}
+
+rdma_dev_res->stats.completions += total_ne;
+
+return total_ne;
}
static void *comp_handler_thread(void *arg)
@@ -122,6 +128,9 @@ static void *comp_handler_thread(void *arg)
while (backend_dev->comp_thread.run) {
do {
rc = qemu_poll_ns(pfds, 1, THR_POLL_TO * (int64_t)SCALE_MS);
+if (!rc) {
+backend_dev->rdma_dev_res->stats.poll_cq_ppoll_to++;
+}
} while (!rc && backend_dev->comp_thread.run);
if (backend_dev->comp_thread.run) {
@@ -138,6 +147,7 @@ static void *comp_handler_thread(void *arg)
errno);
}
+backend_dev->rdma_dev_res->stats.poll_cq_from_bk++;
rdma_poll_cq(backend_dev->rdma_dev_res, ev_cq);
ibv_ack_cq_events(ev_cq, 1);
@@ -271,7 +281,13 @@ int rdma_backend_query_port(RdmaBackendDev *backend_dev,
void rdma_backend_poll_cq(RdmaDeviceResources *rdma_dev_res, RdmaBackendCQ
*cq)
{
-rdma_poll_cq(rdma_dev_res, cq->ibcq);
+int polled;
+
+rdma_dev_res->stats.poll_cq_from_guest++;
+polled = rdma_poll_cq(rdma_dev_res, cq->ibcq);
+if (!polled) {
+rdma_dev_res->stats.poll_cq_from_guest_empty++;
+}
}
static GHashTable *ah_hash;
@@ -333,7 +349,7 @@ static void ah_cache_init(void)
static int build_host_sge_array(RdmaDeviceResources *rdma_dev_res,
struct ibv_sge *dsge, struct ibv_sge *ssge,
-uint8_t num_sge)
+uint8_t num_sge, uint64_t *total_length)
{
RdmaRmMR *mr;
int ssge_idx;
@@ -349,6 +365,8 @@ static int build_host_sge_array(RdmaDeviceResources
*rdma_dev_res,
dsge->length = ssge[ssge_idx].length;
dsge->lkey = rdma_backend_mr_lkey(>backend_mr);
+*total_length += dsge->length;
+
dsge++;
}
@@ -445,8 +463,10 @@ void rdma_backend_post_send(RdmaBackendDev *backend_dev,
rc = mad_send(backend_dev, sgid_idx, sgid, sge, num_sge);
if (rc) {
complete_work(IBV_WC_GENERAL_ERR, VENDOR_ERR_MAD_SEND, ctx);
+backend_dev->rdma_dev_res->stats.mad_tx_err++;
} else {
[Qemu-devel] [Bug 1817865] Re: sorecvfrom freezes guest
Found out that the guest freeze issue is due to a block udp reading call
rather than a deaklock. I have rephase the bug description and sent a
patch in qemu-devel.
** Summary changed:
- deadlock in prepare_mmio_access reading mmio
+ sorecvfrom freezes guest
** Description changed:
QEMU release 3.1.0; Guest running win10.
- The deadlock happens in prepare_mmio_access call when the guest is
- trying to read MMIO address 0xFEBC00C0. This address belongs to
- "Intel(R) PRO/1000 MT Network Connection" as shown in Windows 10 device
- manager. A quick analysis has shown that in prepare_mmio_access call:
-
- static bool prepare_mmio_access(MemoryRegion *mr)
- {
- bool unlocked = !qemu_mutex_iothread_locked();
- bool release_lock = false;
-
- if (unlocked && mr->global_locking) {
- qemu_mutex_lock_iothread();
- ...
-
- "qemu_mutex_iothread_locked()" and "qemu_mutex_lock_iothread()" are not
- atomic operation, so the global mutex could become locked by "util/main-
- loop.c" (line = 236) after "qemu_mutex_iothread_locked()" is called.
-
- GDB backtrace analysis as following:
-
- (gdb) thread 9
- [Switching to thread 9 (Thread 0x7fffe6b7c700 (LWP 14405))]
- #0 __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:103
- 103 ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S: No such file or
directory.
- (gdb) bt
- #0 __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:103
- #1 0x7748c714 in __GI___pthread_mutex_lock (mutex=0x56518340
) at ../nptl/pthread_mutex_lock.c:80
- #2 0x55d8ae7b in qemu_mutex_lock_impl (mutex=0x56518340
,
- file=0x55e7a298 "/home/vic/Projects/tc-qemu/exec.c", line=3197) at
util/qemu-thread-posix.c:66
- #3 0x5584cf66 in qemu_mutex_lock_iothread_impl (file=0x55e7a298
"/home/vic/Projects/tc-qemu/exec.c", line=3197)
- at /home/vic/Projects/tc-qemu/cpus.c:1849
- #4 0x55804ccc in prepare_mmio_access (mr=0x575b9000) at
/home/vic/Projects/tc-qemu/exec.c:3197
- #5 0x55804f90 in flatview_read_continue (fv=0x7fffd86f2390,
addr=4273733824, attrs=..., buf=0x77fcc028 "ۜ/o", len=4,
- addr1=192, l=4, mr=0x575b9000) at
/home/vic/Projects/tc-qemu/exec.c:3292
- #6 0x55805136 in flatview_read (fv=0x7fffd86f2390, addr=4273733824,
attrs=..., buf=0x77fcc028 "ۜ/o", len=4)
- at /home/vic/Projects/tc-qemu/exec.c:3332
- #7 0x558051aa in address_space_read_full (as=0x56517bc0
, addr=4273733824, attrs=...,
- buf=0x77fcc028 "ۜ/o", len=4) at /home/vic/Projects/tc-qemu/exec.c:3345
- #8 0x55805281 in address_space_rw (as=0x56517bc0
, addr=4273733824, attrs=...,
- buf=0x77fcc028 "ۜ/o", len=4, is_write=false) at
/home/vic/Projects/tc-qemu/exec.c:3375
- #9 0x55886199 in kvm_cpu_exec (cpu=0x566d1800) at
/home/vic/Projects/tc-qemu/accel/kvm/kvm-all.c:2031
- #10 0x5584c001 in qemu_kvm_cpu_thread_fn (arg=0x566d1800) at
/home/vic/Projects/tc-qemu/cpus.c:1281
- #11 0x55d8b9f7 in qemu_thread_start (args=0x566f3c00) at
util/qemu-thread-posix.c:498
- #12 0x77489fa3 in start_thread (arg=) at
pthread_create.c:486
- #13 0x773ba80f in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
- (gdb) f 2
- #2 0x55d8ae7b in qemu_mutex_lock_impl (mutex=0x56518340
,
- file=0x55e7a298 "/home/vic/Projects/tc-qemu/exec.c", line=3197) at
util/qemu-thread-posix.c:66
- 66err = pthread_mutex_lock(>lock);
- (gdb) p mutex
- $1 = (QemuMutex *) 0x56518340
- (gdb) p *mutex
- $2 = {lock = pthread_mutex_t = {Type = Normal, Status = Acquired, possibly
with waiters, Owner ID = 14393, Robust = No, Shared = No,
- Protocol = None}, file = 0x55fc2a64 "util/main-loop.c", line = 236,
initialized = true}
- (gdb) thread 1
- [Switching to thread 1 (Thread 0x7495cc00 (LWP 14393))]
- #0 0x77493832 in __libc_recvfrom (fd=147, buf=0x7fffd81ce0cc,
len=1500, flags=0, addr=..., addrlen=0x7fffd9a8)
- at ../sysdeps/unix/sysv/linux/recvfrom.c:27
- 27../sysdeps/unix/sysv/linux/recvfrom.c: No such file or directory.
- (gdb) bt
- #0 0x77493832 in __libc_recvfrom (fd=147, buf=0x7fffd81ce0cc,
len=1500, flags=0, addr=..., addrlen=0x7fffd9a8)
- at ../sysdeps/unix/sysv/linux/recvfrom.c:27
- #1 0x55c18bf3 in sorecvfrom (so=0x7fffd818fe60) at slirp/socket.c:584
- #2 0x55c146f9 in slirp_pollfds_poll (pollfds=0x56655470,
select_error=0) at slirp/slirp.c:753
- #3 0x55d8675b in main_loop_wait (nonblocking=0) at
util/main-loop.c:498
- #4 0x559d2194 in main_loop () at vl.c:1893
- #5 0x559d9d93 in main (argc=16, argv=0x7fffdff8,
envp=0x7fffe080) at vl.c:4692
+ Sometimes sorecvfrom() is called from slirp.c because revents ==
+ G_IO_IN, however inside sorecvfrom() function, ioctlsocket() returns 0
+ bytes available and recvfrom could be blocking indefinitely.
--
[Qemu-devel] [PULL 13/13] hw/m68k/mcf5208: Support loading of bios images
From: Thomas Huth
The MCF5208EVB supports 2 MiB of flash at address 0. Add support
for this memory region and some code to load the file that can
be specified with the "-bios" command line option.
This can be used for example to load U-Boot images for the
MCF5208EVB (we still lack some features in the CPU emulation for
this firmware, though, so it can not be run successfully yet).
Reviewed-by: Stefano Garzarella
Signed-off-by: Thomas Huth
---
hw/m68k/mcf5208.c | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/hw/m68k/mcf5208.c b/hw/m68k/mcf5208.c
index 8531e07..6f6efae 100644
--- a/hw/m68k/mcf5208.c
+++ b/hw/m68k/mcf5208.c
@@ -27,6 +27,8 @@
#define SYS_FREQ 1
+#define ROM_SIZE 0x20
+
#define PCSR_EN 0x0001
#define PCSR_RLD0x0002
#define PCSR_PIF0x0004
@@ -227,6 +229,7 @@ static void mcf5208evb_init(MachineState *machine)
hwaddr entry;
qemu_irq *pic;
MemoryRegion *address_space_mem = get_system_memory();
+MemoryRegion *rom = g_new(MemoryRegion, 1);
MemoryRegion *ram = g_new(MemoryRegion, 1);
MemoryRegion *sram = g_new(MemoryRegion, 1);
@@ -237,6 +240,10 @@ static void mcf5208evb_init(MachineState *machine)
env->vbr = 0;
/* TODO: Configure BARs. */
+/* ROM at 0x */
+memory_region_init_rom(rom, NULL, "mcf5208.rom", ROM_SIZE, _fatal);
+memory_region_add_subregion(address_space_mem, 0x, rom);
+
/* DRAM at 0x4000 */
memory_region_allocate_system_memory(ram, NULL, "mcf5208.ram", ram_size);
memory_region_add_subregion(address_space_mem, 0x4000, ram);
@@ -285,9 +292,30 @@ static void mcf5208evb_init(MachineState *machine)
/* 0xfc0a4000 GPIO. */
/* 0xfc0a8000 SDRAM controller. */
+/* Load firmware */
+if (bios_name) {
+char *fn;
+uint8_t *ptr;
+
+fn = qemu_find_file(QEMU_FILE_TYPE_BIOS, bios_name);
+if (!fn) {
+error_report("Could not find ROM image '%s'", bios_name);
+exit(1);
+}
+if (load_image_targphys(fn, 0x0, ROM_SIZE) < 8) {
+error_report("Could not load ROM image '%s'", bios_name);
+exit(1);
+}
+g_free(fn);
+/* Initial PC is always at offset 4 in firmware binaries */
+ptr = rom_ptr(0x4, 4);
+assert(ptr != NULL);
+env->pc = ldl_p(ptr);
+}
+
/* Load kernel. */
if (!kernel_filename) {
-if (qtest_enabled()) {
+if (qtest_enabled() || bios_name) {
return;
}
error_report("Kernel image must be specified");
--
1.8.3.1
[Qemu-devel] [PULL 07/13] MAINTAINERS: Orphanize the 'GDB stub' subsystem
From: Philippe Mathieu-Daudé Nobody is looking at those files, downgrade this subsystem as orphan. Remove the qemu-devel@nongnu.org entry because the list is always selected by the 'All patches CC here' section. Suggested-by: Markus Armbruster Signed-off-by: Philippe Mathieu-Daudé Signed-off-by: Thomas Huth --- MAINTAINERS | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 30a3359..ee73486 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1815,8 +1815,7 @@ F: util/error.c F: util/qemu-error.c GDB stub -L: qemu-devel@nongnu.org -S: Odd Fixes +S: Orphan F: gdbstub* F: gdb-xml/ -- 1.8.3.1
[Qemu-devel] [PULL 11/13] MAINTAINERS: Clean up the RISC-V TCG backend section
The e-mail address m...@sifive.com of Michael is not valid anymore. Commit 7d04ac38959f8115f2a02 removed the entry already from the main RISC-V section, but apparently forgot to remove it from the TCG backend section, too. Fixes: 7d04ac38959f8115f2a029d81db1c8aac179aa95 Reviewed-by: Palmer Dabbelt Signed-off-by: Thomas Huth --- MAINTAINERS | 1 - 1 file changed, 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 5a6db6c..a4c7ebf 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2254,7 +2254,6 @@ F: tcg/ppc/ F: disas/ppc.c RISC-V -M: Michael Clark M: Palmer Dabbelt M: Alistair Francis L: qemu-ri...@nongnu.org -- 1.8.3.1
[Qemu-devel] [PULL 10/13] MAINTAINERS: Add some missing entries for the sun4m machine
These files / devices are only used by SPARC machines, so we can sort them into the corresponding category in the MAINTAINERS file. Cc: Mark Cave-Ayland Reviewed-by: Philippe Mathieu-Daudé Signed-off-by: Thomas Huth --- MAINTAINERS | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 8c217d8..5a6db6c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1103,12 +1103,15 @@ M: Mark Cave-Ayland S: Maintained F: hw/sparc/sun4m.c F: hw/sparc/sun4m_iommu.c +F: hw/display/cg3.c +F: hw/display/tcx.c F: hw/dma/sparc32_dma.c F: hw/misc/eccmemctl.c -F: hw/misc/slavio_misc.c +F: hw/*/slavio_*.c +F: include/hw/nvram/sun_nvram.h F: include/hw/sparc/sparc32_dma.h -F: pc-bios/openbios-sparc32 F: include/hw/sparc/sun4m_iommu.h +F: pc-bios/openbios-sparc32 Sun4u M: Mark Cave-Ayland -- 1.8.3.1
[Qemu-devel] [PULL 09/13] MAINTAINERS: Add maintainer to the TCG/i386 subsystem
From: Philippe Mathieu-Daudé Richard obviously maintains this subdirectory, make this official :) Remove the qemu-devel@nongnu.org entry because the list is always selected by the 'All patches CC here' section. Cc: Richard Henderson Signed-off-by: Philippe Mathieu-Daudé Signed-off-by: Thomas Huth --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index a1ceccf..8c217d8 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2232,7 +2232,7 @@ F: tcg/arm/ F: disas/arm.c i386 target -L: qemu-devel@nongnu.org +M: Richard Henderson S: Maintained F: tcg/i386/ F: disas/i386.c -- 1.8.3.1
Re: [Qemu-devel] [PATCH 2/3] Migration/colo.c: Fix COLO failover status error
* Zhang, Chen (chen.zh...@intel.com) wrote:
>
> -Original Message-
> From: Dr. David Alan Gilbert [mailto:dgilb...@redhat.com]
> Sent: Tuesday, February 26, 2019 6:55 PM
> To: Zhang, Chen
> Cc: Li Zhijian ; Zhang Chen ;
> Juan Quintela ; zhanghailiang
> ; qemu-dev
> Subject: Re: [PATCH 2/3] Migration/colo.c: Fix COLO failover status error
>
> * Zhang Chen (chen.zh...@intel.com) wrote:
> > From: Zhang Chen
> >
> > When finished COLO failover, the status is FAILOVER_STATUS_COMPLETED.
> > The origin codes misunderstand the FAILOVER_STATUS_REQUIRE.
> >
> > Signed-off-by: Zhang Chen
>
> > Why do these 'case's have to only deal with COMPLETED - what stops the
> > REQUIRE/ACTIVE states appearing when these routines check the status; even
> > if those states only happen for a short amount of time?
>
> Yes, other status just marked the failover processing. We can see
> colo_failover_bh(), the REQUIRE/ACTIVE only exist for a very short time.
But those other states do exist - so don't these case statements have to
do something with them?
Dave
>
> Thanks
> Zhang Chen
>
> Dave
>
> > ---
> > migration/colo.c | 7 ---
> > 1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/migration/colo.c b/migration/colo.c index
> > a916dc178c..a13acac192 100644
> > --- a/migration/colo.c
> > +++ b/migration/colo.c
> > @@ -121,6 +121,7 @@ static void secondary_vm_do_failover(void)
> > }
> > /* Notify COLO incoming thread that failover work is finished */
> > qemu_sem_post(>colo_incoming_sem);
> > +
> > /* For Secondary VM, jump to incoming co */
> > if (mis->migration_incoming_co) {
> > qemu_coroutine_enter(mis->migration_incoming_co);
> > @@ -262,7 +263,7 @@ COLOStatus *qmp_query_colo_status(Error **errp)
> > case FAILOVER_STATUS_NONE:
> > s->reason = COLO_EXIT_REASON_NONE;
> > break;
> > -case FAILOVER_STATUS_REQUIRE:
> > +case FAILOVER_STATUS_COMPLETED:
> > s->reason = COLO_EXIT_REASON_REQUEST;
> > break;
> > default:
> > @@ -582,7 +583,7 @@ out:
> > qapi_event_send_colo_exit(COLO_MODE_PRIMARY,
> >COLO_EXIT_REASON_ERROR);
> > break;
> > -case FAILOVER_STATUS_REQUIRE:
> > +case FAILOVER_STATUS_COMPLETED:
> > qapi_event_send_colo_exit(COLO_MODE_PRIMARY,
> >COLO_EXIT_REASON_REQUEST);
> > break;
> > @@ -854,7 +855,7 @@ out:
> > qapi_event_send_colo_exit(COLO_MODE_SECONDARY,
> >COLO_EXIT_REASON_ERROR);
> > break;
> > -case FAILOVER_STATUS_REQUIRE:
> > +case FAILOVER_STATUS_COMPLETED:
> > qapi_event_send_colo_exit(COLO_MODE_SECONDARY,
> >COLO_EXIT_REASON_REQUEST);
> > break;
> > --
> > 2.17.GIT
> >
> --
> Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [Qemu-devel] can we update QEMU's version of u-boot.e500 ?
On Fri, 4 Jan 2019 at 05:22, David Gibson wrote: > > On Fri, Jan 04, 2019 at 12:44:59AM +0100, Alexander Graf wrote: > > > > > > On 03.01.19 18:38, Peter Maydell wrote: > > > Hi; currently we ship with a u-boot.e500 which is from u-boot > > > v2017.07. It would be nice to move that forward, specifically > > > to at least v2017.11, which contains upstream u-boot's part of the > > > fix for https://bugs.launchpad.net/qemu/+bug/1714750 . > > > (There are more recent releases than that; it's just the first > > > that contains the fix.) > > > > > > Then we could remove the workaround in scripts/make-release and > > > close out the bug. > > > > > > I've cc'd David as the current maintainer of pc-bios/u-boot.e500 > > > and Alex as the last person who did an update. > > > > I think it's a great idea to update it. > > > > David, do you want to do that or rather have me send a patch? > > Please send a patch. > > I'm maintainer of all the ppc boards by default, but I really don't > know anything much about e500 or u-boot. Hi -- any progress on this ? It would be nice to update the u-boot blob before QEMU hits softfreeze for the next release in a couple of weeks... thanks -- PMM
Re: [Qemu-devel] [PATCH 1/5] virtio-balloon: Remove unnecessary MADV_WILLNEED on deflate
On Thu, Feb 14, 2019 at 03:39:12PM +1100, David Gibson wrote:
> When the balloon is inflated, we discard memory place in it using madvise()
> with MADV_DONTNEED. And when we deflate it we use MADV_WILLNEED, which
> sounds like it makes sense but is actually unnecessary.
>
> The misleadingly named MADV_DONTNEED just discards the memory in question,
> it doesn't set any persistent state on it in-kernel; all that's necessary
> to bring the memory back is to touch it. MADV_WILLNEED in contrast
> specifically says that the memory will be used soon and faults it in.
>
> This patch simplify's the balloon operation by dropping the madvise()
> on deflate. This might have an impact on performance - it will move a
> delay at deflate time until that memory is actually touched, which
> might be more latency sensitive. However:
>
> * Memory that's being given back to the guest by deflating the
> balloon *might* be used soon, but it equally could just sit around
> in the guest's pools until needed (or even be faulted out again if
> the host is under memory pressure).
>
> * Usually, the timescale over which you'll be adjusting the balloon
> is long enough that a few extra faults after deflation aren't
> going to make a difference.
>
> Signed-off-by: David Gibson
> Reviewed-by: David Hildenbrand
> Reviewed-by: Michael S. Tsirkin
I'm having second thoughts about this. It might affect performance but
probably won't but we have no idea. Might cause latency jitter after
deflate where it previously didn't happen. This kind of patch should
really be accompanied by benchmarking results, not philosophy.
> ---
> hw/virtio/virtio-balloon.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
> index a12677d4d5..43af521884 100644
> --- a/hw/virtio/virtio-balloon.c
> +++ b/hw/virtio/virtio-balloon.c
> @@ -35,9 +35,8 @@
>
> static void balloon_page(void *addr, int deflate)
> {
> -if (!qemu_balloon_is_inhibited()) {
> -qemu_madvise(addr, BALLOON_PAGE_SIZE,
> -deflate ? QEMU_MADV_WILLNEED : QEMU_MADV_DONTNEED);
> +if (!qemu_balloon_is_inhibited() && !deflate) {
> +qemu_madvise(addr, BALLOON_PAGE_SIZE, QEMU_MADV_DONTNEED);
> }
> }
>
> --
> 2.20.1
Re: [Qemu-devel] [PATCH] trivial malloc to g_malloc in thunk
On Thu, Feb 28, 2019 at 07:12:45PM +0530, Aarushi Mehta wrote:
> Hi
>
> This is a trivial contribution part of the BiteSizedTasks on the wiki.
> I found this discussion
> http://git.corpit.ru/?p=qemu.git;a=commit;h=b45c03f585ea9bb1af76c73e82195418c294919d
> on migrating even g_malloc to g_new, is this not appropriate for the same?
> The wiki can presumably use an update regarding this.
This kind of question should not be in the commit message - it shoudl
go below the '---'
>
> Signed-off-by: Aarushi
> ---
here
This lets people answer the question, without the question becoming
part of the git history.
> thunk.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/thunk.c b/thunk.c
> index d5d8645cd4..03fb2abab7 100644
> --- a/thunk.c
> +++ b/thunk.c
> @@ -89,7 +89,7 @@ void thunk_register_struct(int id, const char *name, const
> argtype *types)
> for(i = 0;i < 2; i++) {
> offset = 0;
> max_align = 1;
> -se->field_offsets[i] = malloc(nb_fields * sizeof(int));
> +se->field_offsets[i] = g_malloc(nb_fields * sizeof(int));
Yes, this should use g_new0
> type_ptr = se->field_types;
> for(j = 0;j < nb_fields; j++) {
> size = thunk_type_size(type_ptr, i);
> --
> 2.17.1
>
>
>
Regards,
Daniel
--
|: https://berrange.com -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
[Qemu-devel] [Bug 1818075] [NEW] qemu-user-x86-64 hangs at vcvttsd2si
Public bug reported: I'm trying to execute code that has been built with -march=skylake -mtune=generic -mavx2 under qemu-user x86-64 with -cpu Skylake-Client. However this code just hangs at 100% CPU. Adding input tracing shows that it is likely hanging when dealing with an AVX instruction: warning: TCG doesn't support requested feature: CPUID.01H:ECX.fma [bit 12] warning: TCG doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17] warning: TCG doesn't support requested feature: CPUID.01H:ECX.x2apic [bit 21] warning: TCG doesn't support requested feature: CPUID.01H:ECX.tsc-deadline [bit 24] warning: TCG doesn't support requested feature: CPUID.01H:ECX.avx [bit 28] warning: TCG doesn't support requested feature: CPUID.01H:ECX.f16c [bit 29] warning: TCG doesn't support requested feature: CPUID.01H:ECX.rdrand [bit 30] warning: TCG doesn't support requested feature: CPUID.07H:EBX.hle [bit 4] warning: TCG doesn't support requested feature: CPUID.07H:EBX.avx2 [bit 5] warning: TCG doesn't support requested feature: CPUID.07H:EBX.invpcid [bit 10] warning: TCG doesn't support requested feature: CPUID.07H:EBX.rtm [bit 11] warning: TCG doesn't support requested feature: CPUID.07H:EBX.rdseed [bit 18] warning: TCG doesn't support requested feature: CPUID.8001H:ECX.3dnowprefetch [bit 8] warning: TCG doesn't support requested feature: CPUID.0DH:EAX.xsavec [bit 1] IN: 0x4000b4ef3b: c5 fb 5c ca vsubsd %xmm2, %xmm0, %xmm1 0x4000b4ef3f: c4 e1 fb 2c d1 vcvttsd2si %xmm1, %rdx 0x4000b4ef44: 4c 31 e2 xorq %r12, %rdx 0x4000b4ef47: 48 85 d2 testq%rdx, %rdx 0x4000b4ef4a: 79 9ejns 0x4000b4eeea [ hangs ] Attaching a gdb produces this stacktrace: (gdb) bt #0 canonicalize (status=0x55a20ff67a88, parm=0x55a20bb807e0 , part=...) at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/fpu/softfloat.c:350 #1 float64_unpack_canonical (s=0x55a20ff67a88, f=0) at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/fpu/softfloat.c:547 #2 float64_sub (a=0, b=4890909195324358656, status=0x55a20ff67a88) at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/fpu/softfloat.c:776 #3 0x55a20baa1949 in helper_subsd (env=, d=0x55a20ff67ad8, s=) at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/target/i386/ops_sse.h:623 #4 0x55a20cfcfea8 in static_code_gen_buffer () #5 0x55a20ba3f764 in cpu_tb_exec (itb=, cpu=0x55a20cea2180 ) at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/accel/tcg/cpu-exec.c:171 #6 cpu_loop_exec_tb (tb_exit=, last_tb=, tb=, cpu=0x55a20cea2180 ) at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/accel/tcg/cpu-exec.c:615 #7 cpu_exec (cpu=cpu@entry=0x55a20ff5f4d0) at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/accel/tcg/cpu-exec.c:725 #8 0x55a20ba6d728 in cpu_loop (env=0x55a20ff67780) at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/linux-user/x86_64/../i386/cpu_loop.c:93 #9 0x55a20ba049ff in main (argc=, argv=0x7ffc58572868, envp=) at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/linux-user/main.c:819 ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1818075 Title: qemu-user-x86-64 hangs at vcvttsd2si Status in QEMU: New Bug description: I'm trying to execute code that has been built with -march=skylake -mtune=generic -mavx2 under qemu-user x86-64 with -cpu Skylake-Client. However this code just hangs at 100% CPU. Adding input tracing shows that it is likely hanging when dealing with an AVX instruction: warning: TCG doesn't support requested feature: CPUID.01H:ECX.fma [bit 12] warning: TCG doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17] warning: TCG doesn't support requested feature: CPUID.01H:ECX.x2apic [bit 21] warning: TCG doesn't support requested feature: CPUID.01H:ECX.tsc-deadline [bit 24] warning: TCG doesn't support requested feature: CPUID.01H:ECX.avx [bit 28] warning: TCG doesn't support requested feature: CPUID.01H:ECX.f16c [bit 29] warning: TCG doesn't support requested feature: CPUID.01H:ECX.rdrand [bit 30] warning: TCG doesn't support requested feature: CPUID.07H:EBX.hle [bit 4] warning: TCG doesn't support requested feature: CPUID.07H:EBX.avx2 [bit 5] warning: TCG doesn't support requested feature: CPUID.07H:EBX.invpcid [bit 10] warning: TCG doesn't support requested feature: CPUID.07H:EBX.rtm [bit 11] warning: TCG doesn't support requested feature: CPUID.07H:EBX.rdseed [bit 18] warning: TCG doesn't support requested feature: CPUID.8001H:ECX.3dnowprefetch [bit 8] warning: TCG doesn't support
Re: [Qemu-devel] [PATCH v2 1/4] block/dirty-bitmaps: add inconsistent bit
28.02.2019 16:44, Eric Blake wrote: > On 2/28/19 4:13 AM, Vladimir Sementsov-Ogievskiy wrote: > >> +++ b/qapi/block-core.json >> @@ -470,12 +470,16 @@ >> # @persistent: true if the bitmap will eventually be flushed to >> persistent >> # storage (since 4.0) so, bitmap can't be inconsistent and persistent, as we don't want to flush inconsistent bitmaps... >>> >>> I think ideally I'd just change this phrasing to say something like >>> "true if the bitmap is stored on-disk, or is scheduled to be flushed to >>> disk." >> >> And such wording leads to immediate question: why it could be stored on disk >> but >> _not_ scheduled to be flushed.. >> >> So if you want, more honest is something like "true if bitmap will be >> flushed to >> storage or if it is @inconsistent (read ahead)." but it's not looking nice... >> >> May be something like this? >> >> true if bitmap is marked to be flushed to persistent storage. Bitmap may or >> may not >> already persist in the storage. Also true if bitmap persist in the storage >> but >> considered inconsistent, in which case it will not be flushed and only may >> be removed, >> look at @inconsistent field description. > > Too long. As @inconsistent is rare, I'd be happy with just: > > @persistent: true if the bitmap is marked for association with > persistent storage > > which covers both future flushes (for a bitmap that is not yet on disk, > but will get there later) and prior inconsistent images (where we > learned that it was inconsistent because of its existing associate with > persistent storage). Okay > >> >> Another thing: what about migration? I don't think we are going to teach >> migration protocol >> to migrate them. So, migration is a way to get rid of inconsistent bitmaps? >> Or what? Or >> we should restrict migration, if there are any inconsistent bitmap, to force >> user to remove >> them first? > > A conservative approach is to start by treating an inconsistent bitmap > as a migration blocker, and could be relaxed later if someone has an > argument for why making migration a backdoor for deletion of > inconsistent bitmaps is a good thing. > Agree -- Best regards, Vladimir
Re: [Qemu-devel] [RFC PATCH 3/4] hw/arm/virt: Enable pc-dimm hotplug support
Hi Igor,
On 2/27/19 6:14 PM, Igor Mammedov wrote:
> On Mon, 28 Jan 2019 11:05:45 +
> Shameer Kolothum wrote:
>
>> pc-dimm memory hotplug is enabled using GPIO(Pin 2) based ACPI
>> event. Hot removal functionality is not yet supported.
>>
>> Signed-off-by: Shameer Kolothum
>> ---
>> hw/arm/virt.c | 57 +++--
>> 1 file changed, 55 insertions(+), 2 deletions(-)
>>
>> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
>> index 884960d..cf64554 100644
>> --- a/hw/arm/virt.c
>> +++ b/hw/arm/virt.c
>> @@ -62,6 +62,7 @@
>> #include "hw/mem/pc-dimm.h"
>> #include "hw/mem/nvdimm.h"
>> #include "hw/acpi/acpi.h"
>> +#include "hw/acpi/pc-hotplug.h"
>>
>> #define DEFINE_VIRT_MACHINE_LATEST(major, minor, latest) \
>> static void virt_##major##_##minor##_class_init(ObjectClass *oc, \
>> @@ -1651,7 +1652,14 @@ static void machvirt_init(MachineState *machine)
>> nvdimm_init_acpi_state(acpi_nvdimm_state, sysmem,
>> vms->fw_cfg, OBJECT(vms));
>> }
>> +if (vms->acpi_memhp_state.is_enabled) {
>> +MemHotplugState *state = >acpi_memhp_state;
>> +hwaddr base;
>>
>> +state->hw_reduced_acpi = true;
>> +base = vms->memmap[VIRT_ACPI_IO].base + ACPI_MEMORY_HOTPLUG_BASE;
>> +acpi_memory_hotplug_init(sysmem, OBJECT(vms), state, base);
>> +}
> this hunk should be a part of 'acpi' device that owns respective interrupts
> and mmio regions.
> (something like we do in x86)
> In this case I'd suggest to make 'base' its property and the board will set
> it during
> device creation.
>
>> vms->bootinfo.ram_size = machine->ram_size;
>> vms->bootinfo.kernel_filename = machine->kernel_filename;
>> vms->bootinfo.kernel_cmdline = machine->kernel_cmdline;
>> @@ -1819,6 +1827,20 @@ static void virt_set_nvdimm_persistence(Object *obj,
>> const char *value,
>> nvdimm_state->persistence_string = g_strdup(value);
>> }
>>
>> +static bool virt_get_memhp_support(Object *obj, Error **errp)
>> +{
>> +VirtMachineState *vms = VIRT_MACHINE(obj);
>> +
>> +return vms->acpi_memhp_state.is_enabled;
>> +}
>> +
>> +static void virt_set_memhp_support(Object *obj, bool value, Error **errp)
>> +{
>> +VirtMachineState *vms = VIRT_MACHINE(obj);
>> +
>> +vms->acpi_memhp_state.is_enabled = value;
>> +}
>> +
>> static CpuInstanceProperties
>> virt_cpu_index_to_props(MachineState *ms, unsigned cpu_index)
>> {
>> @@ -1863,8 +1885,8 @@ static void virt_memory_pre_plug(HotplugHandler
>> *hotplug_dev, DeviceState *dev,
>> const bool is_nvdimm = object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM);
>> VirtMachineState *vms = VIRT_MACHINE(hotplug_dev);
>>
>> -if (dev->hotplugged) {
>> -error_setg(errp, "memory hotplug is not supported");
>> +if (dev->hotplugged && is_nvdimm) {
>> +error_setg(errp, "nvdimm hotplug is not supported");
>> }
>>
>> if (is_nvdimm && !vms->acpi_nvdimm_state.is_enabled) {
>> @@ -1875,6 +1897,22 @@ static void virt_memory_pre_plug(HotplugHandler
>> *hotplug_dev, DeviceState *dev,
>> pc_dimm_pre_plug(PC_DIMM(dev), MACHINE(hotplug_dev), NULL, errp);
>> }
>>
>> +static void virt_memhp_send_event(HotplugHandler *hotplug_dev, DeviceState
>> *dev,
>> + Error **errp)
>> +{
>> +DeviceState *gpio_dev;
>> +VirtMachineState *vms = VIRT_MACHINE(hotplug_dev);
>> +
>> +gpio_dev = virt_get_gpio_dev(GPIO_PCDIMM);
>> +if (!gpio_dev) {
>> +error_setg(errp, "No dev interface to send hotplug event");
> ^^ confusing
>> +return;
>> +}
>> +acpi_memory_plug_cb(hotplug_dev, >acpi_memhp_state,
>> +dev, errp);
>> +qemu_set_irq(qdev_get_gpio_in(gpio_dev, 0), 1);
>> +}
>> +
>> static void virt_memory_plug(HotplugHandler *hotplug_dev,
>> DeviceState *dev, Error **errp)
>> {
>> @@ -1891,6 +1929,10 @@ static void virt_memory_plug(HotplugHandler
>> *hotplug_dev,
>> nvdimm_plug(>acpi_nvdimm_state);
>> }
>>
>> +if (dev->hotplugged && !is_nvdimm) {
>> +virt_memhp_send_event(hotplug_dev, dev, errp);
> ...
> acpi_memory_plug_cb();
> hotplug_handler_plug(HOTPLUG_HANDLER(pcms->gpio_dev), dev, _abort);
> forward snd process hotplug notification event in gpio_dev,
>machine should not care about which and how to deal with random IRQs
>
>> +}
>> +
>> out:
>> error_propagate(errp, local_err);
>> }
>> @@ -1898,6 +1940,11 @@ out:
>> static void virt_memory_unplug(HotplugHandler *hotplug_dev,
>> DeviceState *dev, Error **errp)
>> {
>> +if (dev->hotplugged) {
>> +error_setg(errp, "memory hot unplug is not supported");
>> +return;
>> +}
> what if unplug is called on cold-plugged device?
>
> Better way to disable mgmt initiated unplug is to forbid it in
> unplug_request()
>
Re: [Qemu-devel] [Qemu-block] Guest unresponsive after Virtqueue size exceeded error
On Mon, 25 Feb 2019 at 13:06, Peter Maydell wrote: > > On Mon, 25 Feb 2019 at 12:22, Natanael Copa wrote: > > > > On Mon, 25 Feb 2019 10:34:23 + > > Peter Maydell wrote: > > > The short term fix is to fix your toolchain/compilation > > > environment options so that it isn't trying to override > > > the definition of memcpy(). > > > > The easiest workaround is to simply disable FORTIY_SOURCE, but that > > will weaken the security for all implemented string functions, strcpy, > > memmove etc, so I don't want to do that. > > > > Is it only lduw_he_p that needs to be atomic or are the other functions > > in include/qemu/bswap.h using memcpy also required to be atomic? > > Hard to say, since we haven't done the "audit all the callers" > step that Stefan mentioned. If you're going to replace memcpy > with __builtin_memcpy then the safest thing is to do it for > all those uses (this will also give you much better generated > code for performance purposes). I mentioned this to Richard on IRC the other day, but I think there's a good argument for making upstream QEMU use __builtin_memcpy in these helpers: * it makes us robust against things like this fortify library in the short term (until we fix QEMU to have an equivalent set of functions for doing atomic accesses to AddressSpaces) * in the longer term it will mean that we don't end up with these functions being really badly-performing even if the semantics of the out-of-line memcpy() are correct thanks -- PMM
Re: [Qemu-devel] [PATCH v2 1/4] block/dirty-bitmaps: add inconsistent bit
27.02.2019 21:45, John Snow wrote:
>
>
> On 2/25/19 10:30 AM, Vladimir Sementsov-Ogievskiy wrote:
>> 25.02.2019 17:18, Vladimir Sementsov-Ogievskiy wrote:
>>> 23.02.2019 3:22, John Snow wrote:
Add an inconsistent bit to dirty-bitmaps that allows us to report a bitmap
as
persistent but potentially inconsistent, i.e. if we find bitmaps on a qcow2
that have been marked as "in use".
Signed-off-by: John Snow
---
block/dirty-bitmap.c | 19 +++
include/block/dirty-bitmap.h | 2 ++
qapi/block-core.json | 8 ++--
3 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/block/dirty-bitmap.c b/block/dirty-bitmap.c
index 86c3b87ab9..9042c04788 100644
--- a/block/dirty-bitmap.c
+++ b/block/dirty-bitmap.c
@@ -46,6 +46,9 @@ struct BdrvDirtyBitmap {
and this bitmap must remain
unchanged while
this flag is set. */
bool persistent; /* bitmap must be saved to owner disk
image */
+ bool inconsistent; /* bitmap is persistent, but not owned by
QEMU.
+ * It cannot be used at all in any way,
except
+ * a QMP user can remove it. */
bool migration; /* Bitmap is selected for migration, it
should
not be stored on the next
inactivation
(persistent flag doesn't matter
until next
@@ -462,6 +465,8 @@ BlockDirtyInfoList
*bdrv_query_dirty_bitmaps(BlockDriverState *bs)
info->recording = bdrv_dirty_bitmap_recording(bm);
info->busy = bdrv_dirty_bitmap_busy(bm);
info->persistent = bm->persistent;
+ info->has_inconsistent = bm->inconsistent;
+ info->inconsistent = bm->inconsistent;
entry->value = info;
*plist = entry;
plist = >next;
@@ -709,6 +714,15 @@ void
bdrv_dirty_bitmap_set_persistance(BdrvDirtyBitmap *bitmap, bool persistent)
qemu_mutex_unlock(bitmap->mutex);
}
+/* Called with BQL taken. */
+void bdrv_dirty_bitmap_set_inconsistent(BdrvDirtyBitmap *bitmap)
+{
+ qemu_mutex_lock(bitmap->mutex);
+ bitmap->inconsistent = true;
+ bitmap->disabled = true;
+ qemu_mutex_unlock(bitmap->mutex);
+}
>>>
>>> Didn't you consider separate bdrv_create_inconsistent_bitmap, which will
>>> not allocate HBitmap?
>>>
>>> It may be done separately ofcourse..
>>>
+
/* Called with BQL taken. */
void bdrv_dirty_bitmap_set_migration(BdrvDirtyBitmap *bitmap, bool
migration)
{
@@ -722,6 +736,11 @@ bool
bdrv_dirty_bitmap_get_persistance(BdrvDirtyBitmap *bitmap)
return bitmap->persistent && !bitmap->migration;
}
+bool bdrv_dirty_bitmap_inconsistent(BdrvDirtyBitmap *bitmap)
+{
+ return bitmap->inconsistent;
+}
+
bool bdrv_has_changed_persistent_bitmaps(BlockDriverState *bs)
{
BdrvDirtyBitmap *bm;
diff --git a/include/block/dirty-bitmap.h b/include/block/dirty-bitmap.h
index ba8477b73f..b270773f7e 100644
--- a/include/block/dirty-bitmap.h
+++ b/include/block/dirty-bitmap.h
@@ -68,6 +68,7 @@ void
bdrv_dirty_bitmap_deserialize_finish(BdrvDirtyBitmap *bitmap);
void bdrv_dirty_bitmap_set_readonly(BdrvDirtyBitmap *bitmap, bool
value);
void bdrv_dirty_bitmap_set_persistance(BdrvDirtyBitmap *bitmap,
bool persistent);
+void bdrv_dirty_bitmap_set_inconsistent(BdrvDirtyBitmap *bitmap);
void bdrv_dirty_bitmap_set_busy(BdrvDirtyBitmap *bitmap, bool busy);
void bdrv_merge_dirty_bitmap(BdrvDirtyBitmap *dest, const
BdrvDirtyBitmap *src,
HBitmap **backup, Error **errp);
@@ -91,6 +92,7 @@ bool bdrv_dirty_bitmap_readonly(const BdrvDirtyBitmap
*bitmap);
bool bdrv_has_readonly_bitmaps(BlockDriverState *bs);
bool bdrv_dirty_bitmap_get_autoload(const BdrvDirtyBitmap *bitmap);
bool bdrv_dirty_bitmap_get_persistance(BdrvDirtyBitmap *bitmap);
+bool bdrv_dirty_bitmap_inconsistent(BdrvDirtyBitmap *bitmap);
bool bdrv_dirty_bitmap_busy(BdrvDirtyBitmap *bitmap);
bool bdrv_has_changed_persistent_bitmaps(BlockDriverState *bs);
BdrvDirtyBitmap *bdrv_dirty_bitmap_next(BlockDriverState *bs,
diff --git a/qapi/block-core.json b/qapi/block-core.json
index 6e543594b3..a7209fce22 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -470,12 +470,16 @@
# @persistent: true if the bitmap will eventually be flushed to
Re: [Qemu-devel] [RFC PATCH 0/4] ARM virt: ACPI memory hotplug support
Hi Laszlo, On 2/27/19 9:14 PM, Laszlo Ersek wrote: > On 02/27/19 13:55, Shameerali Kolothum Thodi wrote: >> Hi Laszlo, >> >>> -Original Message- >>> From: Shameerali Kolothum Thodi >>> Sent: 25 February 2019 09:54 >>> To: 'Laszlo Ersek' ; Auger Eric ; >>> shannon.zha...@gmail.com; peter.mayd...@linaro.org; >>> imamm...@redhat.com; qemu-devel@nongnu.org; qemu-...@nongnu.org >>> Cc: xuwei (O) ; Linuxarm ; Ard >>> Biesheuvel ; Leif Lindholm (Linaro address) >>> >>> Subject: RE: [RFC PATCH 0/4] ARM virt: ACPI memory hotplug support >> >> [...] >> >> The root cause seems to be EDK2 ACPI table checksum failure >> as NFIT table is getting updated on hot-add. This needs further >> investigation. > + Ard, Leif, Laszlo if they have any idea of what is missing/wrong. Huh, very interesting; I usually don't expect my sanity checks to fire in practice. :) The message ProcessCmdAddChecksum: invalid checksum range in "etc/acpi/tables" is logged by OVMF's and ArmVirtQemu's ACPI Platform DXE Driver when it finds an invalid COMMAND_ADD_CHECKSUM command in QEMU's ACPI linker/loader script. Please see the command definition in QEMU's "hw/acpi/bios-linker-loader.c". In particular, please refer to the function bios_linker_loader_add_checksum(), which builds the command structure, and documents the fields. (You may also refer to QEMU_LOADER_ADD_CHECKSUM in file "OvmfPkg/AcpiPlatformDxe/QemuLoader.h" in the edk2 source tree, for the same information.) The error message is logged if: - the offset at which the checksum should be stored falls outside of the size of the fw_cfg blob, or - the range over which the checksum should be calculated falls outside (at least in part) of the fw_cfg blob. To me this suggests that QEMU generates an invalid COMMAND_ADD_CHECKSUM command for the firmware. ... I've tried to skim the patches briefly. I think there must be an error in the DSDT building logic that is only active on reboot if an nvdimm module was hot-added before the reboot. >>> >>> Thanks for taking a look and the pointers. I will debug this further >>> and get back. >> >> The root cause of the issue seems to be UEFI not seeing the updated acpi >> table blob size on reboot once a new NFIT table is added(nvdimm hot added). >> >> Please see the debug logs below, >> >> Initial Guest boot >> --- >> >> Debug logs from Qemu: >> >> build_header: acpi sig DSDT len 0x5127 >> build_header: acpi sig FACP len 0x10c >> build_header: acpi sig APIC len 0xa8 >> build_header: acpi sig GTDT len 0x60 >> build_header: acpi sig MCFG len 0x3c >> build_header: acpi sig SPCR len 0x50 >> build_header: acpi sig SRAT len 0x92 >> build_header: acpi sig SSDT len 0x38f >> build_header: acpi sig XSDT len 0x5c >> virt_acpi_build: acpi table_blob len 0x5844 >> >> Debug logs from UEFI: >> >> ProcessCmdAddChecksum: File="etc/acpi/tables" ResultOffset=0x9 Start=0x0 >> Length=0x5127 Blob->Size=0x5844 >> ProcessCmdAddChecksum: File="etc/acpi/tables" ResultOffset=0x5130 >> Start=0x5127 Length=0x10C Blob->Size=0x5844 >> ProcessCmdAddChecksum: File="etc/acpi/tables" ResultOffset=0x523C >> Start=0x5233 Length=0xA8 Blob->Size=0x5844 >> ProcessCmdAddChecksum: File="etc/acpi/tables" ResultOffset=0x52E4 >> Start=0x52DB Length=0x60 Blob->Size=0x5844 >> ProcessCmdAddChecksum: File="etc/acpi/tables" ResultOffset=0x5344 >> Start=0x533B Length=0x3C Blob->Size=0x5844 >> ProcessCmdAddChecksum: File="etc/acpi/tables" ResultOffset=0x5380 >> Start=0x5377 Length=0x50 Blob->Size=0x5844 >> ProcessCmdAddChecksum: File="etc/acpi/tables" ResultOffset=0x53D0 >> Start=0x53C7 Length=0x92 Blob->Size=0x5844 >> ProcessCmdAddChecksum: File="etc/acpi/tables" ResultOffset=0x5462 >> Start=0x5459 Length=0x38F Blob->Size=0x5844 >> ProcessCmdAddChecksum: File="etc/acpi/tables" ResultOffset=0x57F1 >> Start=0x57E8 Length=0x5C Blob->Size=0x5844 >> ProcessCmdAddChecksum: File="etc/acpi/rsdp" ResultOffset=0x8 Start=0x0 >> Length=0x14 Blob->Size=0x24 >> ProcessCmdAddChecksum: File="etc/acpi/rsdp" ResultOffset=0x20 Start=0x0 >> Length=0x24 Blob->Size=0x24 >> InstallQemuFwCfgTables: installed 8 tables >> >> Guest Reboot after ndimm hot added >> >> >> Debug logs from Qemu: >> >> build_header: acpi sig DSDT len 0x5127 >> build_header: acpi sig FACP len 0x10c >> build_header: acpi sig APIC len 0xa8 >> build_header: acpi sig GTDT len 0x60 >> build_header: acpi sig MCFG len 0x3c >> build_header: acpi sig SPCR len 0x50 >> build_header: acpi sig SRAT len 0x92 >> build_header: acpi sig SSDT len 0x38f >> build_header: acpi sig NFIT len 0xe0 -->New >> build_header: acpi sig XSDT len 0x64 >> virt_acpi_build: acpi table_blob len 0x592c -->blob len updated >> >> Debug logs from UEFI: >> >> ProcessCmdAddChecksum: File="etc/acpi/tables" ResultOffset=0x9 Start=0x0
Re: [Qemu-devel] [PATCH v4] iotests: use iotests.VM in 238
Am 27.02.2019 um 15:44 hat Stefan Hajnoczi geschrieben: > Test 238 does not require the kvm accelerator. Using the qtest > accelerator allows the test to run in both non-kvm and non-tcg > environments. > > iotests.VM implicitly uses the qtest accelerator and is really the class > that this test should be using. Switch to that instead of > qemu.QEMUMachine. > > Suggested-by: Thomas Huth > Signed-off-by: Stefan Hajnoczi Thanks, applied to the block branch. Kevin
Re: [Qemu-devel] [PATCH] migration: Cleanup during exit
Dr. David Alan Gilbert (git) writes:
> From: "Dr. David Alan Gilbert"
>
> Currently we cleanup the migration object as we exit main after the
> main_loop finishes; however if there's a migration running things
> get messy and we can end up with the migration thread still trying
> to access freed structures.
>
> We now take a ref to the object around the migration thread itself,
> so the act of dropping the ref during exit doesn't cause us to lose
> the state until the thread quits.
>
> Cancelling the migration during migration also tries to get the thread
> to quit.
>
> We do this a bit earlier; so hopefully migration gets out of the way
> before all the devices etc are freed.
>
> Signed-off-by: Dr. David Alan Gilbert
> Tested-by: Alex Bennée
> ---
> include/migration/misc.h | 2 +-
> migration/migration.c| 10 +-
> vl.c | 7 ++-
> 3 files changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/include/migration/misc.h b/include/migration/misc.h
> index 0471e04d1f..6f9df74436 100644
> --- a/include/migration/misc.h
> +++ b/include/migration/misc.h
> @@ -36,7 +36,7 @@ void dump_vmstate_json_to_file(FILE *out_fp);
>
> /* migration/migration.c */
> void migration_object_init(void);
> -void migration_object_finalize(void);
> +void migration_shutdown(void);
> void qemu_start_incoming_migration(const char *uri, Error **errp);
> bool migration_is_idle(void);
> void add_migration_state_change_notifier(Notifier *notify);
> diff --git a/migration/migration.c b/migration/migration.c
> index e44f77af02..d45561f9b8 100644
> --- a/migration/migration.c
> +++ b/migration/migration.c
> @@ -126,6 +126,7 @@ static bool migration_object_check(MigrationState *ms,
> Error **errp);
> static int migration_maybe_pause(MigrationState *s,
> int *current_active_state,
> int new_state);
> +static void migrate_fd_cancel(MigrationState *s);
>
> void migration_object_init(void)
> {
> @@ -167,8 +168,13 @@ void migration_object_init(void)
> }
> }
>
> -void migration_object_finalize(void)
> +void migration_shutdown(void)
> {
> +/*
> + * Cancel the current migration - that will (eventually)
> + * stop the migration using this structure
> + */
> +migrate_fd_cancel(current_migration);
> object_unref(OBJECT(current_migration));
> }
>
> @@ -3134,6 +3140,7 @@ static void *migration_thread(void *opaque)
>
> rcu_register_thread();
>
> +object_ref(OBJECT(s));
> s->iteration_start_time = qemu_clock_get_ms(QEMU_CLOCK_REALTIME);
>
> qemu_savevm_state_header(s->to_dst_file);
> @@ -3230,6 +3237,7 @@ static void *migration_thread(void *opaque)
>
> trace_migration_thread_after_loop();
> migration_iteration_finish(s);
> +object_unref(OBJECT(s));
> rcu_unregister_thread();
> return NULL;
> }
> diff --git a/vl.c b/vl.c
> index 2f340686a7..e7f460a114 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -4579,6 +4579,12 @@ int main(int argc, char **argv, char **envp)
>
> gdbserver_cleanup();
>
> +/*
> + * cleaning up the migration object cancels any existing migration
> + * try to do this early so that it also stops using devices.
> + */
> +migration_shutdown();
> +
We do like to vary our language over here, I guess shutdown and cleanup
imply subtly different things. FWIW I suspect the gdbserver_cleanup()
should be a shutdown ;-)
Reviewed-by: Alex Bennée
> /* No more vcpu or device emulation activity beyond this point */
> vm_shutdown();
>
> @@ -4594,7 +4600,6 @@ int main(int argc, char **argv, char **envp)
> monitor_cleanup();
> qemu_chr_cleanup();
> user_creatable_cleanup();
> -migration_object_finalize();
> /* TODO: unref root container, check all devices are ok */
>
> return 0;
--
Alex Bennée
Re: [Qemu-devel] [PATCH V2] i386: extended the cpuid_level when Intel PT is enabled
On 30/01/19 00:52, Luwei Kang wrote:
> Intel Processor Trace required CPUID[0x14] but the cpuid_level
> have no change when create a kvm guest with
> e.g. "-cpu qemu64,+intel-pt".
>
> Signed-off-by: Eduardo Habkost
> Signed-off-by: Luwei Kang
> ---
> hw/i386/pc.c | 1 +
> target/i386/cpu.c | 9 +
> target/i386/cpu.h | 3 +++
> 3 files changed, 13 insertions(+)
>
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index 73d688f..72a0a70 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -122,6 +122,7 @@ GlobalProperty pc_compat_3_1[] = {
> { "Cascadelake-Server" "-" TYPE_X86_CPU, "mpx", "on" },
> { "Icelake-Client" "-" TYPE_X86_CPU, "mpx", "on" },
> { "Icelake-Server" "-" TYPE_X86_CPU, "mpx", "on" },
> +{ TYPE_X86_CPU, "x-intel-pt-auto-level", "off" },
> };
> const size_t pc_compat_3_1_len = G_N_ELEMENTS(pc_compat_3_1);
>
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 2f54125..699 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -5023,6 +5023,13 @@ static void x86_cpu_expand_features(X86CPU *cpu, Error
> **errp)
> x86_cpu_adjust_feat_level(cpu, FEAT_C000_0001_EDX);
> x86_cpu_adjust_feat_level(cpu, FEAT_SVM);
> x86_cpu_adjust_feat_level(cpu, FEAT_XSAVE);
> +
> +/* Intel Processor Trace requires CPUID[0x14] */
> +if ((env->features[FEAT_7_0_EBX] & CPUID_7_0_EBX_INTEL_PT) &&
> + kvm_enabled() && cpu->intel_pt_auto_level) {
> +x86_cpu_adjust_level(cpu, >env.cpuid_min_level, 0x14);
> +}
> +
> /* SVM requires CPUID[0x800A] */
> if (env->features[FEAT_8000_0001_ECX] & CPUID_EXT3_SVM) {
> x86_cpu_adjust_level(cpu, >cpuid_min_xlevel, 0x800A);
> @@ -5816,6 +5823,8 @@ static Property x86_cpu_properties[] = {
> DEFINE_PROP_INT32("x-hv-max-vps", X86CPU, hv_max_vps, -1),
> DEFINE_PROP_BOOL("x-hv-synic-kvm-only", X86CPU, hyperv_synic_kvm_only,
> false),
> +DEFINE_PROP_BOOL("x-intel-pt-auto-level", X86CPU, intel_pt_auto_level,
> + true),
> DEFINE_PROP_END_OF_LIST()
> };
>
> diff --git a/target/i386/cpu.h b/target/i386/cpu.h
> index 59656a7..090baa4 100644
> --- a/target/i386/cpu.h
> +++ b/target/i386/cpu.h
> @@ -1455,6 +1455,9 @@ struct X86CPU {
> /* Enable auto level-increase for all CPUID leaves */
> bool full_cpuid_auto_level;
>
> +/* Enable auto level-increase for Intel Processor Trace leave */
> +bool intel_pt_auto_level;
> +
> /* if true fill the top bits of the MTRR_PHYSMASKn variable range */
> bool fill_mtrr_mask;
>
>
Eduardo is back, but I've queued this anyway.
Thanks,
Paolo
[Qemu-devel] [PULL 12/16] target/arm: Add helpers for FMLAL
From: Richard Henderson
Note that float16_to_float32 rightly squashes SNaN to QNaN.
But of course pickNaNMulAdd, for ARM, selects SNaNs first.
So we have to preserve SNaN long enough for the correct NaN
to be selected. Thus float16_to_float32_by_bits.
Signed-off-by: Richard Henderson
Message-id: 20190219222952.22183-2-richard.hender...@linaro.org
Reviewed-by: Peter Maydell
Signed-off-by: Peter Maydell
---
target/arm/helper.h | 9 +++
target/arm/vec_helper.c | 148
2 files changed, 157 insertions(+)
diff --git a/target/arm/helper.h b/target/arm/helper.h
index 747cb64d29f..d363904278a 100644
--- a/target/arm/helper.h
+++ b/target/arm/helper.h
@@ -677,6 +677,15 @@ DEF_HELPER_FLAGS_5(gvec_sqsub_s, TCG_CALL_NO_RWG,
DEF_HELPER_FLAGS_5(gvec_sqsub_d, TCG_CALL_NO_RWG,
void, ptr, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_5(gvec_fmlal_a32, TCG_CALL_NO_RWG,
+ void, ptr, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_5(gvec_fmlal_a64, TCG_CALL_NO_RWG,
+ void, ptr, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_5(gvec_fmlal_idx_a32, TCG_CALL_NO_RWG,
+ void, ptr, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_5(gvec_fmlal_idx_a64, TCG_CALL_NO_RWG,
+ void, ptr, ptr, ptr, ptr, i32)
+
#ifdef TARGET_AARCH64
#include "helper-a64.h"
#include "helper-sve.h"
diff --git a/target/arm/vec_helper.c b/target/arm/vec_helper.c
index dfc635cf9a5..dedef62403a 100644
--- a/target/arm/vec_helper.c
+++ b/target/arm/vec_helper.c
@@ -898,3 +898,151 @@ void HELPER(gvec_sqsub_d)(void *vd, void *vq, void *vn,
}
clear_tail(d, oprsz, simd_maxsz(desc));
}
+
+/*
+ * Convert float16 to float32, raising no exceptions and
+ * preserving exceptional values, including SNaN.
+ * This is effectively an unpack+repack operation.
+ */
+static float32 float16_to_float32_by_bits(uint32_t f16, bool fz16)
+{
+const int f16_bias = 15;
+const int f32_bias = 127;
+uint32_t sign = extract32(f16, 15, 1);
+uint32_t exp = extract32(f16, 10, 5);
+uint32_t frac = extract32(f16, 0, 10);
+
+if (exp == 0x1f) {
+/* Inf or NaN */
+exp = 0xff;
+} else if (exp == 0) {
+/* Zero or denormal. */
+if (frac != 0) {
+if (fz16) {
+frac = 0;
+} else {
+/*
+ * Denormal; these are all normal float32.
+ * Shift the fraction so that the msb is at bit 11,
+ * then remove bit 11 as the implicit bit of the
+ * normalized float32. Note that we still go through
+ * the shift for normal numbers below, to put the
+ * float32 fraction at the right place.
+ */
+int shift = clz32(frac) - 21;
+frac = (frac << shift) & 0x3ff;
+exp = f32_bias - f16_bias - shift + 1;
+}
+}
+} else {
+/* Normal number; adjust the bias. */
+exp += f32_bias - f16_bias;
+}
+sign <<= 31;
+exp <<= 23;
+frac <<= 23 - 10;
+
+return sign | exp | frac;
+}
+
+static uint64_t load4_f16(uint64_t *ptr, int is_q, int is_2)
+{
+/*
+ * Branchless load of u32[0], u64[0], u32[1], or u64[1].
+ * Load the 2nd qword iff is_q & is_2.
+ * Shift to the 2nd dword iff !is_q & is_2.
+ * For !is_q & !is_2, the upper bits of the result are garbage.
+ */
+return ptr[is_q & is_2] >> ((is_2 & ~is_q) << 5);
+}
+
+/*
+ * Note that FMLAL requires oprsz == 8 or oprsz == 16,
+ * as there is not yet SVE versions that might use blocking.
+ */
+
+static void do_fmlal(float32 *d, void *vn, void *vm, float_status *fpst,
+ uint32_t desc, bool fz16)
+{
+intptr_t i, oprsz = simd_oprsz(desc);
+int is_s = extract32(desc, SIMD_DATA_SHIFT, 1);
+int is_2 = extract32(desc, SIMD_DATA_SHIFT + 1, 1);
+int is_q = oprsz == 16;
+uint64_t n_4, m_4;
+
+/* Pre-load all of the f16 data, avoiding overlap issues. */
+n_4 = load4_f16(vn, is_q, is_2);
+m_4 = load4_f16(vm, is_q, is_2);
+
+/* Negate all inputs for FMLSL at once. */
+if (is_s) {
+n_4 ^= 0x8000800080008000ull;
+}
+
+for (i = 0; i < oprsz / 4; i++) {
+float32 n_1 = float16_to_float32_by_bits(n_4 >> (i * 16), fz16);
+float32 m_1 = float16_to_float32_by_bits(m_4 >> (i * 16), fz16);
+d[H4(i)] = float32_muladd(n_1, m_1, d[H4(i)], 0, fpst);
+}
+clear_tail(d, oprsz, simd_maxsz(desc));
+}
+
+void HELPER(gvec_fmlal_a32)(void *vd, void *vn, void *vm,
+void *venv, uint32_t desc)
+{
+CPUARMState *env = venv;
+do_fmlal(vd, vn, vm, >vfp.standard_fp_status, desc,
+ get_flush_inputs_to_zero(>vfp.fp_status_f16));
+}
+
+void HELPER(gvec_fmlal_a64)(void *vd, void *vn, void *vm,
+void *venv, uint32_t desc)
+{
+CPUARMState *env = venv;
+do_fmlal(vd, vn, vm,
[Qemu-devel] [PULL 07/16] hw/arm/iotkit-sysctl: Implement CPUWAIT and INITSVTOR*
The CPUWAIT register acts as a sort of power-control: if a bit
in it is 1 then the CPU will have been forced into waiting
when the system was reset (which in QEMU we model as the
CPU starting powered off). Writing a 0 to the register will
allow the CPU to boot (for QEMU, we model this as powering
it on). Note that writing 0 to the register does not power
off a CPU.
For this to work correctly we need to also honour the
INITSVTOR* registers, which let the guest control where the
CPU will load its SP and PC from when it comes out of reset.
Signed-off-by: Peter Maydell
Reviewed-by: Richard Henderson
Message-id: 20190219125808.25174-8-peter.mayd...@linaro.org
---
hw/misc/iotkit-sysctl.c | 41 +
1 file changed, 37 insertions(+), 4 deletions(-)
diff --git a/hw/misc/iotkit-sysctl.c b/hw/misc/iotkit-sysctl.c
index 05606017fc2..e333c8169a3 100644
--- a/hw/misc/iotkit-sysctl.c
+++ b/hw/misc/iotkit-sysctl.c
@@ -25,6 +25,8 @@
#include "hw/sysbus.h"
#include "hw/registerfields.h"
#include "hw/misc/iotkit-sysctl.h"
+#include "target/arm/arm-powerctl.h"
+#include "target/arm/cpu.h"
REG32(SECDBGSTAT, 0x0)
REG32(SECDBGSET, 0x4)
@@ -69,6 +71,21 @@ static const int sysctl_id[] = {
0x0d, 0xf0, 0x05, 0xb1, /* CID0..CID3 */
};
+/*
+ * Set the initial secure vector table offset address for the core.
+ * This will take effect when the CPU next resets.
+ */
+static void set_init_vtor(uint64_t cpuid, uint32_t vtor)
+{
+Object *cpuobj = OBJECT(arm_get_cpu_by_id(cpuid));
+
+if (cpuobj) {
+if (object_property_find(cpuobj, "init-svtor", NULL)) {
+object_property_set_uint(cpuobj, vtor, "init-svtor", _abort);
+}
+}
+}
+
static uint64_t iotkit_sysctl_read(void *opaque, hwaddr offset,
unsigned size)
{
@@ -229,11 +246,18 @@ static void iotkit_sysctl_write(void *opaque, hwaddr
offset,
s->gretreg = value;
break;
case A_INITSVTOR0:
-qemu_log_mask(LOG_UNIMP, "IoTKit SysCtl INITSVTOR0 unimplemented\n");
s->initsvtor0 = value;
+set_init_vtor(0, s->initsvtor0);
break;
case A_CPUWAIT:
-qemu_log_mask(LOG_UNIMP, "IoTKit SysCtl CPUWAIT unimplemented\n");
+if ((s->cpuwait & 1) && !(value & 1)) {
+/* Powering up CPU 0 */
+arm_set_cpu_on_and_reset(0);
+}
+if ((s->cpuwait & 2) && !(value & 2)) {
+/* Powering up CPU 1 */
+arm_set_cpu_on_and_reset(1);
+}
s->cpuwait = value;
break;
case A_WICCTRL:
@@ -287,8 +311,8 @@ static void iotkit_sysctl_write(void *opaque, hwaddr offset,
if (!s->is_sse200) {
goto bad_offset;
}
-qemu_log_mask(LOG_UNIMP, "IoTKit SysCtl INITSVTOR1 unimplemented\n");
s->initsvtor1 = value;
+set_init_vtor(1, s->initsvtor1);
break;
case A_EWCTRL:
if (!s->is_sse200) {
@@ -382,7 +406,16 @@ static void iotkit_sysctl_reset(DeviceState *dev)
s->gretreg = 0;
s->initsvtor0 = 0x1000;
s->initsvtor1 = 0x1000;
-s->cpuwait = 0;
+if (s->is_sse200) {
+/*
+ * CPU 0 starts on, CPU 1 starts off. In real hardware this is
+ * configurable by the SoC integrator as a verilog parameter.
+ */
+s->cpuwait = 2;
+} else {
+/* CPU 0 starts on */
+s->cpuwait = 0;
+}
s->wicctrl = 0;
s->scsecctrl = 0;
s->fclk_div = 0;
--
2.20.1
[Qemu-devel] [PULL 02/16] hw/arm/armsse: Wire up the MHUs
Create and connect the MHUs in the SSE-200.
Signed-off-by: Peter Maydell
Reviewed-by: Richard Henderson
Message-id: 20190219125808.25174-3-peter.mayd...@linaro.org
---
include/hw/arm/armsse.h | 3 ++-
hw/arm/armsse.c | 40 ++--
2 files changed, 32 insertions(+), 11 deletions(-)
diff --git a/include/hw/arm/armsse.h b/include/hw/arm/armsse.h
index 7ef871c7dfe..81e082cccf8 100644
--- a/include/hw/arm/armsse.h
+++ b/include/hw/arm/armsse.h
@@ -95,6 +95,7 @@
#include "hw/misc/iotkit-sysctl.h"
#include "hw/misc/iotkit-sysinfo.h"
#include "hw/misc/armsse-cpuid.h"
+#include "hw/misc/armsse-mhu.h"
#include "hw/misc/unimp.h"
#include "hw/or-irq.h"
#include "hw/core/split-irq.h"
@@ -166,7 +167,7 @@ typedef struct ARMSSE {
IoTKitSysCtl sysctl;
IoTKitSysCtl sysinfo;
-UnimplementedDeviceState mhu[2];
+ARMSSEMHU mhu[2];
UnimplementedDeviceState ppu[NUM_PPUS];
UnimplementedDeviceState cachectrl[SSE_MAX_CPUS];
UnimplementedDeviceState cpusecctrl[SSE_MAX_CPUS];
diff --git a/hw/arm/armsse.c b/hw/arm/armsse.c
index 129e7ea7fe0..97e3d5e807e 100644
--- a/hw/arm/armsse.c
+++ b/hw/arm/armsse.c
@@ -282,9 +282,9 @@ static void armsse_init(Object *obj)
sizeof(s->sysinfo), TYPE_IOTKIT_SYSINFO);
if (info->has_mhus) {
sysbus_init_child_obj(obj, "mhu0", >mhu[0], sizeof(s->mhu[0]),
- TYPE_UNIMPLEMENTED_DEVICE);
+ TYPE_ARMSSE_MHU);
sysbus_init_child_obj(obj, "mhu1", >mhu[1], sizeof(s->mhu[1]),
- TYPE_UNIMPLEMENTED_DEVICE);
+ TYPE_ARMSSE_MHU);
}
if (info->has_ppus) {
for (i = 0; i < info->num_cpus; i++) {
@@ -766,22 +766,28 @@ static void armsse_realize(DeviceState *dev, Error **errp)
}
if (info->has_mhus) {
-for (i = 0; i < ARRAY_SIZE(s->mhu); i++) {
-char *name;
-char *port;
+/*
+ * An SSE-200 with only one CPU should have only one MHU created,
+ * with the region where the second MHU usually is being RAZ/WI.
+ * We don't implement that SSE-200 config; if we want to support
+ * it then this code needs to be enhanced to handle creating the
+ * RAZ/WI region instead of the second MHU.
+ */
+assert(info->num_cpus == ARRAY_SIZE(s->mhu));
+
+for (i = 0; i < ARRAY_SIZE(s->mhu); i++) {
+char *port;
+int cpunum;
+SysBusDevice *mhu_sbd = SYS_BUS_DEVICE(>mhu[i]);
-name = g_strdup_printf("MHU%d", i);
-qdev_prop_set_string(DEVICE(>mhu[i]), "name", name);
-qdev_prop_set_uint64(DEVICE(>mhu[i]), "size", 0x1000);
object_property_set_bool(OBJECT(>mhu[i]), true,
"realized", );
-g_free(name);
if (err) {
error_propagate(errp, err);
return;
}
port = g_strdup_printf("port[%d]", i + 3);
-mr = sysbus_mmio_get_region(SYS_BUS_DEVICE(>mhu[i]), 0);
+mr = sysbus_mmio_get_region(mhu_sbd, 0);
object_property_set_link(OBJECT(>apb_ppc0), OBJECT(mr),
port, );
g_free(port);
@@ -789,6 +795,20 @@ static void armsse_realize(DeviceState *dev, Error **errp)
error_propagate(errp, err);
return;
}
+
+/*
+ * Each MHU has an irq line for each CPU:
+ * MHU 0 irq line 0 -> CPU 0 IRQ 6
+ * MHU 0 irq line 1 -> CPU 1 IRQ 6
+ * MHU 1 irq line 0 -> CPU 0 IRQ 7
+ * MHU 1 irq line 1 -> CPU 1 IRQ 7
+ */
+for (cpunum = 0; cpunum < info->num_cpus; cpunum++) {
+DeviceState *cpudev = DEVICE(>armv7m[cpunum]);
+
+sysbus_connect_irq(mhu_sbd, cpunum,
+ qdev_get_gpio_in(cpudev, 6 + i));
+}
}
}
--
2.20.1
Re: [Qemu-devel] [PATCH] migration: Cleanup during exit
* Peter Xu (pet...@redhat.com) wrote: > On Wed, Feb 27, 2019 at 04:49:00PM +, Dr. David Alan Gilbert (git) wrote: > > From: "Dr. David Alan Gilbert" > > > > Currently we cleanup the migration object as we exit main after the > > main_loop finishes; however if there's a migration running things > > get messy and we can end up with the migration thread still trying > > to access freed structures. > > > > We now take a ref to the object around the migration thread itself, > > so the act of dropping the ref during exit doesn't cause us to lose > > the state until the thread quits. > > > > Cancelling the migration during migration also tries to get the thread > > to quit. > > > > We do this a bit earlier; so hopefully migration gets out of the way > > before all the devices etc are freed. > > So does it mean that even with the patch it's still possible the > migration thread will be accessing device structs that have already > been freed which can still crash QEMU? Possibly yes; I'm not sure how to go to the next stage and stop that case; the consensus seems to be we don't want to explicitly block during the exit process, so doing a join on the migration thread doesn't seem to be wanted. Dave > Thanks, > > -- > Peter Xu -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [Qemu-devel] [RFC PATCH 0/4] ARM virt: ACPI memory hotplug support
> -Original Message- > From: Auger Eric [mailto:eric.au...@redhat.com] > Sent: 28 February 2019 10:12 > To: Laszlo Ersek ; Shameerali Kolothum Thodi > ; shannon.zha...@gmail.com; > peter.mayd...@linaro.org; imamm...@redhat.com; qemu-devel@nongnu.org; > qemu-...@nongnu.org > Cc: xuwei (O) ; Linuxarm ; Ard > Biesheuvel ; Leif Lindholm (Linaro address) > > Subject: Re: [RFC PATCH 0/4] ARM virt: ACPI memory hotplug support > > Hi Laszlo, > > On 2/27/19 9:14 PM, Laszlo Ersek wrote: > > On 02/27/19 13:55, Shameerali Kolothum Thodi wrote: > >> Hi Laszlo, > >> > >>> -Original Message- > >>> From: Shameerali Kolothum Thodi > >>> Sent: 25 February 2019 09:54 > >>> To: 'Laszlo Ersek' ; Auger Eric > ; > >>> shannon.zha...@gmail.com; peter.mayd...@linaro.org; > >>> imamm...@redhat.com; qemu-devel@nongnu.org; > qemu-...@nongnu.org > >>> Cc: xuwei (O) ; Linuxarm ; > Ard > >>> Biesheuvel ; Leif Lindholm (Linaro address) > >>> > >>> Subject: RE: [RFC PATCH 0/4] ARM virt: ACPI memory hotplug support > >> > >> [...] > >> > >> The root cause seems to be EDK2 ACPI table checksum failure > >> as NFIT table is getting updated on hot-add. This needs further > >> investigation. > > + Ard, Leif, Laszlo if they have any idea of what is missing/wrong. > > Huh, very interesting; I usually don't expect my sanity checks to fire > in practice. :) > > The message > > ProcessCmdAddChecksum: invalid checksum range in > "etc/acpi/tables" > > is logged by OVMF's and ArmVirtQemu's ACPI Platform DXE Driver when > it > finds an invalid COMMAND_ADD_CHECKSUM command in QEMU's ACPI > linker/loader script. > > Please see the command definition in QEMU's > "hw/acpi/bios-linker-loader.c". In particular, please refer to the > function bios_linker_loader_add_checksum(), which builds the command > structure, and documents the fields. > > (You may also refer to QEMU_LOADER_ADD_CHECKSUM in file > "OvmfPkg/AcpiPlatformDxe/QemuLoader.h" in the edk2 source tree, for > the > same information.) > > The error message is logged if: > - the offset at which the checksum should be stored falls outside of the > size of the fw_cfg blob, or > - the range over which the checksum should be calculated falls outside > (at least in part) of the fw_cfg blob. > > To me this suggests that QEMU generates an invalid > COMMAND_ADD_CHECKSUM > command for the firmware. > > ... I've tried to skim the patches briefly. I think there must be an > error in the DSDT building logic that is only active on reboot if an > nvdimm module was hot-added before the reboot. > >>> > >>> Thanks for taking a look and the pointers. I will debug this further > >>> and get back. > >> > >> The root cause of the issue seems to be UEFI not seeing the updated acpi > >> table blob size on reboot once a new NFIT table is added(nvdimm hot > added). > >> > >> Please see the debug logs below, > >> > >> Initial Guest boot > >> --- > >> > >> Debug logs from Qemu: > >> > >> build_header: acpi sig DSDT len 0x5127 > >> build_header: acpi sig FACP len 0x10c > >> build_header: acpi sig APIC len 0xa8 > >> build_header: acpi sig GTDT len 0x60 > >> build_header: acpi sig MCFG len 0x3c > >> build_header: acpi sig SPCR len 0x50 > >> build_header: acpi sig SRAT len 0x92 > >> build_header: acpi sig SSDT len 0x38f > >> build_header: acpi sig XSDT len 0x5c > >> virt_acpi_build: acpi table_blob len 0x5844 > >> > >> Debug logs from UEFI: > >> > >> ProcessCmdAddChecksum: File="etc/acpi/tables" ResultOffset=0x9 > Start=0x0 Length=0x5127 Blob->Size=0x5844 > >> ProcessCmdAddChecksum: File="etc/acpi/tables" ResultOffset=0x5130 > Start=0x5127 Length=0x10C Blob->Size=0x5844 > >> ProcessCmdAddChecksum: File="etc/acpi/tables" ResultOffset=0x523C > Start=0x5233 Length=0xA8 Blob->Size=0x5844 > >> ProcessCmdAddChecksum: File="etc/acpi/tables" ResultOffset=0x52E4 > Start=0x52DB Length=0x60 Blob->Size=0x5844 > >> ProcessCmdAddChecksum: File="etc/acpi/tables" ResultOffset=0x5344 > Start=0x533B Length=0x3C Blob->Size=0x5844 > >> ProcessCmdAddChecksum: File="etc/acpi/tables" ResultOffset=0x5380 > Start=0x5377 Length=0x50 Blob->Size=0x5844 > >> ProcessCmdAddChecksum: File="etc/acpi/tables" ResultOffset=0x53D0 > Start=0x53C7 Length=0x92 Blob->Size=0x5844 > >> ProcessCmdAddChecksum: File="etc/acpi/tables" ResultOffset=0x5462 > Start=0x5459 Length=0x38F Blob->Size=0x5844 > >> ProcessCmdAddChecksum: File="etc/acpi/tables" ResultOffset=0x57F1 > Start=0x57E8 Length=0x5C Blob->Size=0x5844 > >> ProcessCmdAddChecksum: File="etc/acpi/rsdp" ResultOffset=0x8 Start=0x0 > Length=0x14 Blob->Size=0x24 > >> ProcessCmdAddChecksum: File="etc/acpi/rsdp" ResultOffset=0x20 > Start=0x0 Length=0x24 Blob->Size=0x24 > >> InstallQemuFwCfgTables: installed 8 tables > >> > >> Guest Reboot after ndimm hot added > >>
[Qemu-devel] [PATCH v2 1/3] qdev: Let the hotplug_handler_unplug() caller delete the device
When unplugging a device, at one point the device will be destroyed
via object_unparent(). This will, one the one hand, unrealize the
removed device hierarchy, and on the other hand, destroy/free the
device hierarchy.
When chaining hotplug handlers, we want to overwrite a bus hotplug
handler by the machine hotplug handler, to be able to perform
some part of the plug/unplug and to forward the calls to the bus hotplug
handler.
For now, the bus hotplug handler would trigger an object_unparent(), not
allowing us to perform some unplug action on a device after we forwarded
the call to the bus hotplug handler. The device would be gone at that
point.
machine_unplug_handler(dev)
/* eventually do unplug stuff */
bus_unplug_handler(dev)
/* dev is gone, we can't do more unplug stuff */
So move the object_unparent() to the original caller of the unplug. For
now, keep the unrealize() at the original places of the
object_unparent(). For implicitly chained hotplug handlers (e.g. pc
code calling acpi hotplug handlers), the object_unparent() has to be
done by the outermost caller. So when calling hotplug_handler_unplug()
from inside an unplug handler, nothing is to be done.
hotplug_handler_unplug(dev) -> calls machine_unplug_handler()
machine_unplug_handler(dev) {
/* eventually do unplug stuff */
bus_unplug_handler(dev) -> calls unrealize(dev)
/* we can do more unplug stuff but device already unrealized */
}
object_unparent(dev)
In the long run, every unplug action should be factored out of the
unrealize() function into the unplug handler (especially for PCI). Then
we can get rid of the additonal unrealize() calls and object_unparent()
will properly unrealize the device hierarchy after the device has been
unplugged.
hotplug_handler_unplug(dev) -> calls machine_unplug_handler()
machine_unplug_handler(dev) {
/* eventually do unplug stuff */
bus_unplug_handler(dev) -> only unplugs, does not unrealize
/* we can do more unplug stuff */
}
object_unparent(dev) -> will unrealize
The original approach was suggested by Igor Mammedov for the PCI
part, but I extended it to all hotplug handlers. I consider this one
step into the right direction.
To summarize:
- object_unparent() on synchronous unplugs is done by common code
-- "Caller of hotplug_handler_unplug"
- object_unparent() on asynchronous unplugs ("unplug requests") has to
be done manually
-- "Caller of hotplug_handler_unplug"
Reviewed-by: Igor Mammedov
Acked-by: Cornelia Huck
Signed-off-by: David Hildenbrand
---
hw/acpi/cpu.c| 1 +
hw/acpi/memory_hotplug.c | 1 +
hw/acpi/pcihp.c | 3 ++-
hw/core/qdev.c | 3 +--
hw/i386/pc.c | 5 ++---
hw/pci/pci.c | 3 ++-
hw/pci/pcie.c| 3 ++-
hw/pci/shpc.c| 3 ++-
hw/ppc/spapr.c | 9 ++---
hw/ppc/spapr_pci.c | 3 ++-
hw/s390x/css-bridge.c| 2 +-
hw/s390x/s390-pci-bus.c | 13 -
qdev-monitor.c | 9 +++--
13 files changed, 37 insertions(+), 21 deletions(-)
diff --git a/hw/acpi/cpu.c b/hw/acpi/cpu.c
index a0a43fe6b5..7a90c8f82d 100644
--- a/hw/acpi/cpu.c
+++ b/hw/acpi/cpu.c
@@ -126,6 +126,7 @@ static void cpu_hotplug_wr(void *opaque, hwaddr addr,
uint64_t data,
dev = DEVICE(cdev->cpu);
hotplug_ctrl = qdev_get_hotplug_handler(dev);
hotplug_handler_unplug(hotplug_ctrl, dev, NULL);
+object_unparent(OBJECT(dev));
}
break;
case ACPI_CPU_CMD_OFFSET_WR:
diff --git a/hw/acpi/memory_hotplug.c b/hw/acpi/memory_hotplug.c
index 921cad2c5e..297812d5f7 100644
--- a/hw/acpi/memory_hotplug.c
+++ b/hw/acpi/memory_hotplug.c
@@ -189,6 +189,7 @@ static void acpi_memory_hotplug_write(void *opaque, hwaddr
addr, uint64_t data,
error_free(local_err);
break;
}
+object_unparent(OBJECT(dev));
trace_mhp_acpi_pc_dimm_deleted(mem_st->selector);
}
break;
diff --git a/hw/acpi/pcihp.c b/hw/acpi/pcihp.c
index 9429181323..88e4ae1bcd 100644
--- a/hw/acpi/pcihp.c
+++ b/hw/acpi/pcihp.c
@@ -174,6 +174,7 @@ static void acpi_pcihp_eject_slot(AcpiPciHpState *s,
unsigned bsel, unsigned slo
if (!acpi_pcihp_pc_no_hotplug(s, dev)) {
hotplug_ctrl = qdev_get_hotplug_handler(qdev);
hotplug_handler_unplug(hotplug_ctrl, qdev, _abort);
+object_unparent(OBJECT(qdev));
}
}
}
@@ -269,7 +270,7 @@ void acpi_pcihp_device_plug_cb(HotplugHandler *hotplug_dev,
AcpiPciHpState *s,
void acpi_pcihp_device_unplug_cb(HotplugHandler *hotplug_dev, AcpiPciHpState
*s,
DeviceState *dev, Error **errp)
{
-object_unparent(OBJECT(dev));
+object_property_set_bool(OBJECT(dev), false, "realized", NULL);
}
void acpi_pcihp_device_unplug_request_cb(HotplugHandler *hotplug_dev,
diff --git
[Qemu-devel] [PULL 05/13] MAINTAINERS: Add an entry for the Dino machine
From: Philippe Mathieu-Daudé Add Richard as maintainer, and Helge as reviewer. Cc: Richard Henderson Cc: Helge Deller Signed-off-by: Philippe Mathieu-Daudé [thuth: Add the machine entry alphabetically] Signed-off-by: Thomas Huth --- MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index d81f9c4..892d2c4 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -851,6 +851,15 @@ S: Maintained F: hw/cris/axis_dev88.c F: hw/*/etraxfs_*.c +HP-PARISC Machines +-- +Dino +M: Richard Henderson +R: Helge Deller +S: Odd Fixes +F: hw/hppa/ +F: pc-bios/hppa-firmware.img + LM32 Machines - EVR32 and uclinux BSP -- 1.8.3.1
[Qemu-devel] [PULL 03/13] MAINTAINERS: Add missing entries for the QObject section
From: Philippe Mathieu-Daudé Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Thomas Huth Reviewed-by: Markus Armbruster Signed-off-by: Thomas Huth --- MAINTAINERS | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 3a034f9..4e38864 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1940,10 +1940,14 @@ F: include/qapi/qmp/ X: include/qapi/qmp/dispatch.h F: scripts/coccinelle/qobject.cocci F: tests/check-qdict.c -F: tests/check-qnum.c F: tests/check-qjson.c F: tests/check-qlist.c +F: tests/check-qlit.c +F: tests/check-qnull.c +F: tests/check-qnum.c +F: tests/check-qobject.c F: tests/check-qstring.c +F: qdict-test-data.txt T: git https://repo.or.cz/qemu/armbru.git qapi-next QEMU Guest Agent -- 1.8.3.1
Re: [Qemu-devel] [PULL 00/40] target/xtensa queue
Hi Peter,
On Thu, Feb 28, 2019 at 2:27 AM Peter Maydell wrote:
> On Mon, 25 Feb 2019 at 20:32, Max Filippov wrote:
> > please pull the following batch of target/xtensa updates:
>
> Hi -- I'm afraid this fails to build on some clang compilers:
>
> /Users/pm215/src/qemu-for-merges/target/xtensa/translate.c:967:14:
> error: result of comparison of constant 256 with expression of type
> 'enum resource_type' is always true
> [-Werror,-Wtautological-constant-out-of-range-compare]
> assert(r < 256 && g < 256 && n < 65536);
>~ ^ ~~~
Thanks. I've fixed it up with the following:
diff --git a/target/xtensa/translate.c b/target/xtensa/translate.c
index 616ed8f57972..bda4e9469b86 100644
--- a/target/xtensa/translate.c
+++ b/target/xtensa/translate.c
@@ -865,11 +865,12 @@ struct slot_prop {
enum resource_type {
RES_REGFILE,
RES_STATE,
+RES_MAX,
};
static uint32_t encode_resource(enum resource_type r, unsigned g, unsigned n)
{
-assert(r < 256 && g < 256 && n < 65536);
+assert(r < RES_MAX && g < 256 && n < 65536);
return (r << 24) | (g << 16) | n;
}
and pushed the updated tag 20190228-xtensa.
--
Thanks.
-- Max
Re: [Qemu-devel] [PATCH 2/3] Migration/colo.c: Fix COLO failover status error
-Original Message-
From: Dr. David Alan Gilbert [mailto:dgilb...@redhat.com]
Sent: Thursday, February 28, 2019 9:03 PM
To: Zhang, Chen
Cc: Li Zhijian ; Zhang Chen ;
Juan Quintela ; zhanghailiang
; qemu-dev
Subject: Re: [PATCH 2/3] Migration/colo.c: Fix COLO failover status error
* Zhang, Chen (chen.zh...@intel.com) wrote:
>
> -Original Message-
> From: Dr. David Alan Gilbert [mailto:dgilb...@redhat.com]
> Sent: Tuesday, February 26, 2019 6:55 PM
> To: Zhang, Chen
> Cc: Li Zhijian ; Zhang Chen
> ; Juan Quintela ;
> zhanghailiang ; qemu-dev
>
> Subject: Re: [PATCH 2/3] Migration/colo.c: Fix COLO failover status
> error
>
> * Zhang Chen (chen.zh...@intel.com) wrote:
> > From: Zhang Chen
> >
> > When finished COLO failover, the status is FAILOVER_STATUS_COMPLETED.
> > The origin codes misunderstand the FAILOVER_STATUS_REQUIRE.
> >
> > Signed-off-by: Zhang Chen
>
> > Why do these 'case's have to only deal with COMPLETED - what stops the
> > REQUIRE/ACTIVE states appearing when these routines check the status; even
> > if those states only happen for a short amount of time?
>
> Yes, other status just marked the failover processing. We can see
> colo_failover_bh(), the REQUIRE/ACTIVE only exist for a very short time.
But those other states do exist - so don't these case statements have to do
something with them?
Yes, you are right.
I will add another one patch to handle other states in this series next version.
Thanks
Zhang Chen
Dave
>
> Thanks
> Zhang Chen
>
> Dave
>
> > ---
> > migration/colo.c | 7 ---
> > 1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/migration/colo.c b/migration/colo.c index
> > a916dc178c..a13acac192 100644
> > --- a/migration/colo.c
> > +++ b/migration/colo.c
> > @@ -121,6 +121,7 @@ static void secondary_vm_do_failover(void)
> > }
> > /* Notify COLO incoming thread that failover work is finished */
> > qemu_sem_post(>colo_incoming_sem);
> > +
> > /* For Secondary VM, jump to incoming co */
> > if (mis->migration_incoming_co) {
> > qemu_coroutine_enter(mis->migration_incoming_co);
> > @@ -262,7 +263,7 @@ COLOStatus *qmp_query_colo_status(Error **errp)
> > case FAILOVER_STATUS_NONE:
> > s->reason = COLO_EXIT_REASON_NONE;
> > break;
> > -case FAILOVER_STATUS_REQUIRE:
> > +case FAILOVER_STATUS_COMPLETED:
> > s->reason = COLO_EXIT_REASON_REQUEST;
> > break;
> > default:
> > @@ -582,7 +583,7 @@ out:
> > qapi_event_send_colo_exit(COLO_MODE_PRIMARY,
> >COLO_EXIT_REASON_ERROR);
> > break;
> > -case FAILOVER_STATUS_REQUIRE:
> > +case FAILOVER_STATUS_COMPLETED:
> > qapi_event_send_colo_exit(COLO_MODE_PRIMARY,
> >COLO_EXIT_REASON_REQUEST);
> > break;
> > @@ -854,7 +855,7 @@ out:
> > qapi_event_send_colo_exit(COLO_MODE_SECONDARY,
> >COLO_EXIT_REASON_ERROR);
> > break;
> > -case FAILOVER_STATUS_REQUIRE:
> > +case FAILOVER_STATUS_COMPLETED:
> > qapi_event_send_colo_exit(COLO_MODE_SECONDARY,
> >COLO_EXIT_REASON_REQUEST);
> > break;
> > --
> > 2.17.GIT
> >
> --
> Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [Qemu-devel] [PATCH v2 0/3] PCDIMM cleanup
On Thu, 28 Feb 2019 08:46:10 +0800 Wei Yang wrote: > On Wed, Feb 27, 2019 at 06:27:49PM +0100, Igor Mammedov wrote: > >On Wed, 27 Feb 2019 13:59:20 + > >Wei Yang wrote: > > > >> On Wed, Feb 27, 2019 at 02:12:42PM +0100, Igor Mammedov wrote: > >> >On Mon, 25 Feb 2019 12:47:14 + > >> >Wei Yang wrote: > >> > > >> >> >> To me, this is a general rule for PCDIMM, they are hotpluggable. > >> >> >> > >> >> >yes, PCDIMMs are hotpluggable but apci device (piix4pm/ich9/...) > >> >> >handling hotplug > >> >> >should ignore any non-hotpluggable one. If you remove check and then > >> >> >later > >> >> >someone else would add non-hotpluggable memory device or make PC-DIMMs > >> >> >or its > >> >> >variant of non-hotpluggable one, acpi device handling will break. > >> >> >Hence I'd prefer to keep the check. > >> >> > > >> >> > >> >> Ok, if we'd support un-hotpluggable mem device, we could retain this > >> >> check. But this maybe not a proper place. > >> >> > >> >> Based on my understanding, at this point, every thing has been done > >> >> properly. If this check pass, we will send an acpi interrupt to notify > >> >> the guest. In case this is an un-hotpluggable device, every thing looks > >> >> good but no effect in guest. Because we skip the notification. > >> >> > >> >> Maybe we need to move the check in pre-plug? > >> >And what would happen then and afterwards? > >> > > >> >Point is to make one of the handlers in chain to ignore plug event > >> >(i.e. do not generate SCI event) while the rest of handlers complete > >> >successfully mapping device in address space and whatever else. > >> > > >> > >> This will have a well prepared device in system but guest is not > >> notified, right? > >yes, it's theoretically possible to move check up the call stack > >to machine level and not call secondary hotplug handler on non hotplugged > >device but that again depends on what secondary hotplug handler does. > >I'd rather keep logic independent here unless there is good reason not > >to do so. > > > > > >> My idea to move the check in pre-plug will result the qemu return when > >> it see no SCI event will be generated, so there is no device created. > >> > >> I guess current behavior is a designed decision? > >I'd say so. > >PS: > >QEMU's hotplug_hadler API is misnamed at this point as it handles both > >cold (basic device wiring) and hotplug (processing hotplug). > >Maybe we should rename it but I'm not irritated enough by it to do so. > > > > After re-read the code, I found something more. > > First let me describe my understanding a bit. > > To hotplug a device, several part are related: > > * device itself > * machine's hotplug_handler > * bus's hotplug_handler > * acpi configuration > > Currently, some checks are mixed, which makes the logic not that clear. > > Let's come back to the problem in this thread. > > The check in concern is the device's hotpluggable property. And when we look > into device_set_realized, this property is already checked at the very > beginning. This means when we go all the way down to acpi_memory_plug_cb(), if > this device is un-hotpluggable, it is must not a hotplugged device. And the > acpi_send_event() will not be triggered. > > Based on my understanding, mdev->dimm and mdev->is_enabld looks still > necessary to be set for a un-hotplugged device. For both hotpluggable and > un-hotpluggable device. Skip these two steps if the device is not hotpluggable > looks not consistent with others? it might be inconsistent and broken since we don't actually have a nonhotpluggable memory device yet. But I'd would fix it when such device is added (it might depend on being added device whether it needs to be tracked by acpi memory hotplug path or if it uses other means in which case check is correct)
Re: [Qemu-devel] [PATCH] virtio-net: do not start queues that are not enabled by the guest
On Thu, Feb 21, 2019 at 10:18:52AM +0200, Yuri Benditovich wrote:
> On Thu, Feb 21, 2019 at 8:49 AM Jason Wang wrote:
> >
> >
> > On 2019/2/21 下午2:00, Yuri Benditovich wrote:
> > > On Tue, Feb 19, 2019 at 8:27 AM Jason Wang wrote:
> > >>
> > >> On 2019/2/19 上午7:34, Michael S. Tsirkin wrote:
> > >>> On Mon, Feb 18, 2019 at 10:49:08PM +0200, Yuri Benditovich wrote:
> > On Mon, Feb 18, 2019 at 6:39 PM Michael S. Tsirkin
> > wrote:
> > > On Mon, Feb 18, 2019 at 11:58:51AM +0200, Yuri Benditovich wrote:
> > >> On Mon, Feb 18, 2019 at 5:49 AM Jason Wang
> > >> wrote:
> > >>> On 2019/2/13 下午10:51, Yuri Benditovich wrote:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1608226
> > On startup/link-up in multiqueue configuration the virtio-net
> > tries to starts all the queues, including those that the guest
> > will not enable by VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET.
> > If the guest driver does not allocate queues that it will not
> > use (for example, Windows driver does not) and number of actually
> > used queues is less that maximal number supported by the device,
> > >>> Is this a requirement of e.g NDIS? If not, could we simply allocate
> > >>> all
> > >>> queues in this case. This is usually what normal Linux driver did.
> > >>>
> > >>>
> > this causes vhost_net_start to fail and actually disables vhost
> > for all the queues, reducing the performance.
> > Current commit fixes this: initially only first queue is started,
> > upon VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET started all the queues
> > requested by the guest.
> >
> > Signed-off-by: Yuri Benditovich
> > ---
> > hw/net/virtio-net.c | 7 +--
> > 1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> > index 3f319ef723..d3b1ac6d3a 100644
> > --- a/hw/net/virtio-net.c
> > +++ b/hw/net/virtio-net.c
> > @@ -174,7 +174,7 @@ static void virtio_net_vhost_status(VirtIONet
> > *n, uint8_t status)
> > {
> > VirtIODevice *vdev = VIRTIO_DEVICE(n);
> > NetClientState *nc = qemu_get_queue(n->nic);
> > -int queues = n->multiqueue ? n->max_queues : 1;
> > +int queues = n->multiqueue ? n->curr_queues : 1;
> >
> > if (!get_vhost_net(nc->peer)) {
> > return;
> > @@ -1016,9 +1016,12 @@ static int virtio_net_handle_mq(VirtIONet
> > *n, uint8_t cmd,
> > return VIRTIO_NET_ERR;
> > }
> >
> > -n->curr_queues = queues;
> > /* stop the backend before changing the number of queues
> > to avoid handling a
> > * disabled queue */
> > +virtio_net_set_status(vdev, 0);
> > >>> Any reason for doing this?
> > >> I think there are 2 reasons:
> > >> 1. The spec does not require guest SW to allocate unused queues.
> > >> 2. We spend guest's physical memory to just make vhost happy when it
> > >> touches queues that it should not use.
> > >>
> > >> Thanks,
> > >> Yuri Benditovich
> > > The spec also says:
> > > queue_enable The driver uses this to selectively prevent
> > > the device from executing requests from this
> > > virtqueue. 1 - enabled; 0 - disabled.
> > >
> > > While this is not a conformance clause this strongly implies that
> > > queues which are not enabled are never accessed by device.
> > >
> > > Yuri I am guessing you are not enabling these unused queues right?
> > Of course, we (Windows driver) do not.
> > The code of virtio-net passes max_queues to vhost and this causes
> > vhost to try accessing all the queues, fail on unused ones and finally
> > leave vhost disabled at all.
> > >>> Jason, at least for 1.0 accessing disabled queues looks like a spec
> > >>> violation. What do you think?
> > >>
> > >> Yes, but there's some issues:
> > >>
> > >> - How to detect a disabled queue for 0.9x device? Looks like there's no
> > >> way according to the spec, so device must assume all queues was enabled.
> > > Can you please add several words - what is 0.9 device (probably this
> > > is more about driver) and
> > > what is the problem with it?
> >
> >
> > It's not a net specific issue. 0.9x device is legacy device defined in
> > the spec. We don't have a method to disable and enable a specific queue
> > at that time. Michael said we can assume queue address 0 as disabled,
> > but there's still a question of how to enable it. Spec is unclear and it
> > was too late to add thing for legacy device. For 1.0 device we have
> > queue_enable, but its implementation is incomplete, since it can work
> > with
Re: [Qemu-devel] [PATCH v2] qcow2: discard bitmap when removed
28.02.2019 12:26, Andrey Shinkevich wrote: > When a bitmap is removed, we can clean some space on the disk. The size > of a cluster may be larger, so is the size of the bitmap that includes > many clusters. Some bitmaps can be as large as tens of megabytes. > The flag QCOW2_DISCARD_ALWAYS allows a call to the raw_co_pdiscard() > that does the actual cleaning of the image on disk, while with the flag > QCOW2_DISCARD_OTHER, a reference count of the cluster is updated only. not quite right, as it depends on configuration. So I'd reword the whole message to be simpler, like: Bitmap data may take a lot of disk space, so it's better to discard it always. > > Signed-off-by: Andrey Shinkevich Reviewed-by: Vladimir Sementsov-Ogievskiy > --- > v1: Discard old bitmap directories in QCOW2 image > > In the first version of the patch, any call to qcow2_free_clusters() in > block/qcow2-bitmap.c was with the flag QCOW2_DISCARD_ALWAYS, even in the > cases when the cleaned space is insignificant, particularly, in case of > bitmap directories. > Discussed in the email thread with the message ID > <1549974951-731285-1-git-send-email-andrey.shinkev...@virtuozzo.com> > > block/qcow2-bitmap.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/block/qcow2-bitmap.c b/block/qcow2-bitmap.c > index 3ee524d..162744e 100644 > --- a/block/qcow2-bitmap.c > +++ b/block/qcow2-bitmap.c > @@ -202,7 +202,7 @@ static void clear_bitmap_table(BlockDriverState *bs, > uint64_t *bitmap_table, > continue; > } > > -qcow2_free_clusters(bs, addr, s->cluster_size, QCOW2_DISCARD_OTHER); > +qcow2_free_clusters(bs, addr, s->cluster_size, QCOW2_DISCARD_ALWAYS); > bitmap_table[i] = 0; > } > } > -- Best regards, Vladimir
[Qemu-devel] [PULL 06/16] hw/arm/iotkit-sysctl: Add SSE-200 registers
The SYSCTL block in the SSE-200 has some extra registers that
are not present in the IoTKit version. Add these registers
(as reads-as-written stubs), enabled by a new QOM property.
Signed-off-by: Peter Maydell
Reviewed-by: Richard Henderson
Message-id: 20190219125808.25174-7-peter.mayd...@linaro.org
---
include/hw/misc/iotkit-sysctl.h | 20 +++
hw/arm/armsse.c | 2 +
hw/misc/iotkit-sysctl.c | 245 +++-
3 files changed, 262 insertions(+), 5 deletions(-)
diff --git a/include/hw/misc/iotkit-sysctl.h b/include/hw/misc/iotkit-sysctl.h
index 17a145517a4..9c2f23ecd28 100644
--- a/include/hw/misc/iotkit-sysctl.h
+++ b/include/hw/misc/iotkit-sysctl.h
@@ -17,6 +17,9 @@
* "system control register" blocks.
*
* QEMU interface:
+ * + QOM property "SYS_VERSION": value of the SYS_VERSION register of the
+ *system information block of the SSE
+ *(used to identify whether to provide SSE-200-only registers)
* + sysbus MMIO region 0: the system information register bank
* + sysbus MMIO region 1: the system control register bank
*/
@@ -44,6 +47,23 @@ typedef struct IoTKitSysCtl {
uint32_t initsvtor0;
uint32_t cpuwait;
uint32_t wicctrl;
+uint32_t scsecctrl;
+uint32_t fclk_div;
+uint32_t sysclk_div;
+uint32_t clock_force;
+uint32_t initsvtor1;
+uint32_t nmi_enable;
+uint32_t ewctrl;
+uint32_t pdcm_pd_sys_sense;
+uint32_t pdcm_pd_sram0_sense;
+uint32_t pdcm_pd_sram1_sense;
+uint32_t pdcm_pd_sram2_sense;
+uint32_t pdcm_pd_sram3_sense;
+
+/* Properties */
+uint32_t sys_version;
+
+bool is_sse200;
} IoTKitSysCtl;
#endif
diff --git a/hw/arm/armsse.c b/hw/arm/armsse.c
index 97e3d5e807e..6eed2ecf809 100644
--- a/hw/arm/armsse.c
+++ b/hw/arm/armsse.c
@@ -997,6 +997,8 @@ static void armsse_realize(DeviceState *dev, Error **errp)
/* System information registers */
sysbus_mmio_map(SYS_BUS_DEVICE(>sysinfo), 0, 0x4002);
/* System control registers */
+object_property_set_int(OBJECT(>sysctl), info->sys_version,
+"SYS_VERSION", );
object_property_set_bool(OBJECT(>sysctl), true, "realized", );
if (err) {
error_propagate(errp, err);
diff --git a/hw/misc/iotkit-sysctl.c b/hw/misc/iotkit-sysctl.c
index 8c85aea9309..05606017fc2 100644
--- a/hw/misc/iotkit-sysctl.c
+++ b/hw/misc/iotkit-sysctl.c
@@ -17,6 +17,7 @@
*/
#include "qemu/osdep.h"
+#include "qemu/bitops.h"
#include "qemu/log.h"
#include "trace.h"
#include "qapi/error.h"
@@ -28,15 +29,26 @@
REG32(SECDBGSTAT, 0x0)
REG32(SECDBGSET, 0x4)
REG32(SECDBGCLR, 0x8)
+REG32(SCSECCTRL, 0xc)
+REG32(FCLK_DIV, 0x10)
+REG32(SYSCLK_DIV, 0x14)
+REG32(CLOCK_FORCE, 0x18)
REG32(RESET_SYNDROME, 0x100)
REG32(RESET_MASK, 0x104)
REG32(SWRESET, 0x108)
FIELD(SWRESET, SWRESETREQ, 9, 1)
REG32(GRETREG, 0x10c)
REG32(INITSVTOR0, 0x110)
+REG32(INITSVTOR1, 0x114)
REG32(CPUWAIT, 0x118)
-REG32(BUSWAIT, 0x11c)
+REG32(NMI_ENABLE, 0x11c) /* BUSWAIT in IoTKit */
REG32(WICCTRL, 0x120)
+REG32(EWCTRL, 0x124)
+REG32(PDCM_PD_SYS_SENSE, 0x200)
+REG32(PDCM_PD_SRAM0_SENSE, 0x20c)
+REG32(PDCM_PD_SRAM1_SENSE, 0x210)
+REG32(PDCM_PD_SRAM2_SENSE, 0x214)
+REG32(PDCM_PD_SRAM3_SENSE, 0x218)
REG32(PID4, 0xfd0)
REG32(PID5, 0xfd4)
REG32(PID6, 0xfd8)
@@ -67,6 +79,30 @@ static uint64_t iotkit_sysctl_read(void *opaque, hwaddr
offset,
case A_SECDBGSTAT:
r = s->secure_debug;
break;
+case A_SCSECCTRL:
+if (!s->is_sse200) {
+goto bad_offset;
+}
+r = s->scsecctrl;
+break;
+case A_FCLK_DIV:
+if (!s->is_sse200) {
+goto bad_offset;
+}
+r = s->fclk_div;
+break;
+case A_SYSCLK_DIV:
+if (!s->is_sse200) {
+goto bad_offset;
+}
+r = s->sysclk_div;
+break;
+case A_CLOCK_FORCE:
+if (!s->is_sse200) {
+goto bad_offset;
+}
+r = s->clock_force;
+break;
case A_RESET_SYNDROME:
r = s->reset_syndrome;
break;
@@ -79,16 +115,62 @@ static uint64_t iotkit_sysctl_read(void *opaque, hwaddr
offset,
case A_INITSVTOR0:
r = s->initsvtor0;
break;
+case A_INITSVTOR1:
+if (!s->is_sse200) {
+goto bad_offset;
+}
+r = s->initsvtor1;
+break;
case A_CPUWAIT:
r = s->cpuwait;
break;
-case A_BUSWAIT:
-/* In IoTKit BUSWAIT is reserved, R/O, zero */
-r = 0;
+case A_NMI_ENABLE:
+/* In IoTKit this is named BUSWAIT but is marked reserved, R/O, zero */
+if (!s->is_sse200) {
+r = 0;
+break;
+}
+r = s->nmi_enable;
break;
case A_WICCTRL:
r = s->wicctrl;
break;
+case A_EWCTRL:
+if (!s->is_sse200) {
+goto bad_offset;
+}
+r = s->ewctrl;
+break;
+case
[Qemu-devel] [PULL 10/16] target/arm: Gate "miscellaneous FP" insns by ID register field
There is a set of VFP instructions which we implement in
disas_vfp_v8_insn() and gate on the ARM_FEATURE_V8 bit.
These were all first introduced in v8 for A-profile, but in
M-profile they appeared in v7M. Gate them on the MVFR2
FPMisc field instead, and rename the function appropriately.
Signed-off-by: Peter Maydell
Reviewed-by: Richard Henderson
Message-id: 20190222170936.13268-3-peter.mayd...@linaro.org
---
target/arm/cpu.h | 20
target/arm/translate.c | 25 +
2 files changed, 33 insertions(+), 12 deletions(-)
diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 36ea3b58567..ff9ba387b42 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -3328,6 +3328,26 @@ static inline bool isar_feature_aa32_fp16_dpconv(const
ARMISARegisters *id)
return FIELD_EX64(id->mvfr1, MVFR1, FPHP) > 1;
}
+static inline bool isar_feature_aa32_vsel(const ARMISARegisters *id)
+{
+return FIELD_EX64(id->mvfr2, MVFR2, FPMISC) >= 1;
+}
+
+static inline bool isar_feature_aa32_vcvt_dr(const ARMISARegisters *id)
+{
+return FIELD_EX64(id->mvfr2, MVFR2, FPMISC) >= 2;
+}
+
+static inline bool isar_feature_aa32_vrint(const ARMISARegisters *id)
+{
+return FIELD_EX64(id->mvfr2, MVFR2, FPMISC) >= 3;
+}
+
+static inline bool isar_feature_aa32_vminmaxnm(const ARMISARegisters *id)
+{
+return FIELD_EX64(id->mvfr2, MVFR2, FPMISC) >= 4;
+}
+
/*
* 64-bit feature tests via id registers.
*/
diff --git a/target/arm/translate.c b/target/arm/translate.c
index b7702fb49f7..d845923a96b 100644
--- a/target/arm/translate.c
+++ b/target/arm/translate.c
@@ -3357,14 +3357,10 @@ static const uint8_t fp_decode_rm[] = {
FPROUNDING_NEGINF,
};
-static int disas_vfp_v8_insn(DisasContext *s, uint32_t insn)
+static int disas_vfp_misc_insn(DisasContext *s, uint32_t insn)
{
uint32_t rd, rn, rm, dp = extract32(insn, 8, 1);
-if (!arm_dc_feature(s, ARM_FEATURE_V8)) {
-return 1;
-}
-
if (dp) {
VFP_DREG_D(rd, insn);
VFP_DREG_N(rn, insn);
@@ -3375,15 +3371,18 @@ static int disas_vfp_v8_insn(DisasContext *s, uint32_t
insn)
rm = VFP_SREG_M(insn);
}
-if ((insn & 0x0f800e50) == 0x0e000a00) {
+if ((insn & 0x0f800e50) == 0x0e000a00 && dc_isar_feature(aa32_vsel, s)) {
return handle_vsel(insn, rd, rn, rm, dp);
-} else if ((insn & 0x0fb00e10) == 0x0e800a00) {
+} else if ((insn & 0x0fb00e10) == 0x0e800a00 &&
+ dc_isar_feature(aa32_vminmaxnm, s)) {
return handle_vminmaxnm(insn, rd, rn, rm, dp);
-} else if ((insn & 0x0fbc0ed0) == 0x0eb80a40) {
+} else if ((insn & 0x0fbc0ed0) == 0x0eb80a40 &&
+ dc_isar_feature(aa32_vrint, s)) {
/* VRINTA, VRINTN, VRINTP, VRINTM */
int rounding = fp_decode_rm[extract32(insn, 16, 2)];
return handle_vrint(insn, rd, rm, dp, rounding);
-} else if ((insn & 0x0fbc0e50) == 0x0ebc0a40) {
+} else if ((insn & 0x0fbc0e50) == 0x0ebc0a40 &&
+ dc_isar_feature(aa32_vcvt_dr, s)) {
/* VCVTA, VCVTN, VCVTP, VCVTM */
int rounding = fp_decode_rm[extract32(insn, 16, 2)];
return handle_vcvt(insn, rd, rm, dp, rounding);
@@ -3427,10 +3426,12 @@ static int disas_vfp_insn(DisasContext *s, uint32_t
insn)
}
if (extract32(insn, 28, 4) == 0xf) {
-/* Encodings with T=1 (Thumb) or unconditional (ARM):
- * only used in v8 and above.
+/*
+ * Encodings with T=1 (Thumb) or unconditional (ARM):
+ * only used for the "miscellaneous VFP features" added in v8A
+ * and v7M (and gated on the MVFR2.FPMisc field).
*/
-return disas_vfp_v8_insn(s, insn);
+return disas_vfp_misc_insn(s, insn);
}
dp = ((insn & 0xf00) == 0xb00);
--
2.20.1
[Qemu-devel] [PULL 03/16] target/arm/cpu: Allow init-svtor property to be set after realize
Make the M-profile "init-svtor" property be settable after realize.
This matches the hardware, where this is a config signal which
is sampled on CPU reset and can thus be changed between one
reset and another. To do this we have to change the API we
use to add the property.
(We will need this capability for the SSE-200.)
Signed-off-by: Peter Maydell
Reviewed-by: Richard Henderson
Message-id: 20190219125808.25174-4-peter.mayd...@linaro.org
---
target/arm/cpu.c | 29 -
1 file changed, 24 insertions(+), 5 deletions(-)
diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index 8ea6569088d..4d7f6a3bc0c 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -22,6 +22,7 @@
#include "target/arm/idau.h"
#include "qemu/error-report.h"
#include "qapi/error.h"
+#include "qapi/visitor.h"
#include "cpu.h"
#include "internals.h"
#include "qemu-common.h"
@@ -771,9 +772,21 @@ static Property arm_cpu_pmsav7_dregion_property =
pmsav7_dregion,
qdev_prop_uint32, uint32_t);
-/* M profile: initial value of the Secure VTOR */
-static Property arm_cpu_initsvtor_property =
-DEFINE_PROP_UINT32("init-svtor", ARMCPU, init_svtor, 0);
+static void arm_get_init_svtor(Object *obj, Visitor *v, const char *name,
+ void *opaque, Error **errp)
+{
+ARMCPU *cpu = ARM_CPU(obj);
+
+visit_type_uint32(v, name, >init_svtor, errp);
+}
+
+static void arm_set_init_svtor(Object *obj, Visitor *v, const char *name,
+ void *opaque, Error **errp)
+{
+ARMCPU *cpu = ARM_CPU(obj);
+
+visit_type_uint32(v, name, >init_svtor, errp);
+}
void arm_cpu_post_init(Object *obj)
{
@@ -845,8 +858,14 @@ void arm_cpu_post_init(Object *obj)
qdev_prop_allow_set_link_before_realize,
OBJ_PROP_LINK_STRONG,
_abort);
-qdev_property_add_static(DEVICE(obj), _cpu_initsvtor_property,
- _abort);
+/*
+ * M profile: initial value of the Secure VTOR. We can't just use
+ * a simple DEFINE_PROP_UINT32 for this because we want to permit
+ * the property to be set after realize.
+ */
+object_property_add(obj, "init-svtor", "uint32",
+arm_get_init_svtor, arm_set_init_svtor,
+NULL, NULL, _abort);
}
qdev_property_add_static(DEVICE(obj), _cpu_cfgend_property,
--
2.20.1
[Qemu-devel] [PULL 05/16] hw/misc/iotkit-sysctl: Correct typo in INITSVTOR0 register name
The iotkit-sysctl device has a register it names INITSVRTOR0.
This is actually a typo present in the IoTKit documentation
and also in part of the SSE-200 documentation: it should be
INITSVTOR0 because it is specifying the initial value of the
Secure VTOR register in the CPU. Correct the typo.
Signed-off-by: Peter Maydell
Reviewed-by: Richard Henderson
Message-id: 20190219125808.25174-6-peter.mayd...@linaro.org
---
include/hw/misc/iotkit-sysctl.h | 2 +-
hw/misc/iotkit-sysctl.c | 16
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/include/hw/misc/iotkit-sysctl.h b/include/hw/misc/iotkit-sysctl.h
index e36613cb5ee..17a145517a4 100644
--- a/include/hw/misc/iotkit-sysctl.h
+++ b/include/hw/misc/iotkit-sysctl.h
@@ -41,7 +41,7 @@ typedef struct IoTKitSysCtl {
uint32_t reset_syndrome;
uint32_t reset_mask;
uint32_t gretreg;
-uint32_t initsvrtor0;
+uint32_t initsvtor0;
uint32_t cpuwait;
uint32_t wicctrl;
} IoTKitSysCtl;
diff --git a/hw/misc/iotkit-sysctl.c b/hw/misc/iotkit-sysctl.c
index a21d8bd6789..8c85aea9309 100644
--- a/hw/misc/iotkit-sysctl.c
+++ b/hw/misc/iotkit-sysctl.c
@@ -33,7 +33,7 @@ REG32(RESET_MASK, 0x104)
REG32(SWRESET, 0x108)
FIELD(SWRESET, SWRESETREQ, 9, 1)
REG32(GRETREG, 0x10c)
-REG32(INITSVRTOR0, 0x110)
+REG32(INITSVTOR0, 0x110)
REG32(CPUWAIT, 0x118)
REG32(BUSWAIT, 0x11c)
REG32(WICCTRL, 0x120)
@@ -76,8 +76,8 @@ static uint64_t iotkit_sysctl_read(void *opaque, hwaddr
offset,
case A_GRETREG:
r = s->gretreg;
break;
-case A_INITSVRTOR0:
-r = s->initsvrtor0;
+case A_INITSVTOR0:
+r = s->initsvtor0;
break;
case A_CPUWAIT:
r = s->cpuwait;
@@ -145,9 +145,9 @@ static void iotkit_sysctl_write(void *opaque, hwaddr offset,
*/
s->gretreg = value;
break;
-case A_INITSVRTOR0:
-qemu_log_mask(LOG_UNIMP, "IoTKit SysCtl INITSVRTOR0 unimplemented\n");
-s->initsvrtor0 = value;
+case A_INITSVTOR0:
+qemu_log_mask(LOG_UNIMP, "IoTKit SysCtl INITSVTOR0 unimplemented\n");
+s->initsvtor0 = value;
break;
case A_CPUWAIT:
qemu_log_mask(LOG_UNIMP, "IoTKit SysCtl CPUWAIT unimplemented\n");
@@ -206,7 +206,7 @@ static void iotkit_sysctl_reset(DeviceState *dev)
s->reset_syndrome = 1;
s->reset_mask = 0;
s->gretreg = 0;
-s->initsvrtor0 = 0x1000;
+s->initsvtor0 = 0x1000;
s->cpuwait = 0;
s->wicctrl = 0;
}
@@ -230,7 +230,7 @@ static const VMStateDescription iotkit_sysctl_vmstate = {
VMSTATE_UINT32(reset_syndrome, IoTKitSysCtl),
VMSTATE_UINT32(reset_mask, IoTKitSysCtl),
VMSTATE_UINT32(gretreg, IoTKitSysCtl),
-VMSTATE_UINT32(initsvrtor0, IoTKitSysCtl),
+VMSTATE_UINT32(initsvtor0, IoTKitSysCtl),
VMSTATE_UINT32(cpuwait, IoTKitSysCtl),
VMSTATE_UINT32(wicctrl, IoTKitSysCtl),
VMSTATE_END_OF_LIST()
--
2.20.1
Re: [Qemu-devel] [PULL 0/7] softfloat updates, mostly for s390x
On Tue, 26 Feb 2019 at 14:12, Alex Bennée wrote: > > The following changes since commit ef80b99ce7ffbd66b3efd493f4ca99f8abf59e79: > > Merge remote-tracking branch > 'remotes/stsquad/tags/pull-testing-next-220219-1' into staging (2019-02-25 > 14:04:20 +) > > are available in the Git repository at: > > https://github.com/stsquad/qemu.git tags/pull-fpu-next-260219-1 > > for you to fetch changes up to bf30e8662cd2ee8b750945591cb34a31784fb994: > > tests/Makefile.include: test all rounding modes of softfloat (2019-02-26 > 14:08:03 +) > > > Softloat updates, mostly in preparation for s390x usage > > Applied, thanks. Please update the changelog at https://wiki.qemu.org/ChangeLog/4.0 for any user-visible changes. -- PMM
Re: [Qemu-devel] [RFC PATCH 1/4] hw:acpi: Make ACPI IO address space configurable
> -Original Message-
> From: Igor Mammedov [mailto:imamm...@redhat.com]
> Sent: 27 February 2019 16:28
> To: Shameerali Kolothum Thodi
> Cc: eric.au...@redhat.com; shannon.zha...@gmail.com;
> peter.mayd...@linaro.org; qemu-devel@nongnu.org; qemu-...@nongnu.org;
> xuwei (O) ; Linuxarm
> Subject: Re: [RFC PATCH 1/4] hw:acpi: Make ACPI IO address space
> configurable
>
> On Mon, 28 Jan 2019 11:05:43 +
> Shameer Kolothum wrote:
>
> > This is in preparation for adding support for ARM64 platforms where it
> > doesn't use port mapped IO for ACPI IO space.
> >
> > Also add a flag to identify hw reduced ACPI platforms as they might
> > use GPIO hw for signaling ACPI platform events.
> >
> > Signed-off-by: Shameer Kolothum
> > ---
> > hw/acpi/memory_hotplug.c | 13 -
> > hw/i386/acpi-build.c | 3 ++-
> > include/hw/acpi/memory_hotplug.h | 6 --
> > 3 files changed, 14 insertions(+), 8 deletions(-)
> >
> > diff --git a/hw/acpi/memory_hotplug.c b/hw/acpi/memory_hotplug.c index
> > 921cad2..05f1d45 100644
> > --- a/hw/acpi/memory_hotplug.c
> > +++ b/hw/acpi/memory_hotplug.c
> > @@ -34,7 +34,7 @@
> > #define MEMORY_HOTPLUG_IO_LEN 24
> > #define MEMORY_DEVICES_CONTAINER "\\_SB.MHPC"
> >
> > -static uint16_t memhp_io_base;
> > +static hwaddr memhp_io_base;
> >
> > static ACPIOSTInfo *acpi_memory_device_status(int slot, MemStatus
> > *mdev) { @@ -208,7 +208,7 @@ static const MemoryRegionOps
> > acpi_memory_hotplug_ops = { };
> >
> > void acpi_memory_hotplug_init(MemoryRegion *as, Object *owner,
> > - MemHotplugState *state, uint16_t
> io_base)
> > + MemHotplugState *state, hwaddr
> io_base)
> > {
> > MachineState *machine = MACHINE(qdev_get_machine());
> >
> > @@ -279,7 +279,9 @@ void acpi_memory_plug_cb(HotplugHandler
> *hotplug_dev, MemHotplugState *mem_st,
> > mdev->is_enabled = true;
> > if (dev->hotplugged) {
> > mdev->is_inserting = true;
> > -acpi_send_event(DEVICE(hotplug_dev),
> ACPI_MEMORY_HOTPLUG_STATUS);
> > +if (!mem_st->hw_reduced_acpi) {
> > +acpi_send_event(DEVICE(hotplug_dev),
> ACPI_MEMORY_HOTPLUG_STATUS);
> > +}
> Why do you restrict it to non hw_reduced_acpi?
>
> If anything else, I'd expect virt board (or hotplug controller (GED or
> whatever)
> implement AcpiDeviceIfClass and implement arm/virt board specific call backs)
Right. Since this was based on GPIO I was keeping it simple and didn't attempt
to take the AcpiDeviceIfClass path. I will address that with GED.
> then you won't need duplicate and carry hw_reduced_acpi in generic code.
>
> The rest of the patch looks good.
Thanks,
Shameer
> > }
> > }
> >
> > @@ -341,7 +343,8 @@ const VMStateDescription
> vmstate_memory_hotplug =
> > {
> >
> > void build_memory_hotplug_aml(Aml *table, uint32_t nr_mem,
> >const char *res_root,
> > - const char *event_handler_method)
> > + const char *event_handler_method,
> > + AmlRegionSpace rs)
> > {
> > int i;
> > Aml *ifctx;
> > @@ -371,7 +374,7 @@ void build_memory_hotplug_aml(Aml *table,
> uint32_t nr_mem,
> > aml_append(mem_ctrl_dev, aml_name_decl("_CRS", crs));
> >
> > aml_append(mem_ctrl_dev, aml_operation_region(
> > -MEMORY_HOTPLUG_IO_REGION, AML_SYSTEM_IO,
> > +MEMORY_HOTPLUG_IO_REGION, rs,
> > aml_int(memhp_io_base), MEMORY_HOTPLUG_IO_LEN)
> > );
> >
> > diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c index
> > 2e21a31..b62c1a3 100644
> > --- a/hw/i386/acpi-build.c
> > +++ b/hw/i386/acpi-build.c
> > @@ -1852,7 +1852,8 @@ build_dsdt(GArray *table_data, BIOSLinker
> *linker,
> > build_cpus_aml(dsdt, machine, opts, pm->cpu_hp_io_base,
> > "\\_SB.PCI0", "\\_GPE._E02");
> > }
> > -build_memory_hotplug_aml(dsdt, nr_mem, "\\_SB.PCI0",
> "\\_GPE._E03");
> > +build_memory_hotplug_aml(dsdt, nr_mem, "\\_SB.PCI0",
> > + "\\_GPE._E03", AML_SYSTEM_IO);
> >
> > scope = aml_scope("_GPE");
> > {
> > diff --git a/include/hw/acpi/memory_hotplug.h
> > b/include/hw/acpi/memory_hotplug.h
> > index 77c6576..ec56579 100644
> > --- a/include/hw/acpi/memory_hotplug.h
> > +++ b/include/hw/acpi/memory_hotplug.h
> > @@ -26,10 +26,11 @@ typedef struct MemHotplugState {
> > uint32_t selector;
> > uint32_t dev_count;
> > MemStatus *devs;
> > +bool hw_reduced_acpi; /*true for hw reduced acpi platform */
> > } MemHotplugState;
> >
> > void acpi_memory_hotplug_init(MemoryRegion *as, Object *owner,
> > - MemHotplugState *state, uint16_t
> io_base);
> > + MemHotplugState *state, hwaddr
> > + io_base);
> >
> > void acpi_memory_plug_cb(HotplugHandler *hotplug_dev,
>
Re: [Qemu-devel] [PATCH] migration: Cleanup during exit
* Daniel P. Berrangé (berra...@redhat.com) wrote: > On Thu, Feb 28, 2019 at 11:40:19AM +, Dr. David Alan Gilbert wrote: > > * Peter Xu (pet...@redhat.com) wrote: > > > On Wed, Feb 27, 2019 at 04:49:00PM +, Dr. David Alan Gilbert (git) > > > wrote: > > > > From: "Dr. David Alan Gilbert" > > > > > > > > Currently we cleanup the migration object as we exit main after the > > > > main_loop finishes; however if there's a migration running things > > > > get messy and we can end up with the migration thread still trying > > > > to access freed structures. > > > > > > > > We now take a ref to the object around the migration thread itself, > > > > so the act of dropping the ref during exit doesn't cause us to lose > > > > the state until the thread quits. > > > > > > > > Cancelling the migration during migration also tries to get the thread > > > > to quit. > > > > > > > > We do this a bit earlier; so hopefully migration gets out of the way > > > > before all the devices etc are freed. > > > > > > So does it mean that even with the patch it's still possible the > > > migration thread will be accessing device structs that have already > > > been freed which can still crash QEMU? > > > > Possibly yes; I'm not sure how to go to the next stage and stop that > > case; the consensus seems to be we don't want to explicitly block > > during the exit process, so doing a join on the migration thread doesn't > > seem to be wanted. > > Essentially the many *_cleanup() calls at the end of main() in vl.c > are only ever safe if all background threads have stopped using the > resources that are being freed. This isn't the case with migration > currently. I also worry about other threads that might be running > in QEMU, SPICE in particular as it touchs many device backends. > > Aborting the migration & joining the migration threads is the natural > way to address this. Cancelling appears to require the main loop to > still be running, so would require main_loop_should_exit() to issue > the cancel & return false unless it has completed. This would delay > shutdown for as long as it takes migration to abort. ish - cancelling performs a shutdown(2) on the fd, that should be enough in most cases to kick the migration thread into falling out without main loop interaction; I think... > FWIW, even the bdrv_close_all() call during shutdown can delay things > for a considerable time if draining the backends isn't a quick op, > which could be the case if there are storage problems (blocked local > I/O, or interrupted network - rbd/ceph/nfs clients). So I'm not sure > that stopping migration is inherantly worse than what's already > possible with block cleanup, in terms of delaying things. > > A slightly more hacky approach would be to pthread_cancel() all the > migration threads. Normally we'd never use pthread_cancel() as it > is incredibly hard to ensure all memory used by the threads is > freed. Since we're about to exit the process though, this cleanup > does not matter. The risk, however, is that one of the threads is > holding a mutex which then blocks the rest of the *cleanup functions, > so this still feels dangerous. > > Overall to me a clean cancel & join of the migration threads feels > like the only safe option, unless we just remove all notion of > cleanup from QEMU & delete all the _cleanup functions in main() > and let the OS free all memory. That's actually my preference; I think trying to do clean tidy ups here is very racy and doesn't gain much. However, for things like storage there may be locks that have to be properly dropped and bitmaps and things to be stored/sync'd - so just exiting probably isn't safe either. Dave > Regards, > Daniel > -- > |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o-https://fstop138.berrange.com :| > |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
[Qemu-devel] [PULL 12/13] tests/test-qga: Reenable guest-agent qtest
From: Philippe Mathieu-Daudé Due to a misuse of rules.mak logical functions, commit f386df17448 disabled the guest-agent test. Enable it back. Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Thomas Huth Reviewed-by: Laurent Vivier Signed-off-by: Thomas Huth --- tests/Makefile.include | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/Makefile.include b/tests/Makefile.include index 370de59..4154da2 100644 --- a/tests/Makefile.include +++ b/tests/Makefile.include @@ -112,7 +112,7 @@ check-unit-y += tests/test-crypto-secret$(EXESUF) check-unit-$(CONFIG_GNUTLS) += tests/test-crypto-tlscredsx509$(EXESUF) check-unit-$(CONFIG_GNUTLS) += tests/test-crypto-tlssession$(EXESUF) ifneq (,$(findstring qemu-ga,$(TOOLS))) -check-unit-$(land,$(CONFIG_LINUX),$(CONFIG_VIRTIO_SERIAL)) += tests/test-qga$(EXESUF) +check-unit-$(call land,$(CONFIG_LINUX),$(CONFIG_VIRTIO_SERIAL)) += tests/test-qga$(EXESUF) endif check-unit-y += tests/test-timed-average$(EXESUF) check-unit-$(CONFIG_INOTIFY1) += tests/test-util-filemonitor$(EXESUF) -- 1.8.3.1
[Qemu-devel] [RFC v2 0/3] intel_iommu: support scalable mode
Intel vt-d rev3.0 [1] introduces a new translation mode called 'scalable mode', which enables PASID-granular translations for first level, second level, nested and pass-through modes. The vt-d scalable mode is the key ingredient to enable Scalable I/O Virtualization (Scalable IOV) [2] [3], which allows sharing a device in minimal possible granularity (ADI - Assignable Device Interface). As a result, previous Extended Context (ECS) mode is deprecated (no production ever implements ECS). This patch set emulates a minimal capability set of VT-d scalable mode, equivalent to what is available in VT-d legacy mode today: 1. Scalable mode root entry, context entry and PASID table 2. Seconds level translation under scalable mode 3. Queued invalidation (with 256 bits descriptor) 4. Pass-through mode Corresponding intel-iommu driver support will be included in kernel 5.0: https://www.spinics.net/lists/kernel/msg2985279.html We will add emulation of full scalable mode capability along with guest iommu driver progress later, e.g.: 1. First level translation 2. Nested translation 3. Per-PASID invalidation descriptors 4. Page request services for handling recoverable faults To verify the patches, below cases were tested according to Peter Xu's suggestions. +-+++ | | w/ Device Passthr | w/o Device Passthr | | +---++---++ | | virtio-net-pci, vhost=on | virtio-net-pci, vhost=off | virtio-net-pci, vhost=on | virtio-net-pci, vhost=off | | +---++---++ | | netperf | kernel bld | data cp| netperf | kernel bld | data cp | netperf | kernel bld | data cp| netperf | kernel bld | data cp | +-+---++---++ | Legacy | Pass| Pass | Pass | Pass| Pass | Pass | Pass| Pass | Pass | Pass| Pass | Pass| +-+---++---++ | Scalable| Pass| Pass | Pass | Pass| Pass | Pass | Pass| Pass | Pass | Pass| Pass | Pass| +-+---++---++ References: [1] https://software.intel.com/en-us/download/intel-virtualization-technology-for-directed-io-architecture-specification [2] https://software.intel.com/en-us/download/intel-scalable-io-virtualization-technical-specification [3] https://schd.ws/hosted_files/lc32018/00/LC3-SIOV-final.pdf --- v1->v2 Patch 1: - remove unnecessary macros. - rename macros to capital. - make 're->hi' assignment be unconditional to simplify codes. - remove 'vtd_get_context_base' to embed its content into caller. - remove 'vtd_context_entry_format' to to embed its content into caller. - remove unnecessary memset for 'pe->val'. - use 'INTEL_IOMMU_DEVICE' to get 'IntelIOMMUState' to remove input 'IntelIOMMUState *s' parameter. - call 'vtd_get_domain_id' to get domain_id. - check error code returned by 'vtd_ce_get_rid2pasid_entry' in 'vtd_dev_pt_enabled'. - check '!is_fpd_set' of context entry before handing pasid entry. - move 's->root_scalable' assignment to patch 3. - add comment for 'VTD_FR_PASID_TABLE_INV'. - remove not used 'VTD_ROOT_ENTRY_SIZE'. - change 'VTD_CTX_ENTRY_LECY_SIZE' to 'VTD_CTX_ENTRY_LEGACY_SIZE'. - change 'VTD_CTX_ENTRY_SM_SIZE' to 'VTD_CTX_ENTRY_SCALABLE_SIZE'. - use union in 'struct VTDContextEntry' to reduce code changes. Patch 2: - modify s-o-b position. - remove unnecessary macros. - change 'iq_dw' type to bool. - remove initialization to 'inv_desc->val[]'. - modify 'VTDInvDesc' to add a union 'val[4]' to be compatible with both legacy mode and scalable mode. Patch 3: - rename "scalable-mode" to "x-scalable-mode". - remove caching_mode check when scalable_mode is set. - check dma_drain check when scalable_mode is set. This is requested by spec. - remove redundant macros. --- Liu, Yi L (2): intel_iommu: scalable mode emulation intel_iommu: add 256 bits qi_desc support Yi Sun (1): intel_iommu: add scalable-mode option to make scalable mode work hw/i386/intel_iommu.c | 540
Re: [Qemu-devel] [PATCH] trivial malloc to g_malloc in thunk
On Thu, 28 Feb 2019 at 14:00, Eric Blake wrote:
>
> On 2/28/19 7:42 AM, Aarushi Mehta wrote:
> > Hi
> >
> > This is a trivial contribution part of the BiteSizedTasks on the wiki.
> > I found this discussion
> > http://git.corpit.ru/?p=qemu.git;a=commit;h=b45c03f585ea9bb1af76c73e82195418c294919d
> > on migrating even g_malloc to g_new, is this not appropriate for the same?
> > The wiki can presumably use an update regarding this.
> >
> > Signed-off-by: Aarushi
> > ---
> > thunk.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/thunk.c b/thunk.c
> > index d5d8645cd4..03fb2abab7 100644
> > --- a/thunk.c
> > +++ b/thunk.c
> > @@ -89,7 +89,7 @@ void thunk_register_struct(int id, const char *name,
> > const argtype *types)
> > for(i = 0;i < 2; i++) {
> > offset = 0;
> > max_align = 1;
> > -se->field_offsets[i] = malloc(nb_fields * sizeof(int));
> > +se->field_offsets[i] = g_malloc(nb_fields * sizeof(int));
>
> Where is the counterpart free() that needs to be changed to g_free()?
There is none, because this code sets up a data structure at
startup which then lasts for the lifetime of the QEMU process.
This is definitely worth noting in the commit message.
thanks
-- PMM
Re: [Qemu-devel] [PATCH qemu] configure: Enable werror for git worktrees
On Thu, 28 Feb 2019 at 04:36, Alexey Kardashevskiy wrote:
>
> The configure script checks multiple times whether it works in a git
> repository and it does this by "test -e "${source_path}/.git" in 4 cases
> but in one case where it tries to enable werror "-d" is used there which
> fails on git worktrees as .git is a file then and not a directory.
>
> This changes the test to "-e" as other occurrences.
>
> Signed-off-by: Alexey Kardashevskiy
> ---
> configure | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Given that there is this non-obvious pitfall in trying to
hand-code the "are we running from git?" check and that
we do it in five places in configure, that suggests that
we should abstract this out:
sources_in_git() {
# Note that -d will give the wrong answer for git worktrees
test -e "$source_path/.git"
}
and then use wherever we're currently checking by hand:
if sources_in_git && ...
(warning: code not tested at all)
Defining a sources_in_git variable which we set at
the start of the script would work too; no strong preference.
thanks
-- PMM
[Qemu-devel] [Bug 1815889] Re: qemu-system-x86_64 crashed with signal 31 in __pthread_setaffinity_new()
Thanks Daniel and MarcAndre for chiming in here. Atfer thinking more about it I agree to Daniel that actually mesa should honor and stick with its affinity assignment. For documentation purpose: the solution proposed on the ML is at https://lists.freedesktop.org/archives/mesa-dev/2019-February/215926.html I also added a bug tracker to the fredesktop bug as task. ** Also affects: mesa (Ubuntu) Importance: Undecided Status: New ** Also affects: mesa via https://bugs.freedesktop.org/show_bug.cgi?id=109695 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1815889 Title: qemu-system-x86_64 crashed with signal 31 in __pthread_setaffinity_new() Status in Mesa: Unknown Status in QEMU: New Status in mesa package in Ubuntu: New Status in qemu package in Ubuntu: Triaged Bug description: Unable to launch Default Fedora 29 images in gnome-boxes ProblemType: Crash DistroRelease: Ubuntu 19.04 Package: qemu-system-x86 1:3.1+dfsg-2ubuntu1 ProcVersionSignature: Ubuntu 4.19.0-12.13-generic 4.19.18 Uname: Linux 4.19.0-12-generic x86_64 ApportVersion: 2.20.10-0ubuntu20 Architecture: amd64 Date: Thu Feb 14 11:00:45 2019 ExecutablePath: /usr/bin/qemu-system-x86_64 KvmCmdLine: COMMAND STAT EUID RUID PID PPID %CPU COMMAND MachineType: Dell Inc. Precision T3610 ProcEnviron: PATH=(custom, user) ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.19.0-12-generic root=UUID=939b509b-d627-4642-a655-979b44972d17 ro splash quiet vt.handoff=1 Signal: 31 SourcePackage: qemu StacktraceTop: __pthread_setaffinity_new (th=, cpusetsize=128, cpuset=0x7f5771fbf680) at ../sysdeps/unix/sysv/linux/pthread_setaffinity.c:34 () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so start_thread (arg=) at pthread_create.c:486 clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Title: qemu-system-x86_64 crashed with signal 31 in __pthread_setaffinity_new() UpgradeStatus: Upgraded to disco on 2018-11-14 (91 days ago) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo video dmi.bios.date: 11/14/2018 dmi.bios.vendor: Dell Inc. dmi.bios.version: A18 dmi.board.name: 09M8Y8 dmi.board.vendor: Dell Inc. dmi.board.version: A01 dmi.chassis.type: 7 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA18:bd11/14/2018:svnDellInc.:pnPrecisionT3610:pvr00:rvnDellInc.:rn09M8Y8:rvrA01:cvnDellInc.:ct7:cvr: dmi.product.name: Precision T3610 dmi.product.sku: 05D2 dmi.product.version: 00 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/mesa/+bug/1815889/+subscriptions
[Qemu-devel] [PULL 04/16] target/arm/arm-powerctl: Add new arm_set_cpu_on_and_reset()
Currently the Arm arm-powerctl.h APIs allow:
* arm_set_cpu_on(), which powers on a CPU and sets its
initial PC and other startup state
* arm_reset_cpu(), which resets a CPU which is already on
(and fails if the CPU is powered off)
but there is no way to say "power on a CPU as if it had
just come out of reset and don't do anything else to it".
Add a new function arm_set_cpu_on_and_reset(), which does this.
Signed-off-by: Peter Maydell
Reviewed-by: Richard Henderson
Message-id: 20190219125808.25174-5-peter.mayd...@linaro.org
---
target/arm/arm-powerctl.h | 16 +++
target/arm/arm-powerctl.c | 56 +++
2 files changed, 72 insertions(+)
diff --git a/target/arm/arm-powerctl.h b/target/arm/arm-powerctl.h
index 04353923c06..37c8a04f0a9 100644
--- a/target/arm/arm-powerctl.h
+++ b/target/arm/arm-powerctl.h
@@ -74,4 +74,20 @@ int arm_set_cpu_off(uint64_t cpuid);
*/
int arm_reset_cpu(uint64_t cpuid);
+/*
+ * arm_set_cpu_on_and_reset:
+ * @cpuid: the id of the CPU we want to star
+ *
+ * Start the cpu designated by @cpuid and put it through its normal
+ * CPU reset process. The CPU will start in the way it is architected
+ * to start after a power-on reset.
+ *
+ * Returns: QEMU_ARM_POWERCTL_RET_SUCCESS on success.
+ * QEMU_ARM_POWERCTL_INVALID_PARAM if there is no CPU with that ID.
+ * QEMU_ARM_POWERCTL_ALREADY_ON if the CPU is already on.
+ * QEMU_ARM_POWERCTL_ON_PENDING if the CPU is already partway through
+ * powering on.
+ */
+int arm_set_cpu_on_and_reset(uint64_t cpuid);
+
#endif
diff --git a/target/arm/arm-powerctl.c b/target/arm/arm-powerctl.c
index f9de5164e55..f77a950db67 100644
--- a/target/arm/arm-powerctl.c
+++ b/target/arm/arm-powerctl.c
@@ -228,6 +228,62 @@ int arm_set_cpu_on(uint64_t cpuid, uint64_t entry,
uint64_t context_id,
return QEMU_ARM_POWERCTL_RET_SUCCESS;
}
+static void arm_set_cpu_on_and_reset_async_work(CPUState *target_cpu_state,
+run_on_cpu_data data)
+{
+ARMCPU *target_cpu = ARM_CPU(target_cpu_state);
+
+/* Initialize the cpu we are turning on */
+cpu_reset(target_cpu_state);
+target_cpu_state->halted = 0;
+
+/* Finally set the power status */
+assert(qemu_mutex_iothread_locked());
+target_cpu->power_state = PSCI_ON;
+}
+
+int arm_set_cpu_on_and_reset(uint64_t cpuid)
+{
+CPUState *target_cpu_state;
+ARMCPU *target_cpu;
+
+assert(qemu_mutex_iothread_locked());
+
+/* Retrieve the cpu we are powering up */
+target_cpu_state = arm_get_cpu_by_id(cpuid);
+if (!target_cpu_state) {
+/* The cpu was not found */
+return QEMU_ARM_POWERCTL_INVALID_PARAM;
+}
+
+target_cpu = ARM_CPU(target_cpu_state);
+if (target_cpu->power_state == PSCI_ON) {
+qemu_log_mask(LOG_GUEST_ERROR,
+ "[ARM]%s: CPU %" PRId64 " is already on\n",
+ __func__, cpuid);
+return QEMU_ARM_POWERCTL_ALREADY_ON;
+}
+
+/*
+ * If another CPU has powered the target on we are in the state
+ * ON_PENDING and additional attempts to power on the CPU should
+ * fail (see 6.6 Implementation CPU_ON/CPU_OFF races in the PSCI
+ * spec)
+ */
+if (target_cpu->power_state == PSCI_ON_PENDING) {
+qemu_log_mask(LOG_GUEST_ERROR,
+ "[ARM]%s: CPU %" PRId64 " is already powering on\n",
+ __func__, cpuid);
+return QEMU_ARM_POWERCTL_ON_PENDING;
+}
+
+async_run_on_cpu(target_cpu_state, arm_set_cpu_on_and_reset_async_work,
+ RUN_ON_CPU_NULL);
+
+/* We are good to go */
+return QEMU_ARM_POWERCTL_RET_SUCCESS;
+}
+
static void arm_set_cpu_off_async_work(CPUState *target_cpu_state,
run_on_cpu_data data)
{
--
2.20.1
[Qemu-devel] [PULL 01/16] hw/misc/armsse-mhu.c: Model the SSE-200 Message Handling Unit
Implement a model of the Message Handling Unit (MHU) found in
the Arm SSE-200. This is a simple device which just contains
some registers which allow the two cores of the SSE-200
to raise interrupts on each other.
Signed-off-by: Peter Maydell
Reviewed-by: Richard Henderson
Message-id: 20190219125808.25174-2-peter.mayd...@linaro.org
---
hw/misc/Makefile.objs | 1 +
include/hw/misc/armsse-mhu.h| 44 +++
hw/misc/armsse-mhu.c| 198
MAINTAINERS | 2 +
default-configs/arm-softmmu.mak | 1 +
hw/misc/trace-events| 4 +
6 files changed, 250 insertions(+)
create mode 100644 include/hw/misc/armsse-mhu.h
create mode 100644 hw/misc/armsse-mhu.c
diff --git a/hw/misc/Makefile.objs b/hw/misc/Makefile.objs
index 74c91d250c8..c71e07ae35d 100644
--- a/hw/misc/Makefile.objs
+++ b/hw/misc/Makefile.objs
@@ -70,6 +70,7 @@ obj-$(CONFIG_IOTKIT_SECCTL) += iotkit-secctl.o
obj-$(CONFIG_IOTKIT_SYSCTL) += iotkit-sysctl.o
obj-$(CONFIG_IOTKIT_SYSINFO) += iotkit-sysinfo.o
obj-$(CONFIG_ARMSSE_CPUID) += armsse-cpuid.o
+obj-$(CONFIG_ARMSSE_MHU) += armsse-mhu.o
obj-$(CONFIG_PVPANIC) += pvpanic.o
obj-$(CONFIG_AUX) += auxbus.o
diff --git a/include/hw/misc/armsse-mhu.h b/include/hw/misc/armsse-mhu.h
new file mode 100644
index 000..e57eafc2521
--- /dev/null
+++ b/include/hw/misc/armsse-mhu.h
@@ -0,0 +1,44 @@
+/*
+ * ARM SSE-200 Message Handling Unit (MHU)
+ *
+ * Copyright (c) 2019 Linaro Limited
+ * Written by Peter Maydell
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 or
+ * (at your option) any later version.
+ */
+
+/*
+ * This is a model of the Message Handling Unit (MHU) which is part of the
+ * Arm SSE-200 and documented in
+ *
http://infocenter.arm.com/help/topic/com.arm.doc.101104_0100_00_en/corelink_sse200_subsystem_for_embedded_technical_reference_manual_101104_0100_00_en.pdf
+ *
+ * QEMU interface:
+ * + sysbus MMIO region 0: the system information register bank
+ * + sysbus IRQ 0: interrupt for CPU 0
+ * + sysbus IRQ 1: interrupt for CPU 1
+ */
+
+#ifndef HW_MISC_SSE_MHU_H
+#define HW_MISC_SSE_MHU_H
+
+#include "hw/sysbus.h"
+
+#define TYPE_ARMSSE_MHU "armsse-mhu"
+#define ARMSSE_MHU(obj) OBJECT_CHECK(ARMSSEMHU, (obj), TYPE_ARMSSE_MHU)
+
+typedef struct ARMSSEMHU {
+/*< private >*/
+SysBusDevice parent_obj;
+
+/*< public >*/
+MemoryRegion iomem;
+qemu_irq cpu0irq;
+qemu_irq cpu1irq;
+
+uint32_t cpu0intr;
+uint32_t cpu1intr;
+} ARMSSEMHU;
+
+#endif
diff --git a/hw/misc/armsse-mhu.c b/hw/misc/armsse-mhu.c
new file mode 100644
index 000..9ebca32e9aa
--- /dev/null
+++ b/hw/misc/armsse-mhu.c
@@ -0,0 +1,198 @@
+/*
+ * ARM SSE-200 Message Handling Unit (MHU)
+ *
+ * Copyright (c) 2019 Linaro Limited
+ * Written by Peter Maydell
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 or
+ * (at your option) any later version.
+ */
+
+/*
+ * This is a model of the Message Handling Unit (MHU) which is part of the
+ * Arm SSE-200 and documented in
+ *
http://infocenter.arm.com/help/topic/com.arm.doc.101104_0100_00_en/corelink_sse200_subsystem_for_embedded_technical_reference_manual_101104_0100_00_en.pdf
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/log.h"
+#include "trace.h"
+#include "qapi/error.h"
+#include "sysemu/sysemu.h"
+#include "hw/sysbus.h"
+#include "hw/registerfields.h"
+#include "hw/misc/armsse-mhu.h"
+
+REG32(CPU0INTR_STAT, 0x0)
+REG32(CPU0INTR_SET, 0x4)
+REG32(CPU0INTR_CLR, 0x8)
+REG32(CPU1INTR_STAT, 0x10)
+REG32(CPU1INTR_SET, 0x14)
+REG32(CPU1INTR_CLR, 0x18)
+REG32(PID4, 0xfd0)
+REG32(PID5, 0xfd4)
+REG32(PID6, 0xfd8)
+REG32(PID7, 0xfdc)
+REG32(PID0, 0xfe0)
+REG32(PID1, 0xfe4)
+REG32(PID2, 0xfe8)
+REG32(PID3, 0xfec)
+REG32(CID0, 0xff0)
+REG32(CID1, 0xff4)
+REG32(CID2, 0xff8)
+REG32(CID3, 0xffc)
+
+/* Valid bits in the interrupt registers. If any are set the IRQ is raised */
+#define INTR_MASK 0xf
+
+/* PID/CID values */
+static const int armsse_mhu_id[] = {
+0x04, 0x00, 0x00, 0x00, /* PID4..PID7 */
+0x56, 0xb8, 0x0b, 0x00, /* PID0..PID3 */
+0x0d, 0xf0, 0x05, 0xb1, /* CID0..CID3 */
+};
+
+static void armsse_mhu_update(ARMSSEMHU *s)
+{
+qemu_set_irq(s->cpu0irq, s->cpu0intr != 0);
+qemu_set_irq(s->cpu1irq, s->cpu1intr != 0);
+}
+
+static uint64_t armsse_mhu_read(void *opaque, hwaddr offset, unsigned size)
+{
+ARMSSEMHU *s = ARMSSE_MHU(opaque);
+uint64_t r;
+
+switch (offset) {
+case A_CPU0INTR_STAT:
+r = s->cpu0intr;
+break;
+
+case A_CPU1INTR_STAT:
+r = s->cpu1intr;
+break;
+
+case A_PID4 ... A_CID3:
+r = armsse_mhu_id[(offset - A_PID4) / 4];
+break;
+
+case A_CPU0INTR_SET:
+case A_CPU0INTR_CLR:
+case A_CPU1INTR_SET:
+case A_CPU1INTR_CLR:
+
[Qemu-devel] [PULL 09/16] target/arm: Use MVFR1 feature bits to gate A32/T32 FP16 instructions
Instead of gating the A32/T32 FP16 conversion instructions on
the ARM_FEATURE_VFP_FP16 flag, switch to our new approach of
looking at ID register bits. In this case MVFR1 fields FPHP
and SIMDHP indicate the presence of these insns.
This change doesn't alter behaviour for any of our CPUs.
Signed-off-by: Peter Maydell
Reviewed-by: Richard Henderson
Message-id: 20190222170936.13268-2-peter.mayd...@linaro.org
---
target/arm/cpu.h | 37 -
target/arm/cpu.c | 2 --
target/arm/kvm32.c | 3 ---
target/arm/translate.c | 26 ++
4 files changed, 54 insertions(+), 14 deletions(-)
diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 1eea1a408b8..36ea3b58567 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -1730,6 +1730,27 @@ FIELD(ID_DFR0, MPROFDBG, 20, 4)
FIELD(ID_DFR0, PERFMON, 24, 4)
FIELD(ID_DFR0, TRACEFILT, 28, 4)
+FIELD(MVFR0, SIMDREG, 0, 4)
+FIELD(MVFR0, FPSP, 4, 4)
+FIELD(MVFR0, FPDP, 8, 4)
+FIELD(MVFR0, FPTRAP, 12, 4)
+FIELD(MVFR0, FPDIVIDE, 16, 4)
+FIELD(MVFR0, FPSQRT, 20, 4)
+FIELD(MVFR0, FPSHVEC, 24, 4)
+FIELD(MVFR0, FPROUND, 28, 4)
+
+FIELD(MVFR1, FPFTZ, 0, 4)
+FIELD(MVFR1, FPDNAN, 4, 4)
+FIELD(MVFR1, SIMDLS, 8, 4)
+FIELD(MVFR1, SIMDINT, 12, 4)
+FIELD(MVFR1, SIMDSP, 16, 4)
+FIELD(MVFR1, SIMDHP, 20, 4)
+FIELD(MVFR1, FPHP, 24, 4)
+FIELD(MVFR1, SIMDFMAC, 28, 4)
+
+FIELD(MVFR2, SIMDMISC, 0, 4)
+FIELD(MVFR2, FPMISC, 4, 4)
+
QEMU_BUILD_BUG_ON(ARRAY_SIZE(((ARMCPU *)0)->ccsidr) <=
R_V7M_CSSELR_INDEX_MASK);
/* If adding a feature bit which corresponds to a Linux ELF
@@ -1747,7 +1768,6 @@ enum arm_features {
ARM_FEATURE_THUMB2,
ARM_FEATURE_PMSA, /* no MMU; may have Memory Protection Unit */
ARM_FEATURE_VFP3,
-ARM_FEATURE_VFP_FP16,
ARM_FEATURE_NEON,
ARM_FEATURE_M, /* Microcontroller profile. */
ARM_FEATURE_OMAPCP, /* OMAP specific CP15 ops handling. */
@@ -3293,6 +3313,21 @@ static inline bool isar_feature_aa32_fp16_arith(const
ARMISARegisters *id)
return FIELD_EX64(id->id_aa64pfr0, ID_AA64PFR0, FP) == 1;
}
+/*
+ * We always set the FP and SIMD FP16 fields to indicate identical
+ * levels of support (assuming SIMD is implemented at all), so
+ * we only need one set of accessors.
+ */
+static inline bool isar_feature_aa32_fp16_spconv(const ARMISARegisters *id)
+{
+return FIELD_EX64(id->mvfr1, MVFR1, FPHP) > 0;
+}
+
+static inline bool isar_feature_aa32_fp16_dpconv(const ARMISARegisters *id)
+{
+return FIELD_EX64(id->mvfr1, MVFR1, FPHP) > 1;
+}
+
/*
* 64-bit feature tests via id registers.
*/
diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index 4d7f6a3bc0c..a3baf4eeed1 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -1014,7 +1014,6 @@ static void arm_cpu_realizefn(DeviceState *dev, Error
**errp)
}
if (arm_feature(env, ARM_FEATURE_VFP4)) {
set_feature(env, ARM_FEATURE_VFP3);
-set_feature(env, ARM_FEATURE_VFP_FP16);
}
if (arm_feature(env, ARM_FEATURE_VFP3)) {
set_feature(env, ARM_FEATURE_VFP);
@@ -1675,7 +1674,6 @@ static void cortex_a9_initfn(Object *obj)
cpu->dtb_compatible = "arm,cortex-a9";
set_feature(>env, ARM_FEATURE_V7);
set_feature(>env, ARM_FEATURE_VFP3);
-set_feature(>env, ARM_FEATURE_VFP_FP16);
set_feature(>env, ARM_FEATURE_NEON);
set_feature(>env, ARM_FEATURE_THUMB2EE);
set_feature(>env, ARM_FEATURE_EL3);
diff --git a/target/arm/kvm32.c b/target/arm/kvm32.c
index a75e04cc8f3..327375f6252 100644
--- a/target/arm/kvm32.c
+++ b/target/arm/kvm32.c
@@ -125,9 +125,6 @@ bool kvm_arm_get_host_cpu_features(ARMHostCPUFeatures *ahcf)
if (extract32(id_pfr0, 12, 4) == 1) {
set_feature(, ARM_FEATURE_THUMB2EE);
}
-if (extract32(ahcf->isar.mvfr1, 20, 4) == 1) {
-set_feature(, ARM_FEATURE_VFP_FP16);
-}
if (extract32(ahcf->isar.mvfr1, 12, 4) == 1) {
set_feature(, ARM_FEATURE_NEON);
}
diff --git a/target/arm/translate.c b/target/arm/translate.c
index c1175798ac9..b7702fb49f7 100644
--- a/target/arm/translate.c
+++ b/target/arm/translate.c
@@ -3663,17 +3663,27 @@ static int disas_vfp_insn(DisasContext *s, uint32_t
insn)
* UNPREDICTABLE if bit 8 is set prior to ARMv8
* (we choose to UNDEF)
*/
-if ((dp && !arm_dc_feature(s, ARM_FEATURE_V8)) ||
-!arm_dc_feature(s, ARM_FEATURE_VFP_FP16)) {
-return 1;
+if (dp) {
+if (!dc_isar_feature(aa32_fp16_dpconv, s)) {
+return 1;
+}
+} else {
+if (!dc_isar_feature(aa32_fp16_spconv, s)) {
+return 1;
+}
}
rm_is_dp = false;
break;
case 0x06: /* vcvtb.f16.f32, vcvtb.f16.f64 */
case
[Qemu-devel] [PULL 00/16] target-arm queue
The following changes since commit adf2e451f357e993f173ba9b4176dbf3e65fee7e: Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging (2019-02-26 19:04:47 +) are available in the Git repository at: https://git.linaro.org/people/pmaydell/qemu-arm.git tags/pull-target-arm-20190228-1 for you to fetch changes up to 1c9af3a9e05c1607a36df4943f8f5393d7621a91: linux-user: Enable HWCAP_ASIMDFHM, HWCAP_JSCVT (2019-02-28 11:03:05 +) target-arm queue: * add MHU and dual-core support to Musca boards * refactor some VFP insns to be gated by ID registers * Revert "arm: Allow system registers for KVM guests to be changed by QEMU code" * Implement ARMv8.2-FHM extension * Advertise JSCVT via HWCAP for linux-user Peter Maydell (11): hw/misc/armsse-mhu.c: Model the SSE-200 Message Handling Unit hw/arm/armsse: Wire up the MHUs target/arm/cpu: Allow init-svtor property to be set after realize target/arm/arm-powerctl: Add new arm_set_cpu_on_and_reset() hw/misc/iotkit-sysctl: Correct typo in INITSVTOR0 register name hw/arm/iotkit-sysctl: Add SSE-200 registers hw/arm/iotkit-sysctl: Implement CPUWAIT and INITSVTOR* hw/arm/armsse: Unify init-svtor and cpuwait handling target/arm: Use MVFR1 feature bits to gate A32/T32 FP16 instructions target/arm: Gate "miscellaneous FP" insns by ID register field Revert "arm: Allow system registers for KVM guests to be changed by QEMU code" Richard Henderson (5): target/arm: Add helpers for FMLAL target/arm: Implement FMLAL and FMLSL for aarch64 target/arm: Implement VFMAL and VFMSL for aarch32 target/arm: Enable ARMv8.2-FHM for -cpu max linux-user: Enable HWCAP_ASIMDFHM, HWCAP_JSCVT hw/misc/Makefile.objs | 1 + include/hw/arm/armsse.h | 3 +- include/hw/misc/armsse-mhu.h| 44 ++ include/hw/misc/iotkit-sysctl.h | 25 +++- target/arm/arm-powerctl.h | 16 +++ target/arm/cpu.h| 76 +-- target/arm/helper.h | 9 ++ hw/arm/armsse.c | 91 + hw/misc/armsse-mhu.c| 198 +++ hw/misc/iotkit-sysctl.c | 294 ++-- linux-user/elfload.c| 2 + target/arm/arm-powerctl.c | 56 target/arm/cpu.c| 32 - target/arm/cpu64.c | 2 + target/arm/helper.c | 27 +--- target/arm/kvm32.c | 23 +++- target/arm/kvm64.c | 2 - target/arm/machine.c| 2 +- target/arm/translate-a64.c | 49 ++- target/arm/translate.c | 180 target/arm/vec_helper.c | 148 MAINTAINERS | 2 + default-configs/arm-softmmu.mak | 1 + hw/misc/trace-events| 4 + 24 files changed, 1139 insertions(+), 148 deletions(-) create mode 100644 include/hw/misc/armsse-mhu.h create mode 100644 hw/misc/armsse-mhu.c
[Qemu-devel] [PATCH v2 0/3] qdev: Hotplug handler chaining
Can somebody please pick this up in the near future? (@Eduardo, @MST, @Paolo, @David - I have no idea who the right person is :) ) The longer we wait, the more likely it is that some stuff gets upstreamed that conflicts with patch 1 and will break unnoticed. (e.g. spapr PHB hotplug was just upstreamed and required a fixup, luckily I was CC'ed on that one). --- This series implements support for hotplug handler chaining (proposed by Igor), something that is necessary to turn selected virtio devices into memory devices. Planned devices inlude virtio-mem and virtio-pmem. The machine hotplug handler can intercept hotplug handler calls to properly prepare/teardown the memory device part of a device. Control is then passed on to the actual bus hotplug handler. So the default hotplug handler is effectively overwritten to make interception possible. This series was tested against the - now upstream - device unplug tests part of "tests/device-plug-test". v1 -> v2: - Fixed spapr PHB unplug which was just upstreamed RFCv2 -> v1: - "qdev: Let the hotplug_handler_unplug() caller delete the device" -- Fixed two spapr delete_device() calls I missed. Covered by tests now -- Handle + add a comment for host pci bridge unplug, for which we have code but no user yet. - virtio-pmem prototype will be handled from this point by Pankaj again, so no longer included David Hildenbrand (2): qdev: Let the hotplug_handler_unplug() caller delete the device qdev: Provide qdev_get_bus_hotplug_handler() Igor Mammedov (1): qdev: Let machine hotplug handler to override bus hotplug handler hw/acpi/cpu.c| 1 + hw/acpi/memory_hotplug.c | 1 + hw/acpi/pcihp.c | 3 ++- hw/core/qdev.c | 19 --- hw/i386/pc.c | 5 ++--- hw/pci/pci.c | 3 ++- hw/pci/pcie.c| 3 ++- hw/pci/shpc.c| 3 ++- hw/ppc/spapr.c | 9 ++--- hw/ppc/spapr_pci.c | 3 ++- hw/s390x/css-bridge.c| 2 +- hw/s390x/s390-pci-bus.c | 13 - include/hw/qdev-core.h | 12 qdev-monitor.c | 9 +++-- 14 files changed, 60 insertions(+), 26 deletions(-) -- 2.17.2
[Qemu-devel] [PULL 02/13] MAINTAINERS: Add missing entries for the PC machines
From: Philippe Mathieu-Daudé Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Michael S. Tsirkin Signed-off-by: Thomas Huth --- MAINTAINERS | 4 1 file changed, 4 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 22e0293..3a034f9 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1185,6 +1185,10 @@ F: hw/acpi/ich9.c F: include/hw/acpi/ich9.h F: include/hw/acpi/piix4.h F: hw/misc/sga.c +F: hw/isa/apm.c +F: include/hw/isa/apm.h +F: tests/test-x86-cpuid.c +F: tests/test-x86-cpuid-compat.c PC Chipset M: Michael S. Tsirkin -- 1.8.3.1
[Qemu-devel] [PULL 04/13] MAINTAINERS: Add missing test entries to the Cryptography section
From: Philippe Mathieu-Daudé Acked-by: Daniel P. Berrangé Signed-off-by: Philippe Mathieu-Daudé Signed-off-by: Thomas Huth --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 4e38864..d81f9c4 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2069,6 +2069,8 @@ F: crypto/ F: include/crypto/ F: tests/test-crypto-* F: tests/benchmark-crypto-* +F: tests/crypto-tls-* +F: tests/pkix_asn1_tab.c F: qemu.sasl Coroutines -- 1.8.3.1
[Qemu-devel] [PATCH v2 3/3] qdev: Provide qdev_get_bus_hotplug_handler()
Let's use a wrapper instead of looking it up manually. This function can
than be reused when we explicitly want to have the bus hotplug handler
(e.g. when the bus hotplug handler was overwritten by the machine
hotplug handler).
Reviewed-by: Igor Mammedov
Signed-off-by: David Hildenbrand
---
hw/core/qdev.c | 10 +-
include/hw/qdev-core.h | 1 +
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index 7ad45c0bd6..e2207d77a4 100644
--- a/hw/core/qdev.c
+++ b/hw/core/qdev.c
@@ -233,12 +233,20 @@ HotplugHandler
*qdev_get_machine_hotplug_handler(DeviceState *dev)
return NULL;
}
+HotplugHandler *qdev_get_bus_hotplug_handler(DeviceState *dev)
+{
+if (dev->parent_bus) {
+return dev->parent_bus->hotplug_handler;
+}
+return NULL;
+}
+
HotplugHandler *qdev_get_hotplug_handler(DeviceState *dev)
{
HotplugHandler *hotplug_ctrl = qdev_get_machine_hotplug_handler(dev);
if (hotplug_ctrl == NULL && dev->parent_bus) {
-hotplug_ctrl = dev->parent_bus->hotplug_handler;
+hotplug_ctrl = qdev_get_bus_hotplug_handler(dev);
}
return hotplug_ctrl;
}
diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
index 52562555cd..8e0938248b 100644
--- a/include/hw/qdev-core.h
+++ b/include/hw/qdev-core.h
@@ -280,6 +280,7 @@ DeviceState *qdev_try_create(BusState *bus, const char
*name);
void qdev_init_nofail(DeviceState *dev);
void qdev_set_legacy_instance_id(DeviceState *dev, int alias_id,
int required_for_version);
+HotplugHandler *qdev_get_bus_hotplug_handler(DeviceState *dev);
HotplugHandler *qdev_get_machine_hotplug_handler(DeviceState *dev);
/**
* qdev_get_hotplug_handler: Get handler responsible for device wiring
--
2.17.2
Re: [Qemu-devel] [PATCH v7 00/17] ARM virt: Initial RAM expansion and PCDIMM/NVDIMM support
On Thu, 28 Feb 2019 08:48:18 +0100 Auger Eric wrote: > Hi Igor, Shameer, > > On 2/27/19 6:51 PM, Igor Mammedov wrote: > > On Wed, 27 Feb 2019 10:41:45 + > > Shameerali Kolothum Thodi wrote: > > > >> Hi Eric, > >> > >>> -Original Message- > >>> From: Auger Eric [mailto:eric.au...@redhat.com] > >>> Sent: 27 February 2019 10:27 > >>> To: Igor Mammedov > >>> Cc: peter.mayd...@linaro.org; drjo...@redhat.com; da...@redhat.com; > >>> dgilb...@redhat.com; Shameerali Kolothum Thodi > >>> ; qemu-devel@nongnu.org; > >>> qemu-...@nongnu.org; eric.auger@gmail.com; > >>> da...@gibson.dropbear.id.au > >>> Subject: Re: [Qemu-devel] [PATCH v7 00/17] ARM virt: Initial RAM expansion > >>> and PCDIMM/NVDIMM support > >>> > >>> Hi Igor, Shameer, > >>> > >>> On 2/27/19 11:10 AM, Igor Mammedov wrote: > On Tue, 26 Feb 2019 18:53:24 +0100 > Auger Eric wrote: > > > Hi Igor, > > > > On 2/26/19 5:56 PM, Igor Mammedov wrote: > >> On Tue, 26 Feb 2019 14:11:58 +0100 > >> Auger Eric wrote: > >> > >>> Hi Igor, > >>> > >>> On 2/26/19 9:40 AM, Auger Eric wrote: > Hi Igor, > > On 2/25/19 10:42 AM, Igor Mammedov wrote: > > On Fri, 22 Feb 2019 18:35:26 +0100 > > Auger Eric wrote: > > > >> Hi Igor, > >> > >> On 2/22/19 5:27 PM, Igor Mammedov wrote: > >>> On Wed, 20 Feb 2019 23:39:46 +0100 > >>> Eric Auger wrote: > >>> > This series aims to bump the 255GB RAM limit in machvirt and to > support device memory in general, and especially > >>> PCDIMM/NVDIMM. > > In machvirt versions < 4.0, the initial RAM starts at 1GB and can > grow up to 255GB. From 256GB onwards we find IO regions such as > > >>> the > additional GICv3 RDIST region, high PCIe ECAM region and high > >>> PCIe > MMIO region. The address map was 1TB large. This corresponded > >>> to > the max IPA capacity KVM was able to manage. > > Since 4.20, the host kernel is able to support a larger and > dynamic > IPA range. So the guest physical address can go beyond the 1TB. > > >>> The > max GPA size depends on the host kernel configuration and > physical > >>> CPUs. > > In this series we use this feature and allow the RAM to grow > >>> without > any other limit than the one put by the host kernel. > > The RAM still starts at 1GB. First comes the initial ram (-m) of > size > ram_size and then comes the device memory (,maxmem) of size > maxram_size - ram_size. The device memory is potentially > >>> hotpluggable > depending on the instantiated memory objects. > > IO regions previously located between 256GB and 1TB are moved > >>> after > the RAM. Their offset is dynamically computed, depends on > >>> ram_size > and maxram_size. Size alignment is enforced. > > In case maxmem value is inferior to 255GB, the legacy memory > >>> map > still is used. The change of memory map becomes effective from > 4.0 > onwards. > > As we keep the initial RAM at 1GB base address, we do not need > to > >>> do > invasive changes in the EDK2 FW. It seems nobody is eager to do > that job at the moment. > > Device memory being put just after the initial RAM, it is > possible > to get access to this feature while keeping a 1TB address map. > > This series reuses/rebases patches initially submitted by Shameer > in [1] and Kwangwoo in [2] for the PC-DIMM and NV-DIMM parts. > > Functionally, the series is split into 3 parts: > 1) bump of the initial RAM limit [1 - 9] and change in > the memory map > >>> > 2) Support of PC-DIMM [10 - 13] > >>> Is this part complete ACPI wise (for coldplug)? I haven't noticed > >>> DSDT AML here no E820 changes, so ACPI wise pc-dimm shouldn't be > >>> visible to the guest. It might be that DT is masking problem > >>> but well, that won't work on ACPI only guests. > >> > >> guest /proc/meminfo or "lshw -class memory" reflects the amount of > >> > >>> mem > >> added with the DIMM slots. > > Question is how does it get there? Does it come from DT or from > >>> firmware > > via UEFI interfaces? >
[Qemu-devel] [RFC v2 1/3] intel_iommu: scalable mode emulation
From: "Liu, Yi L"
Intel(R) VT-d 3.0 spec introduces scalable mode address translation to
replace extended context mode. This patch extends current emulator to
support Scalable Mode which includes root table, context table and new
pasid table format change. Now intel_iommu emulates both legacy mode
and scalable mode (with legacy-equivalent capability set).
The key points are below:
1. Extend root table operations to support both legacy mode and scalable
mode.
2. Extend context table operations to support both legacy mode and
scalable mode.
3. Add pasid tabled operations to support scalable mode.
Signed-off-by: Liu, Yi L
[Yi Sun is co-developer to contribute much to refine the whole commit.]
Signed-off-by: Yi Sun
---
v2:
- remove unnecessary macros.
- rename macros to capital.
- make 're->hi' assignment be unconditional to simplify codes.
- remove 'vtd_get_context_base' to embed its content into caller.
- remove 'vtd_context_entry_format' to to embed its content into caller.
- remove unnecessary memset for 'pe->val'.
- use 'INTEL_IOMMU_DEVICE' to get 'IntelIOMMUState' to remove input
'IntelIOMMUState *s' parameter.
- call 'vtd_get_domain_id' to get domain_id.
- check error code returned by 'vtd_ce_get_rid2pasid_entry' in
'vtd_dev_pt_enabled'.
- check '!is_fpd_set' of context entry before handing pasid entry.
- move 's->root_scalable' assignment to patch 3.
- add comment for 'VTD_FR_PASID_TABLE_INV'.
- remove not used 'VTD_ROOT_ENTRY_SIZE'.
- change 'VTD_CTX_ENTRY_LECY_SIZE' to 'VTD_CTX_ENTRY_LEGACY_SIZE'.
- change 'VTD_CTX_ENTRY_SM_SIZE' to 'VTD_CTX_ENTRY_SCALABLE_SIZE'.
- use union in 'struct VTDContextEntry' to reduce code changes.
---
hw/i386/intel_iommu.c | 476 ++---
hw/i386/intel_iommu_internal.h | 41 +++-
hw/i386/trace-events | 2 +-
include/hw/i386/intel_iommu.h | 24 ++-
4 files changed, 466 insertions(+), 77 deletions(-)
diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
index ee22e75..109fdbc 100644
--- a/hw/i386/intel_iommu.c
+++ b/hw/i386/intel_iommu.c
@@ -37,6 +37,16 @@
#include "kvm_i386.h"
#include "trace.h"
+/* context entry operations */
+#define VTD_CE_GET_RID2PASID(ce) \
+((ce)->val[1] & VTD_SM_CONTEXT_ENTRY_RID2PASID_MASK)
+#define VTD_CE_GET_PASID_DIR_TABLE(ce) \
+((ce)->val[0] & VTD_PASID_DIR_BASE_ADDR_MASK)
+
+/* pe operations */
+#define VTD_PE_GET_TYPE(pe) ((pe)->val[0] & VTD_SM_PASID_ENTRY_PGTT)
+#define VTD_PE_GET_LEVEL(pe) (2 + (((pe)->val[0] >> 2) &
VTD_SM_PASID_ENTRY_AW))
+
static void vtd_address_space_refresh_all(IntelIOMMUState *s);
static void vtd_address_space_unmap(VTDAddressSpace *as, IOMMUNotifier *n);
@@ -512,9 +522,15 @@ static void vtd_generate_completion_event(IntelIOMMUState
*s)
}
}
-static inline bool vtd_root_entry_present(VTDRootEntry *root)
+static inline bool vtd_root_entry_present(IntelIOMMUState *s,
+ VTDRootEntry *re,
+ uint8_t devfn)
{
-return root->val & VTD_ROOT_ENTRY_P;
+if (s->root_scalable && devfn > UINT8_MAX / 2) {
+return re->hi & VTD_ROOT_ENTRY_P;
+}
+
+return re->lo & VTD_ROOT_ENTRY_P;
}
static int vtd_get_root_entry(IntelIOMMUState *s, uint8_t index,
@@ -524,30 +540,48 @@ static int vtd_get_root_entry(IntelIOMMUState *s, uint8_t
index,
addr = s->root + index * sizeof(*re);
if (dma_memory_read(_space_memory, addr, re, sizeof(*re))) {
-re->val = 0;
+re->lo = 0;
return -VTD_FR_ROOT_TABLE_INV;
}
-re->val = le64_to_cpu(re->val);
+re->lo = le64_to_cpu(re->lo);
+re->hi = le64_to_cpu(re->hi);
return 0;
}
-static inline bool vtd_ce_present(VTDContextEntry *context)
+static inline bool vtd_ce_present(VTDContextEntry *ce)
{
-return context->lo & VTD_CONTEXT_ENTRY_P;
+return ce->lo & VTD_CONTEXT_ENTRY_P;
}
-static int vtd_get_context_entry_from_root(VTDRootEntry *root, uint8_t index,
+static int vtd_get_context_entry_from_root(IntelIOMMUState *s,
+ VTDRootEntry *re,
+ uint8_t index,
VTDContextEntry *ce)
{
-dma_addr_t addr;
+dma_addr_t addr, ce_size;
/* we have checked that root entry is present */
-addr = (root->val & VTD_ROOT_ENTRY_CTP) + index * sizeof(*ce);
-if (dma_memory_read(_space_memory, addr, ce, sizeof(*ce))) {
+ce_size = s->root_scalable ? VTD_CTX_ENTRY_SCALABLE_SIZE :
+ VTD_CTX_ENTRY_LEGACY_SIZE;
+
+if (s->root_scalable && index > UINT8_MAX / 2) {
+index = index & (~VTD_DEVFN_CHECK_MASK);
+addr = re->hi & VTD_ROOT_ENTRY_CTP;
+} else {
+addr = re->lo & VTD_ROOT_ENTRY_CTP;
+}
+
+addr = addr + index * ce_size;
+if (dma_memory_read(_space_memory, addr, ce, ce_size)) {
[Qemu-devel] [RFC v2 3/3] intel_iommu: add scalable-mode option to make scalable mode work
This patch adds an option to provide flexibility for user to expose
Scalable Mode to guest. User could expose Scalable Mode to guest by
the config as below:
"-device intel-iommu,caching-mode=on,scalable-mode=on"
The Linux iommu driver has supported scalable mode. Please refer below
patch set:
https://www.spinics.net/lists/kernel/msg2985279.html
Signed-off-by: Liu, Yi L
Signed-off-by: Yi Sun
---
v2:
- rename "scalable-mode" to "x-scalable-mode".
- remove caching_mode check when scalable_mode is set.
- check dma_drain check when scalable_mode is set. This is requested
by spec.
- remove redundant macros.
---
hw/i386/intel_iommu.c | 24
hw/i386/intel_iommu_internal.h | 4
include/hw/i386/intel_iommu.h | 3 ++-
3 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
index d1eb0c5..ec7722d 100644
--- a/hw/i386/intel_iommu.c
+++ b/hw/i386/intel_iommu.c
@@ -1733,6 +1733,9 @@ static void vtd_root_table_setup(IntelIOMMUState *s)
{
s->root = vtd_get_quad_raw(s, DMAR_RTADDR_REG);
s->root_extended = s->root & VTD_RTADDR_RTT;
+if (s->scalable_mode) {
+s->root_scalable = s->root & VTD_RTADDR_SMT;
+}
s->root &= VTD_RTADDR_ADDR_MASK(s->aw_bits);
trace_vtd_reg_dmar_root(s->root, s->root_extended);
@@ -2442,6 +2445,17 @@ static bool vtd_process_inv_desc(IntelIOMMUState *s)
}
break;
+/*
+ * TODO: the entity of below two cases will be implemented in future
series.
+ * To make guest (which integrates scalable mode support patch set in
+ * iommu driver) work, just return true is enough so far.
+ */
+case VTD_INV_DESC_PC:
+break;
+
+case VTD_INV_DESC_PIOTLB:
+break;
+
case VTD_INV_DESC_WAIT:
trace_vtd_inv_desc("wait", inv_desc.hi, inv_desc.lo);
if (!vtd_process_wait_desc(s, _desc)) {
@@ -3006,6 +3020,7 @@ static Property vtd_properties[] = {
DEFINE_PROP_UINT8("aw-bits", IntelIOMMUState, aw_bits,
VTD_HOST_ADDRESS_WIDTH),
DEFINE_PROP_BOOL("caching-mode", IntelIOMMUState, caching_mode, FALSE),
+DEFINE_PROP_BOOL("x-scalable-mode", IntelIOMMUState, scalable_mode, FALSE),
DEFINE_PROP_BOOL("dma-drain", IntelIOMMUState, dma_drain, true),
DEFINE_PROP_END_OF_LIST(),
};
@@ -3540,6 +3555,15 @@ static void vtd_init(IntelIOMMUState *s)
s->cap |= VTD_CAP_CM;
}
+/* TODO: read cap/ecap from host to decide which cap to be exposed. */
+if (s->scalable_mode) {
+if (!s->dma_drain) {
+error_report("Need to set dma_drain for scalable mode");
+exit(1);
+}
+s->ecap |= VTD_ECAP_SMTS | VTD_ECAP_SRS | VTD_ECAP_SLTS;
+}
+
vtd_reset_caches(s);
/* Define registers with default values and bit semantics */
diff --git a/hw/i386/intel_iommu_internal.h b/hw/i386/intel_iommu_internal.h
index 016fa4c..1160618 100644
--- a/hw/i386/intel_iommu_internal.h
+++ b/hw/i386/intel_iommu_internal.h
@@ -190,7 +190,9 @@
#define VTD_ECAP_EIM(1ULL << 4)
#define VTD_ECAP_PT (1ULL << 6)
#define VTD_ECAP_MHMV (15ULL << 20)
+#define VTD_ECAP_SRS(1ULL << 31)
#define VTD_ECAP_SMTS (1ULL << 43)
+#define VTD_ECAP_SLTS (1ULL << 46)
/* CAP_REG */
/* (offset >> 4) << 24 */
@@ -345,6 +347,8 @@ typedef union VTDInvDesc VTDInvDesc;
#define VTD_INV_DESC_IEC0x4 /* Interrupt Entry Cache
Invalidate Descriptor */
#define VTD_INV_DESC_WAIT 0x5 /* Invalidation Wait Descriptor */
+#define VTD_INV_DESC_PIOTLB 0x6 /* PASID-IOTLB Invalidate Desc */
+#define VTD_INV_DESC_PC 0x7 /* PASID-cache Invalidate Desc */
#define VTD_INV_DESC_NONE 0 /* Not an Invalidate Descriptor */
/* Masks for Invalidation Wait Descriptor*/
diff --git a/include/hw/i386/intel_iommu.h b/include/hw/i386/intel_iommu.h
index 2877c94..c11e3d5 100644
--- a/include/hw/i386/intel_iommu.h
+++ b/include/hw/i386/intel_iommu.h
@@ -227,7 +227,8 @@ struct IntelIOMMUState {
uint8_t womask[DMAR_REG_SIZE]; /* WO (write only - read returns 0) */
uint32_t version;
-bool caching_mode; /* RO - is cap CM enabled? */
+bool caching_mode; /* RO - is cap CM enabled? */
+bool scalable_mode; /* RO - is Scalable Mode supported? */
dma_addr_t root;/* Current root table pointer */
bool root_extended; /* Type of root table (extended or not) */
--
1.9.1
[Qemu-devel] [PULL 4/5] audio/sdlaudio: Remove the semaphore code
From: Thomas Huth
The semaphore code was only working with SDL1.2 - with SDL2, it causes
a deadlock. Since we've removed support for SDL1.2 recently, we can
now completely remove the semaphore code from sdlaudio.c.
Signed-off-by: Thomas Huth
Reviewed-by: Philippe Mathieu-Daudé
Message-id: 1549336101-17623-2-git-send-email-th...@redhat.com
Signed-off-by: Gerd Hoffmann
---
audio/sdlaudio.c | 145 ++-
1 file changed, 5 insertions(+), 140 deletions(-)
diff --git a/audio/sdlaudio.c b/audio/sdlaudio.c
index 9db5ac92bcc0..53bfdbf72439 100644
--- a/audio/sdlaudio.c
+++ b/audio/sdlaudio.c
@@ -38,14 +38,9 @@
#define AUDIO_CAP "sdl"
#include "audio_int.h"
-#define USE_SEMAPHORE (SDL_MAJOR_VERSION < 2)
-
typedef struct SDLVoiceOut {
HWVoiceOut hw;
int live;
-#if USE_SEMAPHORE
-int rpos;
-#endif
int decr;
} SDLVoiceOut;
@@ -57,10 +52,6 @@ static struct {
static struct SDLAudioState {
int exit;
-#if USE_SEMAPHORE
-SDL_mutex *mutex;
-SDL_sem *sem;
-#endif
int initialized;
bool driver_created;
} glob_sdl;
@@ -77,66 +68,6 @@ static void GCC_FMT_ATTR (1, 2) sdl_logerr (const char *fmt,
...)
AUD_log (AUDIO_CAP, "Reason: %s\n", SDL_GetError ());
}
-static int sdl_lock (SDLAudioState *s, const char *forfn)
-{
-#if USE_SEMAPHORE
-if (SDL_LockMutex (s->mutex)) {
-sdl_logerr ("SDL_LockMutex for %s failed\n", forfn);
-return -1;
-}
-#else
-SDL_LockAudio();
-#endif
-
-return 0;
-}
-
-static int sdl_unlock (SDLAudioState *s, const char *forfn)
-{
-#if USE_SEMAPHORE
-if (SDL_UnlockMutex (s->mutex)) {
-sdl_logerr ("SDL_UnlockMutex for %s failed\n", forfn);
-return -1;
-}
-#else
-SDL_UnlockAudio();
-#endif
-
-return 0;
-}
-
-static int sdl_post (SDLAudioState *s, const char *forfn)
-{
-#if USE_SEMAPHORE
-if (SDL_SemPost (s->sem)) {
-sdl_logerr ("SDL_SemPost for %s failed\n", forfn);
-return -1;
-}
-#endif
-
-return 0;
-}
-
-#if USE_SEMAPHORE
-static int sdl_wait (SDLAudioState *s, const char *forfn)
-{
-if (SDL_SemWait (s->sem)) {
-sdl_logerr ("SDL_SemWait for %s failed\n", forfn);
-return -1;
-}
-return 0;
-}
-#endif
-
-static int sdl_unlock_and_post (SDLAudioState *s, const char *forfn)
-{
-if (sdl_unlock (s, forfn)) {
-return -1;
-}
-
-return sdl_post (s, forfn);
-}
-
static int aud_to_sdlfmt (audfmt_e fmt)
{
switch (fmt) {
@@ -243,9 +174,9 @@ static int sdl_open (SDL_AudioSpec *req, SDL_AudioSpec *obt)
static void sdl_close (SDLAudioState *s)
{
if (s->initialized) {
-sdl_lock (s, "sdl_close");
+SDL_LockAudio();
s->exit = 1;
-sdl_unlock_and_post (s, "sdl_close");
+SDL_UnlockAudio();
SDL_PauseAudio (1);
SDL_CloseAudio ();
s->initialized = 0;
@@ -267,30 +198,10 @@ static void sdl_callback (void *opaque, Uint8 *buf, int
len)
int to_mix, decr;
/* dolog ("in callback samples=%d\n", samples); */
-#if USE_SEMAPHORE
-sdl_wait (s, "sdl_callback");
-if (s->exit) {
-return;
-}
-if (sdl_lock (s, "sdl_callback")) {
-return;
-}
-
-if (audio_bug(__func__, sdl->live < 0 || sdl->live > hw->samples)) {
-dolog ("sdl->live=%d hw->samples=%d\n",
- sdl->live, hw->samples);
-return;
-}
-
-if (!sdl->live) {
-goto again;
-}
-#else
if (s->exit || !sdl->live) {
break;
}
-#endif
/* dolog ("in callback live=%d\n", live); */
to_mix = audio_MIN (samples, sdl->live);
@@ -301,33 +212,20 @@ static void sdl_callback (void *opaque, Uint8 *buf, int
len)
/* dolog ("in callback to_mix %d, chunk %d\n", to_mix, chunk); */
hw->clip (buf, src, chunk);
-#if USE_SEMAPHORE
-sdl->rpos = (sdl->rpos + chunk) % hw->samples;
-#else
hw->rpos = (hw->rpos + chunk) % hw->samples;
-#endif
to_mix -= chunk;
buf += chunk << hw->info.shift;
}
samples -= decr;
sdl->live -= decr;
sdl->decr += decr;
-
-#if USE_SEMAPHORE
-again:
-if (sdl_unlock (s, "sdl_callback")) {
-return;
-}
-#endif
}
/* dolog ("done len=%d\n", len); */
-#if (SDL_MAJOR_VERSION >= 2)
/* SDL2 does not clear the remaining buffer for us, so do it on our own */
if (samples) {
memset(buf, 0, samples << hw->info.shift);
}
-#endif
}
static int sdl_write_out (SWVoiceOut *sw, void *buf, int len)
@@ -339,11 +237,8 @@ static int sdl_run_out (HWVoiceOut *hw, int live)
{
int decr;
SDLVoiceOut *sdl = (SDLVoiceOut *) hw;
-SDLAudioState *s = _sdl;
-if (sdl_lock (s, "sdl_run_out")) {
-return 0;
-}
+SDL_LockAudio();
if (sdl->decr > live) {
ldebug
[Qemu-devel] [PULL 0/5] Audio 20190228 patches
The following changes since commit 86c7e2f4a93322a76afea5ee6806a83420d1dfea: Merge remote-tracking branch 'remotes/berrange/tags/authz-core-pull-request' into staging (2019-02-26 17:59:41 +) are available in the git repository at: git://git.kraxel.org/qemu tags/audio-20190228-pull-request for you to fetch changes up to 9399ef168377d9e7f2e33b1c2eb61751aa1b72fa: audio/sdlaudio: Simplify the sdl_callback function (2019-02-28 10:30:08 +0100) audio: fixes and cleanups. Frediano Ziglio (2): audio: Use g_strdup_printf instead of manual building a string audio: Do not check for audio_calloc failure Gerd Hoffmann (1): audio: don't build alsa and sdl by default on linux Thomas Huth (2): audio/sdlaudio: Remove the semaphore code audio/sdlaudio: Simplify the sdl_callback function configure| 2 +- audio/audio.c| 73 - audio/sdlaudio.c | 190 +++ 3 files changed, 36 insertions(+), 229 deletions(-) -- 2.9.3
[Qemu-devel] [PULL 5/5] audio/sdlaudio: Simplify the sdl_callback function
From: Thomas Huth
At the end of the while-loop, either "samples" or "sdl->live" is zero, so
now that we've removed the semaphore code, the content of the while-loop
is always only executed once. Thus we can remove the while-loop now to
get rid of one indentation level here.
Signed-off-by: Thomas Huth
Message-id: 1549336101-17623-3-git-send-email-th...@redhat.com
Signed-off-by: Gerd Hoffmann
---
audio/sdlaudio.c | 45 +++--
1 file changed, 19 insertions(+), 26 deletions(-)
diff --git a/audio/sdlaudio.c b/audio/sdlaudio.c
index 53bfdbf72439..f7ee70b15347 100644
--- a/audio/sdlaudio.c
+++ b/audio/sdlaudio.c
@@ -189,37 +189,30 @@ static void sdl_callback (void *opaque, Uint8 *buf, int
len)
SDLAudioState *s = _sdl;
HWVoiceOut *hw = >hw;
int samples = len >> hw->info.shift;
+int to_mix, decr;
-if (s->exit) {
+if (s->exit || !sdl->live) {
return;
}
-while (samples) {
-int to_mix, decr;
-
-/* dolog ("in callback samples=%d\n", samples); */
-
-if (s->exit || !sdl->live) {
-break;
-}
-
-/* dolog ("in callback live=%d\n", live); */
-to_mix = audio_MIN (samples, sdl->live);
-decr = to_mix;
-while (to_mix) {
-int chunk = audio_MIN (to_mix, hw->samples - hw->rpos);
-struct st_sample *src = hw->mix_buf + hw->rpos;
-
-/* dolog ("in callback to_mix %d, chunk %d\n", to_mix, chunk); */
-hw->clip (buf, src, chunk);
-hw->rpos = (hw->rpos + chunk) % hw->samples;
-to_mix -= chunk;
-buf += chunk << hw->info.shift;
-}
-samples -= decr;
-sdl->live -= decr;
-sdl->decr += decr;
+/* dolog ("in callback samples=%d live=%d\n", samples, sdl->live); */
+
+to_mix = audio_MIN(samples, sdl->live);
+decr = to_mix;
+while (to_mix) {
+int chunk = audio_MIN(to_mix, hw->samples - hw->rpos);
+struct st_sample *src = hw->mix_buf + hw->rpos;
+
+/* dolog ("in callback to_mix %d, chunk %d\n", to_mix, chunk); */
+hw->clip(buf, src, chunk);
+hw->rpos = (hw->rpos + chunk) % hw->samples;
+to_mix -= chunk;
+buf += chunk << hw->info.shift;
}
+samples -= decr;
+sdl->live -= decr;
+sdl->decr += decr;
+
/* dolog ("done len=%d\n", len); */
/* SDL2 does not clear the remaining buffer for us, so do it on our own */
--
2.9.3
[Qemu-devel] [PULL 2/5] audio: Do not check for audio_calloc failure
From: Frediano Ziglio
audio_calloc uses g_malloc0 which never returns in case of
memory failure.
Signed-off-by: Frediano Ziglio
Message-id: 20190225154335.11397-2-fzig...@redhat.com
Signed-off-by: Gerd Hoffmann
---
audio/audio.c | 48 ++--
1 file changed, 6 insertions(+), 42 deletions(-)
diff --git a/audio/audio.c b/audio/audio.c
index 472721a7a9f0..909c817103c8 100644
--- a/audio/audio.c
+++ b/audio/audio.c
@@ -811,12 +811,7 @@ static int audio_attach_capture (HWVoiceOut *hw)
SWVoiceOut *sw;
HWVoiceOut *hw_cap = >hw;
-sc = audio_calloc(__func__, 1, sizeof(*sc));
-if (!sc) {
-dolog ("Could not allocate soft capture voice (%zu bytes)\n",
- sizeof (*sc));
-return -1;
-}
+sc = g_malloc0(sizeof(*sc));
sc->cap = cap;
sw = >sw;
@@ -1960,15 +1955,10 @@ CaptureVoiceOut *AUD_add_capture (
if (audio_validate_settings (as)) {
dolog ("Invalid settings were passed when trying to add capture\n");
audio_print_settings (as);
-goto err0;
+return NULL;
}
-cb = audio_calloc(__func__, 1, sizeof(*cb));
-if (!cb) {
-dolog ("Could not allocate capture callback information, size %zu\n",
- sizeof (*cb));
-goto err0;
-}
+cb = g_malloc0(sizeof(*cb));
cb->ops = *ops;
cb->opaque = cb_opaque;
@@ -1981,12 +1971,7 @@ CaptureVoiceOut *AUD_add_capture (
HWVoiceOut *hw;
CaptureVoiceOut *cap;
-cap = audio_calloc(__func__, 1, sizeof(*cap));
-if (!cap) {
-dolog ("Could not allocate capture voice, size %zu\n",
- sizeof (*cap));
-goto err1;
-}
+cap = g_malloc0(sizeof(*cap));
hw = >hw;
QLIST_INIT (>sw_head);
@@ -1994,23 +1979,11 @@ CaptureVoiceOut *AUD_add_capture (
/* XXX find a more elegant way */
hw->samples = 4096 * 4;
-hw->mix_buf = audio_calloc(__func__, hw->samples,
- sizeof(struct st_sample));
-if (!hw->mix_buf) {
-dolog ("Could not allocate capture mix buffer (%d samples)\n",
- hw->samples);
-goto err2;
-}
+hw->mix_buf = g_new0(struct st_sample, hw->samples);
audio_pcm_init_info (>info, as);
-cap->buf = audio_calloc(__func__, hw->samples, 1 << hw->info.shift);
-if (!cap->buf) {
-dolog ("Could not allocate capture buffer "
- "(%d samples, each %d bytes)\n",
- hw->samples, 1 << hw->info.shift);
-goto err3;
-}
+cap->buf = g_malloc0_n(hw->samples, 1 << hw->info.shift);
hw->clip = mixeng_clip
[hw->info.nchannels == 2]
@@ -2025,15 +1998,6 @@ CaptureVoiceOut *AUD_add_capture (
audio_attach_capture (hw);
}
return cap;
-
-err3:
-g_free (cap->hw.mix_buf);
-err2:
-g_free (cap);
-err1:
-g_free (cb);
-err0:
-return NULL;
}
}
--
2.9.3
[Qemu-devel] [PULL 14/16] target/arm: Implement VFMAL and VFMSL for aarch32
From: Richard Henderson
Signed-off-by: Richard Henderson
Message-id: 20190219222952.22183-4-richard.hender...@linaro.org
Reviewed-by: Peter Maydell
Signed-off-by: Peter Maydell
---
target/arm/cpu.h | 5 ++
target/arm/translate.c | 129 ++---
2 files changed, 101 insertions(+), 33 deletions(-)
diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 8f52914649d..36cd365efaf 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -3296,6 +3296,11 @@ static inline bool isar_feature_aa32_dp(const
ARMISARegisters *id)
return FIELD_EX32(id->id_isar6, ID_ISAR6, DP) != 0;
}
+static inline bool isar_feature_aa32_fhm(const ARMISARegisters *id)
+{
+return FIELD_EX32(id->id_isar6, ID_ISAR6, FHM) != 0;
+}
+
static inline bool isar_feature_aa32_fp16_arith(const ARMISARegisters *id)
{
/*
diff --git a/target/arm/translate.c b/target/arm/translate.c
index d845923a96b..8f7f5b95aab 100644
--- a/target/arm/translate.c
+++ b/target/arm/translate.c
@@ -8383,15 +8383,9 @@ static int disas_neon_insn_3same_ext(DisasContext *s,
uint32_t insn)
gen_helper_gvec_3_ptr *fn_gvec_ptr = NULL;
int rd, rn, rm, opr_sz;
int data = 0;
-bool q;
-
-q = extract32(insn, 6, 1);
-VFP_DREG_D(rd, insn);
-VFP_DREG_N(rn, insn);
-VFP_DREG_M(rm, insn);
-if ((rd | rn | rm) & q) {
-return 1;
-}
+int off_rn, off_rm;
+bool is_long = false, q = extract32(insn, 6, 1);
+bool ptr_is_env = false;
if ((insn & 0xfe200f10) == 0xfc200800) {
/* VCMLA -- 110R R.1S 1000 ...0 */
@@ -8418,10 +8412,39 @@ static int disas_neon_insn_3same_ext(DisasContext *s,
uint32_t insn)
return 1;
}
fn_gvec = u ? gen_helper_gvec_udot_b : gen_helper_gvec_sdot_b;
+} else if ((insn & 0xff300f10) == 0xfc200810) {
+/* VFM[AS]L -- 1100 S.10 1000 .Q.1 */
+int is_s = extract32(insn, 23, 1);
+if (!dc_isar_feature(aa32_fhm, s)) {
+return 1;
+}
+is_long = true;
+data = is_s; /* is_2 == 0 */
+fn_gvec_ptr = gen_helper_gvec_fmlal_a32;
+ptr_is_env = true;
} else {
return 1;
}
+VFP_DREG_D(rd, insn);
+if (rd & q) {
+return 1;
+}
+if (q || !is_long) {
+VFP_DREG_N(rn, insn);
+VFP_DREG_M(rm, insn);
+if ((rn | rm) & q & !is_long) {
+return 1;
+}
+off_rn = vfp_reg_offset(1, rn);
+off_rm = vfp_reg_offset(1, rm);
+} else {
+rn = VFP_SREG_N(insn);
+rm = VFP_SREG_M(insn);
+off_rn = vfp_reg_offset(0, rn);
+off_rm = vfp_reg_offset(0, rm);
+}
+
if (s->fp_excp_el) {
gen_exception_insn(s, 4, EXCP_UDEF,
syn_simd_access_trap(1, 0xe, false), s->fp_excp_el);
@@ -8433,16 +8456,19 @@ static int disas_neon_insn_3same_ext(DisasContext *s,
uint32_t insn)
opr_sz = (1 + q) * 8;
if (fn_gvec_ptr) {
-TCGv_ptr fpst = get_fpstatus_ptr(1);
-tcg_gen_gvec_3_ptr(vfp_reg_offset(1, rd),
- vfp_reg_offset(1, rn),
- vfp_reg_offset(1, rm), fpst,
+TCGv_ptr ptr;
+if (ptr_is_env) {
+ptr = cpu_env;
+} else {
+ptr = get_fpstatus_ptr(1);
+}
+tcg_gen_gvec_3_ptr(vfp_reg_offset(1, rd), off_rn, off_rm, ptr,
opr_sz, opr_sz, data, fn_gvec_ptr);
-tcg_temp_free_ptr(fpst);
+if (!ptr_is_env) {
+tcg_temp_free_ptr(ptr);
+}
} else {
-tcg_gen_gvec_3_ool(vfp_reg_offset(1, rd),
- vfp_reg_offset(1, rn),
- vfp_reg_offset(1, rm),
+tcg_gen_gvec_3_ool(vfp_reg_offset(1, rd), off_rn, off_rm,
opr_sz, opr_sz, data, fn_gvec);
}
return 0;
@@ -8461,14 +8487,9 @@ static int disas_neon_insn_2reg_scalar_ext(DisasContext
*s, uint32_t insn)
gen_helper_gvec_3 *fn_gvec = NULL;
gen_helper_gvec_3_ptr *fn_gvec_ptr = NULL;
int rd, rn, rm, opr_sz, data;
-bool q;
-
-q = extract32(insn, 6, 1);
-VFP_DREG_D(rd, insn);
-VFP_DREG_N(rn, insn);
-if ((rd | rn) & q) {
-return 1;
-}
+int off_rn, off_rm;
+bool is_long = false, q = extract32(insn, 6, 1);
+bool ptr_is_env = false;
if ((insn & 0xff000f10) == 0xfe000800) {
/* VCMLA (indexed) -- 1110 S.RR 1000 ...0 */
@@ -8497,6 +8518,7 @@ static int disas_neon_insn_2reg_scalar_ext(DisasContext
*s, uint32_t insn)
} else if ((insn & 0xffb00f00) == 0xfe200d00) {
/* V[US]DOT -- 1110 0.10 1101 .Q.U */
int u = extract32(insn, 4, 1);
+
if (!dc_isar_feature(aa32_dp, s)) {
return 1;
}
@@ -8504,10 +8526,48 @@ static int disas_neon_insn_2reg_scalar_ext(DisasContext
*s, uint32_t insn)
/* rm is just
[Qemu-devel] [PULL 11/16] Revert "arm: Allow system registers for KVM guests to be changed by QEMU code"
This reverts commit 823e1b3818f9b10b824ddcd756983b6e2fa68730,
which introduces a regression running EDK2 guest firmware
under KVM:
error: kvm run failed Function not implemented
PC=00013f5a6208 X00=404003c4 X01=003a
X02= X03=404003c4 X04=
X05=9646 X06=00013d2ef270 X07=00013e3d1710
X08=09010755ffaf8ba8 X09=ffaf8b9cfeeb5468 X10=feeb546409010756
X11=09010757ffaf8b90 X12=feeb50680903068b X13=090306a1ffaf8bc0
X14= X15= X16=00013f872da0
X17=a6ab X18= X19=00013f5a92d0
X20=00013f5a7a78 X21=003a X22=00013f5a7ab2
X23=00013f5a92e8 X24=00013f631090 X25=0010
X26=0100 X27=00013f89501b X28=00013e3d14e0
X29=00013e3d12a0 X30=00013f5a2518 SP=00013b7be0b0
PSTATE=404003c4 -Z-- EL1t
with
[ 3507.926571] kvm [35042]: load/store instruction decoding not implemented
in the host dmesg.
Revert the change for the moment until we can investigate the
cause of the regression.
Reported-by: Eric Auger
Signed-off-by: Peter Maydell
---
target/arm/cpu.h | 9 +
target/arm/helper.c | 27 ++-
target/arm/kvm32.c | 20 ++--
target/arm/kvm64.c | 2 --
target/arm/machine.c | 2 +-
5 files changed, 22 insertions(+), 38 deletions(-)
diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index ff9ba387b42..3e545a2b146 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -2558,25 +2558,18 @@ bool write_list_to_cpustate(ARMCPU *cpu);
/**
* write_cpustate_to_list:
* @cpu: ARMCPU
- * @kvm_sync: true if this is for syncing back to KVM
*
* For each register listed in the ARMCPU cpreg_indexes list, write
* its value from the ARMCPUState structure into the cpreg_values list.
* This is used to copy info from TCG's working data structures into
* KVM or for outbound migration.
*
- * @kvm_sync is true if we are doing this in order to sync the
- * register state back to KVM. In this case we will only update
- * values in the list if the previous list->cpustate sync actually
- * successfully wrote the CPU state. Otherwise we will keep the value
- * that is in the list.
- *
* Returns: true if all register values were read correctly,
* false if some register was unknown or could not be read.
* Note that we do not stop early on failure -- we will attempt
* reading all registers in the list.
*/
-bool write_cpustate_to_list(ARMCPU *cpu, bool kvm_sync);
+bool write_cpustate_to_list(ARMCPU *cpu);
#define ARM_CPUID_TI915T 0x54029152
#define ARM_CPUID_TI925T 0x54029252
diff --git a/target/arm/helper.c b/target/arm/helper.c
index fbaa801ceaa..1fa282a7fc1 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -265,7 +265,7 @@ static bool raw_accessors_invalid(const ARMCPRegInfo *ri)
return true;
}
-bool write_cpustate_to_list(ARMCPU *cpu, bool kvm_sync)
+bool write_cpustate_to_list(ARMCPU *cpu)
{
/* Write the coprocessor state from cpu->env to the (index,value) list. */
int i;
@@ -274,7 +274,6 @@ bool write_cpustate_to_list(ARMCPU *cpu, bool kvm_sync)
for (i = 0; i < cpu->cpreg_array_len; i++) {
uint32_t regidx = kvm_to_cpreg_id(cpu->cpreg_indexes[i]);
const ARMCPRegInfo *ri;
-uint64_t newval;
ri = get_arm_cp_reginfo(cpu->cp_regs, regidx);
if (!ri) {
@@ -284,29 +283,7 @@ bool write_cpustate_to_list(ARMCPU *cpu, bool kvm_sync)
if (ri->type & ARM_CP_NO_RAW) {
continue;
}
-
-newval = read_raw_cp_reg(>env, ri);
-if (kvm_sync) {
-/*
- * Only sync if the previous list->cpustate sync succeeded.
- * Rather than tracking the success/failure state for every
- * item in the list, we just recheck "does the raw write we must
- * have made in write_list_to_cpustate() read back OK" here.
- */
-uint64_t oldval = cpu->cpreg_values[i];
-
-if (oldval == newval) {
-continue;
-}
-
-write_raw_cp_reg(>env, ri, oldval);
-if (read_raw_cp_reg(>env, ri) != oldval) {
-continue;
-}
-
-write_raw_cp_reg(>env, ri, newval);
-}
-cpu->cpreg_values[i] = newval;
+cpu->cpreg_values[i] = read_raw_cp_reg(>env, ri);
}
return ok;
}
diff --git a/target/arm/kvm32.c b/target/arm/kvm32.c
index 327375f6252..50327989dcc 100644
--- a/target/arm/kvm32.c
+++ b/target/arm/kvm32.c
@@ -384,8 +384,24 @@ int kvm_arch_put_registers(CPUState *cs, int level)
return ret;
}
-write_cpustate_to_list(cpu, true);
-
+/* Note that we do not call write_cpustate_to_list()
+ * here, so we are only writing the tuple list back to
+ * KVM. This is safe because nothing can change the
+ * CPUARMState cp15 fields (in particular gdb accesses cannot)
[Qemu-devel] [PULL 13/16] target/arm: Implement FMLAL and FMLSL for aarch64
From: Richard Henderson
Signed-off-by: Richard Henderson
Message-id: 20190219222952.22183-3-richard.hender...@linaro.org
Reviewed-by: Peter Maydell
Signed-off-by: Peter Maydell
---
target/arm/cpu.h | 5
target/arm/translate-a64.c | 49 +-
2 files changed, 53 insertions(+), 1 deletion(-)
diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 3e545a2b146..8f52914649d 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -3404,6 +3404,11 @@ static inline bool isar_feature_aa64_dp(const
ARMISARegisters *id)
return FIELD_EX64(id->id_aa64isar0, ID_AA64ISAR0, DP) != 0;
}
+static inline bool isar_feature_aa64_fhm(const ARMISARegisters *id)
+{
+return FIELD_EX64(id->id_aa64isar0, ID_AA64ISAR0, FHM) != 0;
+}
+
static inline bool isar_feature_aa64_jscvt(const ARMISARegisters *id)
{
return FIELD_EX64(id->id_aa64isar1, ID_AA64ISAR1, JSCVT) != 0;
diff --git a/target/arm/translate-a64.c b/target/arm/translate-a64.c
index c56e878787c..d3c8eaf0893 100644
--- a/target/arm/translate-a64.c
+++ b/target/arm/translate-a64.c
@@ -10917,9 +10917,29 @@ static void disas_simd_3same_float(DisasContext *s,
uint32_t insn)
if (!fp_access_check(s)) {
return;
}
-
handle_3same_float(s, size, elements, fpopcode, rd, rn, rm);
return;
+
+case 0x1d: /* FMLAL */
+case 0x3d: /* FMLSL */
+case 0x59: /* FMLAL2 */
+case 0x79: /* FMLSL2 */
+if (size & 1 || !dc_isar_feature(aa64_fhm, s)) {
+unallocated_encoding(s);
+return;
+}
+if (fp_access_check(s)) {
+int is_s = extract32(insn, 23, 1);
+int is_2 = extract32(insn, 29, 1);
+int data = (is_2 << 1) | is_s;
+tcg_gen_gvec_3_ptr(vec_full_reg_offset(s, rd),
+ vec_full_reg_offset(s, rn),
+ vec_full_reg_offset(s, rm), cpu_env,
+ is_q ? 16 : 8, vec_full_reg_size(s),
+ data, gen_helper_gvec_fmlal_a64);
+}
+return;
+
default:
unallocated_encoding(s);
return;
@@ -12739,6 +12759,17 @@ static void disas_simd_indexed(DisasContext *s,
uint32_t insn)
}
is_fp = 2;
break;
+case 0x00: /* FMLAL */
+case 0x04: /* FMLSL */
+case 0x18: /* FMLAL2 */
+case 0x1c: /* FMLSL2 */
+if (is_scalar || size != MO_32 || !dc_isar_feature(aa64_fhm, s)) {
+unallocated_encoding(s);
+return;
+}
+size = MO_16;
+/* is_fp, but we pass cpu_env not fp_status. */
+break;
default:
unallocated_encoding(s);
return;
@@ -12849,6 +12880,22 @@ static void disas_simd_indexed(DisasContext *s,
uint32_t insn)
tcg_temp_free_ptr(fpst);
}
return;
+
+case 0x00: /* FMLAL */
+case 0x04: /* FMLSL */
+case 0x18: /* FMLAL2 */
+case 0x1c: /* FMLSL2 */
+{
+int is_s = extract32(opcode, 2, 1);
+int is_2 = u;
+int data = (index << 2) | (is_2 << 1) | is_s;
+tcg_gen_gvec_3_ptr(vec_full_reg_offset(s, rd),
+ vec_full_reg_offset(s, rn),
+ vec_full_reg_offset(s, rm), cpu_env,
+ is_q ? 16 : 8, vec_full_reg_size(s),
+ data, gen_helper_gvec_fmlal_idx_a64);
+}
+return;
}
if (size == 3) {
--
2.20.1
[Qemu-devel] [PULL 08/13] MAINTAINERS: Add maintainers to the Linux subsystem
From: Philippe Mathieu-Daudé Add Michael, Cornelia and Paolo as maintainers of the Linux subsystem. Remove the qemu-devel@nongnu.org entry because the list is always selected by the 'All patches CC here' section. Suggested-by: Paolo Bonzini Signed-off-by: Philippe Mathieu-Daudé Acked-by: Cornelia Huck [thuth: Add update-linux-headers.sh, too] Signed-off-by: Thomas Huth --- MAINTAINERS | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index ee73486..a1ceccf 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -425,10 +425,12 @@ Hosts: -- LINUX -L: qemu-devel@nongnu.org +M: Michael S. Tsirkin +M: Cornelia Huck +M: Paolo Bonzini S: Maintained -F: linux-* F: linux-headers/ +F: scripts/update-linux-headers.sh POSIX M: Paolo Bonzini -- 1.8.3.1
Re: [Qemu-devel] [PATCH 05/11] docs/conf.py: Configure the 'alabaster' theme
On Fri, 1 Feb 2019 at 16:43, Alex Bennée wrote: > > > Peter Maydell writes: > > > Add the 'navigation' bar to the sidebar, which for some > > reason is not enabled by default. Remove 'relations', which > > is effectively disabled anyway and isn't useful for us. > > I'm not sure what the title means... is the theme a reference to a > layout? I thought themes were colours and other such visual frippery > rather than actual content layout. But what do I know as a mere code > monkey... Just noticed I never followed up to this. Sphinx themes allow a bit more customisation than just "colours and fonts": they can also do layout things like changing up what sorts of sidebar information is shown, or indeed whether there's any kind of sidebar at all. Specific themes might expose some theme-specific config options which allow tweaking of how they appear. http://www.sphinx-doc.org/en/stable/theming.html has a few screenshots and gives more of an idea of what sort of tweaks the theming system allows. thanks -- PMM
Re: [Qemu-devel] [RFC PATCH 0/4] ARM virt: ACPI memory hotplug support
> -Original Message- > From: Shameerali Kolothum Thodi > Sent: 28 February 2019 12:04 > To: 'Auger Eric' ; Laszlo Ersek ; > shannon.zha...@gmail.com; peter.mayd...@linaro.org; > imamm...@redhat.com; qemu-devel@nongnu.org; qemu-...@nongnu.org > Cc: xuwei (O) ; Linuxarm ; Ard > Biesheuvel ; Leif Lindholm (Linaro address) > > Subject: RE: [RFC PATCH 0/4] ARM virt: ACPI memory hotplug support > > > > > -Original Message- > > From: Auger Eric [mailto:eric.au...@redhat.com] > > Sent: 28 February 2019 10:12 > > To: Laszlo Ersek ; Shameerali Kolothum Thodi > > ; shannon.zha...@gmail.com; > > peter.mayd...@linaro.org; imamm...@redhat.com; > qemu-devel@nongnu.org; > > qemu-...@nongnu.org > > Cc: xuwei (O) ; Linuxarm ; > Ard > > Biesheuvel ; Leif Lindholm (Linaro address) > > > > Subject: Re: [RFC PATCH 0/4] ARM virt: ACPI memory hotplug support > > > > Hi Laszlo, > > > > On 2/27/19 9:14 PM, Laszlo Ersek wrote: > > > On 02/27/19 13:55, Shameerali Kolothum Thodi wrote: > > >> Hi Laszlo, > > >> > > >>> -Original Message- > > >>> From: Shameerali Kolothum Thodi > > >>> Sent: 25 February 2019 09:54 > > >>> To: 'Laszlo Ersek' ; Auger Eric > > ; > > >>> shannon.zha...@gmail.com; peter.mayd...@linaro.org; > > >>> imamm...@redhat.com; qemu-devel@nongnu.org; > > qemu-...@nongnu.org > > >>> Cc: xuwei (O) ; Linuxarm > ; > > Ard > > >>> Biesheuvel ; Leif Lindholm (Linaro address) > > >>> > > >>> Subject: RE: [RFC PATCH 0/4] ARM virt: ACPI memory hotplug support > > >> > > >> [...] > > >> > > >> The root cause seems to be EDK2 ACPI table checksum failure > > >> as NFIT table is getting updated on hot-add. This needs further > > >> investigation. > > > + Ard, Leif, Laszlo if they have any idea of what is missing/wrong. > > > > Huh, very interesting; I usually don't expect my sanity checks to fire > > in practice. :) > > > > The message > > > > ProcessCmdAddChecksum: invalid checksum range in > > "etc/acpi/tables" > > > > is logged by OVMF's and ArmVirtQemu's ACPI Platform DXE Driver when > > it > > finds an invalid COMMAND_ADD_CHECKSUM command in QEMU's > ACPI > > linker/loader script. > > > > Please see the command definition in QEMU's > > "hw/acpi/bios-linker-loader.c". In particular, please refer to the > > function bios_linker_loader_add_checksum(), which builds the > command > > structure, and documents the fields. > > > > (You may also refer to QEMU_LOADER_ADD_CHECKSUM in file > > "OvmfPkg/AcpiPlatformDxe/QemuLoader.h" in the edk2 source tree, for > > the > > same information.) > > > > The error message is logged if: > > - the offset at which the checksum should be stored falls outside of > > the > > size of the fw_cfg blob, or > > - the range over which the checksum should be calculated falls outside > > (at least in part) of the fw_cfg blob. > > > > To me this suggests that QEMU generates an invalid > > COMMAND_ADD_CHECKSUM > > command for the firmware. > > > > ... I've tried to skim the patches briefly. I think there must be an > > error in the DSDT building logic that is only active on reboot if an > > nvdimm module was hot-added before the reboot. > > >>> > > >>> Thanks for taking a look and the pointers. I will debug this further > > >>> and get back. > > >> > > >> The root cause of the issue seems to be UEFI not seeing the updated acpi > > >> table blob size on reboot once a new NFIT table is added(nvdimm hot > > added). > > >> > > >> Please see the debug logs below, > > >> > > >> Initial Guest boot > > >> --- > > >> > > >> Debug logs from Qemu: > > >> > > >> build_header: acpi sig DSDT len 0x5127 > > >> build_header: acpi sig FACP len 0x10c > > >> build_header: acpi sig APIC len 0xa8 > > >> build_header: acpi sig GTDT len 0x60 > > >> build_header: acpi sig MCFG len 0x3c > > >> build_header: acpi sig SPCR len 0x50 > > >> build_header: acpi sig SRAT len 0x92 > > >> build_header: acpi sig SSDT len 0x38f > > >> build_header: acpi sig XSDT len 0x5c > > >> virt_acpi_build: acpi table_blob len 0x5844 > > >> > > >> Debug logs from UEFI: > > >> > > >> ProcessCmdAddChecksum: File="etc/acpi/tables" ResultOffset=0x9 > > Start=0x0 Length=0x5127 Blob->Size=0x5844 > > >> ProcessCmdAddChecksum: File="etc/acpi/tables" ResultOffset=0x5130 > > Start=0x5127 Length=0x10C Blob->Size=0x5844 > > >> ProcessCmdAddChecksum: File="etc/acpi/tables" ResultOffset=0x523C > > Start=0x5233 Length=0xA8 Blob->Size=0x5844 > > >> ProcessCmdAddChecksum: File="etc/acpi/tables" ResultOffset=0x52E4 > > Start=0x52DB Length=0x60 Blob->Size=0x5844 > > >> ProcessCmdAddChecksum: File="etc/acpi/tables" ResultOffset=0x5344 > > Start=0x533B Length=0x3C Blob->Size=0x5844 > > >> ProcessCmdAddChecksum: File="etc/acpi/tables" ResultOffset=0x5380 > > Start=0x5377 Length=0x50 Blob->Size=0x5844 > > >> ProcessCmdAddChecksum:
[Qemu-devel] [PULL 3/5] audio: don't build alsa and sdl by default on linux
In case no sound hardware is present both alsa and sdl drivers initialize successfully and throw errors later on, i.e. effectively the automatic probing doesn't work. Drop them from the list of default audio drivers for linux because of that. Fixes: 6a48541873 audio: probe audio drivers by default Buglink: https://bugs.launchpad.net/qemu/+bug/1816052 Signed-off-by: Gerd Hoffmann Reviewed-by: Daniel P. Berrangé Tested-by: David Hildenbrand Message-id: 20190219124257.3001-1-kra...@redhat.com --- configure | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure b/configure index 694088a4ec99..540bee19ba1d 100755 --- a/configure +++ b/configure @@ -879,7 +879,7 @@ Haiku) LIBS="-lposix_error_mapper -lnetwork $LIBS" ;; Linux) - audio_drv_list="try-pa try-alsa try-sdl oss" + audio_drv_list="try-pa oss" audio_possible_drivers="oss alsa sdl pa" linux="yes" linux_user="yes" -- 2.9.3
[Qemu-devel] [PULL 1/5] audio: Use g_strdup_printf instead of manual building a string
From: Frediano Ziglio
Instead of using lot of low level function and manually allocate
the temporary string in audio_process_options use more high
level GLib function. The function is not used in hot path but to
read some initial setting.
Signed-off-by: Frediano Ziglio
Message-id: 20190225154335.11397-1-fzig...@redhat.com
Signed-off-by: Gerd Hoffmann
---
audio/audio.c | 25 +
1 file changed, 5 insertions(+), 20 deletions(-)
diff --git a/audio/audio.c b/audio/audio.c
index d163ffbc88f4..472721a7a9f0 100644
--- a/audio/audio.c
+++ b/audio/audio.c
@@ -454,9 +454,7 @@ static void audio_print_options (const char *prefix,
static void audio_process_options (const char *prefix,
struct audio_option *opt)
{
-char *optname;
-const char qemu_prefix[] = "QEMU_";
-size_t preflen, optlen;
+gchar *prefix_upper;
if (audio_bug(__func__, !prefix)) {
dolog ("prefix = NULL\n");
@@ -468,10 +466,10 @@ static void audio_process_options (const char *prefix,
return;
}
-preflen = strlen (prefix);
+prefix_upper = g_utf8_strup(prefix, -1);
for (; opt->name; opt++) {
-size_t len, i;
+char *optname;
int def;
if (!opt->valp) {
@@ -480,21 +478,7 @@ static void audio_process_options (const char *prefix,
continue;
}
-len = strlen (opt->name);
-/* len of opt->name + len of prefix + size of qemu_prefix
- * (includes trailing zero) + zero + underscore (on behalf of
- * sizeof) */
-optlen = len + preflen + sizeof (qemu_prefix) + 1;
-optname = g_malloc (optlen);
-
-pstrcpy (optname, optlen, qemu_prefix);
-
-/* copy while upper-casing, including trailing zero */
-for (i = 0; i <= preflen; ++i) {
-optname[i + sizeof (qemu_prefix) - 1] = qemu_toupper(prefix[i]);
-}
-pstrcat (optname, optlen, "_");
-pstrcat (optname, optlen, opt->name);
+optname = g_strdup_printf("QEMU_%s_%s", prefix_upper, opt->name);
def = 1;
switch (opt->tag) {
@@ -532,6 +516,7 @@ static void audio_process_options (const char *prefix,
*opt->overriddenp = !def;
g_free (optname);
}
+g_free(prefix_upper);
}
static void audio_print_settings (struct audsettings *as)
--
2.9.3
Re: [Qemu-devel] [PATCH] Allow -sandbox off with --disable-seccomp
On Wed, Feb 27, 2019 at 08:21:40PM +0100, Markus Armbruster wrote:
> Daniel P. Berrangé writes:
>
> > On Wed, Feb 27, 2019 at 07:59:11AM -0600, Eric Blake wrote:
> >> On 2/27/19 5:01 AM, Daniel P. Berrangé wrote:
> >> > On Wed, Feb 27, 2019 at 12:21:32PM +1100, David Gibson wrote:
> >> >> At present, when seccomp support is compiled out with --disable-seccomp
> >> >> we fail with an error if the user puts -sandbox on the command line.
> >> >>
> >> >> That kind of makes sense, but it's a bit strange that we reject a
> >> >> request
> >> >> to disable sandboxing with "-sandbox off" saying we don't support
> >> >> sandboxing.
> >> >>
> >> >> This puts in a small sandbox to (correctly) silently ignore -sandbox off
> >> >> when we don't have sandboxing support compiled in. This makes life
> >> >> easier
> >> >> for testcases, since they can safely specify "-sandbox off" without
> >> >> having
> >> >> to care if the qemu they're using is compiled with sandbox support or
> >> >> not.
>
> I can't see such test cases. Can you give specific examples?
>
> >> >> Signed-off-by: David Gibson
> >>
> >> > '-sandbox off' is just syntax sugar for '-sandbox enable=off', with
> >> > the default arg name handled by QemuOpts.
> >>
> >> Except that libvirt probes, via query-command-line-options, whether the
> >> '-sandbox' option supports the 'enable' key. You risk breaking
> >> introspection (where libvirt knows NOT to use enable=on|off) if -sandbox
> >> enable=off is advertised even when the feature is not compiled in.
> >
> > It is even more complex than that. Libvirt looks for "elevateprivileges"
> > option to decide to enable the sandbox. It only looks for "enable" when
> > libvirt is configured to disable the sandbox, at which point is sets
> > "-sandbox off". So I don't think my suggestion should break it.
> >
> > I do hate the idea of QEMU tailoring its CLI handling to suit the
> > current specific impl of one client app though.
> >
> > If anything I'd suggest we should completely disable any parsing
> > of -sandbox when seccomp is disabled, rather than leaving getopt
> > to parse -sandbox and then raise an error.
>
> I'm confused. Are you proposing to silently ignore -sandbox OPTARG
> regardless of OPTARG when CONFIG_SECCOMP is off? If yes, I object. If
> a user asks for a sandbox, and we can't give him one, we should at least
> tell him as much.
No, i mean remove "case QEMU_OPTION_sandbox:" from the code, which
will cause us to report '-sandbox' as an unsupported argument.
> Currently, we have both
>
> #ifdef CONFIG_FOO
> case QEMU_OPTION_FOO:
> ...
> break;
> #endif
This is what I was suggesting for -sandbox above.
>
> and
>
>
> case QEMU_OPTION_FOO:
> #ifdef CONFIG_FOO
> ...
> break;
> #else
> error_report("FOO support is disabled");
> exit(1);
> #endif
This is what -sandbox does currently.
>
> The patch adds a third variant. We need fewer variants, not more.
>
> For what it's worth, conditional QMP commands do not exist when
> disabled, like the first variant above. In particular, introspection
> doesn't have them. Nicely obvious.
>
> QAPIfying the command line (yes, yes, overdue) should make it more like
> QMP.
>
> Wanting nicer errors than "unknown option / command" is legitimate.
>
> Wanting to accept "switch FOO off" even though FOO is disabled is also
> legitimate.
>
> Patches that provide such UI niceties while keeping introspection nicely
> obvious would be acceptable to me, provided they're not too complex.
> But they should be general, not a one-off.
Regards,
Daniel
--
|: https://berrange.com -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Re: [Qemu-devel] [PATCH 30/51] ppc64: Express dependencies of 'pseries' and 'powernv' machines with kconfig
On 07/02/19 18:57, Paolo Bonzini wrote: > diff --git a/default-configs/ppc64-softmmu.mak > b/default-configs/ppc64-softmmu.mak > index d642b67..cca5266 100644 > --- a/default-configs/ppc64-softmmu.mak > +++ b/default-configs/ppc64-softmmu.mak > @@ -5,11 +5,6 @@ include ppc-softmmu.mak > > # For PowerNV > CONFIG_POWERNV=y > -CONFIG_ISA_IPMI_BT=y > > # For pSeries > CONFIG_PSERIES=y > -CONFIG_VIRTIO_VGA=y > -CONFIG_MEM_DEVICE=y > -CONFIG_DIMM=y > -CONFIG_SPAPR_RNG=y > diff --git a/hw/intc/Kconfig b/hw/intc/Kconfig > index 6eea14e..de10a6b 100644 > --- a/hw/intc/Kconfig > +++ b/hw/intc/Kconfig > @@ -31,13 +31,11 @@ config OPENPIC_KVM > > config XICS > bool > -default y > -depends on PSERIES > +depends on POWERNV || PSERIES > > config XICS_SPAPR > bool > -default y > -depends on PSERIES > +select XICS > > config XICS_KVM > bool > diff --git a/hw/mem/Kconfig b/hw/mem/Kconfig > index d1e635c..620fd4c 100644 > --- a/hw/mem/Kconfig > +++ b/hw/mem/Kconfig > @@ -1,5 +1,6 @@ > config DIMM > bool > +select MEM_DEVICE > > config MEM_DEVICE > bool > diff --git a/hw/ppc/Kconfig b/hw/ppc/Kconfig > index fb085d7..be6440e 100644 > --- a/hw/ppc/Kconfig > +++ b/hw/ppc/Kconfig > @@ -1,11 +1,29 @@ > config PSERIES > bool > +imply PCI_DEVICES > +imply TEST_DEVICES > +select DIMM > +select PCI > +select VFIO I'm changing this to "select VFIO if LINUX" to fix non-Linux compilation. Paolo
Re: [Qemu-devel] [RFC v3] target/arm: add ARMv6-M UNDEFINED 32-bit instruction test
Stefan Hajnoczi writes: > Test that 32-bit instructions declared UNDEFINED in the ARMv6-M > Reference Manual really do raise an exception. Also test that the 6 > 32-bit instructions defined in the ARMv6-M Reference Manual do not raise > an exception. > > The Intel HEX (.hex) file is included to save people the trouble of > installing a cross-compiler toolchain. > > To run the test (make sure qemu-system-arm is in your $PATH): > > $ cd tests/tcg/arm > $ make run-test-armv6m-undef > > Based-on: <20181029194519.15628-1-stefa...@redhat.com> > Signed-off-by: Stefan Hajnoczi I'm snarfing this into my testing/enable-system-tcg-tests-v2 as I need a few more example system tests ;-) -- Alex Bennée
Re: [Qemu-devel] [PATCH v1 33/33] s390x/tcg: Implement VECTOR UNPACK *
On 28.02.19 10:28, David Hildenbrand wrote: > On 28.02.19 01:03, Richard Henderson wrote: >> On 2/26/19 3:39 AM, David Hildenbrand wrote: >>> Combine all variant in a single handler. As source and destination >>> have different element sizes, we can't use gvec expansion. Expand >>> manually. Also watch out for overlapping source and destination and >>> use a temporary register in that case. >>> >>> Signed-off-by: David Hildenbrand >>> --- >>> target/s390x/insn-data.def | 8 +++ >>> target/s390x/translate_vx.inc.c | 41 + >>> 2 files changed, 49 insertions(+) >> >> This works as is, so >> Reviewed-by: Richard Henderson >> >> But the same comment applies wrt iteration order and not needing a temporary. >> High unpack can iterate backward, while low unpack can iterate forward, with >> no >> lost data. > > I'll fix that right away. I guess vector pack cannot be handled like this. > > The only way to get rid of the temporary would be to load both elements > from v2 and v3 and then writing the two (half sized) elements in v1. > > I'll have a look. Hmm, as v2 and v3 are handled concatenated it is not that easy. I am not sure if we can handle this without a temporary vector. I thought about packing them first interleaved v2 = [v2e0, v2e1] v3 = [v3e0, ve31] v1 = [v2e0_packed, v3e0_packed, v2e1_packed, v3e1_packed] And then restoring the right order v1 = [v2e0_packed, v2e1_packed, v3e0_packed, v3e1_packed] But than the second operation seems to be the problem. That shuffling would have to be hard coded as far as I can see. (shuffling with MO_8 is nasty -> 14 element shave to be exchanged, in my opinion needing eventually 14 temporary variables) Of course, we can also simply detect duplicates and if so, call into a helper. -- Thanks, David / dhildenb
Re: [Qemu-devel] [PATCH V2] i386: extended the cpuid_level when Intel PT is enabled
> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Thursday, February 28, 2019 7:02 PM
> To: Kang, Luwei ; m...@redhat.com;
> marcel.apfelb...@gmail.com; r...@twiddle.net; ehabk...@redhat.com
> Cc: qemu-devel@nongnu.org
> Subject: Re: [PATCH V2] i386: extended the cpuid_level when Intel PT is
> enabled
>
> On 30/01/19 00:52, Luwei Kang wrote:
> > Intel Processor Trace required CPUID[0x14] but the cpuid_level have no
> > change when create a kvm guest with e.g. "-cpu qemu64,+intel-pt".
> >
> > Signed-off-by: Eduardo Habkost
> > Signed-off-by: Luwei Kang
> > ---
> > hw/i386/pc.c | 1 +
> > target/i386/cpu.c | 9 +
> > target/i386/cpu.h | 3 +++
> > 3 files changed, 13 insertions(+)
> >
> > diff --git a/hw/i386/pc.c b/hw/i386/pc.c index 73d688f..72a0a70 100644
> > --- a/hw/i386/pc.c
> > +++ b/hw/i386/pc.c
> > @@ -122,6 +122,7 @@ GlobalProperty pc_compat_3_1[] = {
> > { "Cascadelake-Server" "-" TYPE_X86_CPU, "mpx", "on" },
> > { "Icelake-Client" "-" TYPE_X86_CPU, "mpx", "on" },
> > { "Icelake-Server" "-" TYPE_X86_CPU, "mpx", "on" },
> > +{ TYPE_X86_CPU, "x-intel-pt-auto-level", "off" },
> > };
> > const size_t pc_compat_3_1_len = G_N_ELEMENTS(pc_compat_3_1);
> >
> > diff --git a/target/i386/cpu.c b/target/i386/cpu.c index
> > 2f54125..699 100644
> > --- a/target/i386/cpu.c
> > +++ b/target/i386/cpu.c
> > @@ -5023,6 +5023,13 @@ static void x86_cpu_expand_features(X86CPU *cpu,
> > Error **errp)
> > x86_cpu_adjust_feat_level(cpu, FEAT_C000_0001_EDX);
> > x86_cpu_adjust_feat_level(cpu, FEAT_SVM);
> > x86_cpu_adjust_feat_level(cpu, FEAT_XSAVE);
> > +
> > +/* Intel Processor Trace requires CPUID[0x14] */
> > +if ((env->features[FEAT_7_0_EBX] & CPUID_7_0_EBX_INTEL_PT) &&
> > + kvm_enabled() && cpu->intel_pt_auto_level) {
> > +x86_cpu_adjust_level(cpu, >env.cpuid_min_level, 0x14);
> > +}
> > +
> > /* SVM requires CPUID[0x800A] */
> > if (env->features[FEAT_8000_0001_ECX] & CPUID_EXT3_SVM) {
> > x86_cpu_adjust_level(cpu, >cpuid_min_xlevel,
> > 0x800A); @@ -5816,6 +5823,8 @@ static Property x86_cpu_properties[] = {
> > DEFINE_PROP_INT32("x-hv-max-vps", X86CPU, hv_max_vps, -1),
> > DEFINE_PROP_BOOL("x-hv-synic-kvm-only", X86CPU, hyperv_synic_kvm_only,
> > false),
> > +DEFINE_PROP_BOOL("x-intel-pt-auto-level", X86CPU, intel_pt_auto_level,
> > + true),
> > DEFINE_PROP_END_OF_LIST()
> > };
> >
> > diff --git a/target/i386/cpu.h b/target/i386/cpu.h index
> > 59656a7..090baa4 100644
> > --- a/target/i386/cpu.h
> > +++ b/target/i386/cpu.h
> > @@ -1455,6 +1455,9 @@ struct X86CPU {
> > /* Enable auto level-increase for all CPUID leaves */
> > bool full_cpuid_auto_level;
> >
> > +/* Enable auto level-increase for Intel Processor Trace leave */
> > +bool intel_pt_auto_level;
> > +
> > /* if true fill the top bits of the MTRR_PHYSMASKn variable range */
> > bool fill_mtrr_mask;
> >
> >
>
> Eduardo is back, but I've queued this anyway.
>
Get it. Thanks!
Luwei Kang
Re: [Qemu-devel] [PATCH] migration: Cleanup during exit
On Thu, Feb 28, 2019 at 11:40:19AM +, Dr. David Alan Gilbert wrote: > * Peter Xu (pet...@redhat.com) wrote: > > On Wed, Feb 27, 2019 at 04:49:00PM +, Dr. David Alan Gilbert (git) > > wrote: > > > From: "Dr. David Alan Gilbert" > > > > > > Currently we cleanup the migration object as we exit main after the > > > main_loop finishes; however if there's a migration running things > > > get messy and we can end up with the migration thread still trying > > > to access freed structures. > > > > > > We now take a ref to the object around the migration thread itself, > > > so the act of dropping the ref during exit doesn't cause us to lose > > > the state until the thread quits. > > > > > > Cancelling the migration during migration also tries to get the thread > > > to quit. > > > > > > We do this a bit earlier; so hopefully migration gets out of the way > > > before all the devices etc are freed. > > > > So does it mean that even with the patch it's still possible the > > migration thread will be accessing device structs that have already > > been freed which can still crash QEMU? > > Possibly yes; I'm not sure how to go to the next stage and stop that > case; the consensus seems to be we don't want to explicitly block > during the exit process, so doing a join on the migration thread doesn't > seem to be wanted. Essentially the many *_cleanup() calls at the end of main() in vl.c are only ever safe if all background threads have stopped using the resources that are being freed. This isn't the case with migration currently. I also worry about other threads that might be running in QEMU, SPICE in particular as it touchs many device backends. Aborting the migration & joining the migration threads is the natural way to address this. Cancelling appears to require the main loop to still be running, so would require main_loop_should_exit() to issue the cancel & return false unless it has completed. This would delay shutdown for as long as it takes migration to abort. FWIW, even the bdrv_close_all() call during shutdown can delay things for a considerable time if draining the backends isn't a quick op, which could be the case if there are storage problems (blocked local I/O, or interrupted network - rbd/ceph/nfs clients). So I'm not sure that stopping migration is inherantly worse than what's already possible with block cleanup, in terms of delaying things. A slightly more hacky approach would be to pthread_cancel() all the migration threads. Normally we'd never use pthread_cancel() as it is incredibly hard to ensure all memory used by the threads is freed. Since we're about to exit the process though, this cleanup does not matter. The risk, however, is that one of the threads is holding a mutex which then blocks the rest of the *cleanup functions, so this still feels dangerous. Overall to me a clean cancel & join of the migration threads feels like the only safe option, unless we just remove all notion of cleanup from QEMU & delete all the _cleanup functions in main() and let the OS free all memory. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
[Qemu-devel] [PULL 06/13] MAINTAINERS: Add maintainer to the POSIX subsystem
From: Philippe Mathieu-Daudé Add Paolo as maintainer of the POSIX subsystem. Remove the qemu-devel@nongnu.org entry because the list is always selected by the 'All patches CC here' section. Cc: Paolo Bonzini Suggested-by: Markus Armbruster Signed-off-by: Philippe Mathieu-Daudé Signed-off-by: Thomas Huth --- MAINTAINERS | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 892d2c4..30a3359 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -431,9 +431,12 @@ F: linux-* F: linux-headers/ POSIX -L: qemu-devel@nongnu.org +M: Paolo Bonzini S: Maintained -F: *posix* +F: os-posix.c +F: include/sysemu/os-posix.h +F: util/*posix*.c +F: include/qemu/*posix*.h NETBSD L: qemu-devel@nongnu.org -- 1.8.3.1
Re: [Qemu-devel] [RFC PATCH 0/4] ARM virt: ACPI memory hotplug support
On 02/28/19 11:12, Auger Eric wrote: > Hi Laszlo, > > On 2/27/19 9:14 PM, Laszlo Ersek wrote: >> On 02/27/19 13:55, Shameerali Kolothum Thodi wrote: >>> Hi Laszlo, >>> -Original Message- From: Shameerali Kolothum Thodi Sent: 25 February 2019 09:54 To: 'Laszlo Ersek' ; Auger Eric ; shannon.zha...@gmail.com; peter.mayd...@linaro.org; imamm...@redhat.com; qemu-devel@nongnu.org; qemu-...@nongnu.org Cc: xuwei (O) ; Linuxarm ; Ard Biesheuvel ; Leif Lindholm (Linaro address) Subject: RE: [RFC PATCH 0/4] ARM virt: ACPI memory hotplug support >>> >>> [...] >>> >>> The root cause seems to be EDK2 ACPI table checksum failure >>> as NFIT table is getting updated on hot-add. This needs further >>> investigation. >> + Ard, Leif, Laszlo if they have any idea of what is missing/wrong. > > Huh, very interesting; I usually don't expect my sanity checks to fire > in practice. :) > > The message > > ProcessCmdAddChecksum: invalid checksum range in "etc/acpi/tables" > > is logged by OVMF's and ArmVirtQemu's ACPI Platform DXE Driver when it > finds an invalid COMMAND_ADD_CHECKSUM command in QEMU's ACPI > linker/loader script. > > Please see the command definition in QEMU's > "hw/acpi/bios-linker-loader.c". In particular, please refer to the > function bios_linker_loader_add_checksum(), which builds the command > structure, and documents the fields. > > (You may also refer to QEMU_LOADER_ADD_CHECKSUM in file > "OvmfPkg/AcpiPlatformDxe/QemuLoader.h" in the edk2 source tree, for the > same information.) > > The error message is logged if: > - the offset at which the checksum should be stored falls outside of the > size of the fw_cfg blob, or > - the range over which the checksum should be calculated falls outside > (at least in part) of the fw_cfg blob. > > To me this suggests that QEMU generates an invalid > COMMAND_ADD_CHECKSUM > command for the firmware. > > ... I've tried to skim the patches briefly. I think there must be an > error in the DSDT building logic that is only active on reboot if an > nvdimm module was hot-added before the reboot. Thanks for taking a look and the pointers. I will debug this further and get back. >>> >>> The root cause of the issue seems to be UEFI not seeing the updated acpi >>> table blob size on reboot once a new NFIT table is added(nvdimm hot added). >>> >>> Please see the debug logs below, >>> >>> Initial Guest boot >>> --- >>> >>> Debug logs from Qemu: >>> >>> build_header: acpi sig DSDT len 0x5127 >>> build_header: acpi sig FACP len 0x10c >>> build_header: acpi sig APIC len 0xa8 >>> build_header: acpi sig GTDT len 0x60 >>> build_header: acpi sig MCFG len 0x3c >>> build_header: acpi sig SPCR len 0x50 >>> build_header: acpi sig SRAT len 0x92 >>> build_header: acpi sig SSDT len 0x38f >>> build_header: acpi sig XSDT len 0x5c >>> virt_acpi_build: acpi table_blob len 0x5844 >>> >>> Debug logs from UEFI: >>> >>> ProcessCmdAddChecksum: File="etc/acpi/tables" ResultOffset=0x9 Start=0x0 >>> Length=0x5127 Blob->Size=0x5844 >>> ProcessCmdAddChecksum: File="etc/acpi/tables" ResultOffset=0x5130 >>> Start=0x5127 Length=0x10C Blob->Size=0x5844 >>> ProcessCmdAddChecksum: File="etc/acpi/tables" ResultOffset=0x523C >>> Start=0x5233 Length=0xA8 Blob->Size=0x5844 >>> ProcessCmdAddChecksum: File="etc/acpi/tables" ResultOffset=0x52E4 >>> Start=0x52DB Length=0x60 Blob->Size=0x5844 >>> ProcessCmdAddChecksum: File="etc/acpi/tables" ResultOffset=0x5344 >>> Start=0x533B Length=0x3C Blob->Size=0x5844 >>> ProcessCmdAddChecksum: File="etc/acpi/tables" ResultOffset=0x5380 >>> Start=0x5377 Length=0x50 Blob->Size=0x5844 >>> ProcessCmdAddChecksum: File="etc/acpi/tables" ResultOffset=0x53D0 >>> Start=0x53C7 Length=0x92 Blob->Size=0x5844 >>> ProcessCmdAddChecksum: File="etc/acpi/tables" ResultOffset=0x5462 >>> Start=0x5459 Length=0x38F Blob->Size=0x5844 >>> ProcessCmdAddChecksum: File="etc/acpi/tables" ResultOffset=0x57F1 >>> Start=0x57E8 Length=0x5C Blob->Size=0x5844 >>> ProcessCmdAddChecksum: File="etc/acpi/rsdp" ResultOffset=0x8 Start=0x0 >>> Length=0x14 Blob->Size=0x24 >>> ProcessCmdAddChecksum: File="etc/acpi/rsdp" ResultOffset=0x20 Start=0x0 >>> Length=0x24 Blob->Size=0x24 >>> InstallQemuFwCfgTables: installed 8 tables >>> >>> Guest Reboot after ndimm hot added >>> >>> >>> Debug logs from Qemu: >>> >>> build_header: acpi sig DSDT len 0x5127 >>> build_header: acpi sig FACP len 0x10c >>> build_header: acpi sig APIC len 0xa8 >>> build_header: acpi sig GTDT len 0x60 >>> build_header: acpi sig MCFG len 0x3c >>> build_header: acpi sig SPCR len 0x50 >>> build_header: acpi sig SRAT len 0x92 >>> build_header: acpi sig SSDT len 0x38f >>> build_header: acpi sig NFIT len 0xe0 -->New >>> build_header: acpi sig XSDT len 0x64 >>>
Re: [Qemu-devel] [PATCH v2 1/3] qdev: Let the hotplug_handler_unplug() caller delete the device
On Thu, 28 Feb 2019 13:28:47 +0100
David Hildenbrand wrote:
> When unplugging a device, at one point the device will be destroyed
> via object_unparent(). This will, one the one hand, unrealize the
> removed device hierarchy, and on the other hand, destroy/free the
> device hierarchy.
>
> When chaining hotplug handlers, we want to overwrite a bus hotplug
> handler by the machine hotplug handler, to be able to perform
> some part of the plug/unplug and to forward the calls to the bus hotplug
> handler.
>
> For now, the bus hotplug handler would trigger an object_unparent(), not
> allowing us to perform some unplug action on a device after we forwarded
> the call to the bus hotplug handler. The device would be gone at that
> point.
>
> machine_unplug_handler(dev)
> /* eventually do unplug stuff */
> bus_unplug_handler(dev)
> /* dev is gone, we can't do more unplug stuff */
>
> So move the object_unparent() to the original caller of the unplug. For
> now, keep the unrealize() at the original places of the
> object_unparent(). For implicitly chained hotplug handlers (e.g. pc
> code calling acpi hotplug handlers), the object_unparent() has to be
> done by the outermost caller. So when calling hotplug_handler_unplug()
> from inside an unplug handler, nothing is to be done.
>
> hotplug_handler_unplug(dev) -> calls machine_unplug_handler()
> machine_unplug_handler(dev) {
> /* eventually do unplug stuff */
> bus_unplug_handler(dev) -> calls unrealize(dev)
> /* we can do more unplug stuff but device already unrealized */
> }
> object_unparent(dev)
>
> In the long run, every unplug action should be factored out of the
> unrealize() function into the unplug handler (especially for PCI). Then
> we can get rid of the additonal unrealize() calls and object_unparent()
> will properly unrealize the device hierarchy after the device has been
> unplugged.
>
> hotplug_handler_unplug(dev) -> calls machine_unplug_handler()
> machine_unplug_handler(dev) {
> /* eventually do unplug stuff */
> bus_unplug_handler(dev) -> only unplugs, does not unrealize
> /* we can do more unplug stuff */
> }
> object_unparent(dev) -> will unrealize
>
> The original approach was suggested by Igor Mammedov for the PCI
> part, but I extended it to all hotplug handlers. I consider this one
> step into the right direction.
>
> To summarize:
> - object_unparent() on synchronous unplugs is done by common code
> -- "Caller of hotplug_handler_unplug"
> - object_unparent() on asynchronous unplugs ("unplug requests") has to
> be done manually
> -- "Caller of hotplug_handler_unplug"
>
> Reviewed-by: Igor Mammedov
> Acked-by: Cornelia Huck
> Signed-off-by: David Hildenbrand
> ---
For the sPAPR bits:
Reviewed-by: Greg Kurz
> hw/acpi/cpu.c| 1 +
> hw/acpi/memory_hotplug.c | 1 +
> hw/acpi/pcihp.c | 3 ++-
> hw/core/qdev.c | 3 +--
> hw/i386/pc.c | 5 ++---
> hw/pci/pci.c | 3 ++-
> hw/pci/pcie.c| 3 ++-
> hw/pci/shpc.c| 3 ++-
> hw/ppc/spapr.c | 9 ++---
> hw/ppc/spapr_pci.c | 3 ++-
> hw/s390x/css-bridge.c| 2 +-
> hw/s390x/s390-pci-bus.c | 13 -
> qdev-monitor.c | 9 +++--
> 13 files changed, 37 insertions(+), 21 deletions(-)
>
> diff --git a/hw/acpi/cpu.c b/hw/acpi/cpu.c
> index a0a43fe6b5..7a90c8f82d 100644
> --- a/hw/acpi/cpu.c
> +++ b/hw/acpi/cpu.c
> @@ -126,6 +126,7 @@ static void cpu_hotplug_wr(void *opaque, hwaddr addr,
> uint64_t data,
> dev = DEVICE(cdev->cpu);
> hotplug_ctrl = qdev_get_hotplug_handler(dev);
> hotplug_handler_unplug(hotplug_ctrl, dev, NULL);
> +object_unparent(OBJECT(dev));
> }
> break;
> case ACPI_CPU_CMD_OFFSET_WR:
> diff --git a/hw/acpi/memory_hotplug.c b/hw/acpi/memory_hotplug.c
> index 921cad2c5e..297812d5f7 100644
> --- a/hw/acpi/memory_hotplug.c
> +++ b/hw/acpi/memory_hotplug.c
> @@ -189,6 +189,7 @@ static void acpi_memory_hotplug_write(void *opaque,
> hwaddr addr, uint64_t data,
> error_free(local_err);
> break;
> }
> +object_unparent(OBJECT(dev));
> trace_mhp_acpi_pc_dimm_deleted(mem_st->selector);
> }
> break;
> diff --git a/hw/acpi/pcihp.c b/hw/acpi/pcihp.c
> index 9429181323..88e4ae1bcd 100644
> --- a/hw/acpi/pcihp.c
> +++ b/hw/acpi/pcihp.c
> @@ -174,6 +174,7 @@ static void acpi_pcihp_eject_slot(AcpiPciHpState *s,
> unsigned bsel, unsigned slo
> if (!acpi_pcihp_pc_no_hotplug(s, dev)) {
> hotplug_ctrl = qdev_get_hotplug_handler(qdev);
> hotplug_handler_unplug(hotplug_ctrl, qdev, _abort);
> +object_unparent(OBJECT(qdev));
> }
> }
> }
> @@ -269,7 +270,7 @@ void acpi_pcihp_device_plug_cb(HotplugHandler
> *hotplug_dev, AcpiPciHpState *s,
Re: [Qemu-devel] [PATCH] trivial malloc to g_malloc in thunk
On 2/28/19 7:42 AM, Aarushi Mehta wrote:
> Hi
>
> This is a trivial contribution part of the BiteSizedTasks on the wiki.
> I found this discussion
> http://git.corpit.ru/?p=qemu.git;a=commit;h=b45c03f585ea9bb1af76c73e82195418c294919d
> on migrating even g_malloc to g_new, is this not appropriate for the same?
> The wiki can presumably use an update regarding this.
>
> Signed-off-by: Aarushi
> ---
> thunk.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/thunk.c b/thunk.c
> index d5d8645cd4..03fb2abab7 100644
> --- a/thunk.c
> +++ b/thunk.c
> @@ -89,7 +89,7 @@ void thunk_register_struct(int id, const char *name, const
> argtype *types)
> for(i = 0;i < 2; i++) {
> offset = 0;
> max_align = 1;
> -se->field_offsets[i] = malloc(nb_fields * sizeof(int));
> +se->field_offsets[i] = g_malloc(nb_fields * sizeof(int));
Where is the counterpart free() that needs to be changed to g_free()?
Also, you absolutely want g_new() or some other variant that separates
the number of elements from the size of the element as two separate
arguments, to avoid the possibility of integer overflow when using * in
a single argument.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
[Qemu-devel] [Bug 1815889] Re: qemu-system-x86_64 crashed with signal 31 in __pthread_setaffinity_new()
Adding Timo who maintainers mesa. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1815889 Title: qemu-system-x86_64 crashed with signal 31 in __pthread_setaffinity_new() Status in Mesa: Unknown Status in QEMU: New Status in mesa package in Ubuntu: New Status in qemu package in Ubuntu: Triaged Bug description: Unable to launch Default Fedora 29 images in gnome-boxes ProblemType: Crash DistroRelease: Ubuntu 19.04 Package: qemu-system-x86 1:3.1+dfsg-2ubuntu1 ProcVersionSignature: Ubuntu 4.19.0-12.13-generic 4.19.18 Uname: Linux 4.19.0-12-generic x86_64 ApportVersion: 2.20.10-0ubuntu20 Architecture: amd64 Date: Thu Feb 14 11:00:45 2019 ExecutablePath: /usr/bin/qemu-system-x86_64 KvmCmdLine: COMMAND STAT EUID RUID PID PPID %CPU COMMAND MachineType: Dell Inc. Precision T3610 ProcEnviron: PATH=(custom, user) ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.19.0-12-generic root=UUID=939b509b-d627-4642-a655-979b44972d17 ro splash quiet vt.handoff=1 Signal: 31 SourcePackage: qemu StacktraceTop: __pthread_setaffinity_new (th=, cpusetsize=128, cpuset=0x7f5771fbf680) at ../sysdeps/unix/sysv/linux/pthread_setaffinity.c:34 () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so start_thread (arg=) at pthread_create.c:486 clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Title: qemu-system-x86_64 crashed with signal 31 in __pthread_setaffinity_new() UpgradeStatus: Upgraded to disco on 2018-11-14 (91 days ago) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo video dmi.bios.date: 11/14/2018 dmi.bios.vendor: Dell Inc. dmi.bios.version: A18 dmi.board.name: 09M8Y8 dmi.board.vendor: Dell Inc. dmi.board.version: A01 dmi.chassis.type: 7 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA18:bd11/14/2018:svnDellInc.:pnPrecisionT3610:pvr00:rvnDellInc.:rn09M8Y8:rvrA01:cvnDellInc.:ct7:cvr: dmi.product.name: Precision T3610 dmi.product.sku: 05D2 dmi.product.version: 00 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/mesa/+bug/1815889/+subscriptions
[Qemu-devel] [PULL 16/16] linux-user: Enable HWCAP_ASIMDFHM, HWCAP_JSCVT
From: Richard Henderson Signed-off-by: Richard Henderson Message-id: 20190219222952.22183-6-richard.hender...@linaro.org Reviewed-by: Peter Maydell Signed-off-by: Peter Maydell --- linux-user/elfload.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/linux-user/elfload.c b/linux-user/elfload.c index 3a50d587ff0..b9f7cbbdc17 100644 --- a/linux-user/elfload.c +++ b/linux-user/elfload.c @@ -602,6 +602,8 @@ static uint32_t get_elf_hwcap(void) GET_FEATURE_ID(aa64_fcma, ARM_HWCAP_A64_FCMA); GET_FEATURE_ID(aa64_sve, ARM_HWCAP_A64_SVE); GET_FEATURE_ID(aa64_pauth, ARM_HWCAP_A64_PACA | ARM_HWCAP_A64_PACG); +GET_FEATURE_ID(aa64_fhm, ARM_HWCAP_A64_ASIMDFHM); +GET_FEATURE_ID(aa64_jscvt, ARM_HWCAP_A64_JSCVT); #undef GET_FEATURE_ID -- 2.20.1
[Qemu-devel] [PULL 15/16] target/arm: Enable ARMv8.2-FHM for -cpu max
From: Richard Henderson Reviewed-by: Peter Maydell Signed-off-by: Richard Henderson Message-id: 20190219222952.22183-5-richard.hender...@linaro.org Signed-off-by: Peter Maydell --- target/arm/cpu.c | 1 + target/arm/cpu64.c | 2 ++ 2 files changed, 3 insertions(+) diff --git a/target/arm/cpu.c b/target/arm/cpu.c index a3baf4eeed1..54b61f917be 100644 --- a/target/arm/cpu.c +++ b/target/arm/cpu.c @@ -2020,6 +2020,7 @@ static void arm_max_initfn(Object *obj) t = cpu->isar.id_isar6; t = FIELD_DP32(t, ID_ISAR6, JSCVT, 1); t = FIELD_DP32(t, ID_ISAR6, DP, 1); +t = FIELD_DP32(t, ID_ISAR6, FHM, 1); cpu->isar.id_isar6 = t; t = cpu->id_mmfr4; diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c index 69e4134f79f..1b0c427277b 100644 --- a/target/arm/cpu64.c +++ b/target/arm/cpu64.c @@ -308,6 +308,7 @@ static void aarch64_max_initfn(Object *obj) t = FIELD_DP64(t, ID_AA64ISAR0, SM3, 1); t = FIELD_DP64(t, ID_AA64ISAR0, SM4, 1); t = FIELD_DP64(t, ID_AA64ISAR0, DP, 1); +t = FIELD_DP64(t, ID_AA64ISAR0, FHM, 1); cpu->isar.id_aa64isar0 = t; t = cpu->isar.id_aa64isar1; @@ -347,6 +348,7 @@ static void aarch64_max_initfn(Object *obj) u = cpu->isar.id_isar6; u = FIELD_DP32(u, ID_ISAR6, JSCVT, 1); u = FIELD_DP32(u, ID_ISAR6, DP, 1); +u = FIELD_DP32(u, ID_ISAR6, FHM, 1); cpu->isar.id_isar6 = u; /* -- 2.20.1
Re: [Qemu-devel] sorecvfrom freezes guest
Hi, On Thu, Feb 28, 2019 at 11:45 AM llyzs wrote: > > Hi, > > I am having a guest freeze issue (win10), and through debugging I found out > that sometimes sorecvfrom() is called from slirp.c because revents == > G_IO_IN, however inside sorecvfrom() function, ioctlsocket() returns 0 > bytes available and recvfrom could be blocking indefinitely. I am not sure > the root cause of the situation, but I added a non-blocking check to > recvfrom and it fixed my issue. My patch is as attached. Please check if > this is a right fix. Thank you for the patch. Could you resend it inline, with the comment in the commit message? Also add the subsystem maintainers in CC: $ scripts/get_maintainer.pl -f slirp Samuel Thibault (maintainer:SLIRP) Jan Kiszka (maintainer:SLIRP) qemu-devel@nongnu.org (open list:All patches CC here) (see also https://wiki.qemu.org/Contribute/SubmitAPatch) -- Marc-André Lureau
[Qemu-devel] [PATCH] socket: fix blocking udp recvfrom.
Sometimes sorecvfrom() is called from slirp.c because revents == G_IO_IN,
however inside sorecvfrom() function, ioctlsocket() returns 0 bytes available
and recvfrom could be blocking indefinitely. This adds a non-blocking flag to
recvfrom and checks data availability.
---
slirp/socket.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/slirp/socket.c b/slirp/socket.c
index c01d8696af..ea30478ce6 100644
--- a/slirp/socket.c
+++ b/slirp/socket.c
@@ -581,7 +581,7 @@ sorecvfrom(struct socket *so)
}
/* } */
- m->m_len = recvfrom(so->s, m->m_data, len, 0,
+ m->m_len = recvfrom(so->s, m->m_data, len, MSG_DONTWAIT,
(struct sockaddr *), );
DEBUG_MISC((dfd, " did recvfrom %d, errno = %d-%s\n",
m->m_len, errno,strerror(errno)));
@@ -618,6 +618,8 @@ sorecvfrom(struct socket *so)
break;
}
m_free(m);
+ } else if (m->m_len==0) {
+ m_free(m);
} else {
/*
* Hack: domain name lookup will be used the most for UDP,
--
2.20.1
Re: [Qemu-devel] [RFC PATCH 3/4] hw/arm/virt: Enable pc-dimm hotplug support
> -Original Message-
> From: Igor Mammedov [mailto:imamm...@redhat.com]
> Sent: 27 February 2019 17:14
> To: Shameerali Kolothum Thodi
> Cc: eric.au...@redhat.com; shannon.zha...@gmail.com;
> peter.mayd...@linaro.org; qemu-devel@nongnu.org; qemu-...@nongnu.org;
> Linuxarm ; xuwei (O)
> Subject: Re: [Qemu-devel] [RFC PATCH 3/4] hw/arm/virt: Enable pc-dimm
> hotplug support
>
> On Mon, 28 Jan 2019 11:05:45 +
> Shameer Kolothum wrote:
>
> > pc-dimm memory hotplug is enabled using GPIO(Pin 2) based ACPI
> > event. Hot removal functionality is not yet supported.
> >
> > Signed-off-by: Shameer Kolothum
> > ---
> > hw/arm/virt.c | 57
> +++--
> > 1 file changed, 55 insertions(+), 2 deletions(-)
> >
> > diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> > index 884960d..cf64554 100644
> > --- a/hw/arm/virt.c
> > +++ b/hw/arm/virt.c
> > @@ -62,6 +62,7 @@
> > #include "hw/mem/pc-dimm.h"
> > #include "hw/mem/nvdimm.h"
> > #include "hw/acpi/acpi.h"
> > +#include "hw/acpi/pc-hotplug.h"
> >
> > #define DEFINE_VIRT_MACHINE_LATEST(major, minor, latest) \
> > static void virt_##major##_##minor##_class_init(ObjectClass *oc, \
> > @@ -1651,7 +1652,14 @@ static void machvirt_init(MachineState
> *machine)
> > nvdimm_init_acpi_state(acpi_nvdimm_state, sysmem,
> > vms->fw_cfg, OBJECT(vms));
> > }
> > +if (vms->acpi_memhp_state.is_enabled) {
> > +MemHotplugState *state = >acpi_memhp_state;
> > +hwaddr base;
> >
> > +state->hw_reduced_acpi = true;
> > +base = vms->memmap[VIRT_ACPI_IO].base +
> ACPI_MEMORY_HOTPLUG_BASE;
> > +acpi_memory_hotplug_init(sysmem, OBJECT(vms), state, base);
> > +}
> this hunk should be a part of 'acpi' device that owns respective interrupts
> and
> mmio regions.
> (something like we do in x86)
> In this case I'd suggest to make 'base' its property and the board will set it
> during
> device creation.
Ok. I will take a look at x86.
> > vms->bootinfo.ram_size = machine->ram_size;
> > vms->bootinfo.kernel_filename = machine->kernel_filename;
> > vms->bootinfo.kernel_cmdline = machine->kernel_cmdline;
> > @@ -1819,6 +1827,20 @@ static void virt_set_nvdimm_persistence(Object
> *obj, const char *value,
> > nvdimm_state->persistence_string = g_strdup(value);
> > }
> >
> > +static bool virt_get_memhp_support(Object *obj, Error **errp)
> > +{
> > +VirtMachineState *vms = VIRT_MACHINE(obj);
> > +
> > +return vms->acpi_memhp_state.is_enabled;
> > +}
> > +
> > +static void virt_set_memhp_support(Object *obj, bool value, Error **errp)
> > +{
> > +VirtMachineState *vms = VIRT_MACHINE(obj);
> > +
> > +vms->acpi_memhp_state.is_enabled = value;
> > +}
> > +
> > static CpuInstanceProperties
> > virt_cpu_index_to_props(MachineState *ms, unsigned cpu_index)
> > {
> > @@ -1863,8 +1885,8 @@ static void virt_memory_pre_plug(HotplugHandler
> *hotplug_dev, DeviceState *dev,
> > const bool is_nvdimm = object_dynamic_cast(OBJECT(dev),
> TYPE_NVDIMM);
> > VirtMachineState *vms = VIRT_MACHINE(hotplug_dev);
> >
> > -if (dev->hotplugged) {
> > -error_setg(errp, "memory hotplug is not supported");
> > +if (dev->hotplugged && is_nvdimm) {
> > +error_setg(errp, "nvdimm hotplug is not supported");
> > }
> >
> > if (is_nvdimm && !vms->acpi_nvdimm_state.is_enabled) {
> > @@ -1875,6 +1897,22 @@ static void
> virt_memory_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev,
> > pc_dimm_pre_plug(PC_DIMM(dev), MACHINE(hotplug_dev), NULL,
> errp);
> > }
> >
> > +static void virt_memhp_send_event(HotplugHandler *hotplug_dev,
> DeviceState *dev,
> > + Error **errp)
> > +{
> > +DeviceState *gpio_dev;
> > +VirtMachineState *vms = VIRT_MACHINE(hotplug_dev);
> > +
> > +gpio_dev = virt_get_gpio_dev(GPIO_PCDIMM);
> > +if (!gpio_dev) {
> > +error_setg(errp, "No dev interface to send hotplug event");
> ^^ confusing
Ok. I think this will anyway change with AcpiDeviceIfClass implementation.
> > +return;
> > +}
> > +acpi_memory_plug_cb(hotplug_dev, >acpi_memhp_state,
> > +dev, errp);
> > +qemu_set_irq(qdev_get_gpio_in(gpio_dev, 0), 1);
> > +}
> > +
> > static void virt_memory_plug(HotplugHandler *hotplug_dev,
> > DeviceState *dev, Error **errp)
> > {
> > @@ -1891,6 +1929,10 @@ static void virt_memory_plug(HotplugHandler
> *hotplug_dev,
> > nvdimm_plug(>acpi_nvdimm_state);
> > }
> >
> > +if (dev->hotplugged && !is_nvdimm) {
> > +virt_memhp_send_event(hotplug_dev, dev, errp);
> ...
> acpi_memory_plug_cb();
> hotplug_handler_plug(HOTPLUG_HANDLER(pcms->gpio_dev), dev,
> _abort);
> forward snd process hotplug notification event in gpio_dev,
>machine should not care about which and how to deal
[Qemu-devel] [PULL 00/13] MAINTAINERS, test and m68k
Hi Peter, the following changes since commit adf2e451f357e993f173ba9b4176dbf3e65fee7e: Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging (2019-02-26 19:04:47 +) are available in the git repository at: https://gitlab.com/huth/qemu.git tags/pull-request-2019-02-28 for you to fetch changes up to 9f04e1d9547224a935778c1935c605d607299070: hw/m68k/mcf5208: Support loading of bios images (2019-02-28 12:18:18 +0100) - Updates to MAINTAINERS file - Re-enable the guest-agent test - Add the possibility to load a bios image on the mcf5208evb machine Philippe Mathieu-Daudé (10): MAINTAINERS: Add missing entries for the sun4u machines MAINTAINERS: Add missing entries for the PC machines MAINTAINERS: Add missing entries for the QObject section MAINTAINERS: Add missing test entries to the Cryptography section MAINTAINERS: Add an entry for the Dino machine MAINTAINERS: Add maintainer to the POSIX subsystem MAINTAINERS: Orphanize the 'GDB stub' subsystem MAINTAINERS: Add maintainers to the Linux subsystem MAINTAINERS: Add maintainer to the TCG/i386 subsystem tests/test-qga: Reenable guest-agent qtest Thomas Huth (3): MAINTAINERS: Add some missing entries for the sun4m machine MAINTAINERS: Clean up the RISC-V TCG backend section hw/m68k/mcf5208: Support loading of bios images MAINTAINERS| 53 ++ hw/m68k/mcf5208.c | 30 +++- tests/Makefile.include | 2 +- 3 files changed, 71 insertions(+), 14 deletions(-)
[Qemu-devel] [PULL 01/13] MAINTAINERS: Add missing entries for the sun4u machines
From: Philippe Mathieu-Daudé Reviewed-by: Mark Cave-Ayland Signed-off-by: Philippe Mathieu-Daudé Signed-off-by: Thomas Huth --- MAINTAINERS | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 8f9f9d7..22e0293 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1100,9 +1100,13 @@ Sun4u M: Mark Cave-Ayland S: Maintained F: hw/sparc64/sun4u.c -F: pc-bios/openbios-sparc64 +F: hw/sparc64/sun4u_iommu.c +F: include/hw/sparc/sun4u_iommu.h F: hw/pci-host/sabre.c F: include/hw/pci-host/sabre.h +F: hw/pci-bridge/simba.c +F: include/hw/pci-bridge/simba.h +F: pc-bios/openbios-sparc64 Sun4v M: Artyom Tarasenko -- 1.8.3.1
Re: [Qemu-devel] [PULL v2 0/3] NBD patches for 2019-02-25
On Tue, 26 Feb 2019 at 16:56, Eric Blake wrote: > > The following changes since commit d88d85f1f0625d57e9f354aa0874c4c8b5d1fb47: > > Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' > into staging (2019-02-25 17:28:04 +) > > are available in the Git repository at: > > https://repo.or.cz/qemu/ericb.git tags/pull-nbd-2019-02-25-v2 > > for you to fetch changes up to 3e6f45446b11ccc20b4b751f70331f03d70369b8: > > iotests: avoid broken pipe with certtool (2019-02-26 10:45:37 -0600) > > (v2: pull in Andrey's v3 python patch per last-minute list emails) > > > nbd patches for 2019-02-25 > > - iotest failure fixes for tests related to NBD > > Applied, thanks. Please update the changelog at https://wiki.qemu.org/ChangeLog/4.0 for any user-visible changes. -- PMM
Re: [Qemu-devel] [PATCH v2 1/4] block/dirty-bitmaps: add inconsistent bit
On 2/28/19 4:13 AM, Vladimir Sementsov-Ogievskiy wrote: > +++ b/qapi/block-core.json > @@ -470,12 +470,16 @@ > # @persistent: true if the bitmap will eventually be flushed to > persistent > # storage (since 4.0) >>> >>> so, bitmap can't be inconsistent and persistent, as we don't want to flush >>> inconsistent bitmaps... >>> >> >> I think ideally I'd just change this phrasing to say something like >> "true if the bitmap is stored on-disk, or is scheduled to be flushed to >> disk." > > And such wording leads to immediate question: why it could be stored on disk > but > _not_ scheduled to be flushed.. > > So if you want, more honest is something like "true if bitmap will be flushed > to > storage or if it is @inconsistent (read ahead)." but it's not looking nice... > > May be something like this? > > true if bitmap is marked to be flushed to persistent storage. Bitmap may or > may not > already persist in the storage. Also true if bitmap persist in the storage but > considered inconsistent, in which case it will not be flushed and only may be > removed, > look at @inconsistent field description. Too long. As @inconsistent is rare, I'd be happy with just: @persistent: true if the bitmap is marked for association with persistent storage which covers both future flushes (for a bitmap that is not yet on disk, but will get there later) and prior inconsistent images (where we learned that it was inconsistent because of its existing associate with persistent storage). > > Another thing: what about migration? I don't think we are going to teach > migration protocol > to migrate them. So, migration is a way to get rid of inconsistent bitmaps? > Or what? Or > we should restrict migration, if there are any inconsistent bitmap, to force > user to remove > them first? A conservative approach is to start by treating an inconsistent bitmap as a migration blocker, and could be relaxed later if someone has an argument for why making migration a backdoor for deletion of inconsistent bitmaps is a good thing. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
Re: [Qemu-devel] [PATCH] Added periodic IRQ support for bcm2836_control local timer
Hi Andrew, That's great news, I'll then bring those drivers up to the modern qemu API! Maybe that's a Linux kernel module configuration issue as well, but with the BCM System Timer small delays depend on polling the counter. Without the qemu support that counter register remains zero, causing an endless loop. TBH it was years ago when I last checked raspbian, but I know for sure that many bare metal applications and libraries (like https://github.com/rsta2/circle) fails to boot because of this, and the community is very excited to have the BCM ST emulation in qemu. The PM thing is mostly for me, I'd like to reboot and shut down the vm gracefully from the guest without the semihosting hack :-) Thank you again, I'll get to work! Best wishes, bzt On 2/27/19, Andrew Baumann wrote: >> From: bzt >> Sent: Wednesday, 27 February 2019 03:54 >> >> I'd like to add more drivers for the bcm283[567] too, and this question >> goes to >> Andrew Baumann mostly. I've seen implemented those missing drivers in his >> repo, which aren't in the qemu mainline yet. I don't want to reinvent the >> wheel, >> so I'm willing to fix those classes to get them right, but I'd like to >> know what's >> wrong with them in the first place. > > Nothing's wrong with them per se, but when I was working on upstreaming the > raspi board I prioritised the device support needed to boot Linux and > Windows on raspi2. The remaining devices were always planned for eventual > inclusion, but just fell off the end of my TODO list. They never went > through code review on qemu-devel, so would probably need some work to bring > them up to modern qemu APIs and standards. > >> I'm interested in fixing the >> TYPE_BCM2835_POWER and TYPE_BCM2835_ST drivers, which I know many >> hoppy OS developers lack and would improve the raspi emulation experience >> remarkably. > > Sounds good to me! > >> It would be still a long way to boot a raspbian image, but still, a >> small step towards that goal at least. > > That's interesting. Raspbian did seem to be working (on pi2) when I last > worked on this. Perhaps it now depends on these devices, but didn't before? > > Cheers, > Andrew >
Re: [Qemu-devel] [PATCH v5] i386, acpi: check acpi_memory_hotplug capacity in pre_plug
On Thu, 28 Feb 2019 09:13:25 +0800
Wei Yang wrote:
> On Wed, Feb 27, 2019 at 07:04:02PM +0100, Igor Mammedov wrote:
> >On Mon, 25 Feb 2019 09:15:34 +0800
> >Wei Yang wrote:
> >
> >> On Mon, Feb 25, 2019 at 09:07:08AM +0800, Wei Yang wrote:
> >> >Currently we do device realization like below:
> >> >
> >> > hotplug_handler_pre_plug()
> >> > dc->realize()
> >> > hotplug_handler_plug()
> >> >
> >> >Before we do device realization and plug, we should allocate necessary
> >> >resources and check if memory-hotplug-support property is enabled.
> >> >
> >> >At the piix4 and ich9, the memory-hotplug-support property is checked at
> >> >plug stage. This means that device has been realized and mapped into guest
> >> >address space 'pc_dimm_plug()' by the time acpi plug handler is called,
> >> >where it might fail and crash QEMU due to reaching g_assert_not_reached()
> >> >(piix4) or error_abort (ich9).
> >> >
> >> >Fix it by checking if memory hotplug is enabled at pre_plug stage
> >> >where we can gracefully abort hotplug request.
> >> >
> >> >Signed-off-by: Wei Yang
> >> >CC: Igor Mammedov
> >> >CC: Eric Blake
> >> >Signed-off-by: Wei Yang
> >> >
> >> >---
> >> >v5:
> >> > * rebase on latest upstream
> >> > * remove a comment before hotplug_handler_pre_plug
> >> > * fix alignment for ich9_pm_device_pre_plug_cb
> >> >v4:
> >> > * fix code alignment of piix4_device_pre_plug_cb
> >> >v3:
> >> > * replace acpi_memory_hotplug with memory-hotplug-support in changelog
> >> > * fix code alignment of ich9_pm_device_pre_plug_cb
> >> > * print which device type memory-hotplug-support is disabled in
> >> > ich9_pm_device_pre_plug_cb and piix4_device_pre_plug_cb
> >> >v2:
> >> > * (imamm...@redhat.com)
> >> > - Almost the whole third paragraph
> >> > * apply this change to ich9
> >> > * use hotplug_handler_pre_plug() instead of open-coding check
> >> >---
> >> > hw/acpi/ich9.c | 15 +--
> >> > hw/acpi/piix4.c| 13 ++---
> >> > hw/i386/pc.c | 2 ++
> >> > hw/isa/lpc_ich9.c | 1 +
> >> > include/hw/acpi/ich9.h | 2 ++
> >> > 5 files changed, 28 insertions(+), 5 deletions(-)
> >> >
> >> >diff --git a/hw/acpi/ich9.c b/hw/acpi/ich9.c
> >> >index c5d8646abc..e53dfe1ee3 100644
> >> >--- a/hw/acpi/ich9.c
> >> >+++ b/hw/acpi/ich9.c
> >> >@@ -483,13 +483,24 @@ void ich9_pm_add_properties(Object *obj,
> >> >ICH9LPCPMRegs *pm, Error **errp)
> >> > NULL);
> >> > }
> >> >
> >> >+void ich9_pm_device_pre_plug_cb(HotplugHandler *hotplug_dev, DeviceState
> >> >*dev,
> >> >+Error **errp)
> >> >+{
> >> >+ICH9LPCState *lpc = ICH9_LPC_DEVICE(hotplug_dev);
> >> >+
> >> >+if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM) &&
> >> >+!lpc->pm.acpi_memory_hotplug.is_enabled)
> >> >+error_setg(errp,
> >> >+ "memory hotplug is not enabled:
> >> >%s.memory-hotplug-support "
> >> >+ "is not set", object_get_typename(OBJECT(lpc)));
> >> >+}
> >> >+
> >> > void ich9_pm_device_plug_cb(HotplugHandler *hotplug_dev, DeviceState
> >> > *dev,
> >> > Error **errp)
> >> > {
> >> > ICH9LPCState *lpc = ICH9_LPC_DEVICE(hotplug_dev);
> >> >
> >> >-if (lpc->pm.acpi_memory_hotplug.is_enabled &&
> >> >-object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
> >> >+if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
> >> > if (object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM)) {
> >> > nvdimm_acpi_plug_cb(hotplug_dev, dev);
> >> > } else {
> >> >diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
> >> >index df8c0db909..8b9654e437 100644
> >> >--- a/hw/acpi/piix4.c
> >> >+++ b/hw/acpi/piix4.c
> >> >@@ -374,9 +374,16 @@ static void piix4_pm_powerdown_req(Notifier *n, void
> >> >*opaque)
> >> > static void piix4_device_pre_plug_cb(HotplugHandler *hotplug_dev,
> >> > DeviceState *dev, Error **errp)
> >>
> >> Hmm, I found one interesting thing.
> >>
> >> This function is introduced in
> >>
> >> commit ec266f408882fd38475f72c4e864ed576228643b
> >> pci/pcihp: perform check for bus capability in pre_plug handler
> >>
> >> This is just implemented in piix4, but don't has the counterpart in ich9.
> >>
> >> So I suggest to have a follow up patch to create the counterpart for ich9
> >> and
> >> then apply this patch on top of that.
> >not sure what do you mean, could you be more specific?
> >
>
> Let me reply here.
>
> Everything starts from device_set_realized().
>
> device_set_realized()
>hotplug_handler_pre_plug()
>dc->realize()
>hotplug_handler_plug()
>
> There is two choice of HotplugHandler :
>
> * dev's bus hotplug_handler
> * machine_hotplug_handler
>
> Take PIIX as an example, machine_hotplug_handler and pci_bus hotplug_handler
> is:
>
> pc_machine_device_[pre_]plug_cb
>
[Qemu-devel] [Bug 1818075] Re: qemu x86 TCG doesn't support AVX insns
my guess is we're doing something unhelpful with the AVX insn, and so the guest code which is checking the result and using it as its loop condition for the jns is just looping forever in_asm log just stopped with this as the last line 0x4000b4ef4a: 79 9ejns 0x4000b4eeea -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1818075 Title: qemu x86 TCG doesn't support AVX insns Status in QEMU: New Bug description: I'm trying to execute code that has been built with -march=skylake -mtune=generic -mavx2 under qemu-user x86-64 with -cpu Skylake-Client. However this code just hangs at 100% CPU. Adding input tracing shows that it is likely hanging when dealing with an AVX instruction: warning: TCG doesn't support requested feature: CPUID.01H:ECX.fma [bit 12] warning: TCG doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17] warning: TCG doesn't support requested feature: CPUID.01H:ECX.x2apic [bit 21] warning: TCG doesn't support requested feature: CPUID.01H:ECX.tsc-deadline [bit 24] warning: TCG doesn't support requested feature: CPUID.01H:ECX.avx [bit 28] warning: TCG doesn't support requested feature: CPUID.01H:ECX.f16c [bit 29] warning: TCG doesn't support requested feature: CPUID.01H:ECX.rdrand [bit 30] warning: TCG doesn't support requested feature: CPUID.07H:EBX.hle [bit 4] warning: TCG doesn't support requested feature: CPUID.07H:EBX.avx2 [bit 5] warning: TCG doesn't support requested feature: CPUID.07H:EBX.invpcid [bit 10] warning: TCG doesn't support requested feature: CPUID.07H:EBX.rtm [bit 11] warning: TCG doesn't support requested feature: CPUID.07H:EBX.rdseed [bit 18] warning: TCG doesn't support requested feature: CPUID.8001H:ECX.3dnowprefetch [bit 8] warning: TCG doesn't support requested feature: CPUID.0DH:EAX.xsavec [bit 1] IN: 0x4000b4ef3b: c5 fb 5c ca vsubsd %xmm2, %xmm0, %xmm1 0x4000b4ef3f: c4 e1 fb 2c d1 vcvttsd2si %xmm1, %rdx 0x4000b4ef44: 4c 31 e2 xorq %r12, %rdx 0x4000b4ef47: 48 85 d2 testq%rdx, %rdx 0x4000b4ef4a: 79 9ejns 0x4000b4eeea [ hangs ] Attaching a gdb produces this stacktrace: (gdb) bt #0 canonicalize (status=0x55a20ff67a88, parm=0x55a20bb807e0 , part=...) at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/fpu/softfloat.c:350 #1 float64_unpack_canonical (s=0x55a20ff67a88, f=0) at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/fpu/softfloat.c:547 #2 float64_sub (a=0, b=4890909195324358656, status=0x55a20ff67a88) at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/fpu/softfloat.c:776 #3 0x55a20baa1949 in helper_subsd (env=, d=0x55a20ff67ad8, s=) at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/target/i386/ops_sse.h:623 #4 0x55a20cfcfea8 in static_code_gen_buffer () #5 0x55a20ba3f764 in cpu_tb_exec (itb=, cpu=0x55a20cea2180 ) at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/accel/tcg/cpu-exec.c:171 #6 cpu_loop_exec_tb (tb_exit=, last_tb=, tb=, cpu=0x55a20cea2180 ) at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/accel/tcg/cpu-exec.c:615 #7 cpu_exec (cpu=cpu@entry=0x55a20ff5f4d0) at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/accel/tcg/cpu-exec.c:725 #8 0x55a20ba6d728 in cpu_loop (env=0x55a20ff67780) at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/linux-user/x86_64/../i386/cpu_loop.c:93 #9 0x55a20ba049ff in main (argc=, argv=0x7ffc58572868, envp=) at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/linux-user/main.c:819 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1818075/+subscriptions
[Qemu-devel] [Bug 1818075] Re: qemu x86 TCG doesn't support AVX insns
Further debugging on IRC reveals that QEMU itself is not hanging, but the guest code is looping infinitely, because QEMU doesn't implement the AVX instruction set and isn't generating an undefined-instruction exception either. So the %rdx output from the AVX insn is wrong and the guest code never exits the loop (whose condition depends on %rdx). We should ideally: * make the x86 decoder properly handle insns that don't exist for the CPU being emulated (not too difficult, but doesn't actually help in running this test program) * implement AVX (a fair chunk of effort; it is being proposed as a GSoC project for this summer) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1818075 Title: qemu x86 TCG doesn't support AVX insns Status in QEMU: New Bug description: I'm trying to execute code that has been built with -march=skylake -mtune=generic -mavx2 under qemu-user x86-64 with -cpu Skylake-Client. However this code just hangs at 100% CPU. Adding input tracing shows that it is likely hanging when dealing with an AVX instruction: warning: TCG doesn't support requested feature: CPUID.01H:ECX.fma [bit 12] warning: TCG doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17] warning: TCG doesn't support requested feature: CPUID.01H:ECX.x2apic [bit 21] warning: TCG doesn't support requested feature: CPUID.01H:ECX.tsc-deadline [bit 24] warning: TCG doesn't support requested feature: CPUID.01H:ECX.avx [bit 28] warning: TCG doesn't support requested feature: CPUID.01H:ECX.f16c [bit 29] warning: TCG doesn't support requested feature: CPUID.01H:ECX.rdrand [bit 30] warning: TCG doesn't support requested feature: CPUID.07H:EBX.hle [bit 4] warning: TCG doesn't support requested feature: CPUID.07H:EBX.avx2 [bit 5] warning: TCG doesn't support requested feature: CPUID.07H:EBX.invpcid [bit 10] warning: TCG doesn't support requested feature: CPUID.07H:EBX.rtm [bit 11] warning: TCG doesn't support requested feature: CPUID.07H:EBX.rdseed [bit 18] warning: TCG doesn't support requested feature: CPUID.8001H:ECX.3dnowprefetch [bit 8] warning: TCG doesn't support requested feature: CPUID.0DH:EAX.xsavec [bit 1] IN: 0x4000b4ef3b: c5 fb 5c ca vsubsd %xmm2, %xmm0, %xmm1 0x4000b4ef3f: c4 e1 fb 2c d1 vcvttsd2si %xmm1, %rdx 0x4000b4ef44: 4c 31 e2 xorq %r12, %rdx 0x4000b4ef47: 48 85 d2 testq%rdx, %rdx 0x4000b4ef4a: 79 9ejns 0x4000b4eeea [ hangs ] Attaching a gdb produces this stacktrace: (gdb) bt #0 canonicalize (status=0x55a20ff67a88, parm=0x55a20bb807e0 , part=...) at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/fpu/softfloat.c:350 #1 float64_unpack_canonical (s=0x55a20ff67a88, f=0) at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/fpu/softfloat.c:547 #2 float64_sub (a=0, b=4890909195324358656, status=0x55a20ff67a88) at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/fpu/softfloat.c:776 #3 0x55a20baa1949 in helper_subsd (env=, d=0x55a20ff67ad8, s=) at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/target/i386/ops_sse.h:623 #4 0x55a20cfcfea8 in static_code_gen_buffer () #5 0x55a20ba3f764 in cpu_tb_exec (itb=, cpu=0x55a20cea2180 ) at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/accel/tcg/cpu-exec.c:171 #6 cpu_loop_exec_tb (tb_exit=, last_tb=, tb=, cpu=0x55a20cea2180 ) at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/accel/tcg/cpu-exec.c:615 #7 cpu_exec (cpu=cpu@entry=0x55a20ff5f4d0) at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/accel/tcg/cpu-exec.c:725 #8 0x55a20ba6d728 in cpu_loop (env=0x55a20ff67780) at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/linux-user/x86_64/../i386/cpu_loop.c:93 #9 0x55a20ba049ff in main (argc=, argv=0x7ffc58572868, envp=) at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/linux-user/main.c:819 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1818075/+subscriptions
[Qemu-devel] [RFC v2 2/3] intel_iommu: add 256 bits qi_desc support
From: "Liu, Yi L"
Per Intel(R) VT-d 3.0, the qi_desc is 256 bits in Scalable
Mode. This patch adds emulation of 256bits qi_desc.
Signed-off-by: Liu, Yi L
[Yi Sun is co-developer to rebase and refine the patch.]
Signed-off-by: Yi Sun
---
v2:
- modify s-o-b position.
- remove unnecessary macros.
- change 'iq_dw' type to bool.
- remove initialization to 'inv_desc->val[]'.
- modify 'VTDInvDesc' to add a union 'val[4]' to be compatible
with both legacy mode and scalable mode.
---
hw/i386/intel_iommu.c | 40 +---
hw/i386/intel_iommu_internal.h | 9 -
include/hw/i386/intel_iommu.h | 1 +
3 files changed, 38 insertions(+), 12 deletions(-)
diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
index 109fdbc..d1eb0c5 100644
--- a/hw/i386/intel_iommu.c
+++ b/hw/i386/intel_iommu.c
@@ -2028,7 +2028,7 @@ static void vtd_handle_gcmd_qie(IntelIOMMUState *s, bool
en)
if (en) {
s->iq = iqa_val & VTD_IQA_IQA_MASK(s->aw_bits);
/* 2^(x+8) entries */
-s->iq_size = 1UL << ((iqa_val & VTD_IQA_QS) + 8);
+s->iq_size = 1UL << ((iqa_val & VTD_IQA_QS) + 8 - (s->iq_dw ? 1 : 0));
s->qi_enabled = true;
trace_vtd_inv_qi_setup(s->iq, s->iq_size);
/* Ok - report back to driver */
@@ -2195,19 +2195,24 @@ static void vtd_handle_iotlb_write(IntelIOMMUState *s)
}
/* Fetch an Invalidation Descriptor from the Invalidation Queue */
-static bool vtd_get_inv_desc(dma_addr_t base_addr, uint32_t offset,
+static bool vtd_get_inv_desc(IntelIOMMUState *s,
VTDInvDesc *inv_desc)
{
-dma_addr_t addr = base_addr + offset * sizeof(*inv_desc);
-if (dma_memory_read(_space_memory, addr, inv_desc,
-sizeof(*inv_desc))) {
-error_report_once("Read INV DESC failed");
-inv_desc->lo = 0;
-inv_desc->hi = 0;
+dma_addr_t base_addr = s->iq;
+uint32_t offset = s->iq_head;
+uint32_t dw = s->iq_dw ? 32 : 16;
+dma_addr_t addr = base_addr + offset * dw;
+
+if (dma_memory_read(_space_memory, addr, inv_desc, dw)) {
+error_report_once("Read INV DESC failed.");
return false;
}
inv_desc->lo = le64_to_cpu(inv_desc->lo);
inv_desc->hi = le64_to_cpu(inv_desc->hi);
+if (dw == 32) {
+inv_desc->val[2] = le64_to_cpu(inv_desc->val[2]);
+inv_desc->val[3] = le64_to_cpu(inv_desc->val[3]);
+}
return true;
}
@@ -2413,10 +2418,11 @@ static bool vtd_process_inv_desc(IntelIOMMUState *s)
uint8_t desc_type;
trace_vtd_inv_qi_head(s->iq_head);
-if (!vtd_get_inv_desc(s->iq, s->iq_head, _desc)) {
+if (!vtd_get_inv_desc(s, _desc)) {
s->iq_last_desc_type = VTD_INV_DESC_NONE;
return false;
}
+
desc_type = inv_desc.lo & VTD_INV_DESC_TYPE;
/* FIXME: should update at first or at last? */
s->iq_last_desc_type = desc_type;
@@ -2501,7 +2507,12 @@ static void vtd_handle_iqt_write(IntelIOMMUState *s)
{
uint64_t val = vtd_get_quad_raw(s, DMAR_IQT_REG);
-s->iq_tail = VTD_IQT_QT(val);
+if (s->iq_dw && val & VTD_IQT_QT_256_RSV_BIT) {
+error_report_once("%s: RSV bit is set: val=0x%"PRIx64,
+ __func__, val);
+return;
+}
+s->iq_tail = VTD_IQT_QT(s->iq_dw, val);
trace_vtd_inv_qi_tail(s->iq_tail);
if (s->qi_enabled && !(vtd_get_long_raw(s, DMAR_FSTS_REG) & VTD_FSTS_IQE))
{
@@ -2770,6 +2781,12 @@ static void vtd_mem_write(void *opaque, hwaddr addr,
} else {
vtd_set_quad(s, addr, val);
}
+if (s->ecap & VTD_ECAP_SMTS &&
+val & VTD_IQA_DW_MASK) {
+s->iq_dw = true;
+} else {
+s->iq_dw = false;
+}
break;
case DMAR_IQA_REG_HI:
@@ -3477,6 +3494,7 @@ static void vtd_init(IntelIOMMUState *s)
s->iq_size = 0;
s->qi_enabled = false;
s->iq_last_desc_type = VTD_INV_DESC_NONE;
+s->iq_dw = false;
s->next_frcd_reg = 0;
s->cap = VTD_CAP_FRO | VTD_CAP_NFR | VTD_CAP_ND |
VTD_CAP_MAMV | VTD_CAP_PSI | VTD_CAP_SLLPS |
@@ -3554,7 +3572,7 @@ static void vtd_init(IntelIOMMUState *s)
vtd_define_quad(s, DMAR_IQH_REG, 0, 0, 0);
vtd_define_quad(s, DMAR_IQT_REG, 0, 0x7fff0ULL, 0);
-vtd_define_quad(s, DMAR_IQA_REG, 0, 0xf007ULL, 0);
+vtd_define_quad(s, DMAR_IQA_REG, 0, 0xf807ULL, 0);
vtd_define_long(s, DMAR_ICS_REG, 0, 0, 0x1UL);
vtd_define_long(s, DMAR_IECTL_REG, 0x8000UL, 0x8000UL, 0);
vtd_define_long(s, DMAR_IEDATA_REG, 0, 0xUL, 0);
diff --git a/hw/i386/intel_iommu_internal.h b/hw/i386/intel_iommu_internal.h
index fe72bc3..016fa4c 100644
--- a/hw/i386/intel_iommu_internal.h
+++ b/hw/i386/intel_iommu_internal.h
@@ -190,6 +190,7 @@
#define VTD_ECAP_EIM(1ULL << 4)
#define VTD_ECAP_PT (1ULL << 6)
#define VTD_ECAP_MHMV (15ULL << 20)
+#define
[Qemu-devel] [Bug 1818075] Re: qemu x86 TCG doesn't support AVX insns
** Summary changed: - qemu-user-x86-64 hangs at vcvttsd2si + qemu x86 TCG doesn't support AVX insns -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1818075 Title: qemu x86 TCG doesn't support AVX insns Status in QEMU: New Bug description: I'm trying to execute code that has been built with -march=skylake -mtune=generic -mavx2 under qemu-user x86-64 with -cpu Skylake-Client. However this code just hangs at 100% CPU. Adding input tracing shows that it is likely hanging when dealing with an AVX instruction: warning: TCG doesn't support requested feature: CPUID.01H:ECX.fma [bit 12] warning: TCG doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17] warning: TCG doesn't support requested feature: CPUID.01H:ECX.x2apic [bit 21] warning: TCG doesn't support requested feature: CPUID.01H:ECX.tsc-deadline [bit 24] warning: TCG doesn't support requested feature: CPUID.01H:ECX.avx [bit 28] warning: TCG doesn't support requested feature: CPUID.01H:ECX.f16c [bit 29] warning: TCG doesn't support requested feature: CPUID.01H:ECX.rdrand [bit 30] warning: TCG doesn't support requested feature: CPUID.07H:EBX.hle [bit 4] warning: TCG doesn't support requested feature: CPUID.07H:EBX.avx2 [bit 5] warning: TCG doesn't support requested feature: CPUID.07H:EBX.invpcid [bit 10] warning: TCG doesn't support requested feature: CPUID.07H:EBX.rtm [bit 11] warning: TCG doesn't support requested feature: CPUID.07H:EBX.rdseed [bit 18] warning: TCG doesn't support requested feature: CPUID.8001H:ECX.3dnowprefetch [bit 8] warning: TCG doesn't support requested feature: CPUID.0DH:EAX.xsavec [bit 1] IN: 0x4000b4ef3b: c5 fb 5c ca vsubsd %xmm2, %xmm0, %xmm1 0x4000b4ef3f: c4 e1 fb 2c d1 vcvttsd2si %xmm1, %rdx 0x4000b4ef44: 4c 31 e2 xorq %r12, %rdx 0x4000b4ef47: 48 85 d2 testq%rdx, %rdx 0x4000b4ef4a: 79 9ejns 0x4000b4eeea [ hangs ] Attaching a gdb produces this stacktrace: (gdb) bt #0 canonicalize (status=0x55a20ff67a88, parm=0x55a20bb807e0 , part=...) at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/fpu/softfloat.c:350 #1 float64_unpack_canonical (s=0x55a20ff67a88, f=0) at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/fpu/softfloat.c:547 #2 float64_sub (a=0, b=4890909195324358656, status=0x55a20ff67a88) at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/fpu/softfloat.c:776 #3 0x55a20baa1949 in helper_subsd (env=, d=0x55a20ff67ad8, s=) at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/target/i386/ops_sse.h:623 #4 0x55a20cfcfea8 in static_code_gen_buffer () #5 0x55a20ba3f764 in cpu_tb_exec (itb=, cpu=0x55a20cea2180 ) at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/accel/tcg/cpu-exec.c:171 #6 cpu_loop_exec_tb (tb_exit=, last_tb=, tb=, cpu=0x55a20cea2180 ) at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/accel/tcg/cpu-exec.c:615 #7 cpu_exec (cpu=cpu@entry=0x55a20ff5f4d0) at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/accel/tcg/cpu-exec.c:725 #8 0x55a20ba6d728 in cpu_loop (env=0x55a20ff67780) at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/linux-user/x86_64/../i386/cpu_loop.c:93 #9 0x55a20ba049ff in main (argc=, argv=0x7ffc58572868, envp=) at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/linux-user/main.c:819 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1818075/+subscriptions
[Qemu-devel] [PATCH v2 01/11] docs/cpu-hotplug.rst: Fix rST markup issues
sphinx-build complains:
docs/cpu-hotplug.rst:67: ERROR: Unexpected indentation.
docs/cpu-hotplug.rst:69: ERROR: Unexpected indentation.
docs/cpu-hotplug.rst:74: WARNING: Block quote ends without a blank line;
unexpected unindent.
docs/cpu-hotplug.rst:75: WARNING: Block quote ends without a blank line;
unexpected unindent.
docs/cpu-hotplug.rst:76: SEVERE: Unexpected section title.
}
{
docs/cpu-hotplug.rst:78: WARNING: Block quote ends without a blank line;
unexpected unindent.
These are the result of not indicating one of the literal
blocks by finishing the preceding paragraph with the "::" marker.
Signed-off-by: Peter Maydell
Reviewed-by: Alex Bennée
---
docs/cpu-hotplug.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/cpu-hotplug.rst b/docs/cpu-hotplug.rst
index 1c268e00b41..e2d4e893b01 100644
--- a/docs/cpu-hotplug.rst
+++ b/docs/cpu-hotplug.rst
@@ -60,7 +60,7 @@ vCPU hotplug
hot-plugged (no "qom-path" member). From its output in step (3), we
can see that ``IvyBridge-IBRS-x86_64-cpu`` is present in socket 0,
while hot-plugging a CPU into socket 1 requires passing the listed
-properties to QMP ``device_add``:
+properties to QMP ``device_add``::
(QEMU) device_add id=cpu-2 driver=IvyBridge-IBRS-x86_64-cpu socket-id=1
core-id=0 thread-id=0
{
--
2.20.1
[Qemu-devel] [PATCH v10 06/10] vl: Set machine ram_size, maxram_size and ram_slots earlier
The machine RAM attributes will need to be analyzed during the configure_accelerator() process. especially kvm_type() arm64 machine callback will use them to know how many IPA/GPA bits are needed to model the whole RAM range. So let's assign those machine state fields before calling configure_accelerator. Signed-off-by: Eric Auger Reviewed-by: Peter Maydell Reviewed-by: Igor Mammedov --- v7 -> v8: - added Igor's R-b v6 -> v7: - add Peter's R-b v4: new --- vl.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/vl.c b/vl.c index 502857a176..fd0d51320d 100644 --- a/vl.c +++ b/vl.c @@ -4239,6 +4239,9 @@ int main(int argc, char **argv, char **envp) machine_opts = qemu_get_machine_opts(); qemu_opt_foreach(machine_opts, machine_set_property, current_machine, _fatal); +current_machine->ram_size = ram_size; +current_machine->maxram_size = maxram_size; +current_machine->ram_slots = ram_slots; configure_accelerator(current_machine, argv[0]); @@ -4434,9 +4437,6 @@ int main(int argc, char **argv, char **envp) replay_checkpoint(CHECKPOINT_INIT); qdev_machine_init(); -current_machine->ram_size = ram_size; -current_machine->maxram_size = maxram_size; -current_machine->ram_slots = ram_slots; current_machine->boot_order = boot_order; /* parse features once if machine provides default cpu_type */ -- 2.20.1
