date:20201125

From: Olaf Hering 

Since meson.git#0240d760c7699a059cc89e584363c6431cdd2b61 setuptools is not 
required anymore.

Signed-off-by: Olaf Hering 
Reviewed-by: Thomas Huth 
Message-Id: <20201124211925.4194-1-o...@aepfle.de>
Signed-off-by: Paolo Bonzini 
---
 configure | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/configure b/configure
index 796cec14de..18c26e0389 100755
--- a/configure
+++ b/configure
@@ -1912,9 +1912,6 @@ fi
 
 case "$meson" in
 git | internal)
-if ! $python -c 'import pkg_resources' > /dev/null 2>&1; then
-error_exit "Python setuptools not found"
-fi
 meson="$python ${source_path}/meson/meson.py"
 ;;
 *) meson=$(command -v "$meson") ;;
-- 
2.26.2

[RFC PATCH 2/2] spapr: nvdimm: Implement async flush hcalls

2020-11-25 Thread Shivaprasad G Bhat

When the persistent memory beacked by a file, a cpu cache flush instruction
is not sufficient to ensure the stores are correctly flushed to the media.

The patch implements the async hcalls for flush operation on demand from the
guest kernel.

The device option sync-dax is by default off and enables explicit asynchronous
flush requests from guest. It can be disabled by setting syn-dax=on.

Signed-off-by: Shivaprasad G Bhat 
---
 hw/mem/nvdimm.c |1 +
 hw/ppc/spapr_nvdimm.c   |   79 +++
 include/hw/mem/nvdimm.h |   10 ++
 include/hw/ppc/spapr.h  |3 +-
 4 files changed, 92 insertions(+), 1 deletion(-)

diff --git a/hw/mem/nvdimm.c b/hw/mem/nvdimm.c
index 03c2201b56..37a4db0135 100644
--- a/hw/mem/nvdimm.c
+++ b/hw/mem/nvdimm.c
@@ -220,6 +220,7 @@ static void nvdimm_write_label_data(NVDIMMDevice *nvdimm, 
const void *buf,
 
 static Property nvdimm_properties[] = {
 DEFINE_PROP_BOOL(NVDIMM_UNARMED_PROP, NVDIMMDevice, unarmed, false),
+DEFINE_PROP_BOOL(NVDIMM_SYNC_DAX_PROP, NVDIMMDevice, sync_dax, false),
 DEFINE_PROP_END_OF_LIST(),
 };
 
diff --git a/hw/ppc/spapr_nvdimm.c b/hw/ppc/spapr_nvdimm.c
index a833a63b5e..557e36aa98 100644
--- a/hw/ppc/spapr_nvdimm.c
+++ b/hw/ppc/spapr_nvdimm.c
@@ -22,6 +22,7 @@
  * THE SOFTWARE.
  */
 #include "qemu/osdep.h"
+#include "qemu/cutils.h"
 #include "qapi/error.h"
 #include "hw/ppc/spapr_drc.h"
 #include "hw/ppc/spapr_nvdimm.h"
@@ -155,6 +156,11 @@ static int spapr_dt_nvdimm(SpaprMachineState *spapr, void 
*fdt,
  "operating-system")));
 _FDT(fdt_setprop(fdt, child_offset, "ibm,cache-flush-required", NULL, 0));
 
+if (!nvdimm->sync_dax) {
+_FDT(fdt_setprop(fdt, child_offset, "ibm,async-flush-required",
+ NULL, 0));
+}
+
 return child_offset;
 }
 
@@ -370,6 +376,78 @@ static target_ulong h_scm_bind_mem(PowerPCCPU *cpu, 
SpaprMachineState *spapr,
 return H_SUCCESS;
 }
 
+typedef struct SCMAsyncFlushData {
+int fd;
+uint64_t token;
+} SCMAsyncFlushData;
+
+static int flush_worker_cb(void *opaque)
+{
+int ret = H_SUCCESS;
+SCMAsyncFlushData *req_data = opaque;
+
+/* flush raw backing image */
+if (qemu_fdatasync(req_data->fd) < 0) {
+error_report("papr_scm: Could not sync nvdimm to backend file: %s",
+ strerror(errno));
+ret = H_HARDWARE;
+}
+
+g_free(req_data);
+
+return ret;
+}
+
+static target_ulong h_scm_async_flush(PowerPCCPU *cpu, SpaprMachineState 
*spapr,
+  target_ulong opcode, target_ulong *args)
+{
+int ret;
+uint32_t drc_index = args[0];
+uint64_t continue_token = args[1];
+SpaprDrc *drc = spapr_drc_by_index(drc_index);
+PCDIMMDevice *dimm;
+HostMemoryBackend *backend = NULL;
+SCMAsyncFlushData *req_data = NULL;
+
+if (!drc || !drc->dev ||
+spapr_drc_type(drc) != SPAPR_DR_CONNECTOR_TYPE_PMEM) {
+return H_PARAMETER;
+}
+
+if (continue_token != 0) {
+ret = spapr_drc_get_async_hcall_status(drc, continue_token);
+if (ret == H_BUSY) {
+args[0] = continue_token;
+return H_LONG_BUSY_ORDER_1_SEC;
+}
+
+return ret;
+}
+
+dimm = PC_DIMM(drc->dev);
+backend = MEMORY_BACKEND(dimm->hostmem);
+
+req_data = g_malloc0(sizeof(SCMAsyncFlushData));
+req_data->fd = memory_region_get_fd(>mr);
+
+continue_token = spapr_drc_get_new_async_hcall_token(drc);
+if (!continue_token) {
+g_free(req_data);
+return H_P2;
+}
+req_data->token = continue_token;
+
+spapr_drc_run_async_hcall(drc, continue_token, _worker_cb, req_data);
+
+ret = spapr_drc_get_async_hcall_status(drc, continue_token);
+if (ret == H_BUSY) {
+args[0] = req_data->token;
+return ret;
+}
+
+return ret;
+}
+
 static target_ulong h_scm_unbind_mem(PowerPCCPU *cpu, SpaprMachineState *spapr,
  target_ulong opcode, target_ulong *args)
 {
@@ -486,6 +564,7 @@ static void spapr_scm_register_types(void)
 spapr_register_hypercall(H_SCM_BIND_MEM, h_scm_bind_mem);
 spapr_register_hypercall(H_SCM_UNBIND_MEM, h_scm_unbind_mem);
 spapr_register_hypercall(H_SCM_UNBIND_ALL, h_scm_unbind_all);
+spapr_register_hypercall(H_SCM_ASYNC_FLUSH, h_scm_async_flush);
 }
 
 type_init(spapr_scm_register_types)
diff --git a/include/hw/mem/nvdimm.h b/include/hw/mem/nvdimm.h
index c699842dd0..9e8795766e 100644
--- a/include/hw/mem/nvdimm.h
+++ b/include/hw/mem/nvdimm.h
@@ -51,6 +51,7 @@ OBJECT_DECLARE_TYPE(NVDIMMDevice, NVDIMMClass, NVDIMM)
 #define NVDIMM_LABEL_SIZE_PROP "label-size"
 #define NVDIMM_UUID_PROP   "uuid"
 #define NVDIMM_UNARMED_PROP"unarmed"
