[PULL 5/8] dump: Fix g_array_unref(NULL) in dump-guest-memory

From: Markus Armbruster When dump_init()'s check for non-zero @length fails, dump_cleanup() passes null s->string_table_buf to g_array_unref(), which spews "GLib: g_array_unref: assertion 'array' failed" to stderr. Guard the g_array_unref(). Signed-off-by: Markus Armbruster Reviewed-by: Marc-A

[PULL 3/8] dump: Add command interface for kdump-raw formats

From: Stephen Brennan The QMP dump API represents the dump format as an enumeration. Add three new enumerators, one for each supported kdump compression, each named "kdump-raw-*". For the HMP command line, rather than adding a new flag corresponding to each format, it seems more human-friendly t

[PULL 8/8] dump: Drop redundant check for empty dump

From: Markus Armbruster dump_init() first computes the size of the dump, taking the filter area into account, and fails if its zero. It then looks for memory in the filter area, and fails if there is none. This is redundant: if the size of the dump is zero, there is no memory, and vice versa.

[PULL 1/8] dump: Pass DumpState to write_ functions

From: Stephen Brennan For the next patch, we need a reference to DumpState when writing data. Signed-off-by: Stephen Brennan Reviewed-by: Daniel P. Berrangé Reviewed-by: Marc-André Lureau Message-Id: <20230918233233.1431858-2-stephen.s.bren...@oracle.com> --- include/sysemu/dump.h | 2 +- d

[PULL 0/8] Dump patches

From: Marc-André Lureau The following changes since commit 6c9ae1ce82b65faa3f266fd103729878cf11e07e: Merge tag 'for-upstream' of https://repo.or.cz/qemu/kevin into staging (2023-11-01 06:58:11 +0900) are available in the Git repository at: https://gitlab.com/marcandre.lureau/qemu.git tags

[PULL 2/8] dump: Allow directly outputting raw kdump format

From: Stephen Brennan The flattened format (currently output by QEMU) is used by makedumpfile only when it is outputting a vmcore to a file which is not seekable. The flattened format functions essentially as a set of instructions of the form "seek to the given offset, then write the given bytes

[PULL 4/8] dump: Rename qmp_dump_guest_memory() parameter to match QAPI schema

From: Markus Armbruster The name of the second parameter differs between QAPI schema and C implementation: it's @protocol in the former and @file in the latter. Potentially confusing. Change the C implementation to match the QAPI schema. Signed-off-by: Markus Armbruster Reviewed-by: Marc-André

[PULL 7/8] dump: Improve some dump-guest-memory error messages

From: Markus Armbruster Zero @length is rejected with "Invalid parameter 'length'". Improve to "parameter 'length' expects a non-zero length". qemu_open_old() is a wrapper around qemu_open_internal() that throws away error information. Switch to the wrapper that doesn't: qemu_create(). Exampl

[PULL 6/8] dump: Recognize "fd:" protocols on Windows hosts

From: Markus Armbruster A few QMP command can work with named file descriptors. The only way to create a named file descriptor used to be QMP command getfd, which only works on POSIX hosts. Thus, named file descriptors were actually usable only there. They became usable on Windows hosts when w

[PATCH v4] tests/avocado: add test to exercize processor address space memory bound checks

QEMU has validations to make sure that a VM is not started with more memory (static and hotpluggable memory) than what the guest processor can address directly with its addressing bits. This change adds a test to make sure QEMU fails to start with a specific error message when an attempt is made to

[qemu-web PATCH] container: silence httpd logs

The httpd logs for qemu.org are huge and are exhausting the disk space on the web server. Silence them, they are of limited use and also a possible privacy issue. Signed-off-by: Paolo Bonzini --- container/conf.d/git.conf| 2 ++ container/conf.d/noname.conf | 2 ++ container/conf.d/www.conf

Re: [PATCH] migration: Unlock mutex in error case

Alex Bennée wrote: > Juan Quintela writes: > >> We were not unlocking bitmap mutex on the error case. >> Coverity discovered the problem. >> >> Fixes: a2326705e5 ("migration: Stop migration immediately in RDMA error >> paths") >> Signed-off-by: Juan Quintela >> --- >> migration/ram.c | 1 + >>

Re: [PATCH 3/5] hw/ppc/e500: QOM-attach CPUs to the machine container

Philippe Mathieu-Daudé writes: > Instead of having CPUs dangling in the /unattached/device > bucket, attach them to the machine container. > > Signed-off-by: Philippe Mathieu-Daudé > --- > hw/ppc/e500.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/hw/ppc/e500.c b/hw/ppc/e500.c > ind

[PATCH v2] migration: Unlock mutex in error case

We were not unlocking bitmap mutex on the error case. To fix it forever change to enclose the code with WITH_QEMU_LOCK_GUARD(). Coverity CID 1523750. Fixes: a2326705e5 ("migration: Stop migration immediately in RDMA error paths") Signed-off-by: Juan Quintela --- migration/ram.c | 106 ++

Re: [RFC PATCH 5/5] hw/ppc/e500: Pass array of CPUs as array of canonical QOM paths

Philippe Mathieu-Daudé writes: > Devices should avoid calling qemu_get_cpu() because this call > doesn't work as expected with heterogeneous machines. Such > devices often iterate over a cluster of CPUs, which the device's > parent has direct access (when creating the child device). > > We can pa

Re: [PATCH v9 03/19] target/riscv/tcg: update priv_ver on user_set extensions

On Thu, Nov 02, 2023 at 07:44:29PM -0300, Daniel Henrique Barboza wrote: > We'll add a new bare CPU type that won't have any default priv_ver. This > means that the CPU will default to priv_ver = 0, i.e. 1.10.0. > > At the same we'll allow these CPUs to enable extensions at will, but > then, if th

Re: [PATCH v9 04/19] target/riscv: add rv64i CPU

On Thu, Nov 02, 2023 at 07:44:30PM -0300, Daniel Henrique Barboza wrote: > We don't have any form of a 'bare bones' CPU. rv64, our default CPUs, > comes with a lot of defaults. This is fine for most regular uses but > it's not suitable when more control of what is actually loaded in the > CPU is re

Re: [PATCH v9 10/19] target/riscv/tcg: add user flag for profile support

On Thu, Nov 02, 2023 at 07:44:36PM -0300, Daniel Henrique Barboza wrote: ... > +if (profile->enabled) { > +/* > + * Note: the 'priv_spec' command line option, if present, > + * will take precedence over this priv_ver bump. > + */ > +

Re: [PATCH v9 18/19] target/riscv: add 'rva22u64' CPU

On Thu, Nov 02, 2023 at 07:44:44PM -0300, Daniel Henrique Barboza wrote: > This CPU was suggested by Alistair [1] and others during the profile > design discussions. It consists of the bare 'rv64i' CPU with rva22u64 > enabled by default, like an alias of '-cpu rv64i,rva22u64=true'. > > Users now h

Re: [PATCH v4 0/4] hw/audio/pcspk: Inline pcspk_init()

Bernhard Beschow writes: > Am 20. Oktober 2023 17:15:04 UTC schrieb "Philippe Mathieu-Daudé" > : >>Unfortunately v2 was merged as commit 40f8214fcd, >>so adapt v3 to clean the mess. >> >>Philippe Mathieu-Daudé (4): >> hw/i386/pc: Pass Error** argument to pc_basic_device_init() >> hw/i386/pc: P

Re: [qemu-web PATCH] container: silence httpd logs

On Fri, Nov 03, 2023 at 08:26:06AM +0100, Paolo Bonzini wrote: > The httpd logs for qemu.org are huge and are exhausting the disk > space on the web server. Silence them, they are of limited use > and also a possible privacy issue. > > Signed-off-by: Paolo Bonzini > --- > container/conf.d/git.c

Re: [PATCH v9 19/19] target/riscv/tcg: do not support profiles for 'max' CPU

On Thu, Nov 02, 2023 at 07:44:45PM -0300, Daniel Henrique Barboza wrote: > There's no gain in allowing the 'max' CPU to support profiles, since it > already contains everything that QEMU can support. And we'll open the > door for 'unorthodox' stuff like users disabling profiles of the 'max' > CPU.

Re: [PATCH v5 2/4] qcow2: add configurations for zoned format extension

Eric Blake writes: > On Mon, Oct 30, 2023 at 08:18:45PM +0800, Sam Li wrote: >> To configure the zoned format feature on the qcow2 driver, it >> requires settings as: the device size, zone model, zone size, >> zone capacity, number of conventional zones, limits on zone >> resources (max append by

Re: [PATCH v6 11/21] virtio-net: Return an error when vhost cannot enable RSS

On Thu, Nov 2, 2023 at 4:56 PM Akihiko Odaki wrote: > On 2023/11/02 19:20, Yuri Benditovich wrote: > > > > > > On Thu, Nov 2, 2023 at 11:33 AM Michael S. Tsirkin > > wrote: > > > > On Thu, Nov 02, 2023 at 11:09:27AM +0200, Yuri Benditovich wrote: > > > Probably w

Re: [PATCH v2 00/10] mirror: allow switching from background to active mode

Vladimir Sementsov-Ogievskiy writes: > On 11.10.23 13:18, Fiona Ebner wrote: >> Am 10.10.23 um 19:55 schrieb Vladimir Sementsov-Ogievskiy: >>> On 09.10.23 12:46, Fiona Ebner wrote: Initially, I tried to go for a more general 'job-change' command, but I couldn't figure out a way to

Re: [PATCH v3 0/9] mirror: allow switching from background to active mode

Fiona Ebner writes: > Am 18.10.23 um 11:41 schrieb Markus Armbruster: >> Fiona Ebner writes: >>> >>> Initially, I tried to go for a more general 'job-change' command, but >>> to avoid mutual inclusion of block-core.json and job.json, more >>> preparation would be required. >> >> Can you elabora

Re: [PATCH 04/24] block: Mark bdrv_root_attach_child() GRAPH_WRLOCK

Am 27.10.2023 um 22:22 hat Eric Blake geschrieben: > On Fri, Oct 27, 2023 at 05:53:13PM +0200, Kevin Wolf wrote: > > Instead of taking the writer lock internally, require callers to already > > hold it when calling bdrv_root_attach_child(). These callers will > > typically already hold the graph lo

Re: [PATCH 09/24] block: Mark bdrv_(un)freeze_backing_chain() and callers GRAPH_RDLOCK

Am 27.10.2023 um 23:00 hat Eric Blake geschrieben: > On Fri, Oct 27, 2023 at 05:53:18PM +0200, Kevin Wolf wrote: > > This adds GRAPH_RDLOCK annotations to declare that callers of > > bdrv_(un)freeze_backing_chain() need to hold a reader lock for the > > graph because it calls bdrv_filter_or_cow_chi

Re: [PATCH v6 11/21] virtio-net: Return an error when vhost cannot enable RSS

On 2023/11/03 18:35, Yuri Benditovich wrote: On Thu, Nov 2, 2023 at 4:56 PM Akihiko Odaki > wrote: On 2023/11/02 19:20, Yuri Benditovich wrote: > > > On Thu, Nov 2, 2023 at 11:33 AM Michael S. Tsirkin mailto:m...@redhat.com> >

Re: [PATCH 23/24] block: Take graph lock for most of .bdrv_open

Am 30.10.2023 um 22:34 hat Eric Blake geschrieben: > On Fri, Oct 27, 2023 at 05:53:32PM +0200, Kevin Wolf wrote: > > Most implementations of .bdrv_open first open their file child (which is > > an operation that internally takes the write lock and therefore we > > shouldn't hold the graph lock whil

Re: [PATCH 1/1] sphinx/qapidoc: Tidy up pylint warning raise-missing-from

On Fri, 3 Nov 2023 at 03:08, John Snow wrote: > > On Wed, Oct 25, 2023 at 6:10 AM Markus Armbruster wrote: > > > > Pylint advises: > > > > docs/sphinx/qapidoc.py:518:12: W0707: Consider explicitly re-raising > > using 'raise ExtensionError(str(err)) from err' (raise-missing-from) > > > > Fro

Re: [PATCH 16/24] block: Mark bdrv_replace_node() GRAPH_WRLOCK

Am 27.10.2023 um 23:33 hat Eric Blake geschrieben: > On Fri, Oct 27, 2023 at 05:53:25PM +0200, Kevin Wolf wrote: > > Instead of taking the writer lock internally, require callers to already > > hold it when calling bdrv_replace_node(). Its callers may already want > > to hold the graph lock and so

Re: [PATCH 19/24] block: Introduce bdrv_co_change_backing_file()

Am 30.10.2023 um 14:57 hat Eric Blake geschrieben: > On Fri, Oct 27, 2023 at 05:53:28PM +0200, Kevin Wolf wrote: > > bdrv_change_backing_file() is called both inside and outside coroutine > > context. This makes it difficult for it to take the graph lock > > internally. It also means that driver im

Re: [PATCH v2 1/4] exec/memattrs: Add iopmp source id, start address, end address to MemTxAttrs

On Fri, 3 Nov 2023 at 03:29, Ethan Chen wrote: > > On Thu, Nov 02, 2023 at 01:53:05PM +, Peter Maydell wrote: > > On Thu, 2 Nov 2023 at 13:49, Peter Xu wrote: > > > > > > On Thu, Nov 02, 2023 at 05:40:12PM +0800, Ethan Chen wrote: > > > > Signed-off-by: Ethan Chen > > > > --- > > > > includ

Re: [PATCH v15 12/14] migration: Implement MigrateChannelList to qmp migration flow.

Fabiano Rosas wrote: > From: Het Gala > > Integrate MigrateChannelList with all transport backends > (socket, exec and rdma) for both src and dest migration > endpoints for qmp migration. > > For current series, limit the size of MigrateChannelList > to single element (single interface) as runtim

Re: [PATCH v4] tests/avocado: add test to exercize processor address space memory bound checks

On 03.11.23 08:04, Ani Sinha wrote: QEMU has validations to make sure that a VM is not started with more memory (static and hotpluggable memory) than what the guest processor can address directly with its addressing bits. This change adds a test to make sure QEMU fails to start with a specific er

Re: Any plans to implement more ARM SMMUv3 features?

Hi Alex, On 10/31/23 13:02, Alex Bennée wrote: > Hi All, > > Since 8.1 we enabled the FEAT_RME CPU feature to allow for Arm CCA > guests to be run under QEMU's Arm emulation. While this is enough for > pure software guests eventually we would want to support modelling > systems with "real" hardwar

[PATCH v5] tests/avocado: add test to exercize processor address space memory bound checks

QEMU has validations to make sure that a VM is not started with more memory (static and hotpluggable memory) than what the guest processor can address directly with its addressing bits. This change adds a test to make sure QEMU fails to start with a specific error message when an attempt is made to

Re: [PATCH 3/5] hw/ppc/e500: QOM-attach CPUs to the machine container

On 3/11/23 08:40, Markus Armbruster wrote: Philippe Mathieu-Daudé writes: Instead of having CPUs dangling in the /unattached/device bucket, attach them to the machine container. Signed-off-by: Philippe Mathieu-Daudé --- hw/ppc/e500.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/

Re: [PATCH v9 19/19] target/riscv/tcg: do not support profiles for 'max' CPU

On 11/3/23 06:01, Andrew Jones wrote: On Thu, Nov 02, 2023 at 07:44:45PM -0300, Daniel Henrique Barboza wrote: There's no gain in allowing the 'max' CPU to support profiles, since it already contains everything that QEMU can support. And we'll open the door for 'unorthodox' stuff like users d

Re: [PATCH v9 03/19] target/riscv/tcg: update priv_ver on user_set extensions

On 11/3/23 05:33, Andrew Jones wrote: On Thu, Nov 02, 2023 at 07:44:29PM -0300, Daniel Henrique Barboza wrote: We'll add a new bare CPU type that won't have any default priv_ver. This means that the CPU will default to priv_ver = 0, i.e. 1.10.0. At the same we'll allow these CPUs to enable e

[PATCH v2 RESEND] [PING] target/ppc: Fix bugs in VSX_CVT_FP_TO_INT and VSX_CVT_FP_TO_INT2 macros

The patch below fixes a bug in the VSX_CVT_FP_TO_INT and VSX_CVT_FP_TO_INT2 macros in target/ppc/fpu_helper.c where a non-NaN floating point value from the source vector is incorrectly converted to 0, 0x8000, or 0x8000 instead of the expected value if a preceding source floating

Re: [PATCH v2 00/10] mirror: allow switching from background to active mode

Am 03.11.2023 um 10:36 hat Markus Armbruster geschrieben: > Vladimir Sementsov-Ogievskiy writes: > > > On 11.10.23 13:18, Fiona Ebner wrote: > >> Am 10.10.23 um 19:55 schrieb Vladimir Sementsov-Ogievskiy: > >>> On 09.10.23 12:46, Fiona Ebner wrote: > > Initially, I tried to go for a mor

[PULL 1/7] system/dirtylimit: Fix a race situation

From: Hyman Huang Fix a race situation for global variable dirtylimit_state. Also, replace usleep by g_usleep to increase platform accessibility to the sleep function. Signed-off-by: Hyman Huang Reviewed-by: Fabiano Rosas Reviewed-by: Juan Quintela Signed-off-by: Juan Quintela Message-ID:

[PULL 0/7] Migration 20231103 patches

a/qemu.git tags/migration-20231103-pull-request for you to fetch changes up to 0983125b405c479a6e7eb49b81cfdae969e28cee: migration: Unlock mutex in error case (2023-11-03 10:48:37 +0100) Migration Pull request (20231103) Hi In

[PULL 6/7] docs/migration: Add the dirty limit section

From: Hyman Huang The dirty limit feature has been introduced since the 8.1 QEMU release but has not reflected in the document, add a section for that. Signed-off-by: Hyman Huang Reviewed-by: Fabiano Rosas Reviewed-by: Juan Quintela Signed-off-by: Juan Quintela Message-ID: <0f2b2c63fec22ea2

[PULL 2/7] system/dirtylimit: Drop the reduplicative check

From: Hyman Huang Checking if dirty limit is in service is done by the dirtylimit_query_all function, drop the reduplicative check in the qmp_query_vcpu_dirty_limit function. Signed-off-by: Hyman Huang Reviewed-by: Fabiano Rosas Reviewed-by: Juan Quintela Signed-off-by: Juan Quintela Message

[PULL 5/7] tests/migration: Introduce dirty-limit into guestperf

From: Hyman Huang Currently, guestperf does not cover the dirty-limit migration, support this feature. Note that dirty-limit requires 'dirty-ring-size' set. To enable dirty-limit, setting x-vcpu-dirty-limit-period as 500ms and x-vcpu-dirty-limit as 10MB/s: $ ./tests/migration/guestperf.py \

[PULL 3/7] tests: Add migration dirty-limit capability test

From: Hyman Huang Add migration dirty-limit capability test if kernel support dirty ring. Migration dirty-limit capability introduce dirty limit capability, two parameters: x-vcpu-dirty-limit-period and vcpu-dirty-limit are introduced to implement the live migration with dirty limit. The test c

[PULL 7/7] migration: Unlock mutex in error case

We were not unlocking bitmap mutex on the error case. To fix it forever change to enclose the code with WITH_QEMU_LOCK_GUARD(). Coverity CID 1523750. Fixes: a2326705e5 ("migration: Stop migration immediately in RDMA error paths") Reviewed-by: Alex Bennée Signed-off-by: Juan Quintela Message-ID:

[PULL 4/7] tests/migration: Introduce dirty-ring-size option into guestperf

From: Hyman Huang Dirty ring size configuration is not supported by guestperf tool. Introduce dirty-ring-size (ranges in [1024, 65536]) option so developers can play with dirty-ring and dirty-limit feature easier. To set dirty ring size with 4096 during migration test: $ ./tests/migration/guest

Re: [PATCH v2 12/12] qdev: Rework array properties based on list visitor

On Mon, Oct 30, 2023 at 03:26:58PM +0100, Kevin Wolf wrote: > Until now, array properties are actually implemented with a hack that > uses multiple properties on the QOM level: a static "foo-len" property > and after it is set, dynamically created "foo[i]" properties. > > In external interfaces (-

Re: [PATCH 04/24] block: Mark bdrv_root_attach_child() GRAPH_WRLOCK

On Fri, Nov 03, 2023 at 10:45:11AM +0100, Kevin Wolf wrote: > Am 27.10.2023 um 22:22 hat Eric Blake geschrieben: > > On Fri, Oct 27, 2023 at 05:53:13PM +0200, Kevin Wolf wrote: > > > Instead of taking the writer lock internally, require callers to already > > > hold it when calling bdrv_root_attach

[PATCH] system/qdev-monitor: move drain_call_rcu call under if (!dev) in qmp_device_add()

Original goal of addition of drain_call_rcu to qmp_device_add was to cover the failure case of qdev_device_add. It seems call of drain_call_rcu was misplaced in 7bed89958bfbf40df what led to waiting for pending RCU callbacks under happy path too. What led to overall performance degradation of qmp_d

Re: [PATCH 16/24] block: Mark bdrv_replace_node() GRAPH_WRLOCK

On Fri, Nov 03, 2023 at 11:32:39AM +0100, Kevin Wolf wrote: ... > > > -GLOBAL_STATE_CODE(); > > > - > > > -/* Make sure that @from doesn't go away until we have successfully > > > attached > > > - * all of its parents to @to. */ > > > > Useful comment that you just moved here in the p

Re: [PATCH 19/24] block: Introduce bdrv_co_change_backing_file()

On Fri, Nov 03, 2023 at 11:33:47AM +0100, Kevin Wolf wrote: > Am 30.10.2023 um 14:57 hat Eric Blake geschrieben: > > On Fri, Oct 27, 2023 at 05:53:28PM +0200, Kevin Wolf wrote: > > > bdrv_change_backing_file() is called both inside and outside coroutine > > > context. This makes it difficult for it

Re: [PATCH v4 05/14] tpm_crb: move ACPI table building to device interface

On 11/2/23 22:37, Joelle van Dyne wrote: On Thu, Nov 2, 2023 at 11:50 AM Stefan Berger wrote: On 10/31/23 00:00, Joelle van Dyne wrote: This logic is similar to TPM TIS ISA device. Since TPM CRB can only support TPM 2.0 backends, we check for this in realize. The problem on x86_64 is t

Re: [PULL 29/32] virtio-blk: implement BlockDevOps->drained_begin()

Hi, Am 30.05.23 um 18:32 schrieb Kevin Wolf: > From: Stefan Hajnoczi > > Detach ioeventfds during drained sections to stop I/O submission from > the guest. virtio-blk is no longer reliant on aio_disable_external() > after this patch. This will allow us to remove the > aio_disable_external() API

Re: [PATCH v6 11/21] virtio-net: Return an error when vhost cannot enable RSS

On Fri, Nov 3, 2023 at 11:55 AM Akihiko Odaki wrote: > On 2023/11/03 18:35, Yuri Benditovich wrote: > > > > > > On Thu, Nov 2, 2023 at 4:56 PM Akihiko Odaki > > wrote: > > > > On 2023/11/02 19:20, Yuri Benditovich wrote: > > > > > > > > > On Th

Re: deadlock when using iothread during backup_clean()

Am 20.10.23 um 15:52 schrieb Fiona Ebner: > And I found that with drive-mirror, the issue during starting seems to > manifest with the bdrv_open() call. Adding a return before it, the guest > IO didn't get stuck in my testing, but adding a return after it, it can > get stuck. I'll try to see if I c

Re: [PATCH v6 15/21] virtio-net: Do not clear VIRTIO_NET_F_HASH_REPORT

On Mon, Oct 30, 2023 at 7:15 AM Akihiko Odaki wrote: > virtio-net can report hash values even if the peer does not have a > virtio-net header. > > Signed-off-by: Akihiko Odaki > --- > hw/net/virtio-net.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/hw/net/virtio-net.c b/hw/net/virt

Re: [PATCH] linux-user/riscv: change default cpu to 'max'

On Mon, 23 Oct 2023 at 02:15, Alistair Francis wrote: > > On Fri, Oct 20, 2023 at 5:46 PM Daniel Henrique Barboza > wrote: > > > > Commit f57d5f8004 deprecated the 'any' CPU type but failed to change the > > default CPU for linux-user. The result is that all linux-users > > invocations that doesn

[PATCH v10 03/18] target/riscv/tcg: update priv_ver on user_set extensions

We'll add a new bare CPU type that won't have any default priv_ver. This means that the CPU will default to priv_ver = 0, i.e. 1.10.0. At the same we'll allow these CPUs to enable extensions at will, but then, if the extension has a priv_ver newer than 1.10, we'll end up disabling it. Users will t

[PATCH v10 06/18] target/riscv/tcg: add 'zic64b' support

zic64b is defined in the RVA22U64 profile [1] as a named feature for "Cache blocks must be 64 bytes in size, naturally aligned in the address space". It's a fantasy name for 64 bytes cache blocks. The RVA22U64 profile mandates this feature, meaning that applications using this profile expects 64 by

[PATCH v10 05/18] target/riscv: add zicbop extension flag

QEMU already implements zicbom (Cache Block Management Operations) and zicboz (Cache Block Zero Operations). Commit 59cb29d6a5 ("target/riscv: add Zicbop cbo.prefetch{i, r, m} placeholder") added placeholders for what would be the instructions for zicbop (Cache Block Prefetch Operations), which are

[PATCH v10 02/18] target/riscv/tcg: do not use "!generic" CPU checks

Our current logic in get/setters of MISA and multi-letter extensions works because we have only 2 CPU types, generic and vendor, and by using "!generic" we're implying that we're talking about vendor CPUs. When adding a third CPU type this logic will break so let's handle it beforehand. In set_mis

[PATCH v10 13/18] target/riscv/tcg: handle profile MISA bits

The profile support is handling multi-letter extensions only. Let's add support for MISA bits as well. We'll go through every known MISA bit. If the profile doesn't declare the bit as mandatory, ignore it. Otherwise, set the bit in env->misa_ext and env->misa_ext_mask. Now that we're setting prof

[PATCH v10 07/18] riscv-qmp-cmds.c: expose named features in cpu_model_expansion

Named features (zic64b the sole example at this moment) aren't expose to users, thus we need another way to expose them. Go through each named feature, get its boolean value, do the needed conversions (bool to qbool, qbool to QObject) and add it to output dict. Another adjustment is needed: named

[PATCH v10 04/18] target/riscv: add rv64i CPU

We don't have any form of a 'bare bones' CPU. rv64, our default CPUs, comes with a lot of defaults. This is fine for most regular uses but it's not suitable when more control of what is actually loaded in the CPU is required. A bare-bones CPU would be annoying to deal with if not by profile suppor

[PATCH v10 15/18] target/riscv/tcg: honor user choice for G MISA bits

RVG behaves like a profile: a single flag enables a set of bits. Right now we're considering user choice when handling RVG and zicsr/zifencei and ignoring user choice on MISA bits. We'll add user warnings for profiles when the user disables its mandatory extensions in the next patch. We'll do the

[PATCH v10 14/18] target/riscv/tcg: add hash table insert helpers

Previous patches added several g_hash_table_insert() patterns. Add two helpers, one for each user hash, to make the code cleaner. Signed-off-by: Daniel Henrique Barboza Reviewed-by: Andrew Jones --- target/riscv/tcg/tcg-cpu.c | 28 1 file changed, 16 insertions(+),

[PATCH v10 01/18] target/riscv: create TYPE_RISCV_VENDOR_CPU

We want to add a new CPU type for bare CPUs that will inherit specific traits of the 2 existing types: - it will allow for extensions to be enabled/disabled, like generic CPUs; - it will NOT inherit defaults, like vendor CPUs. We can make this conditions met by adding an explicit type for the

[PATCH v10 16/18] target/riscv/tcg: validate profiles during finalize

Enabling a profile and then disabling some of its mandatory extensions is a valid use. It can be useful for debugging and testing. But the common expected use of enabling a profile is to enable all its mandatory extensions. Add an user warning when mandatory extensions from an enabled profile are

[PATCH v10 09/18] target/riscv/kvm: add 'rva22u64' flag as unavailable

KVM does not have the means to support enabling the rva22u64 profile. The main reasons are: - we're missing support for some mandatory rva22u64 extensions in the KVM module; - we can't make promises about enabling a profile since it all depends on host support in the end. We'll revisit this

[PATCH v10 17/18] riscv-qmp-cmds.c: add profile flags in cpu-model-expansion

Expose all profile flags for all CPUs when executing query-cpu-model-expansion. This will allow callers to quickly determine if a certain profile is implemented by a given CPU. This includes vendor CPUs - the fact that they don't have profile user flags doesn't mean that they don't implement the pr

[PATCH v10 00/18] rv64i and rva22u64 CPUs, RVA22U64 profile support

Hi, This new version contains changes proposed by Drew in v9. The most notable change is the drop of the 'max' CPU profile restriction. Patches based on Alistair's riscv-to-apply.next. All patches acked. - patch 3: - move the 'priv_spec' comment to cpu_validate_multi_ext_priv_ver() righ

[PATCH v10 10/18] target/riscv/tcg: add user flag for profile support

The TCG emulation implements all the extensions described in the RVA22U64 profile, both mandatory and optional. The mandatory extensions will be enabled via the profile flag. We'll leave the optional extensions to be enabled by hand. Given that this is the first profile we're implementing in TCG w

[PATCH v10 11/18] target/riscv/tcg: add MISA user options hash

We already track user choice for multi-letter extensions because we needed to honor user choice when enabling/disabling extensions during realize(). We refrained from adding the same mechanism for MISA extensions since we didn't need it. Profile support requires tne need to check for user choice f

[PATCH v10 08/18] target/riscv: add rva22u64 profile definition

The rva22U64 profile, described in: https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc#rva22-profiles Contains a set of CPU extensions aimed for 64-bit userspace applications. Enabling this set to be enabled via a single user flag makes it convenient to enable a predictable set of fe

[PATCH v10 18/18] target/riscv: add 'rva22u64' CPU

This CPU was suggested by Alistair [1] and others during the profile design discussions. It consists of the bare 'rv64i' CPU with rva22u64 enabled by default, like an alias of '-cpu rv64i,rva22u64=true'. Users now have an even easier way of consuming this user-mode profile by doing '-cpu rva22u64'

[PATCH v10 12/18] target/riscv/tcg: add riscv_cpu_write_misa_bit()

We have two instances of the setting/clearing a MISA bit from env->misa_ext and env->misa_ext_mask pattern. And the next patch will end up adding one more. Create a helper to avoid code repetition. Signed-off-by: Daniel Henrique Barboza Reviewed-by: Alistair Francis Reviewed-by: LIU Zhiwei Rev

Re: [PATCH v2] migration: Unlock mutex in error case

On Fri, Nov 03, 2023 at 08:42:45AM +0100, Juan Quintela wrote: > We were not unlocking bitmap mutex on the error case. To fix it > forever change to enclose the code with WITH_QEMU_LOCK_GUARD(). > Coverity CID 1523750. > > Fixes: a2326705e5 ("migration: Stop migration immediately in RDMA error >

[PATCH] hw/arm: fix PMU IRQ registration

Since commit 9036e917f8 ("{include/}hw/arm: refactor virt PPI logic") PMU IRQ registration fails for arm64 guests: [0.563689] hw perfevents: unable to request IRQ14 for ARM PMU counters [0.565160] armv8-pmu: probe of pmu failed with error -22 That commit re-defined VIRTUAL_PMU_IRQ to be

Re: [PATCH v4 1/2] vdpa: Restore hash calculation state

On Wed, Oct 25, 2023 at 3:02 AM Hawkins Jiawei wrote: > > This patch introduces vhost_vdpa_net_load_rss() to restore > the hash calculation state at device's startup. > > Signed-off-by: Hawkins Jiawei > --- > v4: > - fix some typos pointed out by Michael > - zero the `cfg` fields at the defin

Re: [PATCH v4 2/2] vdpa: Allow VIRTIO_NET_F_HASH_REPORT in SVQ

On Wed, Oct 25, 2023 at 3:02 AM Hawkins Jiawei wrote: > > Enable SVQ with VIRTIO_NET_F_HASH_REPORT feature. > Acked-by: Eugenio Pérez > Signed-off-by: Hawkins Jiawei > --- > v4: > - no changes > > v3: > https://lore.kernel.org/all/c3b69f0a65600722c1e4d3aa14d53a71e8ffb888.1697902949.git.yin3

Re: [PATCH] hw/arm: fix PMU IRQ registration

On Fri, 3 Nov 2023 at 14:14, Sebastian Ott wrote: > > Since commit 9036e917f8 ("{include/}hw/arm: refactor virt PPI logic") > PMU IRQ registration fails for arm64 guests: > > [0.563689] hw perfevents: unable to request IRQ14 for ARM PMU counters > [0.565160] armv8-pmu: probe of pmu failed

Re: [PATCH v5 3/3] vdpa: Allow VIRTIO_NET_F_RSS in SVQ

On Wed, Oct 25, 2023 at 3:08 AM Hawkins Jiawei wrote: > > Enable SVQ with VIRTIO_NET_F_RSS feature. > Acked-by: Eugenio Pérez > Signed-off-by: Hawkins Jiawei > --- > v5: > - no changes > > v4: > https://lore.kernel.org/all/4ee7f3f339469f41626ca2c3ac7b1c574ebce901.1697904740.git.yin31...@gma

Re: [PATCH v5 2/3] vdpa: Restore receive-side scaling state

On Wed, Oct 25, 2023 at 3:08 AM Hawkins Jiawei wrote: > > This patch reuses vhost_vdpa_net_load_rss() with some > refactorings to restore the receive-side scaling state > at device's startup. > Acked-by: Eugenio Pérez > Signed-off-by: Hawkins Jiawei > --- > v5: > - resolve conflict with the

Re: [RFC PATCH 0/5] hw/ppc/e500: Pass array of CPUs as array of canonical QOM paths

On 11/2/23 04:49, Philippe Mathieu-Daudé wrote: Hi Daniel, On 31/10/23 22:49, Daniel Henrique Barboza wrote: On 10/30/23 11:39, Philippe Mathieu-Daudé wrote: Following the discussion with Peter on my "cpus: Step toward removing global 'first_cpu'" series [*], we now pass the array of CPUs v

Re: [PATCH 5/7] qcow2: zero_l2_subclusters: fall through to discard operation when requested

On 20.10.23 23:56, Andrey Drobyshev wrote: When zeroizing subclusters within single cluster, detect usage of the BDRV_REQ_MAY_UNMAP flag and fall through to the subcluster-based discard operation, much like it's done with the cluster-based discards. That way subcluster-aligned operations "qemu-i

Re: [PATCH 6/7] iotests/common.rc: add disk_usage function

On 20.10.23 23:56, Andrey Drobyshev wrote: Move the definition from iotests/250 to common.rc. This is used to detect real disk usage of sparse files. In particular, we want to use it for checking subclusters-based discards. Signed-off-by: Andrey Drobyshev --- tests/qemu-iotests/250 |

[PATCH v3 0/3] virt: Report UART correctly in ACPI DBG2/SPCR

This patchseries is Udo's patch, plus the necessary extra patches that update the golden-reference files for bios-tables-test so that 'make check' continues to pass. Changes v2->v3: * report the UART as requiring 32-bit accesses, not 16-bit; it turns out that Linux has a bug where it fails to

[PATCH v3 2/3] hw/arm/virt: Report correct register sizes in ACPI DBG2/SPCR tables.

From: Udo Steinberg Documentation for using the GAS in ACPI tables to report debug UART addresses at https://learn.microsoft.com/en-us/windows-hardware/drivers/bringup/acpi-debug-port-table states the following: - The Register Bit Width field contains the register stride and must be a power of

[PATCH v3 3/3] tests/qtest/bios-tables-test: Update virt SPCR and DBG2 golden references

Update the virt SPCR and DBG2 golden reference files to have the fix for the description of the UART. Diffs from iasl: @@ -1,57 +1,57 @@ /* * Intel ACPI Component Architecture * AML/ASL+ Disassembler version 20200925 (64-bit version) * Copyright (c) 2000 - 2020 Intel Corporation * - * Di

[PATCH v3 1/3] tests/qtest/bios-tables-test: Allow changes to virt SPCR and DBG2

Allow changes to the virt board SPCR and DBG2 -- we are going to fix an error in the UART descriptions there. Signed-off-by: Peter Maydell --- tests/qtest/bios-tables-test-allowed-diff.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tests/qtest/bios-tables-test-allowed-diff.h b/tests/qt

Re: [PATCH v3 2/3] hw/arm/virt: Report correct register sizes in ACPI DBG2/SPCR tables.

On Fri, 3 Nov 2023 at 15:21, Peter Maydell wrote: > > From: Udo Steinberg > > Documentation for using the GAS in ACPI tables to report debug UART addresses > at > https://learn.microsoft.com/en-us/windows-hardware/drivers/bringup/acpi-debug-port-table > states the following: > > - The Register B

Re: [PATCH] hw/arm: fix PMU IRQ registration

On Fri, 3 Nov 2023 at 14:27, Peter Maydell wrote: > > On Fri, 3 Nov 2023 at 14:14, Sebastian Ott wrote: > > > > Since commit 9036e917f8 ("{include/}hw/arm: refactor virt PPI logic") > > PMU IRQ registration fails for arm64 guests: > > > > [0.563689] hw perfevents: unable to request IRQ14 for

RE: [PATCH 0/3] Hexagon (target/hexagon) Enable more short-circuit packets

Looks like a problem with git send-email ☹ I will troubleshoot ... > -Original Message- > From: Anton Johansson > Sent: Thursday, November 2, 2023 6:44 PM > To: Taylor Simpson > Cc: qemu-devel@nongnu.org > Subject: Re: [PATCH 0/3] Hexagon (target/hexagon) Enable more short- > circuit p

Re: [PATCH 7/7] iotests/271: check disk usage on subcluster-based discard/unmap

On 20.10.23 23:56, Andrey Drobyshev wrote: Add _verify_du_delta() checker which is used to check that real disk usage delta meets the expectations. For now we use it for checking that subcluster-based discard/unmap operations lead to actual disk usage decrease (i.e. PUNCH_HOLE operation is perfo

Re: [PATCH 4/7] qcow2: make subclusters discardable

On 20.10.23 23:56, Andrey Drobyshev wrote: This commit makes the discard operation work on the subcluster level rather than cluster level. It introduces discard_l2_subclusters() function and makes use of it in qcow2 discard implementation, much like it's done with zero_in_l2_slice() / zero_l2_su

  1   2   >