+#define NVDIMM_SYNC_DAX_PROP"sync-dax"
 
 struct NVDIMMDevice {
 /* private */
@@ -85,6 +86,15 @@ struct NVDIMMDevice {
  */
 bool unarmed;
 
+/*
+ * On PPC64,
+ *

[RFC PATCH 1/2] spapr: drc: Add support for async hcalls at the drc level

2020-11-25 Thread Shivaprasad G Bhat

The patch adds support for async hcalls at the DRC level for the
spapr devices. To be used by spapr-scm devices in the patch/es to follow.

Signed-off-by: Shivaprasad G Bhat 
---
 hw/ppc/spapr_drc.c |  146 
 include/hw/ppc/spapr_drc.h |   25 
 2 files changed, 171 insertions(+)

diff --git a/hw/ppc/spapr_drc.c b/hw/ppc/spapr_drc.c
index 77718cde1f..2cecccf701 100644
--- a/hw/ppc/spapr_drc.c
+++ b/hw/ppc/spapr_drc.c
@@ -15,6 +15,7 @@
 #include "qapi/qmp/qnull.h"
 #include "cpu.h"
 #include "qemu/cutils.h"
+#include "qemu/guest-random.h"
 #include "hw/ppc/spapr_drc.h"
 #include "qom/object.h"
 #include "migration/vmstate.h"
@@ -421,6 +422,145 @@ void spapr_drc_detach(SpaprDrc *drc)
 spapr_drc_release(drc);
 }
 
+
+/*
+ * @drc : device DRC targetting which the async hcalls to be made.
+ *
+ * All subsequent requests to run/query the status should use the
+ * unique token returned here.
+ */
+uint64_t spapr_drc_get_new_async_hcall_token(SpaprDrc *drc)
+{
+Error *err = NULL;
+uint64_t token;
+SpaprDrcDeviceAsyncHCallState *tmp, *next, *state;
+
+state = g_malloc0(sizeof(*state));
+state->pending = true;
+
+qemu_mutex_lock(>async_hcall_states_lock);
+retry:
+if (qemu_guest_getrandom(, sizeof(token), ) < 0) {
+error_report_err(err);
+g_free(state);
+return 0;
+}
+
+if (!token) /* Token should be non-zero */
+goto retry;
+
+if (!QLIST_EMPTY(>async_hcall_states)) {
+QLIST_FOREACH_SAFE(tmp, >async_hcall_states, node, next) {
+if (tmp->continue_token == token) {
+/* If the token already in use, get a new one */
+goto retry;
+}
+}
+}
+
+state->continue_token = token;
+QLIST_INSERT_HEAD(>async_hcall_states, state, node);
+
+qemu_mutex_unlock(>async_hcall_states_lock);
+
+return state->continue_token;
+}
+
+static void *spapr_drc_async_hcall_runner(void *opaque)
+{
+int response = -1;
+SpaprDrcDeviceAsyncHCallState *state = opaque;
+
+/*
+ * state is freed only after this thread finishes(after pthread_join()),
+ * don't worry about it becoming NULL.
+ */
+
+response = state->func(state->data);
+
+state->hcall_ret = response;
+state->pending = 0;
+
+return NULL;
+}
+
+/*
+ * @drc  : device DRC targetting which the async hcalls to be made.
+ * token : The continue token to be used for tracking as recived from
+ * spapr_drc_get_new_async_hcall_token
+ * @func() : the worker function which needs to be executed asynchronously
+ * @data : data to be passed to the asynchronous function. Worker is supposed
+ * to free/cleanup the data that is passed here
+ */
+void spapr_drc_run_async_hcall(SpaprDrc *drc, uint64_t token,
+   SpaprDrcAsyncHcallWorkerFunc *func, void *data)
+{
+SpaprDrcDeviceAsyncHCallState *state, *next;
+
+qemu_mutex_lock(>async_hcall_states_lock);
+QLIST_FOREACH_SAFE(state, >async_hcall_states, node, next) {
+if (state->continue_token == token) {
+state->func = func;
+state->data = data;
+qemu_thread_create(>thread, "sPAPR Async HCALL",
+   spapr_drc_async_hcall_runner, state,
+   QEMU_THREAD_JOINABLE);
+break;
+}
+}
+qemu_mutex_unlock(>async_hcall_states_lock);
+}
+
+/*
+ * spapr_drc_finish_async_hcalls
+ *  Waits for all pending async requests to complete
+ *  thier execution and free the states
+ */
+static void spapr_drc_finish_async_hcalls(SpaprDrc *drc)
+{
+SpaprDrcDeviceAsyncHCallState *state, *next;
+
+if (QLIST_EMPTY(>async_hcall_states)) {
+return;
+}
+
+QLIST_FOREACH_SAFE(state, >async_hcall_states, node, next) {
+qemu_thread_join(>thread);
+QLIST_REMOVE(state, node);
+g_free(state);
+}
+}
+
+/*
+ * spapr_drc_get_async_hcall_status
+ *  Fetches the status of the hcall worker and returns H_BUSY
+ *  if the worker is still running.
+ */
+int spapr_drc_get_async_hcall_status(SpaprDrc *drc, uint64_t token)
+{
+int ret = H_PARAMETER;
+SpaprDrcDeviceAsyncHCallState *state, *node;
+
+qemu_mutex_lock(>async_hcall_states_lock);
+QLIST_FOREACH_SAFE(state, >async_hcall_states, node, node) {
+if (state->continue_token == token) {
+if (state->pending) {
+ret = H_BUSY;
+break;
+} else {
+ret = state->hcall_ret;
+qemu_thread_join(>thread);
+QLIST_REMOVE(state, node);
+g_free(state);
+break;
+}
+}
+}
+qemu_mutex_unlock(>async_hcall_states_lock);
+
+return ret;
+}
+
 void spapr_drc_reset(SpaprDrc *drc)
 {
 SpaprDrcClass *drck = SPAPR_DR_CONNECTOR_GET_CLASS(drc);
@@ -448,6 +588,7 @@ void spapr_drc_reset(SpaprDrc

[RFC PATCH 0/2] spapr: scm: Asynchronus flush hcall support

2020-11-25 Thread Shivaprasad G Bhat

The nvdimm devices are expected to ensure write persistent during power
failure kind of scenarios.

The libpmem has architecture specific instructions like dcbf on power
to flush the cache data to backend nvdimm device during normal writes.

Qemu - virtual nvdimm devices are memory mapped. The dcbf in the guest
doesn't traslate to actual flush to the backend file on the host in case
of file backed vnvdimms. This is addressed by virtio-pmem in case of x86_64
by making asynchronous flushes.

On PAPR, issue is addressed by adding a new hcall to
request for an explicit asynchronous flush requests from the guest ndctl
driver when the backend nvdimm cannot ensure write persistence with dcbf
alone. So, the approach here is to convey when the asynchronous flush is
required in a device tree property. The guest makes the hcall when the
property is found, instead of relying on dcbf.

The first patch adds the necessary asynchronous hcall support infrastructure
code at the DRC level. Second patch implements the hcall using the
infrastructure.

Hcall semantics are in review and not final.

A new device property sync-dax is added to the nvdimm device. When the sync-dax 
is off(default),
the asynchronous hcalls will be called.

With respect to save from new qemu to restore on old qemu, having the
sync-dax by default off(when not specified) causes IO errors in guests as
the async-hcall would not be supported on old qemu. The new hcall
implementation being supported only on the new  pseries machine version,
the current machine version checks may be to prevent sufficient to prevent
such migration. Please suggest what can be done.

The below demonstration shows the map_sync behavior with sync-dax on & off.
(https://github.com/avocado-framework-tests/avocado-misc-tests/blob/master/memory/ndctl.py.data/map_sync.c)

The pmem0 is from nvdimm with With sync-dax=on, and pmem1 is from nvdimm with 
syn-dax=off, mounted as
/dev/pmem0 on /mnt1 type xfs 
(rw,relatime,attr2,dax=always,inode64,logbufs=8,logbsize=32k,noquota)
/dev/pmem1 on /mnt2 type xfs 
(rw,relatime,attr2,dax=always,inode64,logbufs=8,logbsize=32k,noquota)

[root@atest-guest ~]# ./mapsync /mnt1/newfile> When sync-dax=off
[root@atest-guest ~]# ./mapsync /mnt2/newfile> when sync-dax=on
Failed to mmap  with Operation not supported

---

Shivaprasad G Bhat (2):
  spapr: drc: Add support for async hcalls at the drc level
  spapr: nvdimm: Implement async flush hcalls


 hw/mem/nvdimm.c|1
 hw/ppc/spapr_drc.c |  146 
 hw/ppc/spapr_nvdimm.c  |   79 
 include/hw/mem/nvdimm.h|   10 +++
 include/hw/ppc/spapr.h |3 +
 include/hw/ppc/spapr_drc.h |   25 
 6 files changed, 263 insertions(+), 1 deletion(-)

--
Signature

Re: [PATCH] linux-user/mmap.c: check range of mremap result in target address space

2020-11-25 Thread Laurent Vivier

Le 28/10/2020 à 22:38, Tobias Koch a écrit :
> If mremap succeeds, an additional check is performed to ensure that the
> new address range fits into the target address space. This check was
> previously perfomed in host address space, with the upper bound fixed to
> abi_ulong.
> 
> This patch replaces the static check with a call to `guest_range_valid`,
> performing the range check against the actual size of the target address
> space. It also moves the corresponding block to prevent it from being
> called incorrectly when the mapping itself fails.
> 
> Signed-off-by: Tobias Koch 
> ---
>  linux-user/mmap.c | 21 -
>  1 file changed, 12 insertions(+), 9 deletions(-)
> 
> diff --git a/linux-user/mmap.c b/linux-user/mmap.c
> index f261563420..101bd013a1 100644
> --- a/linux-user/mmap.c
> +++ b/linux-user/mmap.c
> @@ -751,20 +751,23 @@ abi_long target_mremap(abi_ulong old_addr, abi_ulong 
> old_size,
>  }
>  if (prot == 0) {
>  host_addr = mremap(g2h(old_addr), old_size, new_size, flags);
> -if (host_addr != MAP_FAILED && reserved_va && old_size > 
> new_size) {
> -mmap_reserve(old_addr + old_size, old_size - new_size);
> +
> +if (host_addr != MAP_FAILED) {
> +/* Check if address fits target address space */
> +if (!guest_range_valid(h2g(host_addr), new_size)) {
> +/* Revert mremap() changes */
> +host_addr = mremap(g2h(old_addr), new_size, old_size,
> +   flags);
> +errno = ENOMEM;
> +host_addr = MAP_FAILED;
> +} else if (reserved_va && old_size > new_size) {
> +mmap_reserve(old_addr + old_size, old_size - new_size);
> +}
>  }
>  } else {
>  errno = ENOMEM;
>  host_addr = MAP_FAILED;
>  }
> -/* Check if address fits target address space */
> -if ((unsigned long)host_addr + new_size > (abi_ulong)-1) {
> -/* Revert mremap() changes */
> -host_addr = mremap(g2h(old_addr), new_size, old_size, flags);
> -errno = ENOMEM;
> -host_addr = MAP_FAILED;
> -}
>  }
>  
>  if (host_addr == MAP_FAILED) {
> 

Reviewed-by: Laurent Vivier

[PATCH] vnc: Fix a memleak in vnc_display_connect()

2020-11-25 Thread Alex Chen

Free the 'sioc' when the qio_channel_socket_connect_sync() fails.

Reported-by: Euler Robot 
Signed-off-by: Alex Chen 
---
 ui/vnc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/ui/vnc.c b/ui/vnc.c
index 49235056f7..dae56e9493 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -3743,6 +3743,7 @@ static int vnc_display_connect(VncDisplay *vd,
 sioc = qio_channel_socket_new();
 qio_channel_set_name(QIO_CHANNEL(sioc), "vnc-reverse");
 if (qio_channel_socket_connect_sync(sioc, saddr[0], errp) < 0) {
+object_unref(OBJECT(sioc));
 return -1;
 }
 vnc_connect(vd, sioc, false, false);
-- 
2.19.1

Re: [PATCH for-6.0 2/8] spapr/xive: Introduce spapr_xive_nr_ends()

2020-11-25 Thread Cédric Le Goater

>> why ? we would stop claiming IPIs in spapr_irq_init() and so
>> they won't appear as being valid anymore, at boot time or
>> restore time.
>>
> 
> If we don't claim the IPIs in spapr_irq_init() anymore then
> we must at least claim them on the path of H_INT_GET_SOURCE_INFO
> otherwise it will fail with H_P2 and the guest won't even
> try to setup the IPI. 

IPIs could be handled a special case as we know in which range 
they are.

> Even if we do that, we still have a
> window where the source is valid in QEMU but not yet at
> the KVM level.

May be some kind of lazy binding with KVM would help us.

The problem is that the guest ESB pages won't be backed by HW 
pages which could lead to a crash. We could overlap the emulated 
one until we are bound to KVM. Just a thought.

C.

Re: [PATCH RFC] vfio: Move the saving of the config space to the right place in VFIO migration

2020-11-25 Thread Shenming Lu

Hi,

After reading everyone's opinions, we have a rough idea for this issue.

One key point is whether it is necessary to setup the config space before
the device can accept further migration data. I think it is decided by
the vendor driver, so we can simply ask the vendor driver about it in
.save_setup, which could avoid a lot of unnecessary copies and settings.
Once we have known the need, we can iterate the config space (before)
along with the device migration data in .save_live_iterate and
.save_live_complete_precopy, and if not needed, we can only migrate the
config space in .save_state.

Another key point is that the interrupt enabling should be after the
restoring of the interrupt controller (might not only interrupts).
My solution is to add a subflag at the beginning of the config data
(right after VFIO_MIG_FLAG_DEV_CONFIG_STATE) to indicate the triggered
actions on the dst (such as whether to enable interrupts).

Below is it's workflow.

On the save path:
In vfio_save_setup():
Ask the vendor driver if it needs the config space setup before it
can accept further migration data.
|
In vfio_save_iterate() (pre-copy):
If *needed*, save the config space which would be setup on the dst
before the migration data, but send with a subflag to instruct not
to (such as) enable interrupts.
|
In vfio_save_complete_precopy() (stop-and-copy, iterable process):
The same as that in vfio_save_iterate().
|
In .save_state (stop-and-copy, non-iterable process):
If *needed*, only send a subflag to instruct to enable interrupts.
If *not needed*, save the config space and setup everything on the dst.

Besides the above idea, we might be able to choose to let the vendor driver do
more: qemu just sends and writes the config data (before) along with the device
migration data every time, and it's up to the vendor driver to filter out/buffer
the received data or reorder the settings...

Thanks,
Shenming

Re: [RFC PATCH 18/25] hw/cxl/device: Add a memory device (8.2.8.5)

2020-11-25 Thread Markus Armbruster

Ben Widawsky  writes:

> On 20-11-13 08:47:59, Markus Armbruster wrote:
>> Eric Blake  writes:
>> 
>> > On 11/10/20 11:47 PM, Ben Widawsky wrote:
>> >> A CXL memory device (AKA Type 3) is a CXL component that contains some
>> >> combination of volatile and persistent memory. It also implements the
>> >> previously defined mailbox interface as well as the memory device
>> >> firmware interface.
>> >> 
>> >> The following example will create a 256M device in a 512M window:
>> >> 
>> >> -object 
>> >> "memory-backend-file,id=cxl-mem1,share,mem-path=cxl-type3,size=512M"
>> >> -device "cxl-type3,bus=rp0,memdev=cxl-mem1,id=cxl-pmem0,size=256M"
>> >> 
>> >> Signed-off-by: Ben Widawsky 
>> >> ---
>> >
>> >> +++ b/qapi/machine.json
>> >> @@ -1394,6 +1394,7 @@
>> >>  { 'union': 'MemoryDeviceInfo',
>> >>'data': { 'dimm': 'PCDIMMDeviceInfo',
>> >>  'nvdimm': 'PCDIMMDeviceInfo',
>> >> +'cxl': 'PCDIMMDeviceInfo',
>> >>  'virtio-pmem': 'VirtioPMEMDeviceInfo',
>> >>  'virtio-mem': 'VirtioMEMDeviceInfo'
>> >>}
>> >
>> > Missing documentation of the new data type, and the fact that it will be
>> > introduced in 6.0.
>> 
>> Old wish list item: improve the QAPI schema frontend to flag this.
>> 
>
> "Introduced in 6.0" - quite the optimist. Kidding aside, this is the area 
> where
> I could use some feedback. CXL Type 3 memory devices can contain both volatile
> and persistent memory at the same time. As such, I think I'll need a new type 
> to
> represent that, but I'd love to know how best to accomplish that.

We can help.  Tell us what information you want to provide in variant
'cxl'.  If it's a superset of an existing variant, give us just the
delta.

>> > Also, Markus has been trying to get rid of so-called
>> > "simple unions" in favor of "flat unions" - every time we modify an
>> > existing simple union, it is worth asking if it is time to first flatten
>> > this.
>> 
>> 0. Simple unions can be transformed into flat unions.  The
>> transformation can either preserve the nested wire format, or flatten
>> it.  See docs/devel/qapi-code-gen.txt "A simple union can always be
>> re-written as a flat union ..."
>> 
>> 1. No new simple unions.
>> 
>> 2. Existing simple unions that can be flattened without breaking
>> backward compatibility have long been flattened.
>> 
>> 3. The remaining simple unions are part of QMP, where we need to
>> preserve the wire format.  We could turn them into flat union preserving
>> the wire format.  Only worthwhile if we kill simple unions and simplify
>> scripts/qapi/.  Opportunity to make the flat union syntax less
>> cumbersome.  Not done due to lack of time.
>> 
>> 4. Kevin and I have been experimenting with ways to provide both flat
>> and nested wire format.  This would pave the way for orderly deprecation
>> of the nested wire format.  May not be practical for QMP output.
>> 
>
> So is there anything for me to do here?

No.  Extending an existing simple union is okay.

We should not add news ones.  We should think twice before we add new
uses of existing ones.

Re: [PATCH for-6.0 4/9] spapr: Set compat mode in spapr_reset_vcpu()

2020-11-25 Thread David Gibson

On Wed, Nov 25, 2020 at 10:51:05AM +0100, Greg Kurz wrote:
> On Wed, 25 Nov 2020 13:39:47 +1100
> David Gibson  wrote:
> 
> > On Mon, Nov 23, 2020 at 12:51:08PM +0100, Greg Kurz wrote:
> > > On Mon, 23 Nov 2020 16:11:30 +1100
> > > David Gibson  wrote:
> > > 
> > > > On Sat, Nov 21, 2020 at 12:42:03AM +0100, Greg Kurz wrote:
> > > > > When it comes to resetting the compat mode of the vCPUS, there are
> > > > > two situations to consider:
> > > > > (1) machine reset should set the compat mode back to the machine 
> > > > > default,
> > > > > ie. spapr->max_compat_pvr
> > > > > (2) hot plugged vCPUs should set their compat mode to mach the boot 
> > > > > vCPU,
> > > > > ie. POWERPC_CPU(first_cpu)->compat_pvr
> > > > > 
> > > > > This is currently handled in two separate places: globally for all 
> > > > > vCPUs
> > > > > from the machine reset code for (1) and for each thread of a core from
> > > > > the hotplug path for (2).
> > > > > 
> > > > > Since the machine reset code already resets all vCPUs, starting with 
> > > > > boot
> > > > > vCPU, consolidate the logic in spapr_reset_vcpu(). Special case the 
> > > > > boot
> > > > > vCPU so that it resets its compat mode back to the machine default. 
> > > > > Any
> > > > > other vCPU just need to match the compat mode of the boot vCPU.
> > > > > 
> > > > > Failing to set the compat mode during machine reset is a fatal error,
> > > > > but not for hot plugged vCPUs. This is arguable because if we've been
> > > > > able to set the boot vCPU compat mode at CAS or during machine reset,
> > > > > it should definitely not fail for other vCPUs. Since 
> > > > > spapr_reset_vcpu()
> > > > > already has a fatal error path for kvm_check_mmu() failures, do the
> > > > > same for ppc_set_compat().
> > > > > 
> > > > > This gets rid of an error path in spapr_core_plug(). It will allow
> > > > > further simplifications.
> > > > > 
> > > > > Signed-off-by: Greg Kurz 
> > > > > ---
> > > > >  hw/ppc/spapr.c  | 16 
> > > > >  hw/ppc/spapr_cpu_core.c | 13 +
> > > > >  2 files changed, 13 insertions(+), 16 deletions(-)
> > > > > 
> > > > > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> > > > > index f58f77389e8e..da7586f548df 100644
> > > > > --- a/hw/ppc/spapr.c
> > > > > +++ b/hw/ppc/spapr.c
> > > > > @@ -1606,8 +1606,6 @@ static void spapr_machine_reset(MachineState 
> > > > > *machine)
> > > > >  spapr_ovec_cleanup(spapr->ov5_cas);
> > > > >  spapr->ov5_cas = spapr_ovec_new();
> > > > >  
> > > > > -ppc_set_compat_all(spapr->max_compat_pvr, _fatal);
> > > > > -
> > > > >  /*
> > > > >   * This is fixing some of the default configuration of the XIVE
> > > > >   * devices. To be called after the reset of the machine devices.
> > > > > @@ -3785,20 +3783,6 @@ static void spapr_core_plug(HotplugHandler 
> > > > > *hotplug_dev, DeviceState *dev,
> > > > >  
> > > > >  core_slot->cpu = OBJECT(dev);
> > > > >  
> > > > > -/*
> > > > > - * Set compatibility mode to match the boot CPU, which was 
> > > > > either set
> > > > > - * by the machine reset code or by CAS.
> > > > > - */
> > > > > -if (hotplugged) {
> > > > > -for (i = 0; i < cc->nr_threads; i++) {
> > > > > -if (ppc_set_compat(core->threads[i],
> > > > > -   POWERPC_CPU(first_cpu)->compat_pvr,
> > > > > -   errp) < 0) {
> > > > > -return;
> > > > > -}
> > > > > -}
> > > > > -}
> > > > > -
> > > > >  if (smc->pre_2_10_has_unused_icps) {
> > > > >  for (i = 0; i < cc->nr_threads; i++) {
> > > > >  cs = CPU(core->threads[i]);
> > > > > diff --git a/hw/ppc/spapr_cpu_core.c b/hw/ppc/spapr_cpu_core.c
> > > > > index 2f7dc3c23ded..17741a3fb77f 100644
> > > > > --- a/hw/ppc/spapr_cpu_core.c
> > > > > +++ b/hw/ppc/spapr_cpu_core.c
> > > > > @@ -27,6 +27,7 @@
> > > > >  
> > > > >  static void spapr_reset_vcpu(PowerPCCPU *cpu)
> > > > >  {
> > > > > +PowerPCCPU *first_ppc_cpu = POWERPC_CPU(first_cpu);
> > > > >  CPUState *cs = CPU(cpu);
> > > > >  CPUPPCState *env = >env;
> > > > >  PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu);
> > > > > @@ -69,6 +70,18 @@ static void spapr_reset_vcpu(PowerPCCPU *cpu)
> > > > >  kvm_check_mmu(cpu, _fatal);
> > > > >  
> > > > >  spapr_irq_cpu_intc_reset(spapr, cpu);
> > > > > +
> > > > > +/*
> > > > > + * The boot CPU is only reset during machine reset : reset its
> > > > > + * compatibility mode to the machine default. For other CPUs,
> > > > > + * either cold plugged or hot plugged, set the compatibility mode
> > > > > + * to match the boot CPU, which was either set by the machine 
> > > > > reset
> > > > > + * code or by CAS.
> > > > > + */
> > > > > +ppc_set_compat(cpu,
> > > > > +   cpu == first_ppc_cpu ?
> > > > > +   spapr->max_compat_pvr : first_ppc_cpu->compat_pvr,
>

[Bug 1719870] Re: Converting 100G VHDX fixed image to QCOW2 fails

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

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

Title:
  Converting 100G VHDX fixed image to QCOW2 fails

Status in QEMU:
  Expired

Bug description:
  Virtual Size recognized incorrectly for VHDX fixed disk and conversion
  fails with error Expression: !qiov || bytes == qiov->size


  PS > & 'C:\Program Files\qemu\qemu-img.exe' --version
  qemu-img version 2.10.0 (v2.10.0-11669-g579e69bd5b-dirty)
  Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers

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

[Bug 1713825] Re: Booting Windows 2016 with qxl video crashes qemu

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

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

Title:
  Booting Windows 2016 with qxl video crashes qemu

Status in QEMU:
  Expired

Bug description:
  launched from libvirt.

  qemu version: 2.9.0
  host: Linux  4.9.34-gentoo #1 SMP Sat Jul 29 13:28:43 PDT 2017 
x86_64 Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz GenuineIntel GNU/Linux
  guest: Windows 2016 64 bit

  Thread 28 (Thread 0x7f0e2edff700 (LWP 29860)):
  #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
  set = {__val = {18446744067266837079, 139698892694944, 
139699853745096, 139700858749789, 4222451712, 139694281220640, 139694281220741, 
139694281220640, 139694281220640, 139694281220810, 
  139694281220940, 139694281220640, 139694281220940, 0, 0, 0}}
  pid = 
  tid = 
  #1  0x7f0ea40b644a in __GI_abort () at abort.c:89
  save_stage = 2
  act = {__sigaction_handler = {sa_handler = 0x7f0e2edfe5c0, 
sa_sigaction = 0x7f0e2edfe5c0}, sa_mask = {__val = {139694281219872, 
139698106269697, 139698892695344, 4, 2676511744, 0, 139698892695144, 0, 
139698892694912, 1, 4737316546111099904, 139700859888720, 
4737316546111099904, 139700862161824, 139700911349760, 94211934977482}}, 
sa_flags = 416, 
sa_restorer = 0x55af6ceb0500 <__PRETTY_FUNCTION__.36381>}
  sigs = {__val = {32, 0 }}
  #2  0x7f0ea40abab6 in __assert_fail_base (fmt=, 
assertion=assertion@entry=0x55af6ceafdca "offset < qxl->vga.vram_size", 
  file=file@entry=0x55af6ceaeaa0 
"/var/tmp/portage/app-emulation/qemu-2.9.0-r2/work/qemu-2.9.0/hw/display/qxl.c",
 line=line@entry=416, 
  function=function@entry=0x55af6ceb0500 <__PRETTY_FUNCTION__.36381> 
"qxl_ram_set_dirty") at assert.c:92
  str = 0x7f0d1c026220 "\340r\002\034\r\177"
  total = 4096
  #3  0x7f0ea40abb81 in __GI___assert_fail 
(assertion=assertion@entry=0x55af6ceafdca "offset < qxl->vga.vram_size", 
  file=file@entry=0x55af6ceaeaa0 
"/var/tmp/portage/app-emulation/qemu-2.9.0-r2/work/qemu-2.9.0/hw/display/qxl.c",
 line=line@entry=416, 
  function=function@entry=0x55af6ceb0500 <__PRETTY_FUNCTION__.36381> 
"qxl_ram_set_dirty") at assert.c:101
  No locals.
  #4  0x55af6cc58805 in qxl_ram_set_dirty (qxl=, 
ptr=) at 
/var/tmp/portage/app-emulation/qemu-2.9.0-r2/work/qemu-2.9.0/hw/display/qxl.c:416
  base = 
  offset = 
  qxl = 
  ptr = 
  base = 
  offset = 
  #5  0x55af6cc5b9e2 in interface_release_resource (sin=0x55af71a91ed0, 
ext=...) at 
/var/tmp/portage/app-emulation/qemu-2.9.0-r2/work/qemu-2.9.0/hw/display/qxl.c:767
  qxl = 0x55af71a91450
  ring = 
  item = 
  id = 18446690739814400920
  __func__ = "interface_release_resource"
  #6  0x7f0ea510afa8 in red_drawable_unref (red_drawable=0x7f0d1c026120) at 
red-worker.c:101
  No locals.
  #7  0x7f0ea510b609 in red_drawable_unref (red_drawable=) 
at red-worker.c:104
  No locals.
  #8  0x7f0ea510eae9 in drawable_unref 
(drawable=drawable@entry=0x7f0e68285ac0) at display-channel.c:1438
  display = 0x55af71dbd3c0
  __FUNCTION__ = "drawable_unref"
  #9  0x7f0ea51109f7 in draw_until (display=display@entry=0x55af71dbd3c0, 
surface=surface@entry=0x7f0e6828aae8, last=0x7f0e68285ac0) at 
display-channel.c:1637
  container = 0x0
  now = 0x7f0e68285ac0
  #10 0x7f0ea510f93f in display_channel_draw (display=0x55af71dbd3c0, 
area=0x7f0e2edfe8e0, surface_id=) at display-channel.c:1729
  surface = 0x7f0e6828aae8
  last = 
  __FUNCTION__ = "display_channel_draw"
  __func__ = "display_channel_draw"

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

[Bug 1721952] Re: Network issue above 2.5.1.1

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

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

Title:
  Network issue above 2.5.1.1

Status in QEMU:
  Expired

Bug description:
  Hi,
  WHen running a QEMU guest (Windows7) on a linux x86-64 server, the network 
stops working after some time for any version above 2.5.1.1

  In 2.5.1.1, all is fine (no issue with network)
  Any version ablve (trying 2.10.1 now), the application in windows stops 
accessing the internet after a while

  THis is my starting line:
  /usr/bin/qemu-system-x86_64 -machine pc-i440fx-1.7,accel=kvm -usb -usbdevice 
tablet -usbdevice keyboard -enable-kvm -cpu core2duo -smp 2 -drive 
file=winpro.qcow,index=0,media=disk,format=qco
  w2 -m 4096 -vga vmware -vnc :3 -k en-us -device e1000,netdev=nic1 -netdev 
user,id=nic1,smb=/data/vps/files/,hostfwd=tcp::10053-:10053,hostfwd=tcp::3387-:3389
 -rtc base=utc,clock=host -daemon
  ize

  Thisis my configure line:
  ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --enable-kvm 
--disable-gtk --disable-xen --disable-user --enable-vnc-sasl --disable-libusb 
--disable-debug-info --disable-spi
  ce --enable-lzo --enable-pie --disable-werror --enable-linux-aio 
--enable-vhost-net --disable-tcmalloc --enable-vde --enable-nettle 
--disable-smartcard --enable-curl

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

[Bug 1779650] Re: The display stays black after waking up a domain via SPICE with a QXL card

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

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

Title:
  The display stays black after waking up a domain via SPICE with a QXL
  card

Status in QEMU:
  Expired

Bug description:
  As the title says, in a jessie VM, waking up a VM via the spice remote
  view works with a VGA graphic card. With a QXL card though, the domain
  wakes up but the display stays black (the keyboard is working though).

  Qemu: Master, 281bd281222776229d5dbf84d1a5c6d8d9d2a34b

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

[Bug 1776760] Re: Loading from a saved state results in blue screen due to qxl_dod driver

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

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

Title:
  Loading from a saved state results in blue screen due to qxl_dod
  driver

Status in QEMU:
  Expired

Bug description:
  Versions:
  Arch Linux (kernel 4.16.13)
  Qemu 2.12
  libvirt 4.3.0
  Windows 10 1803 latest updates installed under libvirt management
  Spice tools 0.132
  QXL DOD driver 0.18 (from redhat server)

  Steps to reproduce:
  1. Boot Windows (xml is attached)
  2. Save VM state through libvirt interface
  3. Restore VM state through libvirt interface

  Result:
  Blue screen. Previously, the result was high CPU usage and a black screen, 
nonresponsive VM; I could only force shut down or force reset it.

  The blue screen mentioned the qxl DOD driver as the culprit, the
  created minidump shows "SYSTEM_THREAD_EXCEPTION_NOT_HANDLED" as error.
  I can provide the memory.dmp file if it's at all helpful (it's around
  250 MB in size).

  libvirt domain logs for the above actions:
  2018-06-13 18:59:49.913+: starting up libvirt version: 4.3.0, qemu 
version: 2.12.0, hostname: arch-vaio.localdomain
  LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin QEMU_AUDIO_DRV=spice 
/usr/bin/qemu-system-x86_64 -name guest=Windows,debug-threads=on -S -object 
secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-4-Windows/master-key.aes
 -machine pc-i440fx-2.7,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu 
Nehalem,vme=on,ss=on,pcid=on,x2apic=on,tsc-deadline=on,hypervisor=on,arat=on,tsc_adjust=on,rdtscp=on,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff
 -m 2048 -realtime mlock=off -smp 4,sockets=1,cores=2,threads=2 -uuid 
f14684d3-5f81-4743-8512-e516d85ca2c9 -no-user-config -nodefaults -chardev 
socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-4-Windows/monitor.sock,server,nowait
 -mon chardev=charmonitor,id=monitor,mode=control -rtc 
base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet 
-no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot 
strict=on -device nec-usb-xhci,id=usb,bus=pci.0,addr=0x6 -device 
virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive 
file=/mnt/media/Qemu/windows10.qcow2,format=qcow2,if=none,id=drive-virtio-disk0 
-device 
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
 -drive 
file=/usr/share/spice-guest-tools/spice-guest-tools.iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on
 -device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 -netdev 
user,id=hostnet0 -device 
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:44:08:31,bus=pci.0,addr=0x3 
-chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 
-chardev spicevmc,id=charchannel0,name=vdagent -device 
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0
 -device usb-tablet,id=input2,bus=usb.0,port=3 -spice 
port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on
 -device 
qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2
 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device 
hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev 
spicevmc,id=charredir0,name=usbredir -device 
usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=1 -chardev 
spicevmc,id=charredir1,name=usbredir -device 
usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=2 -device 
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -sandbox 
on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg 
timestamp=on
  2018-06-13T18:59:50.018852Z qemu-system-x86_64: -chardev pty,id=charserial0: 
char device redirected to /dev/pts/6 (label charserial0)
  main_channel_link: add main channel client
  inputs_connect: inputs channel client create
  red_qxl_set_cursor_peer: 
  main_channel_handle_message: agent start
  main_channel_handle_message: agent start
  main_channel_handle_message: agent start
  main_channel_handle_message: agent start
  main_channel_handle_message: agent start
  main_channel_handle_message: agent start
  main_channel_handle_message: agent start
  2018-06-13 20:28:19.077+: shutting down, reason=saved
  2018-06-13T20:28:19.118226Z qemu-system-x86_64: terminating on signal 15 from 
pid 457 (/usr/bin/libvirtd)
  red_channel_client_disconnect: rcc=0x7f7eaa3d8a30 (channel=0x7f7eaa34d300 
type=5 id=0)
  red_channel_client_disconnect: rcc=0x7f7e22bf04b0 (channel=0x7f7eaa34d3c0 
type=6 id=0)
  red_channel_client_disconnect: rcc=0x7f7e22bd89b0 (channel=0x7f7e214599a0 
type=9 id=0)
  red_channel_client_disconnect: rcc=0x7f7eaa3de270 (channel=0x7f7e21459a70 
type=9 id=1)
  2018-06-13 20:29:04.933+: starting up libvirt version:

[Bug 1722857] Re: Missing PCI "programming interface" ID emulation for USB host controllers

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

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

Title:
  Missing PCI "programming interface" ID emulation for USB host
  controllers

Status in QEMU:
  Expired

Bug description:
  Qemu doesn't currently emulate the correct value of the "register
  level programming interface" field in the PCI config space of USB host
  controllers. As a result, some guest operating systems (most notably
  Windows) fail to load e.g. generic xHCI drivers, and instead ask for a
  vendor-specific driver, which may not be always available.

  Example: "-device nec-usb-xhci" emulates a Renesas (formerly NEC)
  uPD720202 xHCI controller. However, in the PCI config space, it shows
  us as class 0C, subclass 03, prog-if 00 (UHCI) where as the real
  uPD720202 (and all real xHCI controllers) have prog-if 30 (xHCI). A
  Windows guest booted with this option will not recognize devices
  attached to the XHCI controller unless drivers from Renesas are
  manually installed first, even though recent Windows versions include
  a generic xHCI driver that works perfectly well with real uPD720202
  hardware.

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

[Bug 1905651] Re: Tests cannot call g_error

2020-11-25 Thread Doug Evans

An alternative is of course to allow g_error to be called.
One might restrict tests to not call it, but it might be impractical to impose 
that on all code that goes into a test.
One will need to find a way to get glib to not call G_BREAKPOINT for this case.

  if (debugger_present && breakpoint)
G_BREAKPOINT ();
  else
g_abort ();

https://gitlab.gnome.org/GNOME/glib/-/blob/master/glib/gmessages.c#L555

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

Title:
  Tests cannot call g_error

Status in QEMU:
  New

Bug description:
  I stumbled on this writing a new test, using tests/qtest/e1000e-test.c
  as a template.

  g_error() causes SIGTRAP, not SIGABRT, and thus the abort handler doesn't get 
run.
  This in turn means qemu is not killed, which hangs the test because the 
tap-driver.pl script hangs waiting for more input.
  There are a few tests that call g_error().

  The SIGABRT handler explicitly kills qemu, e.g.:

  qos-test.c:
  qtest_add_abrt_handler(kill_qemu_hook_func, s);

  ref:
  
https://git.qemu.org/?p=qemu.git;a=blob;f=tests/qtest/libqtest.c;h=e49f3a1e45f4cd96279241fdb2bbe231029ab922;hb=HEAD#l272

  But not unexpectedly there's no such handler for SIGTRAP.

  Apply this patch to trigger a repro:

  diff --git a/tests/qtest/e1000e-test.c b/tests/qtest/e1000e-test.c
  index fc226fdfeb..e83ace1b5c 100644
  --- a/tests/qtest/e1000e-test.c
  +++ b/tests/qtest/e1000e-test.c
  @@ -87,6 +87,9 @@ static void e1000e_send_verify(QE1000E *d, int 
*test_sockets, QGuestAllocator *a
   /* Wait for TX WB interrupt */
   e1000e_wait_isr(d, E1000E_TX0_MSG_ID);

  +g_message("Test g_error hang ...");
  +g_error("Pretend something timed out");
  +
   /* Check DD bit */
   g_assert_cmphex(le32_to_cpu(descr.upper.data) & dsta_dd, ==, dsta_dd);

  Then:

  configure
  make
  make check-qtest-i386

  check-qtest-i386 will take awhile. To repro faster:

  $ grep qtest-i386/qos-test Makefile.mtest
  .test.name.229 := qtest-i386/qos-test
  $ make run-test-229
  Running test qtest-i386/qos-test
  ** Message: 18:40:49.821: Test g_error hang ...

  ** (tests/qtest/qos-test:3820728): ERROR **: 18:40:49.821: Pretend something 
timed out
  ERROR qtest-i386/qos-test - Bail out! FATAL-ERROR: Pretend something timed out

  At this point things are hung because tap-driver.pl is still waiting
  for input because qemu is still running.

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

[PATCH] Add an announcement about the 2020 QEMU advent calendar and a call for images to include.

2020-11-25 Thread Eldon Stegall

Signed-off-by: Eldon Stegall 
---
 _posts/2020-11-26-qemu-advent-announce.md | 39 +++
 1 file changed, 39 insertions(+)
 create mode 100644 _posts/2020-11-26-qemu-advent-announce.md

diff --git a/_posts/2020-11-26-qemu-advent-announce.md 
b/_posts/2020-11-26-qemu-advent-announce.md
new file mode 100644
index 000..06c0e45
--- /dev/null
+++ b/_posts/2020-11-26-qemu-advent-announce.md
@@ -0,0 +1,39 @@
+---
+layout: post
+title:  "QEMU Advent Calendar 2020 Announcement and Call for Images"
+date:   2020-11-22 18:00:00 -0500
+categories: [contributing, community]
+---
+QEMU Advent Calendar 2020 is around the corner and we are looking for  


   volunteers to contribute disk images that showcase 
something cool, bring
+back retro computing memories, or simply entertain with a puzzle or game.
+
+QEMU Advent Calendar publishes a QEMU disk image each day from
+December 1-24. Each image is a surprise designed to delight an audience
+consisting of the QEMU community and beyond. You can see previous
+years at 
[https://www.qemu-advent-calendar.org/](https://www.qemu-advent-calendar.org/)
+
+You can help us make this year's calendar awesome by:
+ * [Sending disk images](mailto:eldon-q...@eldondev.com?Subject=QEMU 2020 
advent disk image)
+ * Sending ideas for disk images
+
+Here are the requirements for disk images:
+ * Content must be freely redistributable (i.e. no proprietary
+   license that prevents distribution). For GPL based software,
+   you need to provide the source code, too.
+ * Provide a name and a short description of the disk image
+   (e.g. with hints on what to try)
+ * Provide a ./run shell script that prints out the name and
+   description/hints and launches QEMU
+ * Provide a 320x240 screenshot/image/logo for the website
+ * Size should be ideally under 100 MB per disk image
+   (but if some few images are bigger, that should be OK, too)
+
+Check out [this disk
+image](https://www.qemu-advent-calendar.org/2018/download/day24.tar.xz) as an
+example of how to distribute an image. Links to files over 25MB are appreciated
+in lieu of email attachments.
+
+PS: QEMU Advent Calendar is a secular calendar (not
+religious). The idea is to create a fun experience for the QEMU
+community which can be shared with everyone. You don't need
+to celebrate Christmas or another religious festival to participate!
-- 
2.29.2

Re: [PATCH for-6.0 2/8] spapr/xive: Introduce spapr_xive_nr_ends()

2020-11-25 Thread David Gibson

On Wed, Nov 25, 2020 at 11:43:26PM +0100, Greg Kurz wrote:
> On Mon, 23 Nov 2020 14:33:55 +1100
> David Gibson  wrote:
> 
> > On Fri, Nov 20, 2020 at 06:46:40PM +0100, Greg Kurz wrote:
> > > We're going to kill the "nr_ends" field in a subsequent patch.
> > > Prepare ground by using an helper instead of peeking into
> > > the sPAPR XIVE structure directly.
> > > 
> > > Signed-off-by: Greg Kurz 
> > 
> > Applied to ppc-for-6.0, thanks.
> > 
> 
> I'm working on a new approach that doesn't need this change. Especially the
> new approach doesn't kill the "nr_ends" fields, which makes the changelog of
> this patch slightly wrong. Since it doesn't bring much in the end, maybe you
> can just drop it from ppc-for-6.0 ?

Done.

> 
> > 
> > > ---
> > >  include/hw/ppc/spapr_xive.h |  1 +
> > >  hw/intc/spapr_xive.c| 23 ++-
> > >  hw/intc/spapr_xive_kvm.c|  4 ++--
> > >  3 files changed, 17 insertions(+), 11 deletions(-)
> > > 
> > > diff --git a/include/hw/ppc/spapr_xive.h b/include/hw/ppc/spapr_xive.h
> > > index 26c8d90d7196..4b967f13c030 100644
> > > --- a/include/hw/ppc/spapr_xive.h
> > > +++ b/include/hw/ppc/spapr_xive.h
> > > @@ -75,6 +75,7 @@ void spapr_xive_map_mmio(SpaprXive *xive);
> > >  
> > >  int spapr_xive_end_to_target(uint8_t end_blk, uint32_t end_idx,
> > >   uint32_t *out_server, uint8_t *out_prio);
> > > +uint32_t spapr_xive_nr_ends(const SpaprXive *xive);
> > >  
> > >  /*
> > >   * KVM XIVE device helpers
> > > diff --git a/hw/intc/spapr_xive.c b/hw/intc/spapr_xive.c
> > > index 60e0d5769dcc..f473ad9cba47 100644
> > > --- a/hw/intc/spapr_xive.c
> > > +++ b/hw/intc/spapr_xive.c
> > > @@ -192,7 +192,7 @@ void spapr_xive_pic_print_info(SpaprXive *xive, 
> > > Monitor *mon)
> > >  uint32_t end_idx = xive_get_field64(EAS_END_INDEX, eas->w);
> > >  XiveEND *end;
> > >  
> > > -assert(end_idx < xive->nr_ends);
> > > +assert(end_idx < spapr_xive_nr_ends(xive));
> > >  end = >endt[end_idx];
> > >  
> > >  if (xive_end_is_valid(end)) {
> > > @@ -270,7 +270,7 @@ static void spapr_xive_reset(void *dev)
> > >  }
> > >  
> > >  /* Clear all ENDs */
> > > -for (i = 0; i < xive->nr_ends; i++) {
> > > +for (i = 0; i < spapr_xive_nr_ends(xive); i++) {
> > >  spapr_xive_end_reset(>endt[i]);
> > >  }
> > >  }
> > > @@ -288,6 +288,11 @@ static void spapr_xive_instance_init(Object *obj)
> > >  xive->fd = -1;
> > >  }
> > >  
> > > +uint32_t spapr_xive_nr_ends(const SpaprXive *xive)
> > > +{
> > > +return xive->nr_ends;
> > > +}
> > > +
> > >  static void spapr_xive_realize(DeviceState *dev, Error **errp)
> > >  {
> > >  SpaprXive *xive = SPAPR_XIVE(dev);
> > > @@ -336,7 +341,7 @@ static void spapr_xive_realize(DeviceState *dev, 
> > > Error **errp)
> > >   * Allocate the routing tables
> > >   */
> > >  xive->eat = g_new0(XiveEAS, xive->nr_irqs);
> > > -xive->endt = g_new0(XiveEND, xive->nr_ends);
> > > +xive->endt = g_new0(XiveEND, spapr_xive_nr_ends(xive));
> > >  
> > >  xive->nodename = g_strdup_printf("interrupt-controller@%" PRIx64,
> > > xive->tm_base + XIVE_TM_USER_PAGE * (1 << 
> > > TM_SHIFT));
> > > @@ -375,7 +380,7 @@ static int spapr_xive_get_end(XiveRouter *xrtr,
> > >  {
> > >  SpaprXive *xive = SPAPR_XIVE(xrtr);
> > >  
> > > -if (end_idx >= xive->nr_ends) {
> > > +if (end_idx >= spapr_xive_nr_ends(xive)) {
> > >  return -1;
> > >  }
> > >  
> > > @@ -389,7 +394,7 @@ static int spapr_xive_write_end(XiveRouter *xrtr, 
> > > uint8_t end_blk,
> > >  {
> > >  SpaprXive *xive = SPAPR_XIVE(xrtr);
> > >  
> > > -if (end_idx >= xive->nr_ends) {
> > > +if (end_idx >= spapr_xive_nr_ends(xive)) {
> > >  return -1;
> > >  }
> > >  
> > > @@ -1138,7 +1143,7 @@ static target_ulong 
> > > h_int_get_source_config(PowerPCCPU *cpu,
> > >  /* EAS_END_BLOCK is unused on sPAPR */
> > >  end_idx = xive_get_field64(EAS_END_INDEX, eas.w);
> > >  
> > > -assert(end_idx < xive->nr_ends);
> > > +assert(end_idx < spapr_xive_nr_ends(xive));
> > >  end = >endt[end_idx];
> > >  
> > >  nvt_blk = xive_get_field32(END_W6_NVT_BLOCK, end->w6);
> > > @@ -1216,7 +1221,7 @@ static target_ulong h_int_get_queue_info(PowerPCCPU 
> > > *cpu,
> > >  return H_P2;
> > >  }
> > >  
> > > -assert(end_idx < xive->nr_ends);
> > > +assert(end_idx < spapr_xive_nr_ends(xive));
> > >  end = >endt[end_idx];
> > >  
> > >  args[0] = xive->end_base + (1ull << (end_xsrc->esb_shift + 1)) * 
> > > end_idx;
> > > @@ -1304,7 +1309,7 @@ static target_ulong 
> > > h_int_set_queue_config(PowerPCCPU *cpu,
> > >  return H_P2;
> > >  }
> > >  
> > > -assert(end_idx < xive->nr_ends);
> > > +assert(end_idx < spapr_xive_nr_ends(xive));
> > >  memcpy(, >endt[end_idx], sizeof(XiveEND));
> > >  
> > >  switch (qsize) {
> > >

Re: [RFC PATCH 00/27] vDPA software assisted live migration

2020-11-25 Thread Jason Wang

On 2020/11/25 下午8:03, Eugenio Perez Martin wrote:

On Wed, Nov 25, 2020 at 8:09 AM Jason Wang wrote:

On 2020/11/21 上午2:50, Eugenio Pérez wrote:

This series enable vDPA software assisted live migration for vhost-net
devices. This is a new method of vhost devices migration: Instead of
relay on vDPA device's dirty logging capability, SW assisted LM
intercepts dataplane, forwarding the descriptors between VM and device.

In this migration mode, qemu offers a new vring to the device to
read and write into, and disable vhost notifiers, processing guest and
vhost notifications in qemu. On used buffer relay, qemu will mark the
dirty memory as with plain virtio-net devices. This way, devices does
not need to have dirty page logging capability.

This series is a POC doing SW LM for vhost-net devices, which already
have dirty page logging capabilities. None of the changes have actual
effect with current devices until last two patches (26 and 27) are
applied, but they can be rebased on top of any other. These checks the
device to meet all requirements, and disable vhost-net devices logging
so migration goes through SW LM. This last patch is not meant to be
applied in the final revision, it is in the series just for testing
purposes.

For use SW assisted LM these vhost-net devices need to be instantiated:
* With IOMMU (iommu_platform=on,ats=on)
* Without event_idx (event_idx=off)

So a question is at what level do we want to implement qemu assisted
live migration. To me it could be done at two levels:

1) generic vhost level which makes it work for both vhost-net/vhost-user
and vhost-vDPA
2) a specific type of vhost

To me, having a generic one looks better but it would be much more
complicated. So what I read from this series is it was a vhost kernel
specific software assisted live migration which is a good start.
Actually it may even have real use case, e.g it can save dirty bitmaps
for guest with large memory. But we need to address the above
limitations first.

So I would like to know what's the reason for mandating iommu platform
and ats? And I think we need to fix case of event idx support.

There is no specific reason for mandating iommu & ats, it was just
started that way.

I will extend the patch to support those cases too.

Just the notification forwarding (with no descriptor relay) can be
achieved with patches 7 and 9, and starting migration. Partial applies
between 13 and 24 will not work while migrating on source, and patch
25 is needed for the destination to resume network activity.

It is based on the ideas of DPDK SW assisted LM, in the series of

Actually we're better than that since there's no need the trick like
hardcoded IOVA for mediated(shadow) virtqueue.

DPDK's https://patchwork.dpdk.org/cover/48370/ .

I notice that you do GPA->VA translations and try to establish a VA->VA
(use VA as IOVA) mapping via device IOTLB. This shortcut should work for
vhost-kernel/user but not vhost-vDPA. The reason is that there's no
guarantee that the whole 64bit address range could be used as IOVA. One
example is that for hardware IOMMU like intel, it usually has 47 or 52
bits of address width.

So we probably need an IOVA allocator that can make sure the IOVA is not
overlapped and fit for [1]. We can probably build the IOVA for guest VA
via memory listeners. Then we have

1) IOVA for GPA
2) IOVA for shadow VQ

And advertise IOVA to VA mapping to vhost.

[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1b48dc03e575a872404f33b04cd237953c5d7498

Got it, will control it too.

Maybe for vhost-net we could directly send iotlb miss for [0,~0ULL].

It works but it means vhost-net needs some special care. To me a generic
IOVA allocator looks better.

Comments are welcome.

Thanks!

Eugenio Pérez (27):
vhost: Add vhost_dev_can_log
vhost: Add device callback in vhost_migration_log
vhost: Move log resize/put to vhost_dev_set_log
vhost: add vhost_kernel_set_vring_enable
vhost: Add hdev->dev.sw_lm_vq_handler
virtio: Add virtio_queue_get_used_notify_split
vhost: Route guest->host notification through qemu
vhost: Add a flag for software assisted Live Migration
vhost: Route host->guest notification through qemu
vhost: Allocate shadow vring
virtio: const-ify all virtio_tswap* functions
virtio: Add virtio_queue_full
vhost: Send buffers to device
virtio: Remove virtio_queue_get_used_notify_split
vhost: Do not invalidate signalled used
virtio: Expose virtqueue_alloc_element
vhost: add vhost_vring_set_notification_rcu
vhost: add vhost_vring_poll_rcu
vhost: add vhost_vring_get_buf_rcu
vhost: Return used buffers
vhost: Add vhost_virtqueue_memory_unmap
vhost: Add vhost_virtqueue_memory_map
vhost: unmap qemu's shadow virtqueues on sw live migration
vhost: iommu changes
vhost: Do not commit vhost used idx on vhost_virtqueue_stop
vhost: Add vhost_hdev_can_sw_lm
vhost: forbid

Re: [DISCUSSION] Running one qtest test: how?

2020-11-25 Thread Alexander Bulekov

On 201125 1539, Doug Evans wrote:
> Hi.
> 
> I can run a subset of qtest tests with "make check-qtest-TARGET", but
> that's the limit of the granularity that I can find. Why would one want
> more granularity? When adding a test one wants the edit/test cycle as short
> as possible and needlessly running other tests is a pain.
> 
> It'd be really nice to be able to specify one test via make check. I
> realize I can pass V=1 and get some help to dig further. And if I grep for
> my test in Makefile.mtest I can reduce the number of tests down to just the
> test binary I want (e.g., "make run-test-229" to run qtest-i386/qos-test,
> the 229 will vary tree to tree). I don't mind the 229, it's
> machine generated but it's easy to find and will be reasonably stable in
> one build (though ideally one could pass the test name to "make" instead of
> NNN). But I still want more granularity. What I really want is:
> 
> $ make run-test-229 TEST_OPTS="-p /foo/bar"
> 
> so that only test /foo/bar is run (see the output of qos-test --help).
> qos-test binaries can contain dozens of tests, I just want one of them.
> 
> Am I missing something? What do others do when adding a test?

I usually build only what I need and run it manually:
make qemu-system-TARGET
make tests/qtest/qos-test
QEMU_PATH=./qemu-system-TARGET ./tests/qtest/qos-test -p /foo/bar
?
That cuts down on the edit/test cycle, but it probably would be nicer if
there were some way to select a specific test for "make check-qtest".
-Alex

> 
> I'm happy to work on a patch to let one pass additional parameters to the
> test binary as in the above example. Guidance for what will be acceptable
> appreciated. Different test binaries will take different parameters: A
> general mechanism to pass arbitrary additional parameters to the test
> binary (.test.cmd.NNN in mtest-speak) would be quite useful.

[Bug 1905651] [NEW] Tests cannot call g_error

2020-11-25 Thread Doug Evans

Public bug reported:

I stumbled on this writing a new test, using tests/qtest/e1000e-test.c
as a template.

g_error() causes SIGTRAP, not SIGABRT, and thus the abort handler doesn't get 
run.
This in turn means qemu is not killed, which hangs the test because the 
tap-driver.pl script hangs waiting for more input.
There are a few tests that call g_error().

The SIGABRT handler explicitly kills qemu, e.g.:

qos-test.c:
qtest_add_abrt_handler(kill_qemu_hook_func, s);

ref:
https://git.qemu.org/?p=qemu.git;a=blob;f=tests/qtest/libqtest.c;h=e49f3a1e45f4cd96279241fdb2bbe231029ab922;hb=HEAD#l272

But not unexpectedly there's no such handler for SIGTRAP.

Apply this patch to trigger a repro:

diff --git a/tests/qtest/e1000e-test.c b/tests/qtest/e1000e-test.c
index fc226fdfeb..e83ace1b5c 100644
--- a/tests/qtest/e1000e-test.c
+++ b/tests/qtest/e1000e-test.c
@@ -87,6 +87,9 @@ static void e1000e_send_verify(QE1000E *d, int *test_sockets, 
QGuestAllocator *a
 /* Wait for TX WB interrupt */
 e1000e_wait_isr(d, E1000E_TX0_MSG_ID);

+g_message("Test g_error hang ...");
+g_error("Pretend something timed out");
+
 /* Check DD bit */
 g_assert_cmphex(le32_to_cpu(descr.upper.data) & dsta_dd, ==, dsta_dd);

Then:

configure
make
make check-qtest-i386

check-qtest-i386 will take awhile. To repro faster:

$ grep qtest-i386/qos-test Makefile.mtest
.test.name.229 := qtest-i386/qos-test
$ make run-test-229
Running test qtest-i386/qos-test
** Message: 18:40:49.821: Test g_error hang ...

** (tests/qtest/qos-test:3820728): ERROR **: 18:40:49.821: Pretend something 
timed out
ERROR qtest-i386/qos-test - Bail out! FATAL-ERROR: Pretend something timed out

At this point things are hung because tap-driver.pl is still waiting for
input because qemu is still running.

** 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/1905651

Title:
  Tests cannot call g_error

Status in QEMU:
  New

Bug description:
  I stumbled on this writing a new test, using tests/qtest/e1000e-test.c
  as a template.

  g_error() causes SIGTRAP, not SIGABRT, and thus the abort handler doesn't get 
run.
  This in turn means qemu is not killed, which hangs the test because the 
tap-driver.pl script hangs waiting for more input.
  There are a few tests that call g_error().

  The SIGABRT handler explicitly kills qemu, e.g.:

  qos-test.c:
  qtest_add_abrt_handler(kill_qemu_hook_func, s);

  ref:
  
https://git.qemu.org/?p=qemu.git;a=blob;f=tests/qtest/libqtest.c;h=e49f3a1e45f4cd96279241fdb2bbe231029ab922;hb=HEAD#l272

  But not unexpectedly there's no such handler for SIGTRAP.

  Apply this patch to trigger a repro:

  diff --git a/tests/qtest/e1000e-test.c b/tests/qtest/e1000e-test.c
  index fc226fdfeb..e83ace1b5c 100644
  --- a/tests/qtest/e1000e-test.c
  +++ b/tests/qtest/e1000e-test.c
  @@ -87,6 +87,9 @@ static void e1000e_send_verify(QE1000E *d, int 
*test_sockets, QGuestAllocator *a
   /* Wait for TX WB interrupt */
   e1000e_wait_isr(d, E1000E_TX0_MSG_ID);

  +g_message("Test g_error hang ...");
  +g_error("Pretend something timed out");
  +
   /* Check DD bit */
   g_assert_cmphex(le32_to_cpu(descr.upper.data) & dsta_dd, ==, dsta_dd);

  Then:

  configure
  make
  make check-qtest-i386

  check-qtest-i386 will take awhile. To repro faster:

  $ grep qtest-i386/qos-test Makefile.mtest
  .test.name.229 := qtest-i386/qos-test
  $ make run-test-229
  Running test qtest-i386/qos-test
  ** Message: 18:40:49.821: Test g_error hang ...

  ** (tests/qtest/qos-test:3820728): ERROR **: 18:40:49.821: Pretend something 
timed out
  ERROR qtest-i386/qos-test - Bail out! FATAL-ERROR: Pretend something timed out

  At this point things are hung because tap-driver.pl is still waiting
  for input because qemu is still running.

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

[Bug 1826827] Re: dtc crash; pnv_dt_serial cannot find lpc's phandle

2020-11-25 Thread Amol Surati

** Changed in: qemu
   Status: Incomplete => Fix Released

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

Title:
  dtc crash; pnv_dt_serial cannot find lpc's phandle

Status in QEMU:
  Fix Released

Bug description:
  Qemu version:
  QEMU emulator version 4.0.50 (v4.0.0-142-ge0fb2c3d89)
  Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers

  dtc version:
  Version: DTC 1.5.0-g5c3513f6

  -
  pnv_dt_serial has a line which is supposed to set the interrupt-parent of the 
"isa-serial@i3f8" node to the phandle of "lpc@0".

  To that end, it calls fdt_get_phandle as shown below:
  _FDT((fdt_setprop_cell(fdt, node, "interrupt-parent", fdt_get_phandle(fdt, 
lpc_off;

  The function fdt_get_phandle fails to find the property "phandle" (or
  "linux,phandle") for the lpc node. Consequently, pnv_dt_serial sets
  the interrupt-parent to 0.

  Now boot the qemu-system-ppc64 powernv machine, and extract the fdt by
  using the qemu monitor's pmemsave command, taking help of the OPAL
  firmware's messages to locate the fdt in the physical ram.

  qemu-system-ppc64 -m 1g -machine powernv,num-chips=1 \
  -cpu power9 -smp 2,cores=2,threads=1 -accel tcg,thread=multi \
  -kernel ./vmlinux \
  -append 'disable_radix' \
  -serial mon:stdio -nographic -nodefaults

  The kernel vmlinux contains nothing but a single instruction which
  loops infintely, so that we can gather OPAL's messages, especially the
  one below:

  [0.168845963,5] INIT: Starting kernel at 0x2000, fdt at
  0x304b0b70 14404 bytes

  Once the fdt is dumped to a file, run the following:

  'dtc -O dtb -I dts -o out.dts dtb'

  After a few warnings, the dtc application crashes because an assertion
  was fired.

  out.dts: Warning (unit_address_vs_reg): /lpcm-opb@60300/lpc@0: node 
has a unit name, but no reg property
  out.dts: Warning (simple_bus_reg): /lpcm-opb@60300/lpc@0: missing or 
empty reg/ranges property
  out.dts: Warning (avoid_unnecessary_addr_size): /ibm,opal: unnecessary 
#address-cells/#size-cells without "ranges" or child "reg" property
  out.dts: Warning (unique_unit_address): /interrupt-controller@0: duplicate 
unit-address (also used in node /memory@0)
  out.dts: Warning (chosen_node_stdout_path): /chosen:linux,stdout-path: Use 
'stdout-path' instead
  dtc: livetree.c:575: get_node_by_phandle: Assertion `generate_fixups' failed.
  Aborted (core dumped)

  The assertion is fired because get_node_by_phandle receives a phandle
  value of 0, which is unexpected, unless fixups are needed (They are
  not, when running the dtc command).

  Back inside pnv_dt_serial, if the line that sets "interrupt-parent"
  for the serial device node is commented out, the dtc crash is
  prevented. Looking at hw/ppc/e500.c, it takes care of allocating
  necessary phandle values in the nodes, so a similar method can be
  adopted for powernv.

  The dtb is attached.

  Edit: Add version, Correct filenames.

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

Re: [PATCH v2 22/28] target/mips: Extract XBurst Media eXtension Unit translation routines

On 11/23/20 12:44 PM, Philippe Mathieu-Daudé wrote:
> Media eXtension Unit is a SIMD extension from Ingenic.
> 
> Extract 2900 lines from the huge translate.c to a new file,
> 'vendor-xburst-mxu_translate.c.inc'. As there are too many
> inter-dependencies we don't compile it as another object,
> but keep including it in the big translate.o. We gain in
> code maintainability.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  target/mips/translate.c| 2890 +--
>  target/mips/vendor-mxu_translate.c.inc | 2892 
>  2 files changed, 2893 insertions(+), 2889 deletions(-)
>  create mode 100644 target/mips/vendor-mxu_translate.c.inc

Reviewed-by: Richard Henderson 

r~

Re: [PATCH v2 21/28] target/mips: Extract Loongson EXTensions translation routines

On 11/23/20 12:44 PM, Philippe Mathieu-Daudé wrote:
> LoongEXTs are general-purpose extensions from the LoongISA.
> 
> Extract 650 lines of translation routines to
> 'vendor-loong-ext_translate.c.inc'.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  target/mips/translate.c  | 652 +-
>  target/mips/vendor-loong-ext_translate.c.inc | 665 +++
>  2 files changed, 666 insertions(+), 651 deletions(-)
>  create mode 100644 target/mips/vendor-loong-ext_translate.c.inc

Reviewed-by: Richard Henderson 

r~

Re: [PATCH v2 04/28] target/mips: Extract MSA helpers from op_helper.c

On 11/23/20 12:44 PM, Philippe Mathieu-Daudé wrote:
> We have ~400 lines of MSA helpers in the generic op_helper.c,
> move them with the other helpers in 'mod-msa_helper.c'.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  target/mips/mod-msa_helper.c | 392 ++
>  target/mips/op_helper.c  | 393 ---
>  2 files changed, 392 insertions(+), 393 deletions(-)

Reviewed-by: Richard Henderson 

r~

Re: [PATCH v2 03/28] target/mips: Rename msa_helper.c as mod-msa_helper.c

On 11/23/20 12:44 PM, Philippe Mathieu-Daudé wrote:
> MSA means 'MIPS SIMD Architecture' and is defined as a Module by
> MIPS.
> To keep the directory sorted, we use the 'mod' prefix for MIPS
> modules. Rename msa_helper.c as mod-msa_helper.c.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  target/mips/{msa_helper.c => mod-msa_helper.c} | 0
>  target/mips/meson.build| 3 ++-
>  2 files changed, 2 insertions(+), 1 deletion(-)
>  rename target/mips/{msa_helper.c => mod-msa_helper.c} (100%)

Reviewed-by: Richard Henderson 

r~

Re: [PATCH v2 01/28] target/mips: Use FloatRoundMode enum for FCR31 modes conversion

On 11/23/20 12:44 PM, Philippe Mathieu-Daudé wrote:
> Use the FloatRoundMode enum type introduced in commit 3dede407cc6
> ("softfloat: Name rounding mode enum") instead of 'unsigned int'.
> 
> Suggested-by: Richard Henderson 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  target/mips/internal.h   | 3 ++-
>  target/mips/fpu_helper.c | 2 +-
>  2 files changed, 3 insertions(+), 2 deletions(-)

Reviewed-by: Richard Henderson 

r~

[DISCUSSION] Running one qtest test: how?

2020-11-25 Thread Doug Evans

Hi.

I can run a subset of qtest tests with "make check-qtest-TARGET", but
that's the limit of the granularity that I can find. Why would one want
more granularity? When adding a test one wants the edit/test cycle as short
as possible and needlessly running other tests is a pain.

It'd be really nice to be able to specify one test via make check. I
realize I can pass V=1 and get some help to dig further. And if I grep for
my test in Makefile.mtest I can reduce the number of tests down to just the
test binary I want (e.g., "make run-test-229" to run qtest-i386/qos-test,
the 229 will vary tree to tree). I don't mind the 229, it's
machine generated but it's easy to find and will be reasonably stable in
one build (though ideally one could pass the test name to "make" instead of
NNN). But I still want more granularity. What I really want is:

$ make run-test-229 TEST_OPTS="-p /foo/bar"

so that only test /foo/bar is run (see the output of qos-test --help).
qos-test binaries can contain dozens of tests, I just want one of them.

Am I missing something? What do others do when adding a test?

I'm happy to work on a patch to let one pass additional parameters to the
test binary as in the above example. Guidance for what will be acceptable
appreciated. Different test binaries will take different parameters: A
general mechanism to pass arbitrary additional parameters to the test
binary (.test.cmd.NNN in mtest-speak) would be quite useful.

Re: [PATCH for-6.0 2/8] spapr/xive: Introduce spapr_xive_nr_ends()

2020-11-25 Thread Greg Kurz

On Mon, 23 Nov 2020 14:33:55 +1100
David Gibson  wrote:

> On Fri, Nov 20, 2020 at 06:46:40PM +0100, Greg Kurz wrote:
> > We're going to kill the "nr_ends" field in a subsequent patch.
> > Prepare ground by using an helper instead of peeking into
> > the sPAPR XIVE structure directly.
> > 
> > Signed-off-by: Greg Kurz 
> 
> Applied to ppc-for-6.0, thanks.
> 

I'm working on a new approach that doesn't need this change. Especially the
new approach doesn't kill the "nr_ends" fields, which makes the changelog of
this patch slightly wrong. Since it doesn't bring much in the end, maybe you
can just drop it from ppc-for-6.0 ?

> 
> > ---
> >  include/hw/ppc/spapr_xive.h |  1 +
> >  hw/intc/spapr_xive.c| 23 ++-
> >  hw/intc/spapr_xive_kvm.c|  4 ++--
> >  3 files changed, 17 insertions(+), 11 deletions(-)
> > 
> > diff --git a/include/hw/ppc/spapr_xive.h b/include/hw/ppc/spapr_xive.h
> > index 26c8d90d7196..4b967f13c030 100644
> > --- a/include/hw/ppc/spapr_xive.h
> > +++ b/include/hw/ppc/spapr_xive.h
> > @@ -75,6 +75,7 @@ void spapr_xive_map_mmio(SpaprXive *xive);
> >  
> >  int spapr_xive_end_to_target(uint8_t end_blk, uint32_t end_idx,
> >   uint32_t *out_server, uint8_t *out_prio);
> > +uint32_t spapr_xive_nr_ends(const SpaprXive *xive);
> >  
> >  /*
> >   * KVM XIVE device helpers
> > diff --git a/hw/intc/spapr_xive.c b/hw/intc/spapr_xive.c
> > index 60e0d5769dcc..f473ad9cba47 100644
> > --- a/hw/intc/spapr_xive.c
> > +++ b/hw/intc/spapr_xive.c
> > @@ -192,7 +192,7 @@ void spapr_xive_pic_print_info(SpaprXive *xive, Monitor 
> > *mon)
> >  uint32_t end_idx = xive_get_field64(EAS_END_INDEX, eas->w);
> >  XiveEND *end;
> >  
> > -assert(end_idx < xive->nr_ends);
> > +assert(end_idx < spapr_xive_nr_ends(xive));
> >  end = >endt[end_idx];
> >  
> >  if (xive_end_is_valid(end)) {
> > @@ -270,7 +270,7 @@ static void spapr_xive_reset(void *dev)
> >  }
> >  
> >  /* Clear all ENDs */
> > -for (i = 0; i < xive->nr_ends; i++) {
> > +for (i = 0; i < spapr_xive_nr_ends(xive); i++) {
> >  spapr_xive_end_reset(>endt[i]);
> >  }
> >  }
> > @@ -288,6 +288,11 @@ static void spapr_xive_instance_init(Object *obj)
> >  xive->fd = -1;
> >  }
> >  
> > +uint32_t spapr_xive_nr_ends(const SpaprXive *xive)
> > +{
> > +return xive->nr_ends;
> > +}
> > +
> >  static void spapr_xive_realize(DeviceState *dev, Error **errp)
> >  {
> >  SpaprXive *xive = SPAPR_XIVE(dev);
> > @@ -336,7 +341,7 @@ static void spapr_xive_realize(DeviceState *dev, Error 
> > **errp)
> >   * Allocate the routing tables
> >   */
> >  xive->eat = g_new0(XiveEAS, xive->nr_irqs);
> > -xive->endt = g_new0(XiveEND, xive->nr_ends);
> > +xive->endt = g_new0(XiveEND, spapr_xive_nr_ends(xive));
> >  
> >  xive->nodename = g_strdup_printf("interrupt-controller@%" PRIx64,
> > xive->tm_base + XIVE_TM_USER_PAGE * (1 << 
> > TM_SHIFT));
> > @@ -375,7 +380,7 @@ static int spapr_xive_get_end(XiveRouter *xrtr,
> >  {
> >  SpaprXive *xive = SPAPR_XIVE(xrtr);
> >  
> > -if (end_idx >= xive->nr_ends) {
> > +if (end_idx >= spapr_xive_nr_ends(xive)) {
> >  return -1;
> >  }
> >  
> > @@ -389,7 +394,7 @@ static int spapr_xive_write_end(XiveRouter *xrtr, 
> > uint8_t end_blk,
> >  {
> >  SpaprXive *xive = SPAPR_XIVE(xrtr);
> >  
> > -if (end_idx >= xive->nr_ends) {
> > +if (end_idx >= spapr_xive_nr_ends(xive)) {
> >  return -1;
> >  }
> >  
> > @@ -1138,7 +1143,7 @@ static target_ulong 
> > h_int_get_source_config(PowerPCCPU *cpu,
> >  /* EAS_END_BLOCK is unused on sPAPR */
> >  end_idx = xive_get_field64(EAS_END_INDEX, eas.w);
> >  
> > -assert(end_idx < xive->nr_ends);
> > +assert(end_idx < spapr_xive_nr_ends(xive));
> >  end = >endt[end_idx];
> >  
> >  nvt_blk = xive_get_field32(END_W6_NVT_BLOCK, end->w6);
> > @@ -1216,7 +1221,7 @@ static target_ulong h_int_get_queue_info(PowerPCCPU 
> > *cpu,
> >  return H_P2;
> >  }
> >  
> > -assert(end_idx < xive->nr_ends);
> > +assert(end_idx < spapr_xive_nr_ends(xive));
> >  end = >endt[end_idx];
> >  
> >  args[0] = xive->end_base + (1ull << (end_xsrc->esb_shift + 1)) * 
> > end_idx;
> > @@ -1304,7 +1309,7 @@ static target_ulong h_int_set_queue_config(PowerPCCPU 
> > *cpu,
> >  return H_P2;
> >  }
> >  
> > -assert(end_idx < xive->nr_ends);
> > +assert(end_idx < spapr_xive_nr_ends(xive));
> >  memcpy(, >endt[end_idx], sizeof(XiveEND));
> >  
> >  switch (qsize) {
> > @@ -1470,7 +1475,7 @@ static target_ulong h_int_get_queue_config(PowerPCCPU 
> > *cpu,
> >  return H_P2;
> >  }
> >  
> > -assert(end_idx < xive->nr_ends);
> > +assert(end_idx < spapr_xive_nr_ends(xive));
> >  end = >endt[end_idx];
> >  
> >  args[0] = 0;
> > diff --git a/hw/intc/spapr_xive_kvm.c

Re: [PATCH v2 0/6] arch_init.c cleanup

2020-11-25 Thread Roman Bolshakov

On Wed, Nov 25, 2020 at 03:56:30PM -0500, Eduardo Habkost wrote:
> This series gets rid of most of the code in arch_init.c.  It
> moves the QEMU_ARCH macro definitions to corresponding cpu.h
> files, and gets rid of kvm_available() and xen_available().
> 

For the series:
Reviewed-by: Roman Bolshakov 

Thanks,
Roman

[PATCH v3] Fix build with 64 bits time_t

2020-11-25 Thread Fabrice Fontaine

time element is deprecated on new input_event structure in kernel's
input.h [1]

This will avoid the following build failure:

hw/input/virtio-input-host.c: In function 'virtio_input_host_handle_status':
hw/input/virtio-input-host.c:198:28: error: 'struct input_event' has no member 
named 'time'
  198 | if (gettimeofday(, NULL)) {
  |^

Fixes:
 - 
http://autobuild.buildroot.org/results/a538167e288c14208d557cd45446df86d3d599d5
 - 
http://autobuild.buildroot.org/results/efd4474fb4b6c0ce0ab3838ce130429c51e43bbb

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=152194fe9c3f

Signed-off-by: Fabrice Fontaine 
---
Changes v2 -> v3 (after review of Gerd Hoffmann):
 - Replace include on  by
   "standard-headers/linux/input.h" to try to fix build on rhel-7

Changes v1 -> v2 (after review of Michael S. Tsirkin):
 - Drop define of input_event_{sec,usec} as it is already done in
   include/standard-headers/linux/input.h

 contrib/vhost-user-input/main.c | 7 +--
 hw/input/virtio-input-host.c| 5 -
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/contrib/vhost-user-input/main.c b/contrib/vhost-user-input/main.c
index 6020c6f33a..83fdeb4c6d 100644
--- a/contrib/vhost-user-input/main.c
+++ b/contrib/vhost-user-input/main.c
@@ -7,13 +7,13 @@
 #include "qemu/osdep.h"
 
 #include 
-#include 
 
 #include "qemu/iov.h"
 #include "qemu/bswap.h"
 #include "qemu/sockets.h"
 #include "contrib/libvhost-user/libvhost-user.h"
 #include "contrib/libvhost-user/libvhost-user-glib.h"
+#include "standard-headers/linux/input.h"
 #include "standard-headers/linux/virtio_input.h"
 #include "qapi/error.h"
 
@@ -115,13 +115,16 @@ vi_evdev_watch(VuDev *dev, int condition, void *data)
 static void vi_handle_status(VuInput *vi, virtio_input_event *event)
 {
 struct input_event evdev;
+struct timeval tval;
 int rc;
 
-if (gettimeofday(, NULL)) {
+if (gettimeofday(, NULL)) {
 perror("vi_handle_status: gettimeofday");
 return;
 }
 
+evdev.input_event_sec = tval.tv_sec;
+evdev.input_event_usec = tval.tv_usec;
 evdev.type = le16toh(event->type);
 evdev.code = le16toh(event->code);
 evdev.value = le32toh(event->value);
diff --git a/hw/input/virtio-input-host.c b/hw/input/virtio-input-host.c
index 85daf73f1a..137efba57b 100644
--- a/hw/input/virtio-input-host.c
+++ b/hw/input/virtio-input-host.c
@@ -193,13 +193,16 @@ static void virtio_input_host_handle_status(VirtIOInput 
*vinput,
 {
 VirtIOInputHost *vih = VIRTIO_INPUT_HOST(vinput);
 struct input_event evdev;
+struct timeval tval;
 int rc;
 
-if (gettimeofday(, NULL)) {
+if (gettimeofday(, NULL)) {
 perror("virtio_input_host_handle_status: gettimeofday");
 return;
 }
 
+evdev.input_event_sec = tval.tv_sec;
+evdev.input_event_usec = tval.tv_usec;
 evdev.type = le16_to_cpu(event->type);
 evdev.code = le16_to_cpu(event->code);
 evdev.value = le32_to_cpu(event->value);
-- 
2.29.2

Re: [EXTERNAL] Re: [PATCH] WHPX: support for the kernel-irqchip on/off


On 25/11/20 21:35, Sunil Muthuswamy wrote:

  > Sorry, this has missed the 5.2 soft freeze.  Can you please resend it in

about a month?


Paolo, is the branch open now for this kind of change? Where can I track
the branch status?


Hi, you can track it at https://wiki.qemu.org/Planning/5.2.

It's close enough to the release that you can resend (or if no rebasing 
is needed, just tell me).


Paolo

[PATCH 1/1] trace: Send "-d trace:help" output to stdout

2020-11-25 Thread Doug Evans via

... for consistency with "-d help".

Signed-off-by: Doug Evans 
---
 trace/control.c | 12 ++--
 trace/control.h |  3 ++-
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/trace/control.c b/trace/control.c
index b82fb87316..cd04dd4e0c 100644
--- a/trace/control.c
+++ b/trace/control.c
@@ -125,18 +125,18 @@ TraceEvent *trace_event_iter_next(TraceEventIter *iter)
 return NULL;
 }
 
-void trace_list_events(void)
+void trace_list_events(FILE *f)
 {
 TraceEventIter iter;
 TraceEvent *ev;
 trace_event_iter_init(, NULL);
 while ((ev = trace_event_iter_next()) != NULL) {
-fprintf(stderr, "%s\n", trace_event_get_name(ev));
+fprintf(f, "%s\n", trace_event_get_name(ev));
 }
 #ifdef CONFIG_TRACE_DTRACE
-fprintf(stderr, "This list of names of trace points may be incomplete "
-"when using the DTrace/SystemTap backends.\n"
-"Run 'qemu-trace-stap list %s' to print the full list.\n",
+fprintf(f, "This list of names of trace points may be incomplete "
+   "when using the DTrace/SystemTap backends.\n"
+   "Run 'qemu-trace-stap list %s' to print the full list.\n",
 error_get_progname());
 #endif
 }
@@ -176,7 +176,7 @@ static void do_trace_enable_events(const char *line_buf)
 void trace_enable_events(const char *line_buf)
 {
 if (is_help_option(line_buf)) {
-trace_list_events();
+trace_list_events(stdout);
 if (monitor_cur() == NULL) {
 exit(0);
 }
diff --git a/trace/control.h b/trace/control.h
index 05b95ea453..9522a7b318 100644
--- a/trace/control.h
+++ b/trace/control.h
@@ -201,10 +201,11 @@ void trace_fini_vcpu(CPUState *vcpu);
 
 /**
  * trace_list_events:
+ * @f: Where to send output.
  *
  * List all available events.
  */
-void trace_list_events(void);
+void trace_list_events(FILE *f);
 
 /**
  * trace_enable_events:
-- 
2.29.2.454.gaff20da3a2-goog

[PATCH 4/8] semihosting: Support SYS_HEAPINFO when env->boot_info is not set

env->boot_info is only set in some ARM startup paths, so we cannot
rely on it to support the SYS_HEAPINFO semihosting function. When not
available, fallback to finding a RAM memory region containing the
current stack and use the base of that.

Signed-off-by: Keith Packard 
---
 hw/semihosting/common-semi.c | 42 +++-
 1 file changed, 41 insertions(+), 1 deletion(-)

diff --git a/hw/semihosting/common-semi.c b/hw/semihosting/common-semi.c
index 27bdfd0e83..ddfa448cc2 100644
--- a/hw/semihosting/common-semi.c
+++ b/hw/semihosting/common-semi.c
@@ -133,6 +133,35 @@ typedef struct GuestFD {
 
 static GArray *guestfd_array;
 
+#ifndef CONFIG_USER_ONLY
+#include "exec/address-spaces.h"
+/*
+ * Find the base of a RAM region containing the specified address
+ */
+static inline hwaddr
+common_semi_find_region_base(hwaddr addr)
+{
+MemoryRegion *subregion;
+
+/*
+ * Find the chunk of R/W memory containing the address.  This is
+ * used for the SYS_HEAPINFO semihosting call, which should
+ * probably be using information from the loaded application.
+ */
+QTAILQ_FOREACH(subregion, _system_memory()->subregions,
+   subregions_link) {
+if (subregion->ram && !subregion->readonly) {
+Int128 top128 = int128_add(int128_make64(subregion->addr),
+   subregion->size);
+if (subregion->addr <= addr && int128_lt(addr, top128)) {
+return subregion->addr;
+}
+}
+}
+return 0;
+}
+#endif
+
 #ifdef TARGET_ARM
 static inline target_ulong
 common_semi_arg(CPUState *cs, int argno)
@@ -171,7 +200,18 @@ common_semi_rambase(CPUState *cs)
 {
 CPUArchState *env = cs->env_ptr;
 const struct arm_boot_info *info = env->boot_info;
-return info->loader_start;
+target_ulong sp;
+
+if (info) {
+return info->loader_start;
+}
+
+if (is_a64(env)) {
+sp = env->xregs[31];
+} else {
+sp = env->regs[13];
+}
+return common_semi_find_region_base(sp);
 }
 #endif
 
-- 
2.29.2

[PATCH 6/8] semihosting: Implement SYS_ELAPSED and SYS_TICKFREQ

These are part of Semihosting for AArch32 and AArch64 Release 2.0

Signed-off-by: Keith Packard 
---
 hw/semihosting/common-semi.c | 16 
 include/qemu/timer.h |  2 ++
 util/qemu-timer-common.c |  4 
 3 files changed, 22 insertions(+)

diff --git a/hw/semihosting/common-semi.c b/hw/semihosting/common-semi.c
index 2b6a3fd9fd..c84b0d906b 100644
--- a/hw/semihosting/common-semi.c
+++ b/hw/semihosting/common-semi.c
@@ -38,6 +38,7 @@
 #include "hw/semihosting/console.h"
 #include "hw/semihosting/common-semi.h"
 #include "qemu/log.h"
+#include "qemu/timer.h"
 #ifdef CONFIG_USER_ONLY
 #include "qemu.h"
 
@@ -69,6 +70,8 @@
 #define TARGET_SYS_EXIT0x18
 #define TARGET_SYS_SYNCCACHE   0x19
 #define TARGET_SYS_EXIT_EXTENDED 0x20
+#define TARGET_SYS_ELAPSED 0x30
+#define TARGET_SYS_TICKFREQ0x31
 
 /* ADP_Stopped_ApplicationExit is used for exit(0),
  * anything else is implemented as exit(1) */
@@ -832,6 +835,7 @@ target_ulong do_common_semihosting(CPUState *cs)
 uint32_t ret;
 uint32_t len;
 GuestFD *gf;
+int64_t elapsed;
 
 (void) env; /* Used implicitly by arm lock_user macro */
 nr = common_semi_arg(cs, 0) & 0xU;
@@ -1241,6 +1245,18 @@ target_ulong do_common_semihosting(CPUState *cs)
 }
 gdb_exit(cs->env_ptr, ret);
 exit(ret);
+case TARGET_SYS_ELAPSED:
+elapsed = get_clock() - clock_start;
+if (sizeof(target_ulong) == 8) {
+SET_ARG(0, elapsed);
+} else {
+SET_ARG(0, (uint32_t) elapsed);
+SET_ARG(1, (uint32_t) (elapsed >> 32));
+}
+return 0;
+case TARGET_SYS_TICKFREQ:
+/* qemu always uses nsec */
+return 10;
 case TARGET_SYS_SYNCCACHE:
 /*
  * Clean the D-cache and invalidate the I-cache for the specified
diff --git a/include/qemu/timer.h b/include/qemu/timer.h
index bdecc5b41f..ca6fae51f1 100644
--- a/include/qemu/timer.h
+++ b/include/qemu/timer.h
@@ -806,6 +806,8 @@ static inline int64_t get_clock_realtime(void)
 return tv.tv_sec * 10LL + (tv.tv_usec * 1000);
 }
 
+extern int64_t clock_start;
+
 /* Warning: don't insert tracepoints into these functions, they are
also used by simpletrace backend and tracepoints would cause
an infinite recursion! */
diff --git a/util/qemu-timer-common.c b/util/qemu-timer-common.c
index baf3317f74..cc1326f726 100644
--- a/util/qemu-timer-common.c
+++ b/util/qemu-timer-common.c
@@ -27,6 +27,8 @@
 /***/
 /* real time host monotonic timer */
 
+int64_t clock_start;
+
 #ifdef _WIN32
 
 int64_t clock_freq;
@@ -41,6 +43,7 @@ static void __attribute__((constructor)) init_get_clock(void)
 exit(1);
 }
 clock_freq = freq.QuadPart;
+clock_start = get_clock();
 }
 
 #else
@@ -55,5 +58,6 @@ static void __attribute__((constructor)) init_get_clock(void)
 if (clock_gettime(CLOCK_MONOTONIC, ) == 0) {
 use_rt_clock = 1;
 }
+clock_start = get_clock();
 }
 #endif
-- 
2.29.2

[PATCH 8/8] semihosting: Implement SYS_ISERROR

Part of Semihosting for AArch32 and AArch64 Release 2.0

Signed-off-by: Keith Packard 
---
 hw/semihosting/common-semi.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/hw/semihosting/common-semi.c b/hw/semihosting/common-semi.c
index 9a04d98e4e..fda0e714ef 100644
--- a/hw/semihosting/common-semi.c
+++ b/hw/semihosting/common-semi.c
@@ -55,6 +55,7 @@
 #define TARGET_SYS_WRITE   0x05
 #define TARGET_SYS_READ0x06
 #define TARGET_SYS_READC   0x07
+#define TARGET_SYS_ISERROR 0x08
 #define TARGET_SYS_ISTTY   0x09
 #define TARGET_SYS_SEEK0x0a
 #define TARGET_SYS_FLEN0x0c
@@ -962,6 +963,9 @@ target_ulong do_common_semihosting(CPUState *cs)
 return guestfd_fns[gf->type].readfn(cs, gf, arg1, len);
 case TARGET_SYS_READC:
 return qemu_semihosting_console_inc(cs->env_ptr);
+case TARGET_SYS_ISERROR:
+GET_ARG(0);
+return (target_long) arg0 < 0 ? 1 : 0;
 case TARGET_SYS_ISTTY:
 GET_ARG(0);
 
-- 
2.29.2

[PATCH 7/8] semihosting: Implement SYS_TMPNAM

Part of Semihosting for AArch32 and AArch64 Release 2.0

Signed-off-by: Keith Packard 
---
 hw/semihosting/common-semi.c | 21 +++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/hw/semihosting/common-semi.c b/hw/semihosting/common-semi.c
index c84b0d906b..9a04d98e4e 100644
--- a/hw/semihosting/common-semi.c
+++ b/hw/semihosting/common-semi.c
@@ -830,6 +830,7 @@ target_ulong do_common_semihosting(CPUState *cs)
 CPUArchState *env = cs->env_ptr;
 target_ulong args;
 target_ulong arg0, arg1, arg2, arg3;
+target_ulong ul_ret;
 char * s;
 int nr;
 uint32_t ret;
@@ -993,8 +994,24 @@ target_ulong do_common_semihosting(CPUState *cs)
 
 return guestfd_fns[gf->type].flenfn(cs, gf);
 case TARGET_SYS_TMPNAM:
-qemu_log_mask(LOG_UNIMP, "%s: SYS_TMPNAM not implemented", __func__);
-return -1;
+GET_ARG(0);
+GET_ARG(1);
+GET_ARG(2);
+if (asprintf(, "/tmp/qemu-%x%02x", getpid(),
+ (int) (arg1 & 0xff)) < 0) {
+return -1;
+}
+ul_ret = (target_ulong) -1;
+
+/* Make sure there's enough space in the buffer */
+if (strlen(s) < arg2) {
+char *output = lock_user(VERIFY_WRITE, arg0, arg2, 0);
+strcpy(output, s);
+unlock_user(output, arg0, arg2);
+ul_ret = 0;
+}
+free(s);
+return ul_ret;
 case TARGET_SYS_REMOVE:
 GET_ARG(0);
 GET_ARG(1);
-- 
2.29.2

[PATCH 5/8] riscv: Add semihosting support [v13]

Adapt the arm semihosting support code for RISCV. This implementation
is based on the standard for RISC-V semihosting version 0.2 as
documented in

   https://github.com/riscv/riscv-semihosting-spec/releases/tag/0.2

Signed-off-by: Keith Packard 

---

v2:
Update PC after exception is handled to follow
change in the ARM version for SYS_READC

v3:
Disallow semihosting in user mode; report a regular
breakpoint in that case.

v4:
Fix errors reported by checkpatch

v5:
Reference current RISC-V semihosting specification

v6:
Add support for semihosting in riscv64-linux-user and
riscv32-linux-user

v7:
Add meson build support

v8:
Fix errors reported by checkpatch that crept in.

v9:
Changes suggested by Alistair Francis :
Don't add me to the MAINTAINERS file.
Remove duplicate #include in target/riscv/cpu.h
Reference RISC-V semihosting spec in target/riscv/riscv-semi.c

v10:
Use common semihosting implementation instead of a separate copy.

Make sure addresses of the three breakpoint-signaling
instructions all lie within the same page. Change suggested by
Richard Henderson 

v11:
Use CONFIG_ARM_COMPATIBLE_SEMIHOSTING

v12:
Fix bug in SYS_EXIT support on rv64

v13:
Add common_semi_rambase implementation. This locates the
memory region containing the stack and uses the base of that.

Fix SET_ARG and GET_ARG on rv64 targets to operate on 64-bit
values rather than 32-bit. Put_user_ual/get_user_ual are
confusingly defined by softmmu-semi.h as being equivalent to
put_user_u32/get_user_u32.
---
 default-configs/devices/riscv32-softmmu.mak   |  2 +
 default-configs/devices/riscv64-softmmu.mak   |  2 +
 .../targets/riscv32-linux-user.mak|  1 +
 .../targets/riscv64-linux-user.mak|  1 +
 hw/semihosting/common-semi.c  | 82 ++-
 hw/semihosting/common-semi.h  |  5 +-
 linux-user/qemu.h |  4 +-
 linux-user/semihost.c |  8 +-
 qemu-options.hx   | 10 ++-
 target/riscv/cpu_bits.h   |  1 +
 target/riscv/cpu_helper.c | 10 +++
 .../riscv/insn_trans/trans_privileged.c.inc   | 37 -
 target/riscv/translate.c  | 11 +++
 13 files changed, 162 insertions(+), 12 deletions(-)

diff --git a/default-configs/devices/riscv32-softmmu.mak 
b/default-configs/devices/riscv32-softmmu.mak
index 94a236c9c2..d847bd5692 100644
--- a/default-configs/devices/riscv32-softmmu.mak
+++ b/default-configs/devices/riscv32-softmmu.mak
@@ -3,6 +3,8 @@
 # Uncomment the following lines to disable these optional devices:
 #
 #CONFIG_PCI_DEVICES=n
+CONFIG_SEMIHOSTING=y
+CONFIG_ARM_COMPATIBLE_SEMIHOSTING=y
 
 # Boards:
 #
diff --git a/default-configs/devices/riscv64-softmmu.mak 
b/default-configs/devices/riscv64-softmmu.mak
index 76b6195648..d5eec75f05 100644
--- a/default-configs/devices/riscv64-softmmu.mak
+++ b/default-configs/devices/riscv64-softmmu.mak
@@ -3,6 +3,8 @@
 # Uncomment the following lines to disable these optional devices:
 #
 #CONFIG_PCI_DEVICES=n
+CONFIG_SEMIHOSTING=y
+CONFIG_ARM_COMPATIBLE_SEMIHOSTING=y
 
 # Boards:
 #
diff --git a/default-configs/targets/riscv32-linux-user.mak 
b/default-configs/targets/riscv32-linux-user.mak
index dfb259e8aa..6a9d1b1bc1 100644
--- a/default-configs/targets/riscv32-linux-user.mak
+++ b/default-configs/targets/riscv32-linux-user.mak
@@ -2,3 +2,4 @@ TARGET_ARCH=riscv32
 TARGET_BASE_ARCH=riscv
 TARGET_ABI_DIR=riscv
 TARGET_XML_FILES= gdb-xml/riscv-32bit-cpu.xml gdb-xml/riscv-32bit-fpu.xml 
gdb-xml/riscv-64bit-fpu.xml gdb-xml/riscv-32bit-csr.xml 
gdb-xml/riscv-32bit-virtual.xml
+CONFIG_ARM_COMPATIBLE_SEMIHOSTING=y
diff --git a/default-configs/targets/riscv64-linux-user.mak 
b/default-configs/targets/riscv64-linux-user.mak
index b13895f3b0..0a92849a1b 100644
--- a/default-configs/targets/riscv64-linux-user.mak
+++ b/default-configs/targets/riscv64-linux-user.mak
@@ -2,3 +2,4 @@ TARGET_ARCH=riscv64
 TARGET_BASE_ARCH=riscv
 TARGET_ABI_DIR=riscv
 TARGET_XML_FILES= gdb-xml/riscv-64bit-cpu.xml gdb-xml/riscv-32bit-fpu.xml 
gdb-xml/riscv-64bit-fpu.xml gdb-xml/riscv-64bit-csr.xml 
gdb-xml/riscv-64bit-virtual.xml
+CONFIG_ARM_COMPATIBLE_SEMIHOSTING=y
diff --git a/hw/semihosting/common-semi.c b/hw/semihosting/common-semi.c
index ddfa448cc2..2b6a3fd9fd 100644
--- a/hw/semihosting/common-semi.c
+++ b/hw/semihosting/common-semi.c
@@ -1,6 +1,6 @@
 /*
  *  Semihosting support for systems modeled on the Arm "Angel"
- *  semihosting syscalls design.
+ *  semihosting syscalls design. This includes Arm and RISC-V processors
  *
  *  Copyright (c) 2005, 2007 CodeSourcery.
  *  Copyright (c) 2019 Linaro
@@ -25,6 +25,10 @@
  *  ARM Semihosting is documented in:
  * Semihosting for AArch32 and AArch64 Release 2.0
  *

[PATCH 3/8] semihosting: Change internal common-semi interfaces to use CPUState * [v2]

This makes all of the internal interfaces architecture-independent and
renames the internal functions to use the 'common_semi' prefix instead
of 'arm' or 'arm_semi'.

To do this, some new architecture-specific internal helper functions
were created:

static inline target_ulong
common_semi_arg(CPUState *cs, int argno)

Returns the argno'th semihosting argument, where argno can be
either 0 or 1.

static inline void
common_semi_set_ret(CPUState *cs, target_ulong ret)

Sets the semihosting return value.

static inline bool
common_semi_sys_exit_extended(CPUState *cs, int nr)

This detects whether the specified semihosting call, which
is either TARGET_SYS_EXIT or TARGET_SYS_EXIT_EXTENDED should
be executed using the TARGET_SYS_EXIT_EXTENDED semantics.

static inline target_ulong
common_semi_rambase(CPUState *cs)

Returns the base of RAM region used for heap and stack. This
is used to construct plausible values for the SYS_HEAPINFO
call.

In addition, several existing functions have been changed to flag
areas of code which are architecture specific:

static target_ulong
common_semi_flen_buf(CPUState *cs)

Returns the current stack pointer minus 64, which is
where a stat structure will be placed on the stack

#define GET_ARG(n)

This fetches arguments from the semihosting command's argument
block. The address of this is available implicitly through the
local 'args' variable. This is *mostly* architecture
independent, but does depend on the current ABI's notion of
the size of a 'long' parameter, which may need run-time checks
(as it does on AARCH64)

#define SET_ARG(n, val)

This mirrors GET_ARG and stores data back into the argument
block.

Signed-off-by: Keith Packard 
Reviewed-by: Alistair Francis 



v2:
Add common_semi_rambase hook to get memory address for
SYS_HEAPINFO call.
---
 hw/semihosting/common-semi.c | 350 ++-
 1 file changed, 185 insertions(+), 165 deletions(-)

diff --git a/hw/semihosting/common-semi.c b/hw/semihosting/common-semi.c
index cafbe579c7..27bdfd0e83 100644
--- a/hw/semihosting/common-semi.c
+++ b/hw/semihosting/common-semi.c
@@ -32,15 +32,15 @@
 #include "cpu.h"
 #include "hw/semihosting/semihost.h"
 #include "hw/semihosting/console.h"
+#include "hw/semihosting/common-semi.h"
 #include "qemu/log.h"
 #ifdef CONFIG_USER_ONLY
 #include "qemu.h"
 
-#define ARM_ANGEL_HEAP_SIZE (128 * 1024 * 1024)
+#define COMMON_SEMI_HEAP_SIZE (128 * 1024 * 1024)
 #else
 #include "exec/gdbstub.h"
 #include "qemu/cutils.h"
-#include "hw/arm/boot.h"
 #endif
 
 #define TARGET_SYS_OPEN0x01
@@ -133,6 +133,50 @@ typedef struct GuestFD {
 
 static GArray *guestfd_array;
 
+#ifdef TARGET_ARM
+static inline target_ulong
+common_semi_arg(CPUState *cs, int argno)
+{
+ARMCPU *cpu = ARM_CPU(cs);
+CPUARMState *env = >env;
+if (is_a64(env)) {
+return env->xregs[argno];
+} else {
+return env->regs[argno];
+}
+}
+
+static inline void
+common_semi_set_ret(CPUState *cs, target_ulong ret)
+{
+ARMCPU *cpu = ARM_CPU(cs);
+CPUARMState *env = >env;
+if (is_a64(env)) {
+env->xregs[0] = ret;
+} else {
+env->regs[0] = ret;
+}
+}
+
+static inline bool
+common_semi_sys_exit_extended(CPUState *cs, int nr)
+{
+return (nr == TARGET_SYS_EXIT_EXTENDED || is_a64(cs->env_ptr));
+}
+
+#ifndef CONFIG_USER_ONLY
+#include "hw/arm/boot.h"
+static inline target_ulong
+common_semi_rambase(CPUState *cs)
+{
+CPUArchState *env = cs->env_ptr;
+const struct arm_boot_info *info = env->boot_info;
+return info->loader_start;
+}
+#endif
+
+#endif /* TARGET_ARM */
+
 /*
  * Allocate a new guest file descriptor and return it; if we
  * couldn't allocate a new fd then return -1.
@@ -238,11 +282,10 @@ static target_ulong syscall_err;
 #include "exec/softmmu-semi.h"
 #endif
 
-static inline uint32_t set_swi_errno(CPUARMState *env, uint32_t code)
+static inline uint32_t set_swi_errno(CPUState *cs, uint32_t code)
 {
 if (code == (uint32_t)-1) {
 #ifdef CONFIG_USER_ONLY
-CPUState *cs = env_cpu(env);
 TaskState *ts = cs->opaque;
 
 ts->swi_errno = errno;
@@ -253,10 +296,9 @@ static inline uint32_t set_swi_errno(CPUARMState *env, 
uint32_t code)
 return code;
 }
 
-static inline uint32_t get_swi_errno(CPUARMState *env)
+static inline uint32_t get_swi_errno(CPUState *cs)
 {
 #ifdef CONFIG_USER_ONLY
-CPUState *cs = env_cpu(env);
 TaskState *ts = cs->opaque;
 
 return ts->swi_errno;
@@ -265,24 +307,22 @@ static inline uint32_t get_swi_errno(CPUARMState *env)
 #endif
 }
 
-static target_ulong arm_semi_syscall_len;
+static target_ulong common_semi_syscall_len;
 
-static void arm_semi_cb(CPUState *cs, target_ulong ret, target_ulong err)
+static void common_semi_cb(CPUState *cs, target_ulong

[PATCH 1/8] semihosting: Move ARM semihosting code to shared directories [v3]

This commit renames two files which provide ARM semihosting support so
that they can be shared by other architectures:

 1. target/arm/arm-semi.c -> hw/semihosting/common-semi.c
 2. linux-user/arm/semihost.c -> linux-user/semihost.c

The build system was modified use a new config variable,
CONFIG_ARM_COMPATIBLE_SEMIHOSTING, which has been added to the ARM
softmmu and linux-user default configs. The contents of the source
files has not been changed in this patch.

Signed-off-by: Keith Packard 
Reviewed-by: Alistair Francis 



v2
Place common-semi.c name in arm_ss, just as arm-semi.c was

v3
Create CONFIG_ARM_COMPATIBLE_SEMIHOSTING and assign in
arm config files
---
 default-configs/devices/arm-softmmu.mak   | 1 +
 default-configs/targets/aarch64-linux-user.mak| 1 +
 default-configs/targets/arm-linux-user.mak| 1 +
 hw/semihosting/Kconfig| 3 +++
 target/arm/arm-semi.c => hw/semihosting/common-semi.c | 0
 hw/semihosting/meson.build| 3 +++
 linux-user/arm/meson.build| 3 ---
 linux-user/meson.build| 1 +
 linux-user/{arm => }/semihost.c   | 0
 target/arm/meson.build| 2 --
 10 files changed, 10 insertions(+), 5 deletions(-)
 rename target/arm/arm-semi.c => hw/semihosting/common-semi.c (100%)
 rename linux-user/{arm => }/semihost.c (100%)

diff --git a/default-configs/devices/arm-softmmu.mak 
b/default-configs/devices/arm-softmmu.mak
index 08a32123b4..0500156a0c 100644
--- a/default-configs/devices/arm-softmmu.mak
+++ b/default-configs/devices/arm-softmmu.mak
@@ -42,4 +42,5 @@ CONFIG_FSL_IMX25=y
 CONFIG_FSL_IMX7=y
 CONFIG_FSL_IMX6UL=y
 CONFIG_SEMIHOSTING=y
+CONFIG_ARM_COMPATIBLE_SEMIHOSTING=y
 CONFIG_ALLWINNER_H3=y
diff --git a/default-configs/targets/aarch64-linux-user.mak 
b/default-configs/targets/aarch64-linux-user.mak
index 163c9209f4..4713253709 100644
--- a/default-configs/targets/aarch64-linux-user.mak
+++ b/default-configs/targets/aarch64-linux-user.mak
@@ -2,3 +2,4 @@ TARGET_ARCH=aarch64
 TARGET_BASE_ARCH=arm
 TARGET_XML_FILES= gdb-xml/aarch64-core.xml gdb-xml/aarch64-fpu.xml 
gdb-xml/arm-core.xml gdb-xml/arm-vfp.xml gdb-xml/arm-vfp3.xml 
gdb-xml/arm-neon.xml gdb-xml/arm-m-profile.xml
 TARGET_HAS_BFLT=y
+CONFIG_ARM_COMPATIBLE_SEMIHOSTING=y
diff --git a/default-configs/targets/arm-linux-user.mak 
b/default-configs/targets/arm-linux-user.mak
index c7cd872e86..e741ffd4d3 100644
--- a/default-configs/targets/arm-linux-user.mak
+++ b/default-configs/targets/arm-linux-user.mak
@@ -3,3 +3,4 @@ TARGET_SYSTBL_ABI=common,oabi
 TARGET_SYSTBL=syscall.tbl
 TARGET_XML_FILES= gdb-xml/arm-core.xml gdb-xml/arm-vfp.xml 
gdb-xml/arm-vfp3.xml gdb-xml/arm-neon.xml gdb-xml/arm-m-profile.xml
 TARGET_HAS_BFLT=y
+CONFIG_ARM_COMPATIBLE_SEMIHOSTING=y
diff --git a/hw/semihosting/Kconfig b/hw/semihosting/Kconfig
index efe0a30734..4c30dc6b16 100644
--- a/hw/semihosting/Kconfig
+++ b/hw/semihosting/Kconfig
@@ -1,3 +1,6 @@
 
 config SEMIHOSTING
bool
+
+config ARM_COMPATIBLE_SEMIHOSTING
+   bool
diff --git a/target/arm/arm-semi.c b/hw/semihosting/common-semi.c
similarity index 100%
rename from target/arm/arm-semi.c
rename to hw/semihosting/common-semi.c
diff --git a/hw/semihosting/meson.build b/hw/semihosting/meson.build
index f40ac574c4..5b4a170270 100644
--- a/hw/semihosting/meson.build
+++ b/hw/semihosting/meson.build
@@ -2,3 +2,6 @@ specific_ss.add(when: 'CONFIG_SEMIHOSTING', if_true: files(
   'config.c',
   'console.c',
 ))
+
+specific_ss.add(when: ['CONFIG_ARM_COMPATIBLE_SEMIHOSTING'],
+   if_true: files('common-semi.c'))
diff --git a/linux-user/arm/meson.build b/linux-user/arm/meson.build
index 432984b58e..5a93c925cf 100644
--- a/linux-user/arm/meson.build
+++ b/linux-user/arm/meson.build
@@ -1,6 +1,3 @@
-linux_user_ss.add(when: 'TARGET_AARCH64', if_true: files('semihost.c'))
-linux_user_ss.add(when: 'TARGET_ARM', if_true: files('semihost.c'))
-
 subdir('nwfpe')
 
 syscall_nr_generators += {
diff --git a/linux-user/meson.build b/linux-user/meson.build
index 2b94e4ba24..7fe28d659e 100644
--- a/linux-user/meson.build
+++ b/linux-user/meson.build
@@ -16,6 +16,7 @@ linux_user_ss.add(rt)
 
 linux_user_ss.add(when: 'TARGET_HAS_BFLT', if_true: files('flatload.c'))
 linux_user_ss.add(when: 'TARGET_I386', if_true: files('vm86.c'))
+linux_user_ss.add(when: 'CONFIG_ARM_COMPATIBLE_SEMIHOSTING', if_true: 
files('semihost.c'))
 
 
 syscall_nr_generators = {}
diff --git a/linux-user/arm/semihost.c b/linux-user/semihost.c
similarity index 100%
rename from linux-user/arm/semihost.c
rename to linux-user/semihost.c
diff --git a/target/arm/meson.build b/target/arm/meson.build
index f5de2a77b8..15b936c101 100644
--- a/target/arm/meson.build
+++ b/target/arm/meson.build
@@ -32,8 +32,6 @@ arm_ss.add(files(
 ))
 arm_ss.add(zlib)
 
-arm_ss.add(when: 'CONFIG_TCG', if_true: files('arm-semi.c'))
-

[PATCH 0/8] Add RISC-V semihosting 0.2. Finish ARM semihosting 2.0

This series adds support for RISC-V Semihosting, version 0.2 as
specified here:

https://github.com/riscv/riscv-semihosting-spec/releases/tag/0.2

This specification references the ARM semihosting release 2.0 as specified here:

https://static.docs.arm.com/100863/0200/semihosting.pdf

That specification includes several semihosting calls which were not
previously implemented. This series includes implementations for the
remaining calls so that both RISC-V and ARM versions are now complete.

Tests for release 2.0 can be found in picolibc on the semihost-2.0-all
branch:

https://github.com/picolibc/picolibc/tree/semihost-2.0-all

These tests uncovered a bug in the SYS_HEAPINFO implementation for
ARM, which has been fixed in this series as well.

The series is structured as follows:

 1. Move shared semihosting files
 2. Change public common semihosting APIs
 3. Change internal semihosting interfaces
 4. Fix SYS_HEAPINFO crash on ARM
 5. Add RISC-V semihosting implementation
 6-8. Add missing semihosting operations from release 2.0

Signed-off-by: Keith Packard

[PATCH 2/8] semihosting: Change common-semi API to be architecture-independent

The public API is now defined in
hw/semihosting/common-semi.h. do_common_semihosting takes CPUState *
instead of CPUARMState *. All internal functions have been renamed
common_semi_ instead of arm_semi_ or arm_. Aside from the API change,
there are no functional changes in this patch.

Signed-off-by: Keith Packard 
Reviewed-by: Alistair Francis 
---
 hw/semihosting/common-semi.c  | 16 ++--
 hw/semihosting/common-semi.h  | 36 +++
 linux-user/aarch64/cpu_loop.c |  3 ++-
 linux-user/arm/cpu_loop.c |  3 ++-
 target/arm/cpu.h  |  8 
 target/arm/helper.c   |  5 +++--
 target/arm/m_helper.c |  7 ++-
 7 files changed, 59 insertions(+), 19 deletions(-)
 create mode 100644 hw/semihosting/common-semi.h

diff --git a/hw/semihosting/common-semi.c b/hw/semihosting/common-semi.c
index c892e0e674..cafbe579c7 100644
--- a/hw/semihosting/common-semi.c
+++ b/hw/semihosting/common-semi.c
@@ -1,10 +1,14 @@
 /*
- *  Arm "Angel" semihosting syscalls
+ *  Semihosting support for systems modeled on the Arm "Angel"
+ *  semihosting syscalls design.
  *
  *  Copyright (c) 2005, 2007 CodeSourcery.
  *  Copyright (c) 2019 Linaro
  *  Written by Paul Brook.
  *
+ *  Copyright © 2020 by Keith Packard 
+ *  Adapted for systems other than ARM, including RISC-V, by Keith Packard
+ *
  *  This program is free software; you can redistribute it and/or modify
  *  it under the terms of the GNU General Public License as published by
  *  the Free Software Foundation; either version 2 of the License, or
@@ -372,12 +376,12 @@ static target_ulong arm_gdb_syscall(ARMCPU *cpu, 
gdb_syscall_complete_cb cb,
  * do anything with its return value, because it is not necessarily
  * the result of the syscall, but could just be the old value of X0.
  * The only thing safe to do with this is that the callers of
- * do_arm_semihosting() will write it straight back into X0.
+ * do_common_semihosting() will write it straight back into X0.
  * (In linux-user mode, the callback will have happened before
  * gdb_do_syscallv() returns.)
  *
  * We should tidy this up so neither this function nor
- * do_arm_semihosting() return a value, so the mistake of
+ * do_common_semihosting() return a value, so the mistake of
  * doing something with the return value is not possible to make.
  */
 
@@ -674,10 +678,10 @@ static const GuestFDFunctions guestfd_fns[] = {
  * leave the register unchanged. We use 0xdeadbeef as the return value
  * when there isn't a defined return value for the call.
  */
-target_ulong do_arm_semihosting(CPUARMState *env)
+target_ulong do_common_semihosting(CPUState *cs)
 {
-ARMCPU *cpu = env_archcpu(env);
-CPUState *cs = env_cpu(env);
+ARMCPU *cpu = ARM_CPU(cs);
+CPUARMState *env = >env;
 target_ulong args;
 target_ulong arg0, arg1, arg2, arg3;
 char * s;
diff --git a/hw/semihosting/common-semi.h b/hw/semihosting/common-semi.h
new file mode 100644
index 00..bc53e92c79
--- /dev/null
+++ b/hw/semihosting/common-semi.h
@@ -0,0 +1,36 @@
+/*
+ *  Semihosting support for systems modeled on the Arm "Angel"
+ *  semihosting syscalls design.
+ *
+ *  Copyright (c) 2005, 2007 CodeSourcery.
+ *  Copyright (c) 2019 Linaro
+ *  Written by Paul Brook.
+ *
+ *  Copyright © 2020 by Keith Packard 
+ *  Adapted for systems other than ARM, including RISC-V, by Keith Packard
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, see .
+ *
+ *  ARM Semihosting is documented in:
+ * Semihosting for AArch32 and AArch64 Release 2.0
+ * https://static.docs.arm.com/100863/0200/semihosting.pdf
+ *
+ */
+
+#ifndef COMMON_SEMI_H
+#define COMMON_SEMI_H
+
+target_ulong do_common_semihosting(CPUState *cs);
+
+#endif /* COMMON_SEMI_H */
diff --git a/linux-user/aarch64/cpu_loop.c b/linux-user/aarch64/cpu_loop.c
index bbe9fefca8..42b9c15f53 100644
--- a/linux-user/aarch64/cpu_loop.c
+++ b/linux-user/aarch64/cpu_loop.c
@@ -22,6 +22,7 @@
 #include "qemu.h"
 #include "cpu_loop-common.h"
 #include "qemu/guest-random.h"
+#include "hw/semihosting/common-semi.h"
 
 #define get_user_code_u32(x, gaddr, env)\
 ({ abi_long __r = get_user_u32((x), (gaddr));   \
@@ -129,7 +130,7 @@ void cpu_loop(CPUARMState *env)
 queue_signal(env, info.si_signo, QEMU_SI_FAULT, );

Re: [PATCH for-5.2] nsis: Fix build for 64 bit installer

2020-11-25 Thread Marc-André Lureau

On Wed, Nov 25, 2020 at 11:28 PM Peter Maydell 
wrote:

> On Wed, 25 Nov 2020 at 19:23, Stefan Weil  wrote:
> >
> > Pass cpu instead of cpu_family to the NSIS installer script.
> >
> > That script checks for "x86_64" which is the cpu value,
> > while cpu_family is "x86".
> >
> > Signed-off-by: Stefan Weil 
> > ---
> >  meson.build | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
>
> Very unfortunate that this has only surfaced after rc3,
> which should in theory be the cutoff point for 5.2 changes.
>

There is also "[PATCH] qxl: fix segfault" that missed rc3.

-- 
Marc-André Lureau

Re: [PATCH for-5.2] nsis: Fix build for 64 bit installer

2020-11-25 Thread Marc-André Lureau

On Wed, Nov 25, 2020 at 11:22 PM Stefan Weil  wrote:

> Pass cpu instead of cpu_family to the NSIS installer script.
>
> That script checks for "x86_64" which is the cpu value,
> while cpu_family is "x86".
>
> Signed-off-by: Stefan Weil 
>

Reviewed-by: Marc-André Lureau 

---
>  meson.build | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meson.build b/meson.build
> index 5062407c70..8a99c948d3 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -1956,7 +1956,7 @@ if host_machine.system() == 'windows'
>  '@OUTPUT@',
>  get_option('prefix'),
>  meson.current_source_dir(),
> -host_machine.cpu_family(),
> +host_machine.cpu(),
>  '--',
>  '-DDISPLAYVERSION=' + meson.project_version(),
>]
> --
> 2.29.2
>
>
>

-- 
Marc-André Lureau

Re: [PATCH v9 08/12] hw/block/nvme: Support Zoned Namespace Command Set

2020-11-25 Thread Klaus Jensen

On Nov 17 16:32, Keith Busch wrote:
> On Thu, Nov 12, 2020 at 08:36:39PM +0100, Klaus Jensen wrote:
> > On Nov  5 11:53, Dmitry Fomichev wrote:
> > > @@ -133,6 +300,12 @@ static Property nvme_ns_props[] = {
> > >  DEFINE_BLOCK_PROPERTIES(NvmeNamespace, blkconf),
> > >  DEFINE_PROP_UINT32("nsid", NvmeNamespace, params.nsid, 0),
> > >  DEFINE_PROP_UUID("uuid", NvmeNamespace, params.uuid),
> > > +DEFINE_PROP_BOOL("zoned", NvmeNamespace, params.zoned, false),
> > 
> > I disagree on this. Using the "magic" value ensures that only one
> > command set can be selected. We can do a custom property so we can set
> > `iocs=zoned` as well as `iocs=0x2` if that makes it more user friendly?
> 
> IMO, 'iocs' is a rather difficult parameter name for a user to remember
> compared to 'zoned=true'. While 'iocs' is a spec field, the spec isn't
> very user friendly either, and these user parameters can hide the spec
> terms behind human comprehensible names.
> 

I'm okay with a "zoned" bool parameter and having zone size and capacity
in bytes. But parameters such as ZASL, MAR and MOR are "expert"
parameters so I think its better to use the spec field names and
meanings for those. The nvme device already has precedence for using
spec field names (and meanings, e.g. zeroes based) for "expert"
parameters (mdts, aerl).


signature.asc
Description: PGP signature

[Bug 1833053] Re: qemu guest crashes on spice client USB redirected device removal

2020-11-25 Thread Nikolay Kichukov

** Changed in: qemu
   Status: Incomplete => 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/1833053

Title:
  qemu guest crashes on spice client USB redirected device removal

Status in QEMU:
  New

Bug description:
  Hello,

  I am experiencing guest crashes, which cannot be reproduced at all
  times, but are pretty frequent (4 out of 5 tries it would crash). The
  guest crashes when a previously attached USB redirected device through
  SPICE has been removed by the client.

  Steps to reproduce:
  1.) Start windows 10 guest with display driver Spice
  2.) Connect to the console with remote-viewer spice://IP:PORT or via 
virt-viewer (tunnelled through SSH)
  3.) Attach a client USB device, for example storage device, iPhone or Android 
phone
  4.) Observe the guest OS detects it and sets it up
  5.) Go back to 'USB device selection' and untick the USB device
  6.) Observe the guest VM crashed and the below assertion was printed in the 
qemu log for this virtual machine:

  qemu-system-x86_64: 
/var/tmp/portage/app-emulation/qemu-4.0.0-r3/work/qemu-4.0.0/hw/usb/core.c:720: 
usb_ep_get: Assertion `dev != NULL' failed.
  2019-06-17 09:25:09.160+: shutting down, reason=crashed

  
  Versions of related packages on the host:
  app-emulation/qemu-4.0.0-r3
  app-emulation/spice-0.14.0-r2:0
  app-emulation/spice-protocol-0.12.14:0
  net-misc/spice-gtk-0.35:0
  Kernel: 5.1.7-gentoo on Intel x86_64 CPU

  Version of the spice-tools on the guest:
  virtio-win 0.1-126
  QXL 0.1-21
  mingw-vdagent-win 0.8.0

  QEMU command line (generated by libvirt):

  /usr/bin/qemu-system-x86_64 -name guest=W10VM,debug-threads=on -S
  -object
  secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-41-W10VM
  /master-key.aes -machine pc-i440fx-2.12,accel=kvm,usb=off,vmport=off
  ,dump-guest-core=off -cpu
  qemu64,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_synic,hv_stimer
  -m 4500 -realtime mlock=off -smp
  2,maxcpus=4,sockets=4,cores=1,threads=1 -uuid b39afae2-5085-4659-891c-
  b3c65e65af2e -no-user-config -nodefaults -chardev
  socket,id=charmonitor,fd=26,server,nowait -mon
  chardev=charmonitor,id=monitor,mode=control -rtc
  base=localtime,driftfix=slew -no-hpet -global kvm-
  pit.lost_tick_policy=delay -no-shutdown -global PIIX4_PM.disable_s3=1
  -global PIIX4_PM.disable_s4=1 -boot menu=off,strict=on -device ich9
  -usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-
  uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5
  -device ich9-usb-
  uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9
  -usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device
  virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x8 -device virtio-serial-
  pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive
  file=/libvirt/images/W10VM.qcow2,format=qcow2,if=none,id=drive-
  scsi0-0-0-1,cache=unsafe,discard=unmap,detect-zeroes=unmap -device
  scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,device_id=drive-
  scsi0-0-0-1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1,bootindex=1,write-
  cache=on -netdev tap,fd=28,id=hostnet0,vhost=on,vhostfd=29 -device
  virtio-net-
  pci,netdev=hostnet0,id=net0,mac=52:54:00:44:f6:21,bus=pci.0,addr=0x3
  -chardev spicevmc,id=charchannel0,name=vdagent -device
  virtserialport,bus=virtio-
  serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0
  -chardev socket,id=charchannel1,fd=30,server,nowait -device
  virtserialport,bus=virtio-
  serial0.0,nr=3,chardev=charchannel1,id=channel1,name=org.qemu.guest_agent.0
  -chardev spiceport,id=charchannel2,name=org.spice-space.webdav.0
  -device virtserialport,bus=virtio-
  serial0.0,nr=2,chardev=charchannel2,id=channel2,name=org.spice-
  space.webdav.0 -spice port=5901,addr=0.0.0.0,seamless-migration=on
  -device qxl-
  
vga,id=video0,ram_size=134217728,vram_size=134217728,vram64_size_mb=0,vgamem_mb=64,max_outputs=1,bus=pci.0,addr=0x2
  -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-
  duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev
  spicevmc,id=charredir0,name=usbredir -device usb-
  redir,chardev=charredir0,id=redir0,bus=usb.0,port=1 -chardev
  spicevmc,id=charredir1,name=usbredir -device usb-
  redir,chardev=charredir1,id=redir1,bus=usb.0,port=2 -device virtio-
  balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -sandbox
  on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny
  -msg timestamp=on

  
  I have attempted to collect a backtrace, but will need direction as I am not 
sure on which thread to listen and where to set the breakpoint, 'thread apply 
all backtrace' does not seem to work well with the qemu process...

  Thank you

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

[PATCH v2 5/6] Remove unnecessary usage of arch_init.h

The only declarations in arch_init.h are the `arch_type` variable
and the QEMU_ARCH_* constants.  Stop including arch_init.h from
code that don't use neither.

Patch generated automatically using the command:

 $ sed -i -e '/#include "sysemu.arch_init.h"/d' \
   $(comm -23 \
  <(git grep -l arch_init.h | sort) \
  <((git grep -l -w 'arch_type'; g grep -l QEMU_ARCH;) | sort -u))

Signed-off-by: Eduardo Habkost 
---
Cc: Richard Henderson 
Cc: Paolo Bonzini 
Cc: Eduardo Habkost 
Cc: "Michael S. Tsirkin" 
Cc: Marcel Apfelbaum 
Cc: "Hervé Poussineau" 
Cc: Aleksandar Rikalo 
Cc: "Philippe Mathieu-Daudé" 
Cc: Aurelien Jarno 
Cc: Jiaxun Yang 
Cc: David Gibson 
Cc: Palmer Dabbelt 
Cc: Alistair Francis 
Cc: Sagar Karandikar 
Cc: Bastian Koppelmann 
Cc: Markus Armbruster 
Cc: David Hildenbrand 
Cc: Cornelia Huck 
Cc: Thomas Huth 
Cc: Halil Pasic 
Cc: Christian Borntraeger 
Cc: qemu-devel@nongnu.org
Cc: qemu-...@nongnu.org
Cc: qemu-ri...@nongnu.org
Cc: qemu-s3...@nongnu.org
---
 accel/accel.c   | 1 -
 hw/i386/pc.c| 1 -
 hw/i386/pc_piix.c   | 1 -
 hw/i386/pc_q35.c| 1 -
 hw/mips/jazz.c  | 1 -
 hw/mips/malta.c | 1 -
 hw/ppc/prep.c   | 1 -
 hw/riscv/sifive_e.c | 1 -
 hw/riscv/sifive_u.c | 1 -
 hw/riscv/spike.c| 1 -
 hw/riscv/virt.c | 1 -
 monitor/qmp-cmds.c  | 1 -
 target/i386/cpu.c   | 1 -
 target/s390x/cpu.c  | 1 -
 target/s390x/cpu_models.c   | 1 -
 target/ppc/translate_init.c.inc | 1 -
 16 files changed, 16 deletions(-)

diff --git a/accel/accel.c b/accel/accel.c
index 4a64a2b38a..3e567a001f 100644
--- a/accel/accel.c
+++ b/accel/accel.c
@@ -26,7 +26,6 @@
 #include "qemu/osdep.h"
 #include "sysemu/accel.h"
 #include "hw/boards.h"
-#include "sysemu/arch_init.h"
 #include "sysemu/sysemu.h"
 #include "qom/object.h"
 
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 17b514d1da..48a5fb0798 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -67,7 +67,6 @@
 #include "ui/qemu-spice.h"
 #include "exec/memory.h"
 #include "exec/address-spaces.h"
-#include "sysemu/arch_init.h"
 #include "qemu/bitmap.h"
 #include "qemu/config-file.h"
 #include "qemu/error-report.h"
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 13d1628f13..95ee1f39d8 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -44,7 +44,6 @@
 #include "hw/kvm/clock.h"
 #include "sysemu/sysemu.h"
 #include "hw/sysbus.h"
-#include "sysemu/arch_init.h"
 #include "hw/i2c/smbus_eeprom.h"
 #include "hw/xen/xen-x86.h"
 #include "exec/memory.h"
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index a3f4959c43..cf85b240bc 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -31,7 +31,6 @@
 #include "qemu/osdep.h"
 #include "qemu/units.h"
 #include "hw/loader.h"
-#include "sysemu/arch_init.h"
 #include "hw/i2c/smbus_eeprom.h"
 #include "hw/rtc/mc146818rtc.h"
 #include "sysemu/kvm.h"
diff --git a/hw/mips/jazz.c b/hw/mips/jazz.c
index 71448f72ac..6fee2a4ec0 100644
--- a/hw/mips/jazz.c
+++ b/hw/mips/jazz.c
@@ -34,7 +34,6 @@
 #include "hw/isa/isa.h"
 #include "hw/block/fdc.h"
 #include "sysemu/sysemu.h"
-#include "sysemu/arch_init.h"
 #include "hw/boards.h"
 #include "net/net.h"
 #include "hw/scsi/esp.h"
diff --git a/hw/mips/malta.c b/hw/mips/malta.c
index 9d1a3b50b7..6b4387c179 100644
--- a/hw/mips/malta.c
+++ b/hw/mips/malta.c
@@ -38,7 +38,6 @@
 #include "hw/mips/cpudevs.h"
 #include "hw/pci/pci.h"
 #include "sysemu/sysemu.h"
-#include "sysemu/arch_init.h"
 #include "qemu/log.h"
 #include "hw/mips/bios.h"
 #include "hw/ide.h"
diff --git a/hw/ppc/prep.c b/hw/ppc/prep.c
index 4a0cb434a6..5c9ec45749 100644
--- a/hw/ppc/prep.c
+++ b/hw/ppc/prep.c
@@ -43,7 +43,6 @@
 #include "hw/rtc/mc146818rtc.h"
 #include "hw/isa/pc87312.h"
 #include "hw/qdev-properties.h"
-#include "sysemu/arch_init.h"
 #include "sysemu/kvm.h"
 #include "sysemu/qtest.h"
 #include "sysemu/reset.h"
diff --git a/hw/riscv/sifive_e.c b/hw/riscv/sifive_e.c
index 59bac4cc9a..6185872127 100644
--- a/hw/riscv/sifive_e.c
+++ b/hw/riscv/sifive_e.c
@@ -46,7 +46,6 @@
 #include "hw/intc/sifive_plic.h"
 #include "hw/misc/sifive_e_prci.h"
 #include "chardev/char.h"
-#include "sysemu/arch_init.h"
 #include "sysemu/sysemu.h"
 #include "exec/address-spaces.h"
 
diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c
index 2f19a9cda2..53b62284ab 100644
--- a/hw/riscv/sifive_u.c
+++ b/hw/riscv/sifive_u.c
@@ -53,7 +53,6 @@
 #include "hw/intc/sifive_plic.h"
 #include "chardev/char.h"
 #include "net/eth.h"
-#include "sysemu/arch_init.h"
 #include "sysemu/device_tree.h"
 #include "sysemu/runstate.h"
 #include "sysemu/sysemu.h"
diff --git a/hw/riscv/spike.c b/hw/riscv/spike.c
index facac6e7d2..660fcfcfed 100644
--- a/hw/riscv/spike.c
+++ b/hw/riscv/spike.c
@@ -38,7 +38,6 @@
 #include "hw/char/riscv_htif.h"
 #include "hw/intc/sifive_clint.h"
 #include "chardev/char.h"
-#include "sysemu/arch_init.h"
 #include

Re: [PATCH for-5.2] nsis: Fix build for 64 bit installer

2020-11-25 Thread Stefan Weil


Am 25.11.20 um 20:28 schrieb Peter Maydell:


On Wed, 25 Nov 2020 at 19:23, Stefan Weil  wrote:

Pass cpu instead of cpu_family to the NSIS installer script.

That script checks for "x86_64" which is the cpu value,
while cpu_family is "x86".

Signed-off-by: Stefan Weil 
---
  meson.build | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

Very unfortunate that this has only surfaced after rc3,
which should in theory be the cutoff point for 5.2 changes.
Is it possible to get something into the CI/make check
so that we find Windows installer issues sooner?

thanks
-- PMM



I am afraid there are more open issues for QEMU on Windows. They can be 
fixed in 5.2.1, so don't hesitate to finish 5.2.0.


The Meson based build sets bindir=/qemu/. which does not work correctly 
in get_relocated_path().


Finding such issues would require a CI environment which not only builds 
QEMU for Windows, but also runs the results. Some basic tests could be 
done on Linux using Wine, more advanced tests would require a real 
Windows host.


Regards,
Stefan

[PATCH v2 4/6] xen: Delete xen_available() function

The function can be replaced with accel_available("xen").

Signed-off-by: Eduardo Habkost 
---
Cc: Paolo Bonzini 
Cc: qemu-devel@nongnu.org
Cc: Stefano Stabellini 
Cc: Anthony Perard 
Cc: Paul Durrant 
Cc: xen-de...@lists.xenproject.org
Cc: Richard Henderson 
Cc: Claudio Fontana 
Cc: Roman Bolshakov 
---
 include/sysemu/arch_init.h | 2 --
 softmmu/arch_init.c| 9 -
 softmmu/vl.c   | 6 +++---
 3 files changed, 3 insertions(+), 14 deletions(-)

diff --git a/include/sysemu/arch_init.h b/include/sysemu/arch_init.h
index b32ce1afa9..40ac8052b7 100644
--- a/include/sysemu/arch_init.h
+++ b/include/sysemu/arch_init.h
@@ -32,6 +32,4 @@ enum {
 
 extern const uint32_t arch_type;
 
-int xen_available(void);
-
 #endif
diff --git a/softmmu/arch_init.c b/softmmu/arch_init.c
index 79383c8db8..f4770931f5 100644
--- a/softmmu/arch_init.c
+++ b/softmmu/arch_init.c
@@ -49,12 +49,3 @@ int graphic_depth = 32;
 
 
 const uint32_t arch_type = QEMU_ARCH;
-
-int xen_available(void)
-{
-#ifdef CONFIG_XEN
-return 1;
-#else
-return 0;
-#endif
-}
diff --git a/softmmu/vl.c b/softmmu/vl.c
index e6e0ad5a92..74b6ebf1e4 100644
--- a/softmmu/vl.c
+++ b/softmmu/vl.c
@@ -3667,21 +3667,21 @@ void qemu_init(int argc, char **argv, char **envp)
 has_defaults = 0;
 break;
 case QEMU_OPTION_xen_domid:
-if (!(xen_available())) {
+if (!(accel_available("xen"))) {
 error_report("Option not supported for this target");
 exit(1);
 }
 xen_domid = atoi(optarg);
 break;
 case QEMU_OPTION_xen_attach:
-if (!(xen_available())) {
+if (!(accel_available("xen"))) {
 error_report("Option not supported for this target");
 exit(1);
 }
 xen_mode = XEN_ATTACH;
 break;
 case QEMU_OPTION_xen_domid_restrict:
-if (!(xen_available())) {
+if (!(accel_available("xen"))) {
 error_report("Option not supported for this target");
 exit(1);
 }
-- 
2.28.0

[PATCH v2 3/6] kvm: Remove kvm_available() function

The only caller can use accel_available("kvm") instead.

Signed-off-by: Eduardo Habkost 
---
Cc: Markus Armbruster 
Cc: qemu-devel@nongnu.org
Cc: Paolo Bonzini 
Cc: k...@vger.kernel.org
Cc: Richard Henderson 
Cc: Paolo Bonzini 
Cc: Claudio Fontana 
Cc: Roman Bolshakov 
---
 include/sysemu/arch_init.h | 1 -
 monitor/qmp-cmds.c | 2 +-
 softmmu/arch_init.c| 9 -
 3 files changed, 1 insertion(+), 11 deletions(-)

diff --git a/include/sysemu/arch_init.h b/include/sysemu/arch_init.h
index 54f069d491..b32ce1afa9 100644
--- a/include/sysemu/arch_init.h
+++ b/include/sysemu/arch_init.h
@@ -32,7 +32,6 @@ enum {
 
 extern const uint32_t arch_type;
 
-int kvm_available(void);
 int xen_available(void);
 
 #endif
diff --git a/monitor/qmp-cmds.c b/monitor/qmp-cmds.c
index a08143b323..ac5b8a97d7 100644
--- a/monitor/qmp-cmds.c
+++ b/monitor/qmp-cmds.c
@@ -57,7 +57,7 @@ KvmInfo *qmp_query_kvm(Error **errp)
 KvmInfo *info = g_malloc0(sizeof(*info));
 
 info->enabled = kvm_enabled();
-info->present = kvm_available();
+info->present = accel_available("kvm");
 
 return info;
 }
diff --git a/softmmu/arch_init.c b/softmmu/arch_init.c
index 7ef32a98b9..79383c8db8 100644
--- a/softmmu/arch_init.c
+++ b/softmmu/arch_init.c
@@ -50,15 +50,6 @@ int graphic_depth = 32;
 
 const uint32_t arch_type = QEMU_ARCH;
 
-int kvm_available(void)
-{
-#ifdef CONFIG_KVM
-return 1;
-#else
-return 0;
-#endif
-}
-
 int xen_available(void)
 {
 #ifdef CONFIG_XEN
-- 
2.28.0

[PATCH v2 6/6] Rename arch_init.h to arch_type.h

The only declarations in arch_init.h are related to the arch_type
variable (which is a useful feature that allows us to simplify
command line option handling).  Rename the header to reflect its
purpose.

Signed-off-by: Eduardo Habkost 
---
Cc: Markus Armbruster 
Cc: Kevin Wolf 
Cc: Max Reitz 
Cc: Paolo Bonzini 
Cc: "Daniel P. Berrangé" 
Cc: Eduardo Habkost 
Cc: qemu-bl...@nongnu.org
Cc: qemu-devel@nongnu.org
---
 include/sysemu/{arch_init.h => arch_type.h} | 0
 blockdev.c  | 2 +-
 softmmu/arch_init.c | 2 +-
 softmmu/qdev-monitor.c  | 2 +-
 softmmu/vl.c| 2 +-
 stubs/arch_type.c   | 2 +-
 6 files changed, 5 insertions(+), 5 deletions(-)
 rename include/sysemu/{arch_init.h => arch_type.h} (100%)

diff --git a/include/sysemu/arch_init.h b/include/sysemu/arch_type.h
similarity index 100%
rename from include/sysemu/arch_init.h
rename to include/sysemu/arch_type.h
diff --git a/blockdev.c b/blockdev.c
index fe6fb5dc1d..46c10b2609 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -56,7 +56,7 @@
 #include "sysemu/iothread.h"
 #include "block/block_int.h"
 #include "block/trace.h"
-#include "sysemu/arch_init.h"
+#include "sysemu/arch_type.h"
 #include "sysemu/qtest.h"
 #include "sysemu/runstate.h"
 #include "sysemu/replay.h"
diff --git a/softmmu/arch_init.c b/softmmu/arch_init.c
index f4770931f5..5a9bc56387 100644
--- a/softmmu/arch_init.c
+++ b/softmmu/arch_init.c
@@ -24,7 +24,7 @@
 #include "qemu/osdep.h"
 #include "cpu.h"
 #include "sysemu/sysemu.h"
-#include "sysemu/arch_init.h"
+#include "sysemu/arch_type.h"
 #include "hw/pci/pci.h"
 #include "hw/audio/soundhw.h"
 #include "qapi/error.h"
diff --git a/softmmu/qdev-monitor.c b/softmmu/qdev-monitor.c
index bf79d0bbcd..c8b7fb27dc 100644
--- a/softmmu/qdev-monitor.c
+++ b/softmmu/qdev-monitor.c
@@ -22,7 +22,7 @@
 #include "monitor/hmp.h"
 #include "monitor/monitor.h"
 #include "monitor/qdev.h"
-#include "sysemu/arch_init.h"
+#include "sysemu/arch_type.h"
 #include "qapi/error.h"
 #include "qapi/qapi-commands-qdev.h"
 #include "qapi/qmp/qdict.h"
diff --git a/softmmu/vl.c b/softmmu/vl.c
index 74b6ebf1e4..1dd63b2782 100644
--- a/softmmu/vl.c
+++ b/softmmu/vl.c
@@ -95,7 +95,7 @@
 #include "trace/control.h"
 #include "qemu/plugin.h"
 #include "qemu/queue.h"
-#include "sysemu/arch_init.h"
+#include "sysemu/arch_type.h"
 
 #include "ui/qemu-spice.h"
 #include "qapi/string-input-visitor.h"
diff --git a/stubs/arch_type.c b/stubs/arch_type.c
index fc5423bc98..603a49deec 100644
--- a/stubs/arch_type.c
+++ b/stubs/arch_type.c
@@ -1,4 +1,4 @@
 #include "qemu/osdep.h"
-#include "sysemu/arch_init.h"
+#include "sysemu/arch_type.h"
 
 const uint32_t arch_type = QEMU_ARCH_NONE;
-- 
2.28.0

[PATCH v2 2/6] accel: accel_available() function

This function will be used to replace the xen_available() and
kvm_available() functions from arch_init.c.

Signed-off-by: Eduardo Habkost 
---
Cc: Richard Henderson 
Cc: Paolo Bonzini 
Cc: Claudio Fontana 
Cc: Roman Bolshakov 
---
 include/sysemu/accel.h | 1 +
 accel/accel.c  | 5 +
 2 files changed, 6 insertions(+)

diff --git a/include/sysemu/accel.h b/include/sysemu/accel.h
index e08b8ab8fa..a4a00c75c8 100644
--- a/include/sysemu/accel.h
+++ b/include/sysemu/accel.h
@@ -67,6 +67,7 @@ typedef struct AccelClass {
 OBJECT_GET_CLASS(AccelClass, (obj), TYPE_ACCEL)
 
 AccelClass *accel_find(const char *opt_name);
+bool accel_available(const char *name);
 int accel_init_machine(AccelState *accel, MachineState *ms);
 
 /* Called just before os_setup_post (ie just before drop OS privs) */
diff --git a/accel/accel.c b/accel/accel.c
index cb555e3b06..4a64a2b38a 100644
--- a/accel/accel.c
+++ b/accel/accel.c
@@ -46,6 +46,11 @@ AccelClass *accel_find(const char *opt_name)
 return ac;
 }
 
+bool accel_available(const char *name)
+{
+return accel_find(name) != NULL;
+}
+
 int accel_init_machine(AccelState *accel, MachineState *ms)
 {
 AccelClass *acc = ACCEL_GET_CLASS(accel);
-- 
2.28.0

[PATCH v2 0/6] arch_init.c cleanup

This series gets rid of most of the code in arch_init.c.  It
moves the QEMU_ARCH macro definitions to corresponding cpu.h
files, and gets rid of kvm_available() and xen_available().

After this series, only two things remain in arch_init.c:
- the arch_type variable, which seems to be a useful feature; and
- the initialization of graphic_width/graphic_height/graphic_depth,
  which is a hack we must eventually get rid of.

Gerd got rid of the graphic_* initialization hack once (in 2017),
but the series was never merged:
https://lore.kernel.org/qemu-devel/1487715299-21102-5-git-send-email-kra...@redhat.com

Eduardo Habkost (6):
  arch_init: Move QEMU_ARCH definitions to cpu.h
  accel: accel_available() function
  kvm: Remove kvm_available() function
  xen: Delete xen_available() function
  Remove unnecessary usage of arch_init.h
  Rename arch_init.h to arch_type.h

 include/sysemu/accel.h  |  1 +
 include/sysemu/{arch_init.h => arch_type.h} |  3 -
 target/alpha/cpu.h  |  1 +
 target/arm/cpu.h|  1 +
 target/avr/cpu.h|  1 +
 target/cris/cpu.h   |  1 +
 target/hppa/cpu.h   |  1 +
 target/i386/cpu.h   |  1 +
 target/lm32/cpu.h   |  1 +
 target/m68k/cpu.h   |  1 +
 target/microblaze/cpu.h |  1 +
 target/mips/cpu.h   |  1 +
 target/moxie/cpu.h  |  1 +
 target/nios2/cpu.h  |  1 +
 target/openrisc/cpu.h   |  1 +
 target/ppc/cpu.h|  1 +
 target/riscv/cpu.h  |  1 +
 target/rx/cpu.h |  1 +
 target/s390x/cpu.h  |  1 +
 target/sh4/cpu.h|  1 +
 target/sparc/cpu.h  |  1 +
 target/tricore/cpu.h|  1 +
 target/unicore32/cpu.h  |  1 +
 target/xtensa/cpu.h |  1 +
 accel/accel.c   |  6 +-
 blockdev.c  |  2 +-
 hw/i386/pc.c|  1 -
 hw/i386/pc_piix.c   |  1 -
 hw/i386/pc_q35.c|  1 -
 hw/mips/jazz.c  |  1 -
 hw/mips/malta.c |  1 -
 hw/ppc/prep.c   |  1 -
 hw/riscv/sifive_e.c |  1 -
 hw/riscv/sifive_u.c |  1 -
 hw/riscv/spike.c|  1 -
 hw/riscv/virt.c |  1 -
 monitor/qmp-cmds.c  |  3 +-
 softmmu/arch_init.c | 66 +
 softmmu/qdev-monitor.c  |  2 +-
 softmmu/vl.c|  8 +--
 stubs/arch_type.c   |  2 +-
 target/i386/cpu.c   |  1 -
 target/s390x/cpu.c  |  1 -
 target/s390x/cpu_models.c   |  1 -
 target/ppc/translate_init.c.inc |  1 -
 45 files changed, 37 insertions(+), 92 deletions(-)
 rename include/sysemu/{arch_init.h => arch_type.h} (94%)

-- 
2.28.0

[PATCH v2 1/6] arch_init: Move QEMU_ARCH definitions to cpu.h

Instead of a collection of #ifdefs on arch_init.c, define
QEMU_ARCH inside each cpu.h file.

Signed-off-by: Eduardo Habkost 
---
Cc: Richard Henderson 
Cc: Peter Maydell 
Cc: Michael Rolnik 
Cc: Sarah Harris 
Cc: "Edgar E. Iglesias" 
Cc: Paolo Bonzini 
Cc: Eduardo Habkost 
Cc: Michael Walle 
Cc: Laurent Vivier 
Cc: "Philippe Mathieu-Daudé" 
Cc: Aurelien Jarno 
Cc: Jiaxun Yang 
Cc: Aleksandar Rikalo 
Cc: Anthony Green 
Cc: Chris Wulff 
Cc: Marek Vasut 
Cc: Stafford Horne 
Cc: David Gibson 
Cc: Palmer Dabbelt 
Cc: Alistair Francis 
Cc: Sagar Karandikar 
Cc: Bastian Koppelmann 
Cc: Yoshinori Sato 
Cc: David Hildenbrand 
Cc: Cornelia Huck 
Cc: Thomas Huth 
Cc: Mark Cave-Ayland 
Cc: Artyom Tarasenko 
Cc: Guan Xuetao 
Cc: Max Filippov 
Cc: qemu-devel@nongnu.org
Cc: qemu-...@nongnu.org
Cc: qemu-...@nongnu.org
Cc: qemu-ri...@nongnu.org
Cc: qemu-s3...@nongnu.org
---
 target/alpha/cpu.h  |  1 +
 target/arm/cpu.h|  1 +
 target/avr/cpu.h|  1 +
 target/cris/cpu.h   |  1 +
 target/hppa/cpu.h   |  1 +
 target/i386/cpu.h   |  1 +
 target/lm32/cpu.h   |  1 +
 target/m68k/cpu.h   |  1 +
 target/microblaze/cpu.h |  1 +
 target/mips/cpu.h   |  1 +
 target/moxie/cpu.h  |  1 +
 target/nios2/cpu.h  |  1 +
 target/openrisc/cpu.h   |  1 +
 target/ppc/cpu.h|  1 +
 target/riscv/cpu.h  |  1 +
 target/rx/cpu.h |  1 +
 target/s390x/cpu.h  |  1 +
 target/sh4/cpu.h|  1 +
 target/sparc/cpu.h  |  1 +
 target/tricore/cpu.h|  1 +
 target/unicore32/cpu.h  |  1 +
 target/xtensa/cpu.h |  1 +
 softmmu/arch_init.c | 46 -
 23 files changed, 22 insertions(+), 46 deletions(-)

diff --git a/target/alpha/cpu.h b/target/alpha/cpu.h
index 82df108967..313a4e456e 100644
--- a/target/alpha/cpu.h
+++ b/target/alpha/cpu.h
@@ -438,6 +438,7 @@ void alpha_translate_init(void);
 #define ALPHA_CPU_TYPE_SUFFIX "-" TYPE_ALPHA_CPU
 #define ALPHA_CPU_TYPE_NAME(model) model ALPHA_CPU_TYPE_SUFFIX
 #define CPU_RESOLVING_TYPE TYPE_ALPHA_CPU
+#define QEMU_ARCH QEMU_ARCH_ALPHA
 
 void alpha_cpu_list(void);
 /* you can call this signal handler from your SIGBUS and SIGSEGV
diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index e5514c8286..3f469a6485 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -2822,6 +2822,7 @@ bool write_cpustate_to_list(ARMCPU *cpu, bool kvm_sync);
 #define ARM_CPU_TYPE_SUFFIX "-" TYPE_ARM_CPU
 #define ARM_CPU_TYPE_NAME(name) (name ARM_CPU_TYPE_SUFFIX)
 #define CPU_RESOLVING_TYPE TYPE_ARM_CPU
+#define QEMU_ARCH QEMU_ARCH_ARM
 
 #define cpu_signal_handler cpu_arm_signal_handler
 #define cpu_list arm_cpu_list
diff --git a/target/avr/cpu.h b/target/avr/cpu.h
index d148e8c75a..98f5df0ad7 100644
--- a/target/avr/cpu.h
+++ b/target/avr/cpu.h
@@ -31,6 +31,7 @@
 #define AVR_CPU_TYPE_SUFFIX "-" TYPE_AVR_CPU
 #define AVR_CPU_TYPE_NAME(name) (name AVR_CPU_TYPE_SUFFIX)
 #define CPU_RESOLVING_TYPE TYPE_AVR_CPU
+#define QEMU_ARCH QEMU_ARCH_AVR
 
 #define TCG_GUEST_DEFAULT_MO 0
 
diff --git a/target/cris/cpu.h b/target/cris/cpu.h
index d3b6492909..2482915699 100644
--- a/target/cris/cpu.h
+++ b/target/cris/cpu.h
@@ -249,6 +249,7 @@ enum {
 #define CRIS_CPU_TYPE_SUFFIX "-" TYPE_CRIS_CPU
 #define CRIS_CPU_TYPE_NAME(name) (name CRIS_CPU_TYPE_SUFFIX)
 #define CPU_RESOLVING_TYPE TYPE_CRIS_CPU
+#define QEMU_ARCH QEMU_ARCH_CRIS
 
 #define cpu_signal_handler cpu_cris_signal_handler
 
diff --git a/target/hppa/cpu.h b/target/hppa/cpu.h
index 61178fa6a2..74d813289b 100644
--- a/target/hppa/cpu.h
+++ b/target/hppa/cpu.h
@@ -242,6 +242,7 @@ static inline int cpu_mmu_index(CPUHPPAState *env, bool 
ifetch)
 void hppa_translate_init(void);
 
 #define CPU_RESOLVING_TYPE TYPE_HPPA_CPU
+#define QEMU_ARCH QEMU_ARCH_HPPA
 
 static inline target_ulong hppa_form_gva_psw(target_ureg psw, uint64_t spc,
  target_ureg off)
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 88e8586f8f..03202f610c 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -1971,6 +1971,7 @@ uint64_t cpu_get_tsc(CPUX86State *env);
 #define X86_CPU_TYPE_SUFFIX "-" TYPE_X86_CPU
 #define X86_CPU_TYPE_NAME(name) (name X86_CPU_TYPE_SUFFIX)
 #define CPU_RESOLVING_TYPE TYPE_X86_CPU
+#define QEMU_ARCH QEMU_ARCH_I386
 
 #ifdef TARGET_X86_64
 #define TARGET_DEFAULT_CPU_TYPE X86_CPU_TYPE_NAME("qemu64")
diff --git a/target/lm32/cpu.h b/target/lm32/cpu.h
index ea7c01ca8b..169c0ff19d 100644
--- a/target/lm32/cpu.h
+++ b/target/lm32/cpu.h
@@ -238,6 +238,7 @@ bool lm32_cpu_do_semihosting(CPUState *cs);
 #define LM32_CPU_TYPE_SUFFIX "-" TYPE_LM32_CPU
 #define LM32_CPU_TYPE_NAME(model) model LM32_CPU_TYPE_SUFFIX
 #define CPU_RESOLVING_TYPE TYPE_LM32_CPU
+#define QEMU_ARCH QEMU_ARCH_LM32
 
 #define cpu_list lm32_cpu_list
 #define cpu_signal_handler cpu_lm32_signal_handler
diff --git a/target/m68k/cpu.h b/target/m68k/cpu.h
index 521ac67cdd..87b5324b2c 100644
--- a/target/m68k/cpu.h
+++ b/target/m68k/cpu.h
@@ -514,6 +514,7 @@ enum {

RE: [EXTERNAL] Re: [PATCH] WHPX: support for the kernel-irqchip on/off

2020-11-25 Thread Sunil Muthuswamy

 > Sorry, this has missed the 5.2 soft freeze.  Can you please resend it in
> about a month?
> 
> Thanks,
> 
> Paolo
Paolo, is the branch open now for this kind of change? Where can I track
the branch status?

Re: [DISCUSSION] Allow ACPI default OEM ID and OEM table ID fields to be set.

2020-11-25 Thread Antoine Damhet

On Wed, Nov 25, 2020 at 11:04:55AM -0500, Michael S. Tsirkin wrote:
> On Wed, Nov 25, 2020 at 01:32:51PM +, Richard W.M. Jones wrote:
> > On Wed, Nov 25, 2020 at 02:27:11PM +0100, Antoine Damhet wrote:
> > > Hello,
> > > 
> > > We recently found out that some softwares are effectively crashing
> > > when they detect qemu's `OEM ID` or `OEM table ID` in the ACPI tables.
> > > 
> > > I see no reason not to expose the setting to the user/command-line. A
> > > previous patch has been submitted in 2015[1] but did not get through
> > > because (if I understand correctly) using the IDs on the `SLIC`, `BXPC`
> > > and `RSDT` tables were enough at the time.
> > > 
> > > If you agree, I am willing to forward port the patches of M. Jones but I
> > > need to ask how it would work `Signed-Off`-wise ?
> > 
> > On this point, the patch I sent was actually written by
> > Michael Tokarev, I was only trying to get them upstream.
> > 
> > Rich.
> 
> I think at least one of the issues is that e.g. UEFI at least
> seems to assume unique OEM table IDs e.g. for SSDTs.
> 
> So let's try to be more specific please, which software
> crashes, what does it want to see and in which table.

I'm sorry I cannot give you the name of the crashing software due to a
company policy. But I can tell you that if either `BOCHS ` or `BXPC` is
present in any of the tables it will crash. Any (or at least the few
that I threw at it) other string will work so it seems it's some kind
of DRM-related hypervisor detection.

As for the uniqueness of the table IDs, I guess it would be sane to keep
the same pattern (id+table sig) but allowing the first 4 bytes to be
overridden.

[...]

-- 
Antoine 'xdbob' Damhet

Re: [PATCH v2] Fix build with 64 bits time_t

2020-11-25 Thread Fabrice Fontaine

Le mer. 25 nov. 2020 à 13:06, Gerd Hoffmann  a écrit :
>
> On Wed, Nov 18, 2020 at 09:38:24PM +0100, Fabrice Fontaine wrote:
> > time element is deprecated on new input_event structure in kernel's
> > input.h [1]
> >
> > This will avoid the following build failure:
> >
> > hw/input/virtio-input-host.c: In function 'virtio_input_host_handle_status':
> > hw/input/virtio-input-host.c:198:28: error: 'struct input_event' has no 
> > member named 'time'
> >   198 | if (gettimeofday(, NULL)) {
> >   |^
>
> Fails to build (rhel-7).
>
> >  - Drop define of input_event_{sec,usec} as it is already done in
> >include/standard-headers/linux/input.h
>
> Maybe these are not used?  So it breaks with old system headers?
contrib/vhost-user-input/main.c is including  instead
of ./include/standard-headers/linux/input.h, this could be the root
cause. I'll send a v3.
>
> take care,
>   Gerd
>
Best Regards,

Fabrice

Re: [PATCH 1/1] Fix to show vfio migration stat in migration status

* Kirti Wankhede (kwankh...@nvidia.com) wrote:
> 
> 
> On 11/26/2020 12:33 AM, Dr. David Alan Gilbert wrote:
> > * Kirti Wankhede (kwankh...@nvidia.com) wrote:
> > > 
> > > 
> > > On 11/25/2020 3:00 PM, Dr. David Alan Gilbert wrote:
> > > > * Kirti Wankhede (kwankh...@nvidia.com) wrote:
> > > > > Header file where CONFIG_VFIO is defined is not included in 
> > > > > migration.c
> > > > > file. Include config devices header file in migration.c.
> > > > > 
> > > > > Fixes: 3710586caa5d ("qapi: Add VFIO devices migration stats in 
> > > > > Migration
> > > > > stats")
> > > > > 
> > > > > Signed-off-by: Kirti Wankhede 
> > > > 
> > > > Given it's got build problems; I suggest actually something cleaner
> > > > would be to swing populate_vfio_info into one of the vfio specific
> > > > files, add a stubs/ entry somewhere and then migration.c doesn't need
> > > > to include the device or header stuff.
> > > > 
> > > 
> > > Still function prototype for populate_vfio_info() and its stub has to be
> > > placed in some header file.
> > 
> > Which header file isn't that important;
> 
> Any recommendation which header file to use?

I guess ./include/hw/vfio/vfio.h or one of the other vfio headers that
works even if vfio isn't configured?

Dave

> Thanks,
> Kirti
> 
> > and the stub goes in a file in
> > stubs/
> > 
> > > Earlier I used CONFIG_LINUX instead of CONFIG_VFIO which works here. 
> > > Should
> > > I change it back to CONFIG_LINUX?
> > 
> > No.
> > 
> > > I'm not very much aware of meson build system, I tested by configuring
> > > specific target, but I think by default if target build is not specified
> > > during configuration, it builds for multiple target that's where this 
> > > build
> > > is failing. Any help on how to fix it would be helpful.
> > 
> > With my suggestion you don't have to do anything clever to meson
> > (which I don't know much about either).
> > 
> > Dave
> > 
> > > Thanks,
> > > Kirti
> > > 
> > > > Dave
> > > > 
> > > > > ---
> > > > >meson.build   | 1 +
> > > > >migration/migration.c | 1 +
> > > > >2 files changed, 2 insertions(+)
> > > > > 
> > > > > diff --git a/meson.build b/meson.build
> > > > > index 7ddf983ff7f5..24526499cfb5 100644
> > > > > --- a/meson.build
> > > > > +++ b/meson.build
> > > > > @@ -1713,6 +1713,7 @@ common_ss.add_all(when: 'CONFIG_USER_ONLY', 
> > > > > if_true: user_ss)
> > > > >common_all = common_ss.apply(config_all, strict: false)
> > > > >common_all = static_library('common',
> > > > > +
> > > > > c_args:'-DCONFIG_DEVICES="@0@-config-devices.h"'.format(target) ,
> > > > >build_by_default: false,
> > > > >sources: common_all.sources() + genh,
> > > > >dependencies: 
> > > > > common_all.dependencies(),
> > > > > diff --git a/migration/migration.c b/migration/migration.c
> > > > > index 87a9b59f83f4..650efb81daad 100644
> > > > > --- a/migration/migration.c
> > > > > +++ b/migration/migration.c
> > > > > @@ -57,6 +57,7 @@
> > > > >#include "qemu/queue.h"
> > > > >#include "multifd.h"
> > > > > +#include CONFIG_DEVICES
> > > > >#ifdef CONFIG_VFIO
> > > > >#include "hw/vfio/vfio-common.h"
> > > > >#endif
> > > > > -- 
> > > > > 2.7.0
> > > > > 
> > > 
> 
-- 
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

Re: [Bug 1821054] Re: qemu segfault error when using pcie to dual pci adapter

2020-11-25 Thread Brian Liddle

No I never did. I reached out to try and get info on how to run or get a
backtrack and never heard anything. I finally gave up and ended up
selling the computer since I never got it working how I wanted to.

> On Nov 25, 2020, at 10:20 AM, Thomas Huth <1821...@bugs.launchpad.net> wrote:
> 
> Hi! Did you ever get a backtrace? ... otherwise I think we have to close
> this ticket due to insufficient data...
> 
> ** Changed in: qemu
>   Status: New => Incomplete
> 
> -- 
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1821054
> 
> Title:
>  qemu segfault error when using pcie to dual pci adapter
> 
> Status in QEMU:
>  Incomplete
> 
> Bug description:
>  All the information I have is located in the Unraid forum on post 
> "https://forums.unraid.net/topic/78545-internal-error-qemu-unexpectedly-closed-the-monitor;
>  I am happy to provide any addition information requested. Please let me 
> know. Reporting bug here based on recommendation by admin in that forum.
> 
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/qemu/+bug/1821054/+subscriptions

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

Title:
  qemu segfault error when using pcie to dual pci adapter

Status in QEMU:
  Incomplete

Bug description:
  All the information I have is located in the Unraid forum on post 
"https://forums.unraid.net/topic/78545-internal-error-qemu-unexpectedly-closed-the-monitor;
  I am happy to provide any addition information requested. Please let me know. 
Reporting bug here based on recommendation by admin in that forum.

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

Re: [PATCH 1/1] Fix to show vfio migration stat in migration status

2020-11-25 Thread Kirti Wankhede





On 11/26/2020 12:33 AM, Dr. David Alan Gilbert wrote:

* Kirti Wankhede (kwankh...@nvidia.com) wrote:



On 11/25/2020 3:00 PM, Dr. David Alan Gilbert wrote:

* Kirti Wankhede (kwankh...@nvidia.com) wrote:

Header file where CONFIG_VFIO is defined is not included in migration.c
file. Include config devices header file in migration.c.

Fixes: 3710586caa5d ("qapi: Add VFIO devices migration stats in Migration
stats")

Signed-off-by: Kirti Wankhede 


Given it's got build problems; I suggest actually something cleaner
would be to swing populate_vfio_info into one of the vfio specific
files, add a stubs/ entry somewhere and then migration.c doesn't need
to include the device or header stuff.



Still function prototype for populate_vfio_info() and its stub has to be
placed in some header file.


Which header file isn't that important; 


Any recommendation which header file to use?

Thanks,
Kirti


and the stub goes in a file in
stubs/


Earlier I used CONFIG_LINUX instead of CONFIG_VFIO which works here. Should
I change it back to CONFIG_LINUX?


No.


I'm not very much aware of meson build system, I tested by configuring
specific target, but I think by default if target build is not specified
during configuration, it builds for multiple target that's where this build
is failing. Any help on how to fix it would be helpful.


With my suggestion you don't have to do anything clever to meson
(which I don't know much about either).

Dave


Thanks,
Kirti


Dave


---
   meson.build   | 1 +
   migration/migration.c | 1 +
   2 files changed, 2 insertions(+)

diff --git a/meson.build b/meson.build
index 7ddf983ff7f5..24526499cfb5 100644
--- a/meson.build
+++ b/meson.build
@@ -1713,6 +1713,7 @@ common_ss.add_all(when: 'CONFIG_USER_ONLY', if_true: 
user_ss)
   common_all = common_ss.apply(config_all, strict: false)
   common_all = static_library('common',
+
c_args:'-DCONFIG_DEVICES="@0@-config-devices.h"'.format(target) ,
   build_by_default: false,
   sources: common_all.sources() + genh,
   dependencies: common_all.dependencies(),
diff --git a/migration/migration.c b/migration/migration.c
index 87a9b59f83f4..650efb81daad 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -57,6 +57,7 @@
   #include "qemu/queue.h"
   #include "multifd.h"
+#include CONFIG_DEVICES
   #ifdef CONFIG_VFIO
   #include "hw/vfio/vfio-common.h"
   #endif
--
2.7.0

Re: [PATCH for-5.2] nsis: Fix build for 64 bit installer

2020-11-25 Thread Peter Maydell

On Wed, 25 Nov 2020 at 19:23, Stefan Weil  wrote:
>
> Pass cpu instead of cpu_family to the NSIS installer script.
>
> That script checks for "x86_64" which is the cpu value,
> while cpu_family is "x86".
>
> Signed-off-by: Stefan Weil 
> ---
>  meson.build | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Very unfortunate that this has only surfaced after rc3,
which should in theory be the cutoff point for 5.2 changes.
Is it possible to get something into the CI/make check
so that we find Windows installer issues sooner?

thanks
-- PMM

[PATCH for-5.2] nsis: Fix build for 64 bit installer

2020-11-25 Thread Stefan Weil

Pass cpu instead of cpu_family to the NSIS installer script.

That script checks for "x86_64" which is the cpu value,
while cpu_family is "x86".

Signed-off-by: Stefan Weil 
---
 meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meson.build b/meson.build
index 5062407c70..8a99c948d3 100644
--- a/meson.build
+++ b/meson.build
@@ -1956,7 +1956,7 @@ if host_machine.system() == 'windows'
 '@OUTPUT@',
 get_option('prefix'),
 meson.current_source_dir(),
-host_machine.cpu_family(),
+host_machine.cpu(),
 '--',
 '-DDISPLAYVERSION=' + meson.project_version(),
   ]
-- 
2.29.2

Re: [PATCH v3 2/7] introduce UFFD-WP low-level interface helpers

2020-11-25 Thread Andrey Gruzdev


On 25.11.2020 21:43, Dr. David Alan Gilbert wrote:

* Andrey Gruzdev (andrey.gruz...@virtuozzo.com) wrote:

On 24.11.2020 20:57, Dr. David Alan Gilbert wrote:

* Andrey Gruzdev (andrey.gruz...@virtuozzo.com) wrote:

Implemented support for the whole RAM block memory
protection/un-protection. Introduced higher level
ram_write_tracking_start() and ram_write_tracking_stop()
to start/stop tracking guest memory writes.

Signed-off-by: Andrey Gruzdev 
---
   include/exec/memory.h |   7 ++
   migration/ram.c   | 267 ++
   migration/ram.h   |   4 +
   3 files changed, 278 insertions(+)

diff --git a/include/exec/memory.h b/include/exec/memory.h
index 0f3e6bcd5e..3d798fce16 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -139,6 +139,13 @@ typedef struct IOMMUNotifier IOMMUNotifier;
   /* RAM is a persistent kind memory */
   #define RAM_PMEM (1 << 5)
+/*
+ * UFFDIO_WRITEPROTECT is used on this RAMBlock to
+ * support 'write-tracking' migration type.
+ * Implies ram_state->ram_wt_enabled.
+ */
+#define RAM_UF_WRITEPROTECT (1 << 6)
+
   static inline void iommu_notifier_init(IOMMUNotifier *n, IOMMUNotify fn,
  IOMMUNotifierFlag flags,
  hwaddr start, hwaddr end,
diff --git a/migration/ram.c b/migration/ram.c
index 7811cde643..7f273c9996 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -56,6 +56,12 @@
   #include "savevm.h"
   #include "qemu/iov.h"
   #include "multifd.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "sysemu/runstate.h"
   /***/
   /* ram save/restore */
@@ -298,6 +304,8 @@ struct RAMSrcPageRequest {
   struct RAMState {
   /* QEMUFile used for this migration */
   QEMUFile *f;
+/* UFFD file descriptor, used in 'write-tracking' migration */
+int uffdio_fd;
   /* Last block that we have visited searching for dirty pages */
   RAMBlock *last_seen_block;
   /* Last block from where we have sent data */
@@ -453,6 +461,181 @@ static QemuThread *decompress_threads;
   static QemuMutex decomp_done_lock;
   static QemuCond decomp_done_cond;
+/**
+ * uffd_create_fd: create UFFD file descriptor
+ *
+ * Returns non-negative file descriptor or negative value in case of an error
+ */
+static int uffd_create_fd(void)
+{
+int uffd;
+struct uffdio_api api_struct;
+uint64_t ioctl_mask = BIT(_UFFDIO_REGISTER) | BIT(_UFFDIO_UNREGISTER);


You need to be a bit careful about doing this in migration/ram.c - it's
generic code; at minimum it needs ifdef'ing for Linux.



Yes, it's totally linux-specific, I think better to move this code out of
migration/ram.c, as Peter proposed.


+uffd = syscall(__NR_userfaultfd, O_CLOEXEC | O_NONBLOCK);
+if (uffd < 0) {
+error_report("uffd_create_fd() failed: UFFD not supported");
+return -1;
+}
+
+api_struct.api = UFFD_API;
+api_struct.features = UFFD_FEATURE_PAGEFAULT_FLAG_WP;
+if (ioctl(uffd, UFFDIO_API, _struct)) {
+error_report("uffd_create_fd() failed: "
+"API version not supported version=%llx errno=%i",
+api_struct.api, errno);
+goto fail;
+}
+
+if ((api_struct.ioctls & ioctl_mask) != ioctl_mask) {
+error_report("uffd_create_fd() failed: "
+"PAGEFAULT_FLAG_WP feature missing");
+goto fail;
+}
+
+return uffd;


Should we be putting that somewher that we can share with postcopy?



Sure, maybe to util/uffd-wp.c + include/qemu/uffd-wp.h.
What do you think?


Or how about a userfaultfd.c somewhere?

Dave



For userfaultfd.c I'm also ok.

Andrey


+fail:
+close(uffd);
+return -1;
+}
+
+/**
+ * uffd_close_fd: close UFFD file descriptor
+ *
+ * @uffd: UFFD file descriptor
+ */
+static void uffd_close_fd(int uffd)
+{
+assert(uffd >= 0);
+close(uffd);
+}
+
+/**
+ * uffd_register_memory: register memory range with UFFD
+ *
+ * Returns 0 in case of success, negative value on error
+ *
+ * @uffd: UFFD file descriptor
+ * @start: starting virtual address of memory range
+ * @length: length of memory range
+ * @track_missing: generate events on missing-page faults
+ * @track_wp: generate events on write-protected-page faults
+ */
+static int uffd_register_memory(int uffd, hwaddr start, hwaddr length,
+bool track_missing, bool track_wp)
+{
+struct uffdio_register uffd_register;
+
+uffd_register.range.start = start;
+uffd_register.range.len = length;
+uffd_register.mode = (track_missing ? UFFDIO_REGISTER_MODE_MISSING : 0) |
+ (track_wp ? UFFDIO_REGISTER_MODE_WP : 0);
+
+if (ioctl(uffd, UFFDIO_REGISTER, _register)) {
+error_report("uffd_register_memory() failed: "
+"start=%0"PRIx64" len=%"PRIu64" mode=%llu errno=%i",
+start, length, uffd_register.mode, errno);
+return -1;
+}
+
+

Re: [PATCH v3 3/7] support UFFD write fault processing in ram_save_iterate()

2020-11-25 Thread Andrey Gruzdev


On 25.11.2020 21:41, Dr. David Alan Gilbert wrote:

* Andrey Gruzdev (andrey.gruz...@virtuozzo.com) wrote:

On 25.11.2020 16:08, Dr. David Alan Gilbert wrote:

* Andrey Gruzdev (andrey.gruz...@virtuozzo.com) wrote:

In this particular implementation the same single migration
thread is responsible for both normal linear dirty page
migration and procesing UFFD page fault events.

Processing write faults includes reading UFFD file descriptor,
finding respective RAM block and saving faulting page to
the migration stream. After page has been saved, write protection
can be removed. Since asynchronous version of qemu_put_buffer()
is expected to be used to save pages, we also have to flush
migraion stream prior to un-protecting saved memory range.

Write protection is being removed for any previously protected
memory chunk that has hit the migration stream. That's valid
for pages from linear page scan along with write fault pages.

Signed-off-by: Andrey Gruzdev 
---
   migration/ram.c | 124 
   1 file changed, 115 insertions(+), 9 deletions(-)

diff --git a/migration/ram.c b/migration/ram.c
index 7f273c9996..08a1d7a252 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -314,6 +314,8 @@ struct RAMState {
   ram_addr_t last_page;
   /* last ram version we have seen */
   uint32_t last_version;
+/* 'write-tracking' migration is enabled */
+bool ram_wt_enabled;
   /* We are in the first round */
   bool ram_bulk_stage;
   /* The free page optimization is enabled */
@@ -574,8 +576,6 @@ static int uffd_protect_memory(int uffd, hwaddr start, 
hwaddr length, bool wp)
   return 0;
   }
-__attribute__ ((unused))
-static int uffd_read_events(int uffd, struct uffd_msg *msgs, int count);
   __attribute__ ((unused))
   static bool uffd_poll_events(int uffd, int tmo);
@@ -1929,6 +1929,86 @@ static int ram_save_host_page(RAMState *rs, 
PageSearchStatus *pss,
   return pages;
   }
+/**
+ * ram_find_block_by_host_address: find RAM block containing host page
+ *
+ * Returns true if RAM block is found and pss->block/page are
+ * pointing to the given host page, false in case of an error
+ *
+ * @rs: current RAM state
+ * @pss: page-search-status structure
+ */
+static bool ram_find_block_by_host_address(RAMState *rs, PageSearchStatus *pss,
+hwaddr page_address)
+{
+bool found = false;
+
+pss->block = rs->last_seen_block;
+do {
+if (page_address >= (hwaddr) pss->block->host &&
+(page_address + TARGET_PAGE_SIZE) <=
+((hwaddr) pss->block->host + pss->block->used_length)) {
+pss->page = (unsigned long)
+((page_address - (hwaddr) pss->block->host) >> 
TARGET_PAGE_BITS);
+found = true;
+break;
+}
+
+pss->block = QLIST_NEXT_RCU(pss->block, next);
+if (!pss->block) {
+/* Hit the end of the list */
+pss->block = QLIST_FIRST_RCU(_list.blocks);
+}
+} while (pss->block != rs->last_seen_block);
+
+rs->last_seen_block = pss->block;
+/*
+ * Since we are in the same loop with ram_find_and_save_block(),
+ * need to reset pss->complete_round after switching to
+ * other block/page in pss.
+ */
+pss->complete_round = false;
+
+return found;
+}
+
+/**
+ * get_fault_page: try to get next UFFD write fault page and, if pending fault
+ *   is found, put info about RAM block and block page into pss structure
+ *
+ * Returns true in case of UFFD write fault detected, false otherwise
+ *
+ * @rs: current RAM state
+ * @pss: page-search-status structure
+ *
+ */
+static bool get_fault_page(RAMState *rs, PageSearchStatus *pss)
+{
+struct uffd_msg uffd_msg;
+hwaddr page_address;
+int res;
+
+if (!rs->ram_wt_enabled) {
+return false;
+}
+
+res = uffd_read_events(rs->uffdio_fd, _msg, 1);
+if (res <= 0) {
+return false;
+}
+
+page_address = uffd_msg.arg.pagefault.address;
+if (!ram_find_block_by_host_address(rs, pss, page_address)) {
+/* In case we couldn't find respective block, just unprotect faulting 
page */
+uffd_protect_memory(rs->uffdio_fd, page_address, TARGET_PAGE_SIZE, 
false);
+error_report("ram_find_block_by_host_address() failed: address=0x%0lx",
+ page_address);
+return false;
+}
+
+return true;
+}
+
   /**
* ram_find_and_save_block: finds a dirty page and sends it to f
*
@@ -1955,25 +2035,50 @@ static int ram_find_and_save_block(RAMState *rs, bool 
last_stage)
   return pages;
   }
+if (!rs->last_seen_block) {
+rs->last_seen_block = QLIST_FIRST_RCU(_list.blocks);
+}
   pss.block = rs->last_seen_block;
   pss.page = rs->last_page;
   pss.complete_round = false;
-if (!pss.block) {
-pss.block = QLIST_FIRST_RCU(_list.blocks);
-}
-
   do {
+ram_addr_t page;
+

Re: [PATCH 1/1] Fix to show vfio migration stat in migration status

* Kirti Wankhede (kwankh...@nvidia.com) wrote:
> 
> 
> On 11/25/2020 3:00 PM, Dr. David Alan Gilbert wrote:
> > * Kirti Wankhede (kwankh...@nvidia.com) wrote:
> > > Header file where CONFIG_VFIO is defined is not included in migration.c
> > > file. Include config devices header file in migration.c.
> > > 
> > > Fixes: 3710586caa5d ("qapi: Add VFIO devices migration stats in Migration
> > > stats")
> > > 
> > > Signed-off-by: Kirti Wankhede 
> > 
> > Given it's got build problems; I suggest actually something cleaner
> > would be to swing populate_vfio_info into one of the vfio specific
> > files, add a stubs/ entry somewhere and then migration.c doesn't need
> > to include the device or header stuff.
> > 
> 
> Still function prototype for populate_vfio_info() and its stub has to be
> placed in some header file.

Which header file isn't that important; and the stub goes in a file in
stubs/

> Earlier I used CONFIG_LINUX instead of CONFIG_VFIO which works here. Should
> I change it back to CONFIG_LINUX?

No.

> I'm not very much aware of meson build system, I tested by configuring
> specific target, but I think by default if target build is not specified
> during configuration, it builds for multiple target that's where this build
> is failing. Any help on how to fix it would be helpful.

With my suggestion you don't have to do anything clever to meson
(which I don't know much about either).

Dave

> Thanks,
> Kirti
> 
> > Dave
> > 
> > > ---
> > >   meson.build   | 1 +
> > >   migration/migration.c | 1 +
> > >   2 files changed, 2 insertions(+)
> > > 
> > > diff --git a/meson.build b/meson.build
> > > index 7ddf983ff7f5..24526499cfb5 100644
> > > --- a/meson.build
> > > +++ b/meson.build
> > > @@ -1713,6 +1713,7 @@ common_ss.add_all(when: 'CONFIG_USER_ONLY', 
> > > if_true: user_ss)
> > >   common_all = common_ss.apply(config_all, strict: false)
> > >   common_all = static_library('common',
> > > +
> > > c_args:'-DCONFIG_DEVICES="@0@-config-devices.h"'.format(target) ,
> > >   build_by_default: false,
> > >   sources: common_all.sources() + genh,
> > >   dependencies: common_all.dependencies(),
> > > diff --git a/migration/migration.c b/migration/migration.c
> > > index 87a9b59f83f4..650efb81daad 100644
> > > --- a/migration/migration.c
> > > +++ b/migration/migration.c
> > > @@ -57,6 +57,7 @@
> > >   #include "qemu/queue.h"
> > >   #include "multifd.h"
> > > +#include CONFIG_DEVICES
> > >   #ifdef CONFIG_VFIO
> > >   #include "hw/vfio/vfio-common.h"
> > >   #endif
> > > -- 
> > > 2.7.0
> > > 
> 
-- 
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

[PATCH] iotests: Add test for the regression fixed in c8bf9a9169

2020-11-25 Thread Alberto Garcia

Signed-off-by: Alberto Garcia 
Suggested-by: Maxim Levitsky 
---
 tests/qemu-iotests/313 | 103 +
 tests/qemu-iotests/313.out |  29 +++
 tests/qemu-iotests/group   |   1 +
 3 files changed, 133 insertions(+)
 create mode 100755 tests/qemu-iotests/313
 create mode 100644 tests/qemu-iotests/313.out

diff --git a/tests/qemu-iotests/313 b/tests/qemu-iotests/313
new file mode 100755
index 00..0a5202ad49
--- /dev/null
+++ b/tests/qemu-iotests/313
@@ -0,0 +1,103 @@
+#!/usr/bin/env bash
+#
+# Test for the regression fixed in commit c8bf9a9169
+#
+# Copyright (C) 2020 Igalia, S.L.
+# Author: Alberto Garcia 
+# Based on a test case by Maxim Levitsky 
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see .
+#
+
+# creator
+owner=be...@igalia.com
+
+seq=`basename $0`
+echo "QA output created by $seq"
+
+status=1# failure is the default!
+
+_cleanup()
+{
+_cleanup_test_img
+}
+trap "_cleanup; exit \$status" 0 1 2 3 15
+
+# get standard environment, filters and checks
+. ./common.rc
+. ./common.filter
+
+_supported_fmt qcow2
+_supported_proto file
+_supported_os Linux
+_unsupported_imgopts cluster_size refcount_bits extended_l2 compat=0.10 
data_file
+
+# The cluster size must be at least the granularity of the mirror job (4KB)
+# Note that larger cluster sizes will produce very large images (several GBs)
+cluster_size=4096
+refcount_bits=64 # Make it equal to the L2 entry size for convenience
+options="cluster_size=${cluster_size},refcount_bits=${refcount_bits}"
+
+# Number of refcount entries per refcount blocks
+ref_entries=$(( ${cluster_size} * 8 / ${refcount_bits} ))
+
+# Number of data clusters needed to fill a refcount block
+# Equals ${ref_entries} minus two (one L2 table and one refcount block)
+data_clusters_per_refblock=$(( ${ref_entries} - 2 ))
+
+# Number of entries in the refcount cache
+ref_blocks=4
+
+# Write enough data clusters to fill the refcount cache and allocate
+# one more refcount block.
+# Subtract 3 clusters from the total: qcow2 header, refcount table, L1 table
+total_data_clusters=$(( ${data_clusters_per_refblock} * ${ref_blocks} + 1 - 3 
))
+
+# Total size to write in bytes
+total_size=$(( ${total_data_clusters} * ${cluster_size} ))
+
+echo
+echo '### Create the image'
+echo
+TEST_IMG_FILE=$TEST_IMG.base _make_test_img -o $options $total_size | 
_filter_img_create_size
+
+echo
+echo '### Write data to allocate more refcount blocks than the cache can hold'
+echo
+$QEMU_IO -c "write -P 1 0 $total_size" $TEST_IMG.base | _filter_qemu_io
+
+echo
+echo '### Create an overlay'
+echo
+_make_test_img -F $IMGFMT -b $TEST_IMG.base -o $options | 
_filter_img_create_size
+
+echo
+echo '### Fill the overlay with zeroes'
+echo
+$QEMU_IO -c "write -z 0 $total_size" $TEST_IMG | _filter_qemu_io
+
+echo
+echo '### Commit changes to the base image'
+echo
+$QEMU_IMG commit $TEST_IMG
+
+echo
+echo '### Check the base image'
+echo
+$QEMU_IMG check $TEST_IMG.base
+
+# success, all done
+echo "*** done"
+rm -f $seq.full
+status=0
diff --git a/tests/qemu-iotests/313.out b/tests/qemu-iotests/313.out
new file mode 100644
index 00..adb9f7bd95
--- /dev/null
+++ b/tests/qemu-iotests/313.out
@@ -0,0 +1,29 @@
+QA output created by 313
+
+### Create the image
+
+Formatting 'TEST_DIR/t.IMGFMT.base', fmt=IMGFMT size=SIZE
+
+### Write data to allocate more refcount blocks than the cache can hold
+
+wrote 8347648/8347648 bytes at offset 0
+7.961 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+
+### Create an overlay
+
+Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=SIZE 
backing_file=TEST_DIR/t.IMGFMT.base backing_fmt=IMGFMT
+
+### Fill the overlay with zeroes
+
+wrote 8347648/8347648 bytes at offset 0
+7.961 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+
+### Commit changes to the base image
+
+Image committed.
+
+### Check the base image
+
+No errors were found on the image.
+Image end offset: 8396800
+*** done
diff --git a/tests/qemu-iotests/group b/tests/qemu-iotests/group
index 2960dff728..df339f1720 100644
--- a/tests/qemu-iotests/group
+++ b/tests/qemu-iotests/group
@@ -316,3 +316,4 @@
 305 rw quick
 307 rw quick export
 309 rw auto quick
+313 rw auto quick
-- 
2.20.1

Re: [PATCH 1/1] Fix to show vfio migration stat in migration status

2020-11-25 Thread Kirti Wankhede





On 11/25/2020 3:00 PM, Dr. David Alan Gilbert wrote:

* Kirti Wankhede (kwankh...@nvidia.com) wrote:

Header file where CONFIG_VFIO is defined is not included in migration.c
file. Include config devices header file in migration.c.

Fixes: 3710586caa5d ("qapi: Add VFIO devices migration stats in Migration
stats")

Signed-off-by: Kirti Wankhede 


Given it's got build problems; I suggest actually something cleaner
would be to swing populate_vfio_info into one of the vfio specific
files, add a stubs/ entry somewhere and then migration.c doesn't need
to include the device or header stuff.



Still function prototype for populate_vfio_info() and its stub has to be 
placed in some header file.


Earlier I used CONFIG_LINUX instead of CONFIG_VFIO which works here. 
Should I change it back to CONFIG_LINUX?


I'm not very much aware of meson build system, I tested by configuring 
specific target, but I think by default if target build is not specified 
during configuration, it builds for multiple target that's where this 
build is failing. Any help on how to fix it would be helpful.


Thanks,
Kirti


Dave


---
  meson.build   | 1 +
  migration/migration.c | 1 +
  2 files changed, 2 insertions(+)

diff --git a/meson.build b/meson.build
index 7ddf983ff7f5..24526499cfb5 100644
--- a/meson.build
+++ b/meson.build
@@ -1713,6 +1713,7 @@ common_ss.add_all(when: 'CONFIG_USER_ONLY', if_true: 
user_ss)
  
  common_all = common_ss.apply(config_all, strict: false)

  common_all = static_library('common',
+
c_args:'-DCONFIG_DEVICES="@0@-config-devices.h"'.format(target) ,
  build_by_default: false,
  sources: common_all.sources() + genh,
  dependencies: common_all.dependencies(),
diff --git a/migration/migration.c b/migration/migration.c
index 87a9b59f83f4..650efb81daad 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -57,6 +57,7 @@
  #include "qemu/queue.h"
  #include "multifd.h"
  
+#include CONFIG_DEVICES

  #ifdef CONFIG_VFIO
  #include "hw/vfio/vfio-common.h"
  #endif
--
2.7.0

Re: [PATCH v3 2/7] introduce UFFD-WP low-level interface helpers

* Andrey Gruzdev (andrey.gruz...@virtuozzo.com) wrote:
> On 24.11.2020 20:57, Dr. David Alan Gilbert wrote:
> > * Andrey Gruzdev (andrey.gruz...@virtuozzo.com) wrote:
> > > Implemented support for the whole RAM block memory
> > > protection/un-protection. Introduced higher level
> > > ram_write_tracking_start() and ram_write_tracking_stop()
> > > to start/stop tracking guest memory writes.
> > > 
> > > Signed-off-by: Andrey Gruzdev 
> > > ---
> > >   include/exec/memory.h |   7 ++
> > >   migration/ram.c   | 267 ++
> > >   migration/ram.h   |   4 +
> > >   3 files changed, 278 insertions(+)
> > > 
> > > diff --git a/include/exec/memory.h b/include/exec/memory.h
> > > index 0f3e6bcd5e..3d798fce16 100644
> > > --- a/include/exec/memory.h
> > > +++ b/include/exec/memory.h
> > > @@ -139,6 +139,13 @@ typedef struct IOMMUNotifier IOMMUNotifier;
> > >   /* RAM is a persistent kind memory */
> > >   #define RAM_PMEM (1 << 5)
> > > +/*
> > > + * UFFDIO_WRITEPROTECT is used on this RAMBlock to
> > > + * support 'write-tracking' migration type.
> > > + * Implies ram_state->ram_wt_enabled.
> > > + */
> > > +#define RAM_UF_WRITEPROTECT (1 << 6)
> > > +
> > >   static inline void iommu_notifier_init(IOMMUNotifier *n, IOMMUNotify fn,
> > >  IOMMUNotifierFlag flags,
> > >  hwaddr start, hwaddr end,
> > > diff --git a/migration/ram.c b/migration/ram.c
> > > index 7811cde643..7f273c9996 100644
> > > --- a/migration/ram.c
> > > +++ b/migration/ram.c
> > > @@ -56,6 +56,12 @@
> > >   #include "savevm.h"
> > >   #include "qemu/iov.h"
> > >   #include "multifd.h"
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include "sysemu/runstate.h"
> > >   /***/
> > >   /* ram save/restore */
> > > @@ -298,6 +304,8 @@ struct RAMSrcPageRequest {
> > >   struct RAMState {
> > >   /* QEMUFile used for this migration */
> > >   QEMUFile *f;
> > > +/* UFFD file descriptor, used in 'write-tracking' migration */
> > > +int uffdio_fd;
> > >   /* Last block that we have visited searching for dirty pages */
> > >   RAMBlock *last_seen_block;
> > >   /* Last block from where we have sent data */
> > > @@ -453,6 +461,181 @@ static QemuThread *decompress_threads;
> > >   static QemuMutex decomp_done_lock;
> > >   static QemuCond decomp_done_cond;
> > > +/**
> > > + * uffd_create_fd: create UFFD file descriptor
> > > + *
> > > + * Returns non-negative file descriptor or negative value in case of an 
> > > error
> > > + */
> > > +static int uffd_create_fd(void)
> > > +{
> > > +int uffd;
> > > +struct uffdio_api api_struct;
> > > +uint64_t ioctl_mask = BIT(_UFFDIO_REGISTER) | 
> > > BIT(_UFFDIO_UNREGISTER);
> > 
> > You need to be a bit careful about doing this in migration/ram.c - it's
> > generic code; at minimum it needs ifdef'ing for Linux.
> > 
> 
> Yes, it's totally linux-specific, I think better to move this code out of
> migration/ram.c, as Peter proposed.
> 
> > > +uffd = syscall(__NR_userfaultfd, O_CLOEXEC | O_NONBLOCK);
> > > +if (uffd < 0) {
> > > +error_report("uffd_create_fd() failed: UFFD not supported");
> > > +return -1;
> > > +}
> > > +
> > > +api_struct.api = UFFD_API;
> > > +api_struct.features = UFFD_FEATURE_PAGEFAULT_FLAG_WP;
> > > +if (ioctl(uffd, UFFDIO_API, _struct)) {
> > > +error_report("uffd_create_fd() failed: "
> > > +"API version not supported version=%llx errno=%i",
> > > +api_struct.api, errno);
> > > +goto fail;
> > > +}
> > > +
> > > +if ((api_struct.ioctls & ioctl_mask) != ioctl_mask) {
> > > +error_report("uffd_create_fd() failed: "
> > > +"PAGEFAULT_FLAG_WP feature missing");
> > > +goto fail;
> > > +}
> > > +
> > > +return uffd;
> > 
> > Should we be putting that somewher that we can share with postcopy?
> > 
> 
> Sure, maybe to util/uffd-wp.c + include/qemu/uffd-wp.h.
> What do you think?

Or how about a userfaultfd.c somewhere?

Dave

> > > +fail:
> > > +close(uffd);
> > > +return -1;
> > > +}
> > > +
> > > +/**
> > > + * uffd_close_fd: close UFFD file descriptor
> > > + *
> > > + * @uffd: UFFD file descriptor
> > > + */
> > > +static void uffd_close_fd(int uffd)
> > > +{
> > > +assert(uffd >= 0);
> > > +close(uffd);
> > > +}
> > > +
> > > +/**
> > > + * uffd_register_memory: register memory range with UFFD
> > > + *
> > > + * Returns 0 in case of success, negative value on error
> > > + *
> > > + * @uffd: UFFD file descriptor
> > > + * @start: starting virtual address of memory range
> > > + * @length: length of memory range
> > > + * @track_missing: generate events on missing-page faults
> > > + * @track_wp: generate events on write-protected-page faults
> > > + */
> > > +static int

Re: [PATCH v3 3/7] support UFFD write fault processing in ram_save_iterate()

* Andrey Gruzdev (andrey.gruz...@virtuozzo.com) wrote:
> On 25.11.2020 16:08, Dr. David Alan Gilbert wrote:
> > * Andrey Gruzdev (andrey.gruz...@virtuozzo.com) wrote:
> > > In this particular implementation the same single migration
> > > thread is responsible for both normal linear dirty page
> > > migration and procesing UFFD page fault events.
> > > 
> > > Processing write faults includes reading UFFD file descriptor,
> > > finding respective RAM block and saving faulting page to
> > > the migration stream. After page has been saved, write protection
> > > can be removed. Since asynchronous version of qemu_put_buffer()
> > > is expected to be used to save pages, we also have to flush
> > > migraion stream prior to un-protecting saved memory range.
> > > 
> > > Write protection is being removed for any previously protected
> > > memory chunk that has hit the migration stream. That's valid
> > > for pages from linear page scan along with write fault pages.
> > > 
> > > Signed-off-by: Andrey Gruzdev 
> > > ---
> > >   migration/ram.c | 124 
> > >   1 file changed, 115 insertions(+), 9 deletions(-)
> > > 
> > > diff --git a/migration/ram.c b/migration/ram.c
> > > index 7f273c9996..08a1d7a252 100644
> > > --- a/migration/ram.c
> > > +++ b/migration/ram.c
> > > @@ -314,6 +314,8 @@ struct RAMState {
> > >   ram_addr_t last_page;
> > >   /* last ram version we have seen */
> > >   uint32_t last_version;
> > > +/* 'write-tracking' migration is enabled */
> > > +bool ram_wt_enabled;
> > >   /* We are in the first round */
> > >   bool ram_bulk_stage;
> > >   /* The free page optimization is enabled */
> > > @@ -574,8 +576,6 @@ static int uffd_protect_memory(int uffd, hwaddr 
> > > start, hwaddr length, bool wp)
> > >   return 0;
> > >   }
> > > -__attribute__ ((unused))
> > > -static int uffd_read_events(int uffd, struct uffd_msg *msgs, int count);
> > >   __attribute__ ((unused))
> > >   static bool uffd_poll_events(int uffd, int tmo);
> > > @@ -1929,6 +1929,86 @@ static int ram_save_host_page(RAMState *rs, 
> > > PageSearchStatus *pss,
> > >   return pages;
> > >   }
> > > +/**
> > > + * ram_find_block_by_host_address: find RAM block containing host page
> > > + *
> > > + * Returns true if RAM block is found and pss->block/page are
> > > + * pointing to the given host page, false in case of an error
> > > + *
> > > + * @rs: current RAM state
> > > + * @pss: page-search-status structure
> > > + */
> > > +static bool ram_find_block_by_host_address(RAMState *rs, 
> > > PageSearchStatus *pss,
> > > +hwaddr page_address)
> > > +{
> > > +bool found = false;
> > > +
> > > +pss->block = rs->last_seen_block;
> > > +do {
> > > +if (page_address >= (hwaddr) pss->block->host &&
> > > +(page_address + TARGET_PAGE_SIZE) <=
> > > +((hwaddr) pss->block->host + 
> > > pss->block->used_length)) {
> > > +pss->page = (unsigned long)
> > > +((page_address - (hwaddr) pss->block->host) >> 
> > > TARGET_PAGE_BITS);
> > > +found = true;
> > > +break;
> > > +}
> > > +
> > > +pss->block = QLIST_NEXT_RCU(pss->block, next);
> > > +if (!pss->block) {
> > > +/* Hit the end of the list */
> > > +pss->block = QLIST_FIRST_RCU(_list.blocks);
> > > +}
> > > +} while (pss->block != rs->last_seen_block);
> > > +
> > > +rs->last_seen_block = pss->block;
> > > +/*
> > > + * Since we are in the same loop with ram_find_and_save_block(),
> > > + * need to reset pss->complete_round after switching to
> > > + * other block/page in pss.
> > > + */
> > > +pss->complete_round = false;
> > > +
> > > +return found;
> > > +}
> > > +
> > > +/**
> > > + * get_fault_page: try to get next UFFD write fault page and, if pending 
> > > fault
> > > + *   is found, put info about RAM block and block page into pss structure
> > > + *
> > > + * Returns true in case of UFFD write fault detected, false otherwise
> > > + *
> > > + * @rs: current RAM state
> > > + * @pss: page-search-status structure
> > > + *
> > > + */
> > > +static bool get_fault_page(RAMState *rs, PageSearchStatus *pss)
> > > +{
> > > +struct uffd_msg uffd_msg;
> > > +hwaddr page_address;
> > > +int res;
> > > +
> > > +if (!rs->ram_wt_enabled) {
> > > +return false;
> > > +}
> > > +
> > > +res = uffd_read_events(rs->uffdio_fd, _msg, 1);
> > > +if (res <= 0) {
> > > +return false;
> > > +}
> > > +
> > > +page_address = uffd_msg.arg.pagefault.address;
> > > +if (!ram_find_block_by_host_address(rs, pss, page_address)) {
> > > +/* In case we couldn't find respective block, just unprotect 
> > > faulting page */
> > > +uffd_protect_memory(rs->uffdio_fd, page_address, 
> > > TARGET_PAGE_SIZE, false);
> > > +

[Bug 1820247] Re: QEMU random crash caused by libspice-server

The QEMU project is currently considering to move its bug tracking to another 
system. For this we need to know which bugs are still valid and which could be 
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the state 
back to "New" within the next 60 days, otherwise this report will be marked as 
"Expired". Or mark it as "Fix Released" if the problem has been solved with a 
newer version of QEMU already. Thank you and sorry for the inconvenience.

** Changed in: qemu
   Status: New => Incomplete

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

Title:
  QEMU random crash caused by libspice-server

Status in QEMU:
  Incomplete

Bug description:
  Hi,

  One of our OpenStack instances crashed. It seems there was some
  problem related to SPICE. Attaching what we had in qemu log. Also
  sending our versions:

  Linux pre-node1 4.18.0-13-generic #14~18.04.1-Ubuntu SMP Thu Dec 6
  14:09:52 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

  QEMU emulator version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.9)
  Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers

  
  root@pre-node1:~# cat /var/log/libvirt/qemu/instance-0038.log 
  2019-03-10 20:39:36.510+: starting up libvirt version: 4.0.0, package: 
1ubuntu8.6 (Christian Ehrhardt  Fri, 09 Nov 
2018 07:42:01 +0100), qemu version: 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.9), 
hostname: pre-node1
  LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin 
QEMU_AUDIO_DRV=spice /usr/bin/kvm-spice -name 
guest=instance-0038,debug-threads=on -S -object 
secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-5-instance-0038/master-key.aes
 -machine pc-i440fx-bionic,accel=kvm,usb=off,dump-guest-core=off,mem-merge=off 
-cpu 
Skylake-Server-IBRS,ss=on,hypervisor=on,tsc_adjust=on,clflushopt=on,pku=on,ssbd=on,xsaves=on
 -m 2048 -realtime mlock=on -smp 2,sockets=1,cores=1,threads=2 -object 
memory-backend-file,id=ram-node0,prealloc=yes,mem-path=/dev/hugepages/libvirt/qemu/5-instance-0038,share=yes,size=2147483648,host-nodes=0,policy=bind
 -numa node,nodeid=0,cpus=0-1,memdev=ram-node0 -uuid 
3c3d04f3-4b25-4ea5-8836-0e06eef9dcb7 -smbios 'type=1,manufacturer=OpenStack 
Foundation,product=OpenStack 
Nova,version=18.1.1,serial=93fa1a55-ba3a-4a99-80b3-3a7bb4e964af,uuid=3c3d04f3-4b25-4ea5-8836-0e06eef9dcb7,family=Virtual
 Machine' -no-user-config -nodefaults -chardev 
socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-5-instance-0038/monitor.sock,server,nowait
 -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew 
-global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -boot strict=on 
-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device 
virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 -drive 
file=/var/lib/nova/instances/3c3d04f3-4b25-4ea5-8836-0e06eef9dcb7/disk,format=qcow2,if=none,id=drive-virtio-disk0,cache=none,discard=ignore,throttling.iops-read=5000,throttling.iops-write=5000
 -device 
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
 -add-fd set=0,fd=29 -chardev 
pty,id=charserial0,logfile=/dev/fdset/0,logappend=on -device 
isa-serial,chardev=charserial0,id=serial0 -chardev 
spicevmc,id=charchannel0,name=vdagent -device 
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0
 -spice port=5900,addr=10.252.0.101,disable-ticketing,seamless-migration=on 
-device 
qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2
 -device vfio-pci,host=25:04.1,id=hostdev0,bus=pci.0,addr=0x5 -device 
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -msg timestamp=on
  2019-03-10T20:39:36.568276Z qemu-system-x86_64: -chardev 
pty,id=charserial0,logfile=/dev/fdset/0,logappend=on: char device redirected to 
/dev/pts/2 (label charserial0)
  inputs_channel_detach_tablet: 
  main_channel_link: add main channel client
  main_channel_client_handle_pong: net test: latency 32.76 ms, bitrate 
33384953 bps (31.838372 Mbps)
  red_qxl_set_cursor_peer: 
  inputs_connect: inputs channel client create

  (process:65324): Spice-WARNING **: 16:35:23.769: Failed to create channel 
client: Client 0x55e7c157e970: duplicate channel type 2 id 0
  red_qxl_set_cursor_peer: 

  (process:65324): Spice-WARNING **: 16:35:24.142: Failed to create
  channel client: Client 0x55e7c157e970: duplicate channel type 4 id 0

  (process:65324): Spice-CRITICAL **: 16:35:24.142: 
cursor-channel.c:353:cursor_channel_connect: condition `ccc != NULL' failed
  2019-03-13 15:35:31.785+: shutting down, reason=crashed


  
  I am also attaching some gdb information extracted from qemu crash dump file. 
These are backtraces of particular threads within the crashed QEMU process.

[Bug 1826827] Re: dtc crash; pnv_dt_serial cannot find lpc's phandle

The QEMU project is currently considering to move its bug tracking to another 
system. For this we need to know which bugs are still valid and which could be 
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the state 
back to "New" or "Confirmed" within the next 60 days, otherwise this report 
will be marked as "Expired". Or mark it as "Fix Released" if the problem has 
been solved with a newer version of QEMU already. Thank you and sorry for the 
inconvenience.

** Changed in: qemu
   Status: New => Incomplete

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

Title:
  dtc crash; pnv_dt_serial cannot find lpc's phandle

Status in QEMU:
  Incomplete

Bug description:
  Qemu version:
  QEMU emulator version 4.0.50 (v4.0.0-142-ge0fb2c3d89)
  Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers

  dtc version:
  Version: DTC 1.5.0-g5c3513f6

  -
  pnv_dt_serial has a line which is supposed to set the interrupt-parent of the 
"isa-serial@i3f8" node to the phandle of "lpc@0".

  To that end, it calls fdt_get_phandle as shown below:
  _FDT((fdt_setprop_cell(fdt, node, "interrupt-parent", fdt_get_phandle(fdt, 
lpc_off;

  The function fdt_get_phandle fails to find the property "phandle" (or
  "linux,phandle") for the lpc node. Consequently, pnv_dt_serial sets
  the interrupt-parent to 0.

  Now boot the qemu-system-ppc64 powernv machine, and extract the fdt by
  using the qemu monitor's pmemsave command, taking help of the OPAL
  firmware's messages to locate the fdt in the physical ram.

  qemu-system-ppc64 -m 1g -machine powernv,num-chips=1 \
  -cpu power9 -smp 2,cores=2,threads=1 -accel tcg,thread=multi \
  -kernel ./vmlinux \
  -append 'disable_radix' \
  -serial mon:stdio -nographic -nodefaults

  The kernel vmlinux contains nothing but a single instruction which
  loops infintely, so that we can gather OPAL's messages, especially the
  one below:

  [0.168845963,5] INIT: Starting kernel at 0x2000, fdt at
  0x304b0b70 14404 bytes

  Once the fdt is dumped to a file, run the following:

  'dtc -O dtb -I dts -o out.dts dtb'

  After a few warnings, the dtc application crashes because an assertion
  was fired.

  out.dts: Warning (unit_address_vs_reg): /lpcm-opb@60300/lpc@0: node 
has a unit name, but no reg property
  out.dts: Warning (simple_bus_reg): /lpcm-opb@60300/lpc@0: missing or 
empty reg/ranges property
  out.dts: Warning (avoid_unnecessary_addr_size): /ibm,opal: unnecessary 
#address-cells/#size-cells without "ranges" or child "reg" property
  out.dts: Warning (unique_unit_address): /interrupt-controller@0: duplicate 
unit-address (also used in node /memory@0)
  out.dts: Warning (chosen_node_stdout_path): /chosen:linux,stdout-path: Use 
'stdout-path' instead
  dtc: livetree.c:575: get_node_by_phandle: Assertion `generate_fixups' failed.
  Aborted (core dumped)

  The assertion is fired because get_node_by_phandle receives a phandle
  value of 0, which is unexpected, unless fixups are needed (They are
  not, when running the dtc command).

  Back inside pnv_dt_serial, if the line that sets "interrupt-parent"
  for the serial device node is commented out, the dtc crash is
  prevented. Looking at hw/ppc/e500.c, it takes care of allocating
  necessary phandle values in the nodes, so a similar method can be
  adopted for powernv.

  The dtb is attached.

  Edit: Add version, Correct filenames.

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

Re: [RFC PATCH 00/25] Introduce CXL 2.0 Emulation

2020-11-25 Thread Ben Widawsky

On 20-11-17 14:09:14, Jonathan Cameron wrote:

[snip]

> 
> Agreed, it was the intermediate state that I wasn't keen on of structures 
> defined
> but then given 0 size.  I'd rather just look at them all once.  If that 
> sometimes
> means introducing a file that isn't even referenced for a few patches, that's
> fine by me.

I've pushed v2 which hopefully addressed most of the feedback from you (it also
should fix some of the BIOS table failures from v1). My next plan is to
implement a few more firmware commands, and work on supporting interleaving
using the work from Phil. I will repost to the list after that.

https://gitlab.com/bwidawsk/qemu/-/tree/cxl-2.0v2

Re: [PATCH] tests/docker, tests/vm: remove setuptools from images

On 25/11/2020 18.50, Paolo Bonzini wrote:
> Setuptools is not needed anymore by the bundled copy of meson,
> remove it.
> 
> Suggested-by: Thomas Huth 
> Signed-off-by: Paolo Bonzini 
> ---
>  .cirrus.yml| 1 -
>  tests/docker/dockerfiles/debian10.docker   | 1 -
>  tests/docker/dockerfiles/fedora-win32-cross.docker | 1 -
>  tests/docker/dockerfiles/fedora-win64-cross.docker | 1 -
>  tests/vm/freebsd   | 1 -
>  tests/vm/haiku.x86_64  | 1 -
>  tests/vm/netbsd| 1 -
>  tests/vm/openbsd   | 1 -
>  8 files changed, 8 deletions(-)

Needs to go in after the patch that removes the check in the configure
script. Then:

Reviewed-by: Thomas Huth

Re: [PATCH v4 2/2] arm64: kvm: Introduce MTE VCPU feature

2020-11-25 Thread James Morse

Hi Steven, Catalin,

On 18/11/2020 16:01, Steven Price wrote:
> On 17/11/2020 16:07, Catalin Marinas wrote:
>> On Mon, Oct 26, 2020 at 03:57:27PM +, Steven Price wrote:
>>> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
>>> index 19aacc7d64de..38fe25310ca1 100644
>>> --- a/arch/arm64/kvm/mmu.c
>>> +++ b/arch/arm64/kvm/mmu.c
>>> @@ -862,6 +862,26 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, 
>>> phys_addr_t
>>> fault_ipa,
>>>   if (vma_pagesize == PAGE_SIZE && !force_pte)
>>>   vma_pagesize = transparent_hugepage_adjust(memslot, hva,
>>>  , _ipa);
>>> +
>>> +    /*
>>> + * The otherwise redundant test for system_supports_mte() allows the
>>> + * code to be compiled out when CONFIG_ARM64_MTE is not present.
>>> + */
>>> +    if (system_supports_mte() && kvm->arch.mte_enabled && pfn_valid(pfn)) {
>>> +    /*
>>> + * VM will be able to see the page's tags, so we must ensure
>>> + * they have been initialised.
>>> + */
>>> +    struct page *page = pfn_to_page(pfn);
>>> +    long i, nr_pages = compound_nr(page);
>>> +
>>> +    /* if PG_mte_tagged is set, tags have already been initialised */
>>> +    for (i = 0; i < nr_pages; i++, page++) {
>>> +    if (!test_and_set_bit(PG_mte_tagged, >flags))
>>> +    mte_clear_page_tags(page_address(page));
>>> +    }
>>> +    }
>>
>> If this page was swapped out and mapped back in, where does the
>> restoring from swap happen?
> 
> Restoring from swap happens above this in the call to gfn_to_pfn_prot()
> 
>> I may have asked in the past, is user_mem_abort() the only path for
>> mapping Normal pages into stage 2?
>>
> 
> That is my understanding (and yes you asked before) and no one has corrected 
> me! ;)

A recent discovery: Copy on write will cause kvm_set_spte_handler() to fixup 
the mapping
(instead of just invalidating it) on the assumption the guest is going to read 
whatever
was written.

Its possible user_mem_abort() will go and stomp on that mapping a second time, 
but if the
VMM triggers this at stage1, you won't have a vcpu for the update.


Thanks,

James

Re: [PATCH v1] configure: remove python pkg_resources check


On 25/11/20 05:19, Thomas Huth wrote:

On 24/11/2020 22.19, Olaf Hering wrote:

Since meson.git#0240d760c7699a059cc89e584363c6431cdd2b61 setuptools is not 
required anymore.


That commit was part of meson 0.55.1. We require at least meson 0.55.3. So
right, this should be fine.


Signed-off-by: Olaf Hering 
---
  configure | 3 ---
  1 file changed, 3 deletions(-)

diff --git a/configure b/configure
index 8c5d2f9a69..ce9b3c0a33 100755
--- a/configure
+++ b/configure
@@ -1913,9 +1913,6 @@ fi
  
  case "$meson" in

  git | internal)
-if ! $python -c 'import pkg_resources' > /dev/null 2>&1; then
-error_exit "Python setuptools not found"
-fi
  meson="$python ${source_path}/meson/meson.py"
  ;;
  *) meson=$(command -v "$meson") ;;


Reviewed-by: Thomas Huth 

I guess we could now also remove the corresponding package from the docker
and vm files?

$ grep -r setuptool tests/
tests/docker/dockerfiles/debian10.docker: python3-setuptools \
tests/docker/dockerfiles/fedora-win32-cross.docker:python3-setuptools \
tests/docker/dockerfiles/fedora-win64-cross.docker:python3-setuptools \
tests/vm/freebsd:"py37-setuptools",
tests/vm/openbsd:"py3-setuptools",
tests/vm/haiku.x86_64:"setuptools_python3"
tests/vm/netbsd:"py37-setuptools",



Yes, it should.  I sent a patch for this.

Paolo

[PATCH] tests/docker, tests/vm: remove setuptools from images

Setuptools is not needed anymore by the bundled copy of meson,
remove it.

Suggested-by: Thomas Huth 
Signed-off-by: Paolo Bonzini 
---
 .cirrus.yml| 1 -
 tests/docker/dockerfiles/debian10.docker   | 1 -
 tests/docker/dockerfiles/fedora-win32-cross.docker | 1 -
 tests/docker/dockerfiles/fedora-win64-cross.docker | 1 -
 tests/vm/freebsd   | 1 -
 tests/vm/haiku.x86_64  | 1 -
 tests/vm/netbsd| 1 -
 tests/vm/openbsd   | 1 -
 8 files changed, 8 deletions(-)

diff --git a/.cirrus.yml b/.cirrus.yml
index f0209b7a3e..2e45b3254f 100644
--- a/.cirrus.yml
+++ b/.cirrus.yml
@@ -85,7 +85,6 @@ windows_msys2_task:
 C:\tools\msys64\usr\bin\bash.exe -lc "pacman --noconfirm -S --needed \
   diffutils git grep make pkg-config sed \
   mingw-w64-x86_64-python \
-  mingw-w64-x86_64-python-setuptools \
   mingw-w64-x86_64-toolchain \
   mingw-w64-x86_64-SDL2 \
   mingw-w64-x86_64-SDL2_image \
diff --git a/tests/docker/dockerfiles/debian10.docker 
b/tests/docker/dockerfiles/debian10.docker
index 21cc671d71..73a3caac9c 100644
--- a/tests/docker/dockerfiles/debian10.docker
+++ b/tests/docker/dockerfiles/debian10.docker
@@ -30,7 +30,6 @@ RUN apt update && \
 pkg-config \
 psmisc \
 python3 \
-python3-setuptools \
 python3-sphinx \
 $(apt-get -s build-dep qemu | egrep ^Inst | fgrep '[all]' | cut -d\  
-f2)
 
diff --git a/tests/docker/dockerfiles/fedora-win32-cross.docker 
b/tests/docker/dockerfiles/fedora-win32-cross.docker
index 5903e1b0b4..087df598a0 100644
--- a/tests/docker/dockerfiles/fedora-win32-cross.docker
+++ b/tests/docker/dockerfiles/fedora-win32-cross.docker
@@ -30,7 +30,6 @@ ENV PACKAGES \
 perl-Test-Harness \
 python3 \
 python3-PyYAML \
-python3-setuptools \
 tar \
 which
 
diff --git a/tests/docker/dockerfiles/fedora-win64-cross.docker 
b/tests/docker/dockerfiles/fedora-win64-cross.docker
index 7f03cd8ffc..d5d2f5f00d 100644
--- a/tests/docker/dockerfiles/fedora-win64-cross.docker
+++ b/tests/docker/dockerfiles/fedora-win64-cross.docker
@@ -26,7 +26,6 @@ ENV PACKAGES \
 perl-Test-Harness \
 python3 \
 python3-PyYAML \
-python3-setuptools \
 tar \
 which
 
diff --git a/tests/vm/freebsd b/tests/vm/freebsd
index 04ee793381..09f3ee6cb8 100755
--- a/tests/vm/freebsd
+++ b/tests/vm/freebsd
@@ -33,7 +33,6 @@ class FreeBSDVM(basevm.BaseVM):
 "pkgconf",
 "bzip2",
 "python37",
-"py37-setuptools",
 "ninja",
 
 # gnu tools
diff --git a/tests/vm/haiku.x86_64 b/tests/vm/haiku.x86_64
index 37af48bf1b..2eb736dae1 100755
--- a/tests/vm/haiku.x86_64
+++ b/tests/vm/haiku.x86_64
@@ -77,7 +77,6 @@ class HaikuVM(basevm.BaseVM):
 "devel:libusb_1.0",
 "devel:libz",
 "ninja",
-"setuptools_python3"
 ]
 
 # https://dev.haiku-os.org/ticket/16512 virtio disk1 shows up as 0 
(reversed order)
diff --git a/tests/vm/netbsd b/tests/vm/netbsd
index 596717cc76..b9efc269d2 100755
--- a/tests/vm/netbsd
+++ b/tests/vm/netbsd
@@ -31,7 +31,6 @@ class NetBSDVM(basevm.BaseVM):
 "pkgconf",
 "xz",
 "python37",
-"py37-setuptools",
 "ninja-build",
 
 # gnu tools
diff --git a/tests/vm/openbsd b/tests/vm/openbsd
index 386b2c72f7..4d1399378e 100755
--- a/tests/vm/openbsd
+++ b/tests/vm/openbsd
@@ -30,7 +30,6 @@ class OpenBSDVM(basevm.BaseVM):
 "git",
 "pkgconf",
 "bzip2", "xz",
-"py3-setuptools",
 "ninja",
 
 # gnu tools
-- 
2.26.2

Re: help with a build-user and build-user-plugin failure

2020-11-25 Thread Claudio Fontana

On 11/25/20 6:02 PM, Alex Bennée wrote:
> 
> Claudio Fontana  writes:
> 
>> Hi Alex,
>>
>> On 11/25/20 10:42 AM, Alex Bennée wrote:
>>>
>>> Philippe Mathieu-Daudé  writes:
>>>
 On 11/24/20 12:04 PM, Claudio Fontana wrote:
> Hi Alex,
>
> I am seeing build failures with build-user and build-user-plugin:
>
> https://gitlab.com/hw-claudio/qemu/-/pipelines/220245998
>
> and I am trying to start investigating.
>
> How do I reproduce this locally?
>
> I am trying to run locally the check-tcg rule, but I cannot get it to 
> work.
> I managed to work around the problem of static libraries (disabled them),
>
> but then I get:
>
>   BUILD   TCG tests for x86_64-linux-user
>   BUILD   x86_64-linux-user guest-tests with cc
> /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: 
> /tmp/ccgqtAM9.o: in function `test_fops':
> /dev/shm/cfontana/qemu/tests/tcg/i386/test-i386.c:759: undefined 
> reference to `fmod'
> /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: 
> /dev/shm/cfontana/qemu/tests/tcg/i386/test-i386.c:760: undefined 
> reference to `sqrt'
> /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: 
> /dev/shm/cfontana/qemu/tests/tcg/i386/test-i386.c:761: undefined 
> reference to `sin'
> /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: 
> /dev/shm/cfontana/qemu/tests/tcg/i386/test-i386.c:762: undefined 
> reference to `cos'
>
> Have you seen it before?
> Any suggestions? I'm on OpenSUSE Leap 15 SP2.

 Related to 3fc1aad3864 ("configure: remove unnecessary libm test")
 + tcg tests still not ported to Meson?
>>>
>>> Hmm so we certainly need libm for the testcase but I guess this is> failing 
>>> with a local cross compiler rather than docker? I'm not sure the
>>> global feature test should be relevant for testcases.
>>>
>>
>> Probably it's my attempt to make it work with non-static libm that failed 
>> then,
>>
>> is it supposed to work?
>>
>> I see mention of BUILD_STATIC there, but it does not seem to actually work 
>> for me.
>>
>> If I use static libm, then it works.
>> If I uninstall static libm, any attempt to build fails, regardless of
>> whether I pass BUILD_STATIC='n' or so.
> 
> All the test cases themselves should be built as static although I see
> we fall back for the case of using a local cross compiler. That normally
> only covers the case where the host compiler can also build for 32 bit
> for testcases.
> 
>>
>> Ciao and thanks,
>>
>> CLaudio
> 
> 

Ok, so static build required then, np!

Thanks,

Claudio

Re: help with a build-user and build-user-plugin failure

2020-11-25 Thread Alex Bennée



Claudio Fontana  writes:

> Hi Alex,
>
> On 11/25/20 10:42 AM, Alex Bennée wrote:
>> 
>> Philippe Mathieu-Daudé  writes:
>> 
>>> On 11/24/20 12:04 PM, Claudio Fontana wrote:
 Hi Alex,

 I am seeing build failures with build-user and build-user-plugin:

 https://gitlab.com/hw-claudio/qemu/-/pipelines/220245998

 and I am trying to start investigating.

 How do I reproduce this locally?

 I am trying to run locally the check-tcg rule, but I cannot get it to work.
 I managed to work around the problem of static libraries (disabled them),

 but then I get:

   BUILD   TCG tests for x86_64-linux-user
   BUILD   x86_64-linux-user guest-tests with cc
 /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: 
 /tmp/ccgqtAM9.o: in function `test_fops':
 /dev/shm/cfontana/qemu/tests/tcg/i386/test-i386.c:759: undefined reference 
 to `fmod'
 /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: 
 /dev/shm/cfontana/qemu/tests/tcg/i386/test-i386.c:760: undefined reference 
 to `sqrt'
 /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: 
 /dev/shm/cfontana/qemu/tests/tcg/i386/test-i386.c:761: undefined reference 
 to `sin'
 /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: 
 /dev/shm/cfontana/qemu/tests/tcg/i386/test-i386.c:762: undefined reference 
 to `cos'

 Have you seen it before?
 Any suggestions? I'm on OpenSUSE Leap 15 SP2.
>>>
>>> Related to 3fc1aad3864 ("configure: remove unnecessary libm test")
>>> + tcg tests still not ported to Meson?
>> 
>> Hmm so we certainly need libm for the testcase but I guess this is> failing 
>> with a local cross compiler rather than docker? I'm not sure the
>> global feature test should be relevant for testcases.
>> 
>
> Probably it's my attempt to make it work with non-static libm that failed 
> then,
>
> is it supposed to work?
>
> I see mention of BUILD_STATIC there, but it does not seem to actually work 
> for me.
>
> If I use static libm, then it works.
> If I uninstall static libm, any attempt to build fails, regardless of
> whether I pass BUILD_STATIC='n' or so.

All the test cases themselves should be built as static although I see
we fall back for the case of using a local cross compiler. That normally
only covers the case where the host compiler can also build for 32 bit
for testcases.

>
> Ciao and thanks,
>
> CLaudio


-- 
Alex Bennée

Re: [RFC PATCH 18/25] hw/cxl/device: Add a memory device (8.2.8.5)

2020-11-25 Thread Ben Widawsky

On 20-11-13 08:47:59, Markus Armbruster wrote:
> Eric Blake  writes:
> 
> > On 11/10/20 11:47 PM, Ben Widawsky wrote:
> >> A CXL memory device (AKA Type 3) is a CXL component that contains some
> >> combination of volatile and persistent memory. It also implements the
> >> previously defined mailbox interface as well as the memory device
> >> firmware interface.
> >> 
> >> The following example will create a 256M device in a 512M window:
> >> 
> >> -object 
> >> "memory-backend-file,id=cxl-mem1,share,mem-path=cxl-type3,size=512M"
> >> -device "cxl-type3,bus=rp0,memdev=cxl-mem1,id=cxl-pmem0,size=256M"
> >> 
> >> Signed-off-by: Ben Widawsky 
> >> ---
> >
> >> +++ b/qapi/machine.json
> >> @@ -1394,6 +1394,7 @@
> >>  { 'union': 'MemoryDeviceInfo',
> >>'data': { 'dimm': 'PCDIMMDeviceInfo',
> >>  'nvdimm': 'PCDIMMDeviceInfo',
> >> +'cxl': 'PCDIMMDeviceInfo',
> >>  'virtio-pmem': 'VirtioPMEMDeviceInfo',
> >>  'virtio-mem': 'VirtioMEMDeviceInfo'
> >>}
> >
> > Missing documentation of the new data type, and the fact that it will be
> > introduced in 6.0.
> 
> Old wish list item: improve the QAPI schema frontend to flag this.
> 

"Introduced in 6.0" - quite the optimist. Kidding aside, this is the area where
I could use some feedback. CXL Type 3 memory devices can contain both volatile
and persistent memory at the same time. As such, I think I'll need a new type to
represent that, but I'd love to know how best to accomplish that.

> > Also, Markus has been trying to get rid of so-called
> > "simple unions" in favor of "flat unions" - every time we modify an
> > existing simple union, it is worth asking if it is time to first flatten
> > this.
> 
> 0. Simple unions can be transformed into flat unions.  The
> transformation can either preserve the nested wire format, or flatten
> it.  See docs/devel/qapi-code-gen.txt "A simple union can always be
> re-written as a flat union ..."
> 
> 1. No new simple unions.
> 
> 2. Existing simple unions that can be flattened without breaking
> backward compatibility have long been flattened.
> 
> 3. The remaining simple unions are part of QMP, where we need to
> preserve the wire format.  We could turn them into flat union preserving
> the wire format.  Only worthwhile if we kill simple unions and simplify
> scripts/qapi/.  Opportunity to make the flat union syntax less
> cumbersome.  Not done due to lack of time.
> 
> 4. Kevin and I have been experimenting with ways to provide both flat
> and nested wire format.  This would pave the way for orderly deprecation
> of the nested wire format.  May not be practical for QMP output.
> 

So is there anything for me to do here?

Re: [PATCH 1/1] Fix qcow2 corruption on discard

2020-11-25 Thread Alberto Garcia

On Tue 24 Nov 2020 08:44:00 PM CET, Maxim Levitsky wrote:
> On Tue, 2020-11-24 at 20:59 +0200, Maxim Levitsky wrote:
>> On Tue, 2020-11-24 at 19:59 +0100, Alberto Garcia wrote:
>> > On Tue 24 Nov 2020 10:17:23 AM CET, Kevin Wolf wrote:
>> > > We can then continue work to find a minimal reproducer and merge the
>> > > test case in the early 6.0 cycle.
>> > 
>> > I haven't been able to reproduce the problem yet, do you have any
>> > findings?
>> > 
>> > Berto
>> > 
>> 
>> I have a working reproducer script. I'll send it in a hour or so.
>> Best regards,
>>  Maxim Levitsky
>
> I have attached a minimal reproducer for this issue.
> I can convert this to an iotest if you think that this is worth it.

I think it would be a good idea to have an iotest, I can also prepare if
you don't have time.

Thanks for the script!

Berto

[Bug 1779447] Re: SLIRP SMB silently fails with MacOS smbd

2020-11-25 Thread Alexander Richardson

** Changed in: qemu
   Status: Incomplete => 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/1779447

Title:
  SLIRP SMB silently fails with MacOS smbd

Status in QEMU:
  New

Bug description:
  When using the -net 
user,id=net0,ipv6=off,smb=/path/to/share/option,hostfwd=tcp::19500-:22 I can 
successfully mount_smbfs the shared directory on the guest when QEMU is running 
on a Linux or FreeBSD host. However, on a MacOS host the mount_smbfs command 
just fails with
  `mount_smbfs: unable to open connection: syserr = Connection reset by peer`.
  After some debugging it turns out this is because the smbd shipped by macos 
is incompatible and doesn't use the same config file/command line arguments.

  I have since got it working by compiling the sources form samba.org
  and using the --smbd= configure option pointing to that binary.

  Would it be possible to print a warning message or even better abort
  the launch saying smbd is incompatible with QEMU if the -smb= flag is
  passed? It appears that smbd should die with an error code on invalid
  arguments so QEMU should be able to report that.

  
  This was happening with QEMU built from git sources at 
c1c2a435905ae76b159c573b0c0d6f095b45ebc6.

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

[Bug 1833053] Re: qemu guest crashes on spice client USB redirected device removal

The QEMU project is currently considering to move its bug tracking to another 
system. For this we need to know which bugs are still valid and which could be 
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the state 
back to "New" within the next 60 days, otherwise this report will be marked as 
"Expired". Or mark it as "Fix Released" if the problem has been solved with a 
newer version of QEMU already. Thank you and sorry for the inconvenience.

** Changed in: qemu
   Status: New => Incomplete

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

Title:
  qemu guest crashes on spice client USB redirected device removal

Status in QEMU:
  Incomplete

Bug description:
  Hello,

  I am experiencing guest crashes, which cannot be reproduced at all
  times, but are pretty frequent (4 out of 5 tries it would crash). The
  guest crashes when a previously attached USB redirected device through
  SPICE has been removed by the client.

  Steps to reproduce:
  1.) Start windows 10 guest with display driver Spice
  2.) Connect to the console with remote-viewer spice://IP:PORT or via 
virt-viewer (tunnelled through SSH)
  3.) Attach a client USB device, for example storage device, iPhone or Android 
phone
  4.) Observe the guest OS detects it and sets it up
  5.) Go back to 'USB device selection' and untick the USB device
  6.) Observe the guest VM crashed and the below assertion was printed in the 
qemu log for this virtual machine:

  qemu-system-x86_64: 
/var/tmp/portage/app-emulation/qemu-4.0.0-r3/work/qemu-4.0.0/hw/usb/core.c:720: 
usb_ep_get: Assertion `dev != NULL' failed.
  2019-06-17 09:25:09.160+: shutting down, reason=crashed

  
  Versions of related packages on the host:
  app-emulation/qemu-4.0.0-r3
  app-emulation/spice-0.14.0-r2:0
  app-emulation/spice-protocol-0.12.14:0
  net-misc/spice-gtk-0.35:0
  Kernel: 5.1.7-gentoo on Intel x86_64 CPU

  Version of the spice-tools on the guest:
  virtio-win 0.1-126
  QXL 0.1-21
  mingw-vdagent-win 0.8.0

  QEMU command line (generated by libvirt):

  /usr/bin/qemu-system-x86_64 -name guest=W10VM,debug-threads=on -S
  -object
  secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-41-W10VM
  /master-key.aes -machine pc-i440fx-2.12,accel=kvm,usb=off,vmport=off
  ,dump-guest-core=off -cpu
  qemu64,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_synic,hv_stimer
  -m 4500 -realtime mlock=off -smp
  2,maxcpus=4,sockets=4,cores=1,threads=1 -uuid b39afae2-5085-4659-891c-
  b3c65e65af2e -no-user-config -nodefaults -chardev
  socket,id=charmonitor,fd=26,server,nowait -mon
  chardev=charmonitor,id=monitor,mode=control -rtc
  base=localtime,driftfix=slew -no-hpet -global kvm-
  pit.lost_tick_policy=delay -no-shutdown -global PIIX4_PM.disable_s3=1
  -global PIIX4_PM.disable_s4=1 -boot menu=off,strict=on -device ich9
  -usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-
  uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5
  -device ich9-usb-
  uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9
  -usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device
  virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x8 -device virtio-serial-
  pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive
  file=/libvirt/images/W10VM.qcow2,format=qcow2,if=none,id=drive-
  scsi0-0-0-1,cache=unsafe,discard=unmap,detect-zeroes=unmap -device
  scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,device_id=drive-
  scsi0-0-0-1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1,bootindex=1,write-
  cache=on -netdev tap,fd=28,id=hostnet0,vhost=on,vhostfd=29 -device
  virtio-net-
  pci,netdev=hostnet0,id=net0,mac=52:54:00:44:f6:21,bus=pci.0,addr=0x3
  -chardev spicevmc,id=charchannel0,name=vdagent -device
  virtserialport,bus=virtio-
  serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0
  -chardev socket,id=charchannel1,fd=30,server,nowait -device
  virtserialport,bus=virtio-
  serial0.0,nr=3,chardev=charchannel1,id=channel1,name=org.qemu.guest_agent.0
  -chardev spiceport,id=charchannel2,name=org.spice-space.webdav.0
  -device virtserialport,bus=virtio-
  serial0.0,nr=2,chardev=charchannel2,id=channel2,name=org.spice-
  space.webdav.0 -spice port=5901,addr=0.0.0.0,seamless-migration=on
  -device qxl-
  
vga,id=video0,ram_size=134217728,vram_size=134217728,vram64_size_mb=0,vgamem_mb=64,max_outputs=1,bus=pci.0,addr=0x2
  -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-
  duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev
  spicevmc,id=charredir0,name=usbredir -device usb-
  redir,chardev=charredir0,id=redir0,bus=usb.0,port=1 -chardev
  spicevmc,id=charredir1,name=usbredir -device usb-
  redir,chardev=charredir1,id=redir1,bus=usb.0,port=2 -device virtio-
  balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -sandbox

Re: [PATCH v2] hw/arm/virt enable support for virtio-mem

2020-11-25 Thread David Hildenbrand

On 25.11.20 17:11, Jonathan Cameron wrote:
> On Wed, 25 Nov 2020 16:54:53 +0100
> David Hildenbrand  wrote:
> 
>>
>> 64k guest on 4k host with 512MiB block size seems fine.
>>
>> If there are any places anyone thinks need particular poking I'd 
>> appreciate a hint :)
>
> If things seem to work for now, that's great :) Thanks!
>  
 Cool.  I'll run a few more comprehensive tests then send out the
 trivial patch to enable the kernel option + v2 of the qemu support.  
>>>
>>> Perfect, thanks!  
>>
>> Oh, btw, I have no idea what the state of vfio-pci + QEMU on arm64 is.
>> In case it's supposed to work, you could give
>>
>> https://lkml.kernel.org/r/20201119153918.120976-1-da...@redhat.com
>>
>> to see what we're missing.
> 
> vfio-pci works in general (and we use it a lot), so sure I'll give
> this a test run.

Cool.

In case you get it to run, please test with both "online_kernel" and
"online_movable" in the guest, and small boot memory (e.g., 2 GiB).

For example, on x86-64 I got my vfio-pci provided GPUs to consume
virtio-mem memory easily when starting with 2-4 GiB boot memory and
using "online_kernel". (I verified that when not creating the mappings,
IO errors can be observed and graphics are messed up).

-- 
Thanks,

David / dhildenb

[Bug 1826568] Re: RISC-V Disassembler/translator instruction decoding disagreement

2020-11-25 Thread Floyd42

** Changed in: qemu
   Status: Incomplete => 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/1826568

Title:
  RISC-V Disassembler/translator instruction decoding disagreement

Status in QEMU:
  New

Bug description:
  
  When running QEMU V3.1.0 for platform  RISC-V, 64bit, Spike V1.10 with "-d 
in_asm -singlestep -D qemu_log.txt", my (faulty) test code brought up this 
message in the logs:

0x8002cade:  05139517e2bf  illegal 
Disassembler disagrees with translator over instruction decoding
Please report this to qemu-devel@nongnu.org

  
  You may want to resolve the disagreement.

  Axel

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

[Bug 1837049] Re: qemu-system-ppc segfaults with -display sdl

Closing according to comment #3

** Changed in: qemu
   Status: New => Fix Released

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

Title:
  qemu-system-ppc segfaults with -display sdl

Status in QEMU:
  Fix Released

Bug description:
  Hello.

  I was trying to debug this segfault:
  https://lists.nongnu.org/archive/html/qemu-ppc/2019-07/msg00186.html

  I recompiled latest qemu from git (commit 
0b18cfb8f1828c905139b54c8644b0d8f4aad879 ), using this configure line:
  ./configure --target-list=i386-softmmu,x86_64-softmmu,ppc-softmmu 
--audio-drv-list=alsa --disable-werror --extra-cflags="-Og" --enable-debug-tcg

  after this I tried original line under gdb, it was still segfaulting:

  --copy-
  gdb ./ppc-softmmu/qemu-system-ppc
  GNU gdb (GDB) 7.11.1
  Copyright (C) 2016 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
  and "show warranty" for details.
  This GDB was configured as "i586-slackware-linux".
  Type "show configuration" for configuration details.
  For bug reporting instructions, please see:
  .
  Find the GDB manual and other documentation resources online at:
  .
  For help, type "help".
  Type "apropos word" to search for commands related to "word"...
  Reading symbols from ./ppc-softmmu/qemu-system-ppc...done.
  warning: File "/dev/shm/qemu/.gdbinit" auto-loading has been declined by your 
`auto-load safe-path' set to "$debugdir:$datadir/auto-load".
  To enable execution of this file add
  add-auto-load-safe-path /dev/shm/qemu/.gdbinit
  line to your configuration file "/home/guest/.gdbinit".
  To completely disable this security protection add
  set auto-load safe-path /
  line to your configuration file "/home/guest/.gdbinit".
  For more information about this security protection see the
  "Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
  info "(gdb)Auto-loading safe path"
  (gdb) run  -M mac99,via=pmu -L ../queue-vga/pc-bios -cdrom 
/mnt/sdb1/PPC-img/lubuntu-16.04-desktop-powerpc.iso -m 512 -display sdl,gl=on 
-vga std -d guest_errors,unimp -boot d -cpu G4 -g 1024x768x24 -device ES1370
  Starting program: /dev/shm/qemu/ppc-softmmu/qemu-system-ppc -M mac99,via=pmu 
-L ../queue-vga/pc-bios -cdrom 
/mnt/sdb1/PPC-img/lubuntu-16.04-desktop-powerpc.iso -m 512 -display sdl,gl=on 
-vga std -d guest_errors,unimp -boot d -cpu G4 -g 1024x768x24 -device ES1370
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/libthread_db.so.1".
  [New Thread 0xf560cb40 (LWP 8100)]
  [New Thread 0xf4c1ab40 (LWP 8101)]
  [New Thread 0xec1b7b40 (LWP 8102)]
  [New Thread 0xc5821b40 (LWP 8104)]
  [Thread 0xf4c1ab40 (LWP 8101) exited]
  [New Thread 0xf4c1ab40 (LWP 8119)]

  Thread 4 "qemu-system-ppc" received signal SIGSEGV, Segmentation fault.
  [Switching to Thread 0xec1b7b40 (LWP 8102)]
  0xf26c2e44 in code_gen_buffer ()
  (gdb) bt full
  #0  0x in code_gen_buffer ()
  #1  0x56710cf6 in cpu_exec (itb=, cpu=) at 
/dev/shm/qemu/accel/tcg/cpu-exec.c:173
  env = 
  ret = 
  last_tb = 
  tb_exit = 
  tb_ptr = 0xf26c2cc0  "‹]ш…Ы\017ЊБ\020"
  ret = 0
  insns_left = 
  cflags = 
  tb = 0x5722fe58
  last_tb = 
  tb_exit = 
  cc = 
  __func__ = "cpu_exec"
  ret = 
  sc = 
  #2  0x56710cf6 in cpu_exec (tb_exit=, last_tb=, tb=, cpu=) at 
/dev/shm/qemu/accel/tcg/cpu-exec.c:621
  ret = 0
  insns_left = 
  cflags = 
  tb = 0x5722fe58
  last_tb = 
  tb_exit = 
  cc = 
  __func__ = "cpu_exec"
  ret = 
  sc = 
  #3  0x56710cf6 in cpu_exec (cpu=0x573db8f8) at 
/dev/shm/qemu/accel/tcg/cpu-exec.c:732
  cflags = 
  tb = 0x5722fe58
  last_tb = 
  tb_exit = 
  cc = 
  __func__ = "cpu_exec"
  ret = 
  sc = 
  #4  0x566cfade in tcg_cpu_exec (cpu=0x573db8f8) at /dev/shm/qemu/cpus.c:1435
  ret = 
  #5  0x566d1e6d in qemu_tcg_rr_cpu_thread_fn (arg=0x573db8f8) at 
/dev/shm/qemu/cpus.c:1537
  r = 
  cpu = 0x573db8f8
  __PRETTY_FUNCTION__ = "qemu_tcg_rr_cpu_thread_fn"
  #6  0x56b56fe0 in qemu_thread_start (args=0x57400668) at 
util/qemu-thread-posix.c:502
  __cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {1461911128, 
1463813736, 1461911128, -333745816, 247778263, 1392237730}, __mask_was_saved = 
0}}, __pad = {0xec1b70d0, 0x0, 0x0, 0x0}}
  __cancel_routine = 0x56b57040 
  __not_first_call =

[Bug 1826568] Re: RISC-V Disassembler/translator instruction decoding disagreement

The QEMU project is currently considering to move its bug tracking to another 
system. For this we need to know which bugs are still valid and which could be 
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the state 
back to "New" within the next 60 days, otherwise this report will be marked as 
"Expired". Or mark it as "Fix Released" if the problem has been solved with a 
newer version of QEMU already. Thank you and sorry for the inconvenience.

** Changed in: qemu
   Status: New => Incomplete

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

Title:
  RISC-V Disassembler/translator instruction decoding disagreement

Status in QEMU:
  Incomplete

Bug description:
  
  When running QEMU V3.1.0 for platform  RISC-V, 64bit, Spike V1.10 with "-d 
in_asm -singlestep -D qemu_log.txt", my (faulty) test code brought up this 
message in the logs:

0x8002cade:  05139517e2bf  illegal 
Disassembler disagrees with translator over instruction decoding
Please report this to qemu-devel@nongnu.org

  
  You may want to resolve the disagreement.

  Axel

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

[Bug 1821054] Re: qemu segfault error when using pcie to dual pci adapter

Hi! Did you ever get a backtrace? ... otherwise I think we have to close
this ticket due to insufficient data...

** Changed in: qemu
   Status: New => Incomplete

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

Title:
  qemu segfault error when using pcie to dual pci adapter

Status in QEMU:
  Incomplete

Bug description:
  All the information I have is located in the Unraid forum on post 
"https://forums.unraid.net/topic/78545-internal-error-qemu-unexpectedly-closed-the-monitor;
  I am happy to provide any addition information requested. Please let me know. 
Reporting bug here based on recommendation by admin in that forum.

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

Re: [PATCH v2] hw/arm/virt enable support for virtio-mem

2020-11-25 Thread Jonathan Cameron

On Wed, 25 Nov 2020 16:54:53 +0100
David Hildenbrand  wrote:

> 
>  64k guest on 4k host with 512MiB block size seems fine.
> 
>  If there are any places anyone thinks need particular poking I'd 
>  appreciate a hint :)
> >>>
> >>> If things seem to work for now, that's great :) Thanks!
> >>>  
> >> Cool.  I'll run a few more comprehensive tests then send out the
> >> trivial patch to enable the kernel option + v2 of the qemu support.  
> > 
> > Perfect, thanks!  
> 
> Oh, btw, I have no idea what the state of vfio-pci + QEMU on arm64 is.
> In case it's supposed to work, you could give
> 
> https://lkml.kernel.org/r/20201119153918.120976-1-da...@redhat.com
> 
> to see what we're missing.

vfio-pci works in general (and we use it a lot), so sure I'll give
this a test run.

> 
> I added a short virtio-pci guide to
> 
> https://virtio-mem.gitlab.io/user-guide/user-guide-qemu.html
> 

Thanks,

Jonathan

Re: [DISCUSSION] Allow ACPI default OEM ID and OEM table ID fields to be set.

2020-11-25 Thread Michael S. Tsirkin

On Wed, Nov 25, 2020 at 01:32:51PM +, Richard W.M. Jones wrote:
> On Wed, Nov 25, 2020 at 02:27:11PM +0100, Antoine Damhet wrote:
> > Hello,
> > 
> > We recently found out that some softwares are effectively crashing
> > when they detect qemu's `OEM ID` or `OEM table ID` in the ACPI tables.
> > 
> > I see no reason not to expose the setting to the user/command-line. A
> > previous patch has been submitted in 2015[1] but did not get through
> > because (if I understand correctly) using the IDs on the `SLIC`, `BXPC`
> > and `RSDT` tables were enough at the time.
> > 
> > If you agree, I am willing to forward port the patches of M. Jones but I
> > need to ask how it would work `Signed-Off`-wise ?
> 
> On this point, the patch I sent was actually written by
> Michael Tokarev, I was only trying to get them upstream.
> 
> Rich.

I think at least one of the issues is that e.g. UEFI at least
seems to assume unique OEM table IDs e.g. for SSDTs.

So let's try to be more specific please, which software
crashes, what does it want to see and in which table.


> > Thanks in advance for your time,
> > 
> > PS: the softwares will crash if the signature is found in any of the
> > exposed tables.
> > 
> > [1]: 
> > https://lore.kernel.org/qemu-devel/1441220618-4750-1-git-send-email-rjo...@redhat.com/
> > 
> > -- 
> > Antoine 'xdbob' Damhet
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-p2v converts physical machines to virtual machines.  Boot with a
> live CD or over the network (PXE) and turn machines into KVM guests.
> http://libguestfs.org/virt-v2v

Re: [PATCH RFC] tests/acceptance: add a test for devices on s390x

2020-11-25 Thread Philippe Mathieu-Daudé

Hi Cornelia,

On 11/25/20 4:03 PM, Thomas Huth wrote:
> On 25/11/2020 14.58, Cornelia Huck wrote:
>> This adds a very basic test for checking that we present devices
>> in a way that Linux can consume: boot with both virtio-net-ccw and
>> virtio-net-pci attached and then verify that Linux is able to see
>> and detect these devices.
> 
> Thanks for tackling it!
> 
>> Signed-off-by: Cornelia Huck 
>> ---
>>
>> A very basic test, but it would have caught the recent zPCI regression.

Thanks for adding this test :)

>>
>> If anyone has a better idea than using early debug shells in the Debian
>> install image, please let me know. At least it's quick, as we can check
>> for the devices quite early in the boot sequence.

This is the simplest cheaper way I think.

Alternative is to use Guenter's images:
https://github.com/groeck/linux-build-test/tree/master/rootfs/s390

>>
>> Not sure if running under both kvm and tcg on an s390 host would add
>> useful extra coverage. Also not sure if this needs fencing on any of the
>> public CIs (have not tried yet).
> 
> We're only running the acceptance tests in the gitlab-CI, no worries about
> the others.
> 
>> ---
>>  tests/acceptance/s390_devices.py | 68 
>>  1 file changed, 68 insertions(+)
>>  create mode 100644 tests/acceptance/s390_devices.py
>>
>> diff --git a/tests/acceptance/s390_devices.py 
>> b/tests/acceptance/s390_devices.py
>> new file mode 100644
>> index ..6ce47061f35d
>> --- /dev/null
>> +++ b/tests/acceptance/s390_devices.py
> 
> s390x_devices.py ?
> 
> Or maybe even machine_s390x.py instead, like the other machine*.py files?

Feel free to use whatever name/directory structure that help others to
find your tests (don't forget to add an entry to MAINTAINERS).

Regards,

Phil.

Re: [PATCH v2] hw/arm/virt enable support for virtio-mem

2020-11-25 Thread David Hildenbrand


 64k guest on 4k host with 512MiB block size seems fine.

 If there are any places anyone thinks need particular poking I'd 
 appreciate a hint :)  
>>>
>>> If things seem to work for now, that's great :) Thanks!
>>>
>> Cool.  I'll run a few more comprehensive tests then send out the
>> trivial patch to enable the kernel option + v2 of the qemu support.
> 
> Perfect, thanks!

Oh, btw, I have no idea what the state of vfio-pci + QEMU on arm64 is.
In case it's supposed to work, you could give

https://lkml.kernel.org/r/20201119153918.120976-1-da...@redhat.com

to see what we're missing.

I added a short virtio-pci guide to

https://virtio-mem.gitlab.io/user-guide/user-guide-qemu.html

-- 
Thanks,

David / dhildenb

Re: [PATCH RFC] tests/acceptance: add a test for devices on s390x

2020-11-25 Thread Cornelia Huck

On Wed, 25 Nov 2020 16:03:13 +0100
Thomas Huth  wrote:

> On 25/11/2020 14.58, Cornelia Huck wrote:
> > This adds a very basic test for checking that we present devices
> > in a way that Linux can consume: boot with both virtio-net-ccw and
> > virtio-net-pci attached and then verify that Linux is able to see
> > and detect these devices.  
> 
> Thanks for tackling it!
> 
> > Signed-off-by: Cornelia Huck 
> > ---
> > 
> > A very basic test, but it would have caught the recent zPCI regression.
> > 
> > If anyone has a better idea than using early debug shells in the Debian
> > install image, please let me know. At least it's quick, as we can check
> > for the devices quite early in the boot sequence.
> > 
> > Not sure if running under both kvm and tcg on an s390 host would add
> > useful extra coverage. Also not sure if this needs fencing on any of the
> > public CIs (have not tried yet).  
> 
> We're only running the acceptance tests in the gitlab-CI, no worries about
> the others.
> 
> > ---
> >  tests/acceptance/s390_devices.py | 68 
> >  1 file changed, 68 insertions(+)
> >  create mode 100644 tests/acceptance/s390_devices.py
> > 
> > diff --git a/tests/acceptance/s390_devices.py 
> > b/tests/acceptance/s390_devices.py
> > new file mode 100644
> > index ..6ce47061f35d
> > --- /dev/null
> > +++ b/tests/acceptance/s390_devices.py  
> 
> s390x_devices.py ?
> 
> Or maybe even machine_s390x.py instead, like the other machine*.py files?

Makes sense.

> 
> > @@ -0,0 +1,68 @@
> > +# Functional test that boots an s390x Linux guest with ccw and PCI devices
> > +# attached and checks whether the devices are recognized by Linux
> > +#
> > +# Copyright (c) 2020 Red Hat, Inc.
> > +#
> > +# Author:
> > +#  Cornelia Huck 
> > +#
> > +# This work is licensed under the terms of the GNU GPL, version 2 or
> > +# later.  See the COPYING file in the top-level directory.
> > +
> > +
> > +import os
> > +
> > +from avocado_qemu import Test
> > +from avocado_qemu import exec_command_and_wait_for_pattern
> > +from avocado_qemu import wait_for_console_pattern
> > +
> > +class CheckS390xDevices(Test):
> > +KERNEL_COMMON_COMMAND_LINE = 'printk.time=0 '
> > +
> > +def wait_for_console_pattern(self, success_message, vm=None):
> > +wait_for_console_pattern(self, success_message,
> > + failure_message='Kernel panic - not 
> > syncing',
> > + vm=vm)
> > +
> > +timeout = 60  
> 
> Running on public CIs can be slow ... I'd maybe directly start with 90 or
> 120 here.

Ok; I found it hard to pick a sensible value here.

> 
> > +def test(self):
> > +
> > +"""
> > +:avocado: tags=arch:s390x
> > +:avocado: tags=machine:s390-ccw-virtio
> > +"""
> > +
> > +# XXX: switch to https when debian fixes their certificate
> > +kernel_url = ('http://archive.debian.org/debian/dists/jessie/main'
> > +  
> > '/installer-s390x/current/images/generic/kernel.debian')
> > +kernel_hash = '5af1aa839754f4d8817fb5878b4d55dfc887f45d'
> > +kernel_path = self.fetch_asset(kernel_url, asset_hash=kernel_hash)
> > +
> > +initrd_url = ('http://archive.debian.org/debian/dists/jessie/main'
> > +  
> > '/installer-s390x/current/images/generic/initrd.debian')
> > +initrd_hash = '99252b28306184b876f979585e2d4bfe96b27464'
> > +initrd_path = self.fetch_asset(initrd_url, asset_hash=initrd_hash)
> > +
> > +self.vm.set_console()
> > +kernel_command_line = (self.KERNEL_COMMON_COMMAND_LINE +
> > +  'console=sclp0 root=/dev/ram0 BOOT_DEBUG=3')
> > +self.vm.add_args('-nographic',
> > + '-kernel', kernel_path,
> > + '-initrd', initrd_path,
> > + '-append', kernel_command_line,
> > + '-device', 'virtio-net-ccw,devno=fe.1.',
> > + '-device', 'virtio-net-pci')  
> 
> Maybe use '-device', 'virtio-net-pci,addr=6' or something similar to check a
> non-default PCI address, too?

Not sure if addr= will do the trick, I may need to add a zpci device.

> 
> > +self.vm.launch()
> > +
> > +shell_ready = "sh: can't access tty; job control turned off"
> > +self.wait_for_console_pattern(shell_ready)
> > +# first debug shell is too early, we need to wait for device 
> > detection
> > +exec_command_and_wait_for_pattern(self, 'exit', shell_ready)
> > +
> > +ccw_bus_id="0.1."
> > +pci_bus_id=":00:00.0"
> > +exec_command_and_wait_for_pattern(self, 'ls /sys/bus/ccw/devices/',
> > +  ccw_bus_id)
> > +exec_command_and_wait_for_pattern(self, 'ls /sys/bus/pci/devices/',
> > +  pci_bus_id)
> >   
> 
> Additional ideas (likely for

Re: [PATCH 2/3] qemu/atomic: Drop special case for unsupported compiler

2020-11-25 Thread Marc-André Lureau

Hi

On Mon, Sep 28, 2020 at 5:49 PM Peter Maydell 
wrote:

> On Mon, 28 Sep 2020 at 14:12, Philippe Mathieu-Daudé 
> wrote:
> >
> > Since commit efc6c070aca ("configure: Add a test for the
> > minimum compiler version") the minimum compiler version
> > required for GCC is 4.8, which has the GCC BZ#36793 bug fixed.
> >
> > We can safely remove the special case introduced in commit
> > a281ebc11a6 ("virtio: add missing mb() on notification").
>
> > -/*
> > - * We use GCC builtin if it's available, as that can use mfence on
> > - * 32-bit as well, e.g. if built with -march=pentium-m. However, on
> > - * i386 the spec is buggy, and the implementation followed it until
> > - * 4.3 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36793).
> > - */
> > -#if defined(__i386__) || defined(__x86_64__)
> > -#if !QEMU_GNUC_PREREQ(4, 4)
> > -#if defined __x86_64__
> > -#define smp_mb()({ asm volatile("mfence" ::: "memory"); (void)0; })
> > -#else
> > -#define smp_mb()({ asm volatile("lock; addl $0,0(%%esp) " :::
> "memory"); (void)0; })
> > -#endif
> > -#endif
> > -#endif
>
> You need to be a bit cautious about removing QEMU_GNUC_PREREQ()
> checks, because clang advertises itself as GCC 4.2 via the
> __GNUC__ and __GNUC_MINOR__ macros that QEMU_GNUC_PREREQ()
> tests, and so unless the code has explicitly handled clang
> via a different ifdef or feature test clang will be using
> the fallback codepath in cases like this. So you also need
> to find out whether all our supported versions of clang
> are OK with the gcc-4.4-and-up version of this code...
> (I think that deleting this set of #ifs means we end up
> with the "just use __sync_synchronize()" version of smp_mb()
> later on in the header?)
>

With clang 3.8 (xenial amd64) __ATOMIC_RELAXED is defined, so the chunk to
remove which is x86-specific anyway, isn't reached.

Reviewed-by: Marc-André Lureau 


-- 
Marc-André Lureau

Re: [PATCH v2] hw/arm/virt enable support for virtio-mem

2020-11-25 Thread David Hildenbrand

> Ah. I'd missed that quirk around MAX_ORDER.  It's also true of ARM64 with
> 4k pages.  As you can probably guess I'd forgotten to recompile my 4k test
> kernel after adding that particular check. :(
> 
> Ah well. Given we are already in a situation where adding 2MiB doesn't 
> actually
> do anything useful, I guess it's not really a problem to merrily let the host
> add less than the guest can make use of.  So we allow adding any multiple of
> 2MiB but reality is the guest isn't going to use anything other than 512MiB
> chunks.

Right, and the host can observe the change not happening when not
aligned to 512 MB. There are plans for a virtio-mem extension for the
guest to present a status - e.g., why the requested size cannot be
achieved (requested size not alignment, usable region too small,
ENOMEM/EBUSY when unplugging, ...).

[...]

>>>
>>> 4K guest on 64K host seems fine and no such limit is needed - though there
>>> may be performance issues doing that.  
>>
>> Yeah, if one is lucky to get one of these 512 MiB huge pages at all :)
> 
> Not too hard on my 1TB test system that's running nothing much else, but 
> agreed it
> won't be trivial more generally.

Hehe, right ! (... and here I am, testing with 64GB machines ... :) )

It's more of an issue in the guest to get 512 MB without ZONE_MOVABLE to
unplug ... especially with smaller VMs.

> 
>>
>>>
>>> 64k guest on 4k host with 512MiB block size seems fine.
>>>
>>> If there are any places anyone thinks need particular poking I'd appreciate 
>>> a hint :)  
>>
>> If things seem to work for now, that's great :) Thanks!
>>
> Cool.  I'll run a few more comprehensive tests then send out the
> trivial patch to enable the kernel option + v2 of the qemu support.

Perfect, thanks!

-- 
Thanks,

David / dhildenb

Re: [PATCH RFC] tests/acceptance: add a test for devices on s390x

On 25/11/2020 14.58, Cornelia Huck wrote:
> This adds a very basic test for checking that we present devices
> in a way that Linux can consume: boot with both virtio-net-ccw and
> virtio-net-pci attached and then verify that Linux is able to see
> and detect these devices.

Thanks for tackling it!

> Signed-off-by: Cornelia Huck 
> ---
> 
> A very basic test, but it would have caught the recent zPCI regression.
> 
> If anyone has a better idea than using early debug shells in the Debian
> install image, please let me know. At least it's quick, as we can check
> for the devices quite early in the boot sequence.
> 
> Not sure if running under both kvm and tcg on an s390 host would add
> useful extra coverage. Also not sure if this needs fencing on any of the
> public CIs (have not tried yet).

We're only running the acceptance tests in the gitlab-CI, no worries about
the others.

> ---
>  tests/acceptance/s390_devices.py | 68 
>  1 file changed, 68 insertions(+)
>  create mode 100644 tests/acceptance/s390_devices.py
> 
> diff --git a/tests/acceptance/s390_devices.py 
> b/tests/acceptance/s390_devices.py
> new file mode 100644
> index ..6ce47061f35d
> --- /dev/null
> +++ b/tests/acceptance/s390_devices.py

s390x_devices.py ?

Or maybe even machine_s390x.py instead, like the other machine*.py files?

> @@ -0,0 +1,68 @@
> +# Functional test that boots an s390x Linux guest with ccw and PCI devices
> +# attached and checks whether the devices are recognized by Linux
> +#
> +# Copyright (c) 2020 Red Hat, Inc.
> +#
> +# Author:
> +#  Cornelia Huck 
> +#
> +# This work is licensed under the terms of the GNU GPL, version 2 or
> +# later.  See the COPYING file in the top-level directory.
> +
> +
> +import os
> +
> +from avocado_qemu import Test
> +from avocado_qemu import exec_command_and_wait_for_pattern
> +from avocado_qemu import wait_for_console_pattern
> +
> +class CheckS390xDevices(Test):
> +KERNEL_COMMON_COMMAND_LINE = 'printk.time=0 '
> +
> +def wait_for_console_pattern(self, success_message, vm=None):
> +wait_for_console_pattern(self, success_message,
> + failure_message='Kernel panic - not 
> syncing',
> + vm=vm)
> +
> +timeout = 60

Running on public CIs can be slow ... I'd maybe directly start with 90 or
120 here.

> +def test(self):
> +
> +"""
> +:avocado: tags=arch:s390x
> +:avocado: tags=machine:s390-ccw-virtio
> +"""
> +
> +# XXX: switch to https when debian fixes their certificate
> +kernel_url = ('http://archive.debian.org/debian/dists/jessie/main'
> +  
> '/installer-s390x/current/images/generic/kernel.debian')
> +kernel_hash = '5af1aa839754f4d8817fb5878b4d55dfc887f45d'
> +kernel_path = self.fetch_asset(kernel_url, asset_hash=kernel_hash)
> +
> +initrd_url = ('http://archive.debian.org/debian/dists/jessie/main'
> +  
> '/installer-s390x/current/images/generic/initrd.debian')
> +initrd_hash = '99252b28306184b876f979585e2d4bfe96b27464'
> +initrd_path = self.fetch_asset(initrd_url, asset_hash=initrd_hash)
> +
> +self.vm.set_console()
> +kernel_command_line = (self.KERNEL_COMMON_COMMAND_LINE +
> +  'console=sclp0 root=/dev/ram0 BOOT_DEBUG=3')
> +self.vm.add_args('-nographic',
> + '-kernel', kernel_path,
> + '-initrd', initrd_path,
> + '-append', kernel_command_line,
> + '-device', 'virtio-net-ccw,devno=fe.1.',
> + '-device', 'virtio-net-pci')

Maybe use '-device', 'virtio-net-pci,addr=6' or something similar to check a
non-default PCI address, too?

> +self.vm.launch()
> +
> +shell_ready = "sh: can't access tty; job control turned off"
> +self.wait_for_console_pattern(shell_ready)
> +# first debug shell is too early, we need to wait for device 
> detection
> +exec_command_and_wait_for_pattern(self, 'exit', shell_ready)
> +
> +ccw_bus_id="0.1."
> +pci_bus_id=":00:00.0"
> +exec_command_and_wait_for_pattern(self, 'ls /sys/bus/ccw/devices/',
> +  ccw_bus_id)
> +exec_command_and_wait_for_pattern(self, 'ls /sys/bus/pci/devices/',
> +  pci_bus_id)
> 

Additional ideas (likely for later patches): Set a custom mac address for
the virtio-net devices and check whether they show up correctly in the
guest... Use "ping" to send some packets around (with -netdev user)...

 Thomas

Re: [PATCH v2 3/8] qnum: QNumValue type for QNum value literals

On Wed, Nov 25, 2020 at 07:40:48AM +0100, Markus Armbruster wrote:
> Eduardo Habkost  writes:
> 
> > On Tue, Nov 24, 2020 at 04:20:37PM +0100, Markus Armbruster wrote:
> >> Eduardo Habkost  writes:
> >> 
> >> > On Tue, Nov 24, 2020 at 09:49:30AM +0100, Markus Armbruster wrote:
> >> >> Eduardo Habkost  writes:
> >> >> 
> >> >> > On Mon, Nov 23, 2020 at 08:51:27AM +0100, Markus Armbruster wrote:
> >> >> >> Eduardo Habkost  writes:
> >> >> >> 
> >> >> >> > On Fri, Nov 20, 2020 at 06:29:16AM +0100, Markus Armbruster wrote:
> >> >> >> [...]
> >> >> >> >> When the structure of a data type is to be kept away from its 
> >> >> >> >> users, I
> >> >> >> >> prefer to keep it out of the public header, so the compiler 
> >> >> >> >> enforces the
> >> >> >> >> encapsulation.
> >> >> >> >
> >> >> >> > I prefer that too, except that it is impossible when users of the
> >> >> >> > API need the compiler to know the struct size.
> >> >> >> 
> >> >> >> There are cases where the structure of a data type should be
> >> >> >> encapsulated, yet its size must be made known for performance (avoid
> >> >> >> dynamic memory allocation and pointer chasing).
> >> >> >> 
> >> >> >> Need for encapsulation correlates with complex algorithms and data
> >> >> >> structures.  The cost of dynamic allocation is often in the noise 
> >> >> >> then.
> >> >> >
> >> >> > I don't know what we are talking about anymore.  None of this
> >> >> > applies to the QNum API, right?
> >> >> >
> >> >> > QNum/QNumValue are not complex data structures, and the reason we
> >> >> > need the compiler to know the size of QNumValue is not related to
> >> >> > performance at all.
> >> >> 
> >> >> We started with the question whether to make QNumValue's members
> >> >> private.  We digressed to the question when to make members private.
> >> >> So back to the original question.
> >> >> 
> >> >> > We might still want to discourage users of the QNum API from
> >> >> > accessing QNum.u/QNumValue.u directly.  Documenting the field as
> >> >> > private is a very easy way to do it.
> >> >> 
> >> >> It's a complete non-issue.  QNum has been around for years, and we
> >> >> haven't had any issues that could've been plausibly avoided by asking
> >> >> people to refrain from accessing its members.
> >> >> 
> >> >> If there was an actual need to keep the members private, I'd move the
> >> >> struct out of the header, so the compiler enforces privacy.
> >> >
> >> > Understood.  There's still a question I'd like to answer, to
> >> > decide how the API documentation should look like:
> >> >
> >> >   Is QNum.u/QNumValue.u required to be part of the API
> >> >   documentation?
> >> >
> >> > If accessing that field directly is not necessary for using the
> >> > API, I don't think it should appear in the documentation (because
> >> > it would be just noise).
> >> 
> >> The current patch's comment on QNumValue looks good to me.
> >> 
> >> Does this answer your question?
> >
> > The current patch (v3) doesn't address the question.  It doesn't
> > include documentation for the field, but doesn't hide it.
> > kernel-doc will print a warning on that case.
> 
> Do we care?

Yes.  Peter will reject pull requests if it generates kernel-doc
warnings.

> How many such warnings exist before the patch?

Zero.

> Does this series add just this one, or more?

The current series (v3) doesn't add any, because I dropped the
patch that added QObject and QNum documentation to docs/devel.  I
still want to resubmit that patch later, though.

> 
> Use your judgement, then be ready to explain it :)

OK!

-- 
Eduardo

Re: [PATCH v2] hw/arm/virt enable support for virtio-mem

2020-11-25 Thread Jonathan Cameron

On Tue, 24 Nov 2020 20:17:35 +0100
David Hildenbrand  wrote:

> On 24.11.20 19:11, Jonathan Cameron wrote:
> > On Mon, 9 Nov 2020 20:47:09 +0100
> > David Hildenbrand  wrote:
> > 
> > +CC Eric based on similar query in other branch of the thread.
> >   
> >> On 05.11.20 18:43, Jonathan Cameron wrote:  
> >>> Basically a cut and paste job from the x86 support with the exception of
> >>> needing a larger block size as the Memory Block Size (MIN_SECTION_SIZE)
> >>> on ARM64 in Linux is 1G.
> >>>
> >>> Tested:
> >>> * In full emulation and with KVM on an arm64 server.
> >>> * cold and hotplug for the virtio-mem-pci device.
> >>> * Wide range of memory sizes, added at creation and later.
> >>> * Fairly basic memory usage of memory added.  Seems to function as normal.
> >>> * NUMA setup with virtio-mem-pci devices on each node.
> >>> * Simple migration test.
> >>>
> >>> Related kernel patch just enables the Kconfig item for ARM64 as an
> >>> alternative to x86 in drivers/virtio/Kconfig
> >>>
> >>> The original patches from David Hildenbrand stated that he thought it 
> >>> should
> >>> work for ARM64 but it wasn't enabled in the kernel [1]
> >>> It appears he was correct and everything 'just works'.
> >>>
> >>> The build system related stuff is intended to ensure virtio-mem support is
> >>> not built for arm32 (build will fail due no defined block size).
> >>> If there is a more elegant way to do this, please point me in the right
> >>> direction.
> >>
> >> You might be aware of https://virtio-mem.gitlab.io/developer-guide.html 
> >> and the "issue" with 64k base pages - 512MB granularity. Similar as the 
> >> question from Auger, have you tried running arm64 with differing page 
> >> sizes in host/guest?
> >>  
> > 
> > Hi David,
> >   
> >> With recent kernels, you can use "memhp_default_state=online_movable" on 
> >> the kernel cmdline to make memory unplug more likely to succeed - 
> >> especially with 64k base pages. You just have to be sure to not hotplug 
> >> "too much memory" to a VM.  
> > 
> > Thanks for the pointer - that definitely simplifies testing.  Was getting a 
> > bit
> > tedious with out that.
> > 
> > As ever other stuff got in the way, so I only just got back to looking at 
> > this.
> > 
> > I've not done a particularly comprehensive set of tests yet, but things seem
> > to 'work' with mixed page sizes.
> > 
> > With 64K pages in general, you run into a problem with the device 
> > block_size being
> > smaller than the subblock_size.  I've just added a check for that into the  
> 
> "device block size smaller than subblock size" - that's very common,
> e.g.,  on x86-64.
> 
> E.g., device_block_size is 2MiB, subblock size 4MiB - until we improve
> that in the future in Linux guests.

Ah. I'd missed that quirk around MAX_ORDER.  It's also true of ARM64 with
4k pages.  As you can probably guess I'd forgotten to recompile my 4k test
kernel after adding that particular check. :(

Ah well. Given we are already in a situation where adding 2MiB doesn't actually
do anything useful, I guess it's not really a problem to merrily let the host
add less than the guest can make use of.  So we allow adding any multiple of
2MiB but reality is the guest isn't going to use anything other than 512MiB
chunks.

> 
> Or did you mean something else?
> 
> > virtio-mem kernel driver and have it fail to probe if that happens.  I don't
> > think such a setup makes any sense anyway so no loss there.  Should it make 
> > sense
> > to drop that restriction in the future we can deal with that then without 
> > breaking
> > backwards compatibility.
> > 
> > So the question is whether it makes sense to bother with virtio-mem support
> > at all on ARM64 with 64k pages given currently the minimum workable 
> > block_size
> > is 512MiB?  I guess there is an argument of virtio-mem being a possibly more
> > convenient interface than full memory HP.  Curious to hear what people 
> > think on
> > this?  
> 
> IMHO we really want it. For example, RHEL is always 64k. This is a
> current guest limitation, to be improved in the future - either by
> moving away from 512MB huge pages with 64k or by improving
> alloc_contig_range().

Sure.  Would be great if we do one day support 2MiB on 64k.

> 
> > 
> > 4K guest on 64K host seems fine and no such limit is needed - though there
> > may be performance issues doing that.  
> 
> Yeah, if one is lucky to get one of these 512 MiB huge pages at all :)

Not too hard on my 1TB test system that's running nothing much else, but agreed 
it
won't be trivial more generally.

> 
> > 
> > 64k guest on 4k host with 512MiB block size seems fine.
> > 
> > If there are any places anyone thinks need particular poking I'd appreciate 
> > a hint :)  
> 
> If things seem to work for now, that's great :) Thanks!
> 
Cool.  I'll run a few more comprehensive tests then send out the
trivial patch to enable the kernel option + v2 of the qemu support.

Jonathan

Re: [RFC v5 12/12] accel: centralize initialization of CpusAccelOps