[RFC 3/5] hw/nvme: make the metadata of ZNS emulation persistent

The NVMe ZNS devices follow NVMe ZNS spec but the state of namespace zones does not persist accross restarts of QEMU. This patch makes the metadata of ZNS emulation persistent by using new block layer APIs. The ZNS device calls zone report and zone mgmt APIs from the block layer which will handle z

[RFC 2/5] qcow2: add zone device metadata with zd_extension

Zone descriptor data is host definied data that is associated with each zone. Add zone descriptor extensions to zonedmeta and blk_get_zone_extension to access zd_extensions. Signed-off-by: Sam Li --- block/block-backend.c | 15 ++ block/qcow2.c | 86 ++

[RFC 1/5] hw/nvme: use blk_get_*() to access zone info in the block layer

The zone information is contained in the BlockLimits fileds. Add blk_get_*() functions to access the block layer and update zone info accessing in the NVMe device emulation. Signed-off-by: Sam Li --- block/block-backend.c | 56 block/qcow2.c

[RFC 0/5] Add persistence to NVMe ZNS emulation

ZNS emulation follows NVMe ZNS spec but the state of namespace zones does not persist accross restarts of QEMU. This patch makes the metadata of ZNS emulation persistent by using new block layer APIs and the qcow2 img as backing file. It is the second part after the patches - adding full zoned stor

Re: [PULL 00/14] linux-user image mapping fixes

16.08.2023 00:42, Helge Deller wrote: On 8/15/23 23:09, Richard Henderson wrote: ... Let's wait a bit and see if we're not just exchanging one set of bugs for another. Yes, and I think 8.0 isn't in that bad shape? Well, I dunno. It all started with 8.0 bugs, after I uploaded 8.0 to debian

[PATCH] target/riscv: Align the AIA model to v1.0 ratified spec

According to the new spec, when vsiselect has a reserved value, attempts from M-mode or HS-mode to access vsireg, or from VS-mode to access sireg, should preferably raise an illegal instruction exception. Signed-off-by: Tommy Wu Reviewed-by: Frank Chang --- target/riscv/csr.c | 7 +-- 1 fil

Re: [RFC PATCH] tcg/ppc: Enable direct branching tcg_out_goto_tb with TCG_REG_TB

On 16/8/23 2:07 am, Richard Henderson wrote: On 8/14/23 22:01, Jordan Niethe wrote: Direct branch patching was disabled when using TCG_REG_TB in commit 736a1588c1 ("tcg/ppc: Fix race in goto_tb implementation"). Commit 7502f89c74 ("tcg/ppc: Use prefixed instructions for tcg_out_goto_tb") used

Re: [PATCH] migrate/ram: let ram_save_target_page_legacy() return if qemu file got error

On 2023/8/16 6:19, 【外部账号】 Peter Xu wrote: On Tue, Aug 15, 2023 at 09:35:19AM -0300, Fabiano Rosas wrote: Guoyi Tu writes: When the migration process of a virtual machine using huge pages is cancelled, QEMU will continue to complete the processing of the current huge page through the qemu f

Re: [PATCH] migrate/ram: let ram_save_target_page_legacy() return if qemu file got error

On 2023/8/15 20:35, 【外部账号】 Fabiano Rosas wrote: Guoyi Tu writes: When the migration process of a virtual machine using huge pages is cancelled, QEMU will continue to complete the processing of the current huge page through the qemu file object got an error set. These processing, such as com

[PATCH v6 2/9] virtio-gpu: CONTEXT_INIT feature

From: Antonio Caggiano The feature can be enabled when a backend wants it. Signed-off-by: Antonio Caggiano Reviewed-by: Marc-André Lureau Signed-off-by: Gurchetan Singh Tested-by: Alyssa Ross Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Akihiko Odaki --- hw/display/virtio-gpu-base.c

[PATCH v6 4/9] virtio-gpu: blob prep

From: Antonio Caggiano This adds preparatory functions needed to: - decode blob cmds - tracking iovecs Signed-off-by: Antonio Caggiano Signed-off-by: Dmitry Osipenko Signed-off-by: Gurchetan Singh Tested-by: Alyssa Ross Tested-by: Emmanouil Pitsidianakis Reviewed-by: Emmanouil Pi

[PATCH v6 8/9] gfxstream + rutabaga: enable rutabaga

This change enables rutabaga to receive virtio-gpu-3d hypercalls when it is active. Signed-off-by: Gurchetan Singh Tested-by: Alyssa Ross Tested-by: Emmanouil Pitsidianakis Reviewed-by: Emmanouil Pitsidianakis --- v3: Whitespace fix (Akihiko) hw/display/virtio-gpu-base.c | 3 ++- hw/display/

[PATCH v6 3/9] virtio-gpu: hostmem

From: Gerd Hoffmann Use VIRTIO_GPU_SHM_ID_HOST_VISIBLE as id for virtio-gpu. Signed-off-by: Antonio Caggiano Tested-by: Alyssa Ross Acked-by: Michael S. Tsirkin --- hw/display/virtio-gpu-pci.c| 14 ++ hw/display/virtio-gpu.c| 1 + hw/display/virtio-vga.c| 33

[PATCH v6 6/9] gfxstream + rutabaga: add initial support for gfxstream

This adds initial support for gfxstream and cross-domain. Both features rely on virtio-gpu blob resources and context types, which are also implemented in this patch. gfxstream has a long and illustrious history in Android graphics paravirtualization. It has been powering graphics in the Android

[PATCH v6 7/9] gfxstream + rutabaga: meson support

- Add meson detection of rutabaga_gfx - Build virtio-gpu-rutabaga.c + associated vga/pci files when present Signed-off-by: Gurchetan Singh Tested-by: Alyssa Ross Tested-by: Emmanouil Pitsidianakis Reviewed-by: Emmanouil Pitsidianakis --- v3: Fix alignment issues (Akihiko) hw/display/meson.

[PATCH v6 5/9] gfxstream + rutabaga prep: added need defintions, fields, and options

This modifies the common virtio-gpu.h file have the fields and defintions needed by gfxstream/rutabaga, by VirtioGpuRutabaga. Signed-off-by: Gurchetan Singh Tested-by: Alyssa Ross Tested-by: Emmanouil Pitsidianakis Reviewed-by: Emmanouil Pitsidianakis --- v1: void *rutabaga --> struct rutabaga

[PATCH v6 9/9] docs/system: add basic virtio-gpu documentation

This adds basic documentation for virtio-gpu. Suggested-by: Akihiko Odaki Signed-off-by: Gurchetan Singh Tested-by: Alyssa Ross Tested-by: Emmanouil Pitsidianakis Reviewed-by: Emmanouil Pitsidianakis --- v2: - Incorporated suggestions by Akihiko Odaki - Listed the currently supported caps

[PATCH v6 1/9] virtio: Add shared memory capability

From: "Dr. David Alan Gilbert" Define a new capability type 'VIRTIO_PCI_CAP_SHARED_MEMORY_CFG' to allow defining shared memory regions with sizes and offsets of 2^32 and more. Multiple instances of the capability are allowed and distinguished by a device-specific 'id'. Signed-off-by: Dr. David A

[PATCH v6 0/9] gfxstream + rutabaga_gfx

From: Gurchetan Singh Prior versions: v5: https://lists.gnu.org/archive/html/qemu-devel/2023-08/msg02339.html v4: https://lists.gnu.org/archive/html/qemu-devel/2023-08/msg01566.html v3: https://lists.gnu.org/archive/html/qemu-devel/2023-08/msg00565.html v2: https://lists.gnu.org/archive/html/

Re: [PATCH v5 1/5] ebpf: Added eBPF map update through mmap.

On Mon, Aug 14, 2023 at 4:36 PM Andrew Melnichenko wrote: > > Hi, all. > > I've researched an issue a bit. And what can we do? > In the case of an "old" kernel 5.4, we need to load RSS eBPF without > BPF_F_MAPPABLE > and use bpf syscall to update the maps. This requires additional capabilities, >

Re: [PATCH 3/5] migration/ram: Move xbzrle zero page handling into save_zero_page

Fabiano Rosas writes: > It makes a bit more sense to have the zero page handling of xbzrle > right where we save the zero page. > > This also makes save_zero_page() follow the same format as > save_compress_page() at the top level of > ram_save_target_page_legacy(). > > Signed-off-by: Fabiano Ros

Re: [PATCH 5/5] migration/ram: Merge save_zero_page functions

Peter Xu writes: > On Tue, Aug 15, 2023 at 11:38:28AM -0300, Fabiano Rosas wrote: >> We don't need to do this in two pieces. One single function makes it >> easier to grasp, specially since it removes the indirection on the >> return value handling. >> >> Signed-off-by: Fabiano Rosas >> --- >>

[PATCH v3 0/8] riscv: detecting user choice in TCG extensions

Based-on: 20230815223741.433763-1-dbarb...@ventanamicro.com ("[PATCH v8 00/12] riscv: add 'max' CPU, deprecate 'any'") Hi, This new version was rebased on top of the new version of its parent series. Recent changes made there conflicted with the previous version of this work. No changes made asi

[PATCH v3 2/8] target/riscv: make CPUCFG() macro public

The RISC-V KVM driver uses a CPUCFG() macro that calculates the offset of a certain field in the struct RISCVCPUConfig. We're going to use this macro in target/riscv/cpu.c as well in the next patches. Make it public. Rename it to CPU_CFG_OFFSET() for more clarity while we're at it. Signed-off-by:

[PATCH v3 5/8] target/riscv/cpu.c: introduce RISCVCPUMultiExtConfig

If we want to make better decisions when auto-enabling extensions during realize() we need a way to tell if an user set an extension manually. The RISC-V KVM driver has its own solution via a KVMCPUConfig struct that has an 'user_set' flag that is set during the Property set() callback. The set() c

[PATCH v3 3/8] target/riscv/cpu.c: introduce cpu_cfg_ext_auto_update()

During realize() time we're activating a lot of extensions based on some criteria, e.g.: if (cpu->cfg.ext_zk) { cpu->cfg.ext_zkn = true; cpu->cfg.ext_zkr = true; cpu->cfg.ext_zkt = true; } This practice resulted in at least one case where we ended up enabling somet

[PATCH v3 6/8] target/riscv: use isa_ext_update_enabled() in init_max_cpu_extensions()

Before adding support to detect if an extension was user set we need to handle how we're enabling extensions in riscv_init_max_cpu_extensions(). object_property_set_bool() calls the set() callback for the property, and we're going to use this callback to set the 'multi_ext_user_opts' hash. This me

[PATCH v3 4/8] target/riscv/cpu.c: use cpu_cfg_ext_auto_update() during realize()

Let's change the other instances in realize() where we're enabling an extension based on a certain criteria (e.g. it's a dependency of another extension). We're leaving icsr and ifencei being enabled during RVG for later - we'll want to error out in that case. Every other extension enablement duri

[PATCH v3 7/8] target/riscv/cpu.c: honor user choice in cpu_cfg_ext_auto_update()

Add a new cpu_cfg_ext_is_user_set() helper to check if an extension was set by the user in the command line. Use it inside cpu_cfg_ext_auto_update() to verify if the user set a certain extension and, if that's the case, do not change its value. This will make us honor user choice instead of overwr

[PATCH v3 8/8] target/riscv/cpu.c: consider user option with RVG

Enabling RVG will enable a set of extensions that we're not checking if the user was okay enabling or not. And in this case we want to error out, instead of ignoring, otherwise we will be inconsistent enabling RVG without all its extensions. After this patch, disabling ifencei or icsr while enabli

[PATCH v3 1/8] target/riscv/cpu.c: use offset in isa_ext_is_enabled/update_enabled

We'll have future usage for a function where, given an offset of the struct RISCVCPUConfig, the flag is updated to a certain val. Change all existing callers to use edata->ext_enable_offset instead of 'edata'. Signed-off-by: Daniel Henrique Barboza Reviewed-by: Alistair Francis --- target/risc

Re: [PATCH] migrate/ram: let ram_save_target_page_legacy() return if qemu file got error

Peter Xu writes: > On Tue, Aug 15, 2023 at 09:35:19AM -0300, Fabiano Rosas wrote: >> Guoyi Tu writes: >> >> > When the migration process of a virtual machine using huge pages is >> > cancelled, >> > QEMU will continue to complete the processing of the current huge page >> > through the qemu fi

[PATCH v8 12/12] target/riscv: deprecate the 'any' CPU type

The 'any' CPU type was introduced in commit dc5bd18fa5725 ("RISC-V CPU Core Definition"), being around since the beginning. It's not an easy CPU to use: it's undocumented and its name doesn't tell users much about what the CPU is supposed to bring. 'git log' doesn't help us either in knowing what w

[PATCH v8 09/12] target/riscv/cpu.c: limit cfg->vext_spec log message

Inside riscv_cpu_validate_v() we're always throwing a log message if the user didn't set a vector version via 'vext_spec'. We're going to include one case with the 'max' CPU where env->vext_ver will be set in the cpu_init(). But that alone will not stop the "vector version is not specified" messag

[PATCH v8 06/12] target/riscv/cpu.c: split non-ratified exts from riscv_cpu_extensions[]

Create a new riscv_cpu_experimental_exts[] to store the non-ratified extensions properties. Once they are ratified we'll move them back to riscv_cpu_extensions[]. riscv_cpu_add_user_properties() and riscv_cpu_add_kvm_properties() are changed to keep adding non-ratified properties to users. Signed

[PATCH v8 00/12] riscv: add 'max' CPU, deprecate 'any'

Hi, In this version we replaced the macros added in patch 7 and 8 with regular functions instead. Patches missing acks: 4,7,8 Changes from v7: - patch 7: - add riscv_cpu_add_qdev_prop_array() function instead of a macro - patch 8: - add riscv_cpu_add_kvm_unavail_prop_array() function instead

[PATCH v8 03/12] target/riscv/cpu.c: split kvm prop handling to its own helper

Future patches will split the existing Property arrays even further, and the existing code in riscv_cpu_add_user_properties() will start to scale bad with it because it's dealing with KVM constraints mixed in with TCG constraints. We're going to pay a high price to share a couple of common lines of

[PATCH v8 07/12] target/riscv/cpu.c: add riscv_cpu_add_qdev_prop_array()

The code inside riscv_cpu_add_user_properties() became quite repetitive after recent changes. Add a helper to hide the repetition away. Signed-off-by: Daniel Henrique Barboza --- target/riscv/cpu.c | 27 +++ 1 file changed, 11 insertions(+), 16 deletions(-) diff --git a/

[PATCH v8 02/12] target/riscv/cpu.c: skip 'bool' check when filtering KVM props

After the introduction of riscv_cpu_options[] all properties in riscv_cpu_extensions[] are booleans. This check is now obsolete. Signed-off-by: Daniel Henrique Barboza Reviewed-by: Alistair Francis --- target/riscv/cpu.c | 14 -- 1 file changed, 4 insertions(+), 10 deletions(-) dif

[PATCH v8 11/12] avocado, risc-v: add opensbi tests for 'max' CPU

Add smoke tests to ensure that we'll not break the 'max' CPU type when adding new ratified extensions to be enabled. Signed-off-by: Daniel Henrique Barboza Reviewed-by: Alistair Francis --- tests/avocado/riscv_opensbi.py | 16 1 file changed, 16 insertions(+) diff --git a/test

[PATCH v8 10/12] target/riscv: add 'max' CPU type

The 'max' CPU type is used by tooling to determine what's the most capable CPU a current QEMU version implements. Other archs such as ARM implements this type. Let's add it to RISC-V. What we consider "most capable CPU" in this context are related to ratified, non-vendor extensions. This means tha

[PATCH v8 04/12] target/riscv: add DEFINE_PROP_END_OF_LIST() to riscv_cpu_options[]

Add DEFINE_PROP_END_OF_LIST() and eliminate the ARRAY_SIZE() usage when iterating in the riscv_cpu_options[] array, making it similar to what we already do when working with riscv_cpu_extensions[]. We also have a more sophisticated motivation behind this change. In the future we might need to expo

[PATCH v8 05/12] target/riscv/cpu.c: split vendor exts from riscv_cpu_extensions[]

Our goal is to make riscv_cpu_extensions[] hold only ratified, non-vendor extensions. Create a new riscv_cpu_vendor_exts[] array for them, changing riscv_cpu_add_user_properties() and riscv_cpu_add_kvm_properties() accordingly. Signed-off-by: Daniel Henrique Barboza Reviewed-by: Alistair Francis

[PATCH v8 08/12] target/riscv/cpu.c: add riscv_cpu_add_kvm_unavail_prop_array()

Use a helper in riscv_cpu_add_kvm_properties() to eliminate some of its code repetition. Signed-off-by: Daniel Henrique Barboza --- target/riscv/cpu.c | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c index a0c14d

[PATCH v8 01/12] target/riscv/cpu.c: split CPU options from riscv_cpu_extensions[]

We'll add a new CPU type that will enable a considerable amount of extensions. To make it easier for us we'll do a few cleanups in our existing riscv_cpu_extensions[] array. Start by splitting all CPU non-boolean options from it. Create a new riscv_cpu_options[] array for them. Add all these prope

Re: [PATCH v3 09/10] migration: Be consistent about shutdown of source shared files

On Tue, Aug 15, 2023 at 07:19:43PM -0300, Fabiano Rosas wrote: > Peter Xu writes: > > > On Fri, Aug 11, 2023 at 12:08:35PM -0300, Fabiano Rosas wrote: > >> When doing cleanup, we currently close() some of the shared migration > >> files and shutdown() + close() others. Be consistent by always cal

Re: [PATCH 5/5] migration/ram: Merge save_zero_page functions

On Tue, Aug 15, 2023 at 11:38:28AM -0300, Fabiano Rosas wrote: > We don't need to do this in two pieces. One single function makes it > easier to grasp, specially since it removes the indirection on the > return value handling. > > Signed-off-by: Fabiano Rosas > --- > migration/ram.c | 41 ++

Re: [PATCH v3 10/10] migration: Add a wrapper to cleanup migration files

Peter Xu writes: > On Fri, Aug 11, 2023 at 12:08:36PM -0300, Fabiano Rosas wrote: >> We currently have a pattern for cleaning up a migration QEMUFile: >> >> qemu_mutex_lock(&s->qemu_file_lock); >> file = s->file_name; >> s->file_name = NULL; >> qemu_mutex_unlock(&s->qemu_file_lock); >>

Re: [PATCH 4/5] migration/ram: Return early from save_zero_page

On Tue, Aug 15, 2023 at 11:38:27AM -0300, Fabiano Rosas wrote: > Invert the first conditional so we return early when len == 0. This is > merely to make the next patch easier to read. > > Signed-off-by: Fabiano Rosas > --- > migration/ram.c | 29 +++-- > 1 file changed, 1

Re: [PATCH 3/5] migration/ram: Move xbzrle zero page handling into save_zero_page

On Tue, Aug 15, 2023 at 11:38:26AM -0300, Fabiano Rosas wrote: > It makes a bit more sense to have the zero page handling of xbzrle > right where we save the zero page. > > This also makes save_zero_page() follow the same format as > save_compress_page() at the top level of > ram_save_target_page_

Re: [PATCH 2/5] migration/ram: Stop passing QEMUFile around in save_zero_page

On Tue, Aug 15, 2023 at 11:38:25AM -0300, Fabiano Rosas wrote: > We don't need the QEMUFile when we're already passing the > PageSearchStatus. > > Signed-off-by: Fabiano Rosas Reviewed-by: Peter Xu -- Peter Xu

Re: [PATCH 1/5] migration/ram: Remove RAMState from xbzrle_cache_zero_page

On Tue, Aug 15, 2023 at 11:38:24AM -0300, Fabiano Rosas wrote: > 'rs' is not used in that function. It's a leftover from commit > 9360447d34 ("ram: Use MigrationStats for statistics"). > > Signed-off-by: Fabiano Rosas Reviewed-by: Peter Xu -- Peter Xu

Re: [PATCH] migrate/ram: let ram_save_target_page_legacy() return if qemu file got error

On Tue, Aug 15, 2023 at 09:35:19AM -0300, Fabiano Rosas wrote: > Guoyi Tu writes: > > > When the migration process of a virtual machine using huge pages is > > cancelled, > > QEMU will continue to complete the processing of the current huge page > > through the qemu file object got an error set.

Re: [PATCH v3 09/10] migration: Be consistent about shutdown of source shared files

Peter Xu writes: > On Fri, Aug 11, 2023 at 12:08:35PM -0300, Fabiano Rosas wrote: >> When doing cleanup, we currently close() some of the shared migration >> files and shutdown() + close() others. Be consistent by always calling >> shutdown() before close(). >> >> Do this only for the source fil

Re: [PATCH v3 10/10] migration: Add a wrapper to cleanup migration files

On Fri, Aug 11, 2023 at 12:08:36PM -0300, Fabiano Rosas wrote: > We currently have a pattern for cleaning up a migration QEMUFile: > > qemu_mutex_lock(&s->qemu_file_lock); > file = s->file_name; > s->file_name = NULL; > qemu_mutex_unlock(&s->qemu_file_lock); > > migration_ioc_unregister

Re: [PATCH v3 09/10] migration: Be consistent about shutdown of source shared files

On Fri, Aug 11, 2023 at 12:08:35PM -0300, Fabiano Rosas wrote: > When doing cleanup, we currently close() some of the shared migration > files and shutdown() + close() others. Be consistent by always calling > shutdown() before close(). > > Do this only for the source files for now because the sou

Re: [PATCH v3 08/10] migration: Move return path cleanup to main migration thread

On Fri, Aug 11, 2023 at 12:08:34PM -0300, Fabiano Rosas wrote: > Now that the return path thread is allowed to finish during a paused > migration, we can move the cleanup of the QEMUFiles to the main > migration thread. > > Signed-off-by: Fabiano Rosas Reviewed-by: Peter Xu -- Peter Xu

Re: [PATCH v7 07/12] target/riscv/cpu.c: add ADD_CPU_QDEV_PROPERTIES_ARRAY() macro

On 8/15/23 14:15, Daniel Henrique Barboza wrote: I assume that you don't fancy this macro usage, and probably for a good reason, I prefer to use macros only for things that cannot be done another way. When debugging, one cannot step through macros in any reasonable way. r~

Re: [PATCH v3 07/10] migration: Replace the return path retry logic

On Fri, Aug 11, 2023 at 12:08:33PM -0300, Fabiano Rosas wrote: > Replace the return path retry logic with finishing and restarting the > thread. This fixes a race when resuming the migration that leads to a > segfault. > > Currently when doing postcopy we consider that an IO error on the > return

Re: [PATCH v3 06/10] migration: Consolidate return path closing code

On Fri, Aug 11, 2023 at 12:08:32PM -0300, Fabiano Rosas wrote: > We'll start calling the await_return_path_close_on_source() function > from other parts of the code, so move all of the related checks and > tracepoints into it. > > Signed-off-by: Fabiano Rosas Reviewed-by: Peter Xu -- Peter Xu

Re: [PATCH v3 05/10] migration: Remove redundant cleanup of postcopy_qemufile_src

On Fri, Aug 11, 2023 at 12:08:31PM -0300, Fabiano Rosas wrote: > This file is owned by the return path thread which is already doing > cleanup. > > Signed-off-by: Fabiano Rosas Reviewed-by: Peter Xu -- Peter Xu

Re: [PATCH v3 04/10] migration: Fix possible race when shutting down to_dst_file

On Fri, Aug 11, 2023 at 12:08:30PM -0300, Fabiano Rosas wrote: > It's not safe to call qemu_file_shutdown() on the to_dst_file without > first checking for the file's presence under the lock. The cleanup of > this file happens at postcopy_pause() and migrate_fd_cleanup() which > are not necessarily

Re: [PATCH v3 01/10] migration: Fix possible race when setting rp_state.error

On Fri, Aug 11, 2023 at 12:08:27PM -0300, Fabiano Rosas wrote: > We don't need to set the rp_state.error right after a shutdown because > qemu_file_shutdown() always sets the QEMUFile error, so the return > path thread would have seen it and set the rp error itself. > > Setting the error outside o

Re: [PATCH v3 03/10] migration: Fix possible race when checking to_dst_file for errors

On Fri, Aug 11, 2023 at 12:08:29PM -0300, Fabiano Rosas wrote: > diff --git a/migration/migration.c b/migration/migration.c > index 0067c927fa..85c171f32c 100644 > --- a/migration/migration.c > +++ b/migration/migration.c > @@ -2057,11 +2057,10 @@ static int > await_return_path_close_on_source(Mig

Re: [PULL 00/14] linux-user image mapping fixes

On 8/15/23 23:09, Richard Henderson wrote: On 8/15/23 06:51, Michael Tokarev wrote: 09.08.2023 00:08, Richard Henderson пишет: The following changes since commit 0450cf08976f9036feaded438031b4cba94f6452:    Merge tag 'fixes-pull-request' of https://gitlab.com/marcandre.lureau/qemu into stagin

Re: [PATCH v7 07/12] target/riscv/cpu.c: add ADD_CPU_QDEV_PROPERTIES_ARRAY() macro

On 8/15/23 17:44, Richard Henderson wrote: On 8/15/23 13:15, Daniel Henrique Barboza wrote: @@ -1883,6 +1883,13 @@ static void cpu_set_cfg_unavailable(Object *obj, Visitor *v,   }   #endif +#define ADD_CPU_QDEV_PROPERTIES_ARRAY(_dev, _array) \ +    do { \ +    for (Property *prop = _arra

Re: [PULL 00/14] linux-user image mapping fixes

On 8/15/23 06:51, Michael Tokarev wrote: 09.08.2023 00:08, Richard Henderson пишет: The following changes since commit 0450cf08976f9036feaded438031b4cba94f6452:    Merge tag 'fixes-pull-request' of https://gitlab.com/marcandre.lureau/qemu into staging (2023-08-07 13:55:00 -0700) are availabl

Re: [PATCH v7 07/12] target/riscv/cpu.c: add ADD_CPU_QDEV_PROPERTIES_ARRAY() macro

On 8/15/23 13:15, Daniel Henrique Barboza wrote: @@ -1883,6 +1883,13 @@ static void cpu_set_cfg_unavailable(Object *obj, Visitor *v, } #endif +#define ADD_CPU_QDEV_PROPERTIES_ARRAY(_dev, _array) \ +do { \ +for (Property *prop = _array; prop && prop->name; prop++) { \ +

[PATCH v2 4/8] target/riscv/cpu.c: use cpu_cfg_ext_auto_update() during realize()

Let's change the other instances in realize() where we're enabling an extension based on a certain criteria (e.g. it's a dependency of another extension). We're leaving icsr and ifencei being enabled during RVG for later - we'll want to error out in that case. Every other extension enablement duri

[PATCH v2 3/8] target/riscv/cpu.c: introduce cpu_cfg_ext_auto_update()

During realize() time we're activating a lot of extensions based on some criteria, e.g.: if (cpu->cfg.ext_zk) { cpu->cfg.ext_zkn = true; cpu->cfg.ext_zkr = true; cpu->cfg.ext_zkt = true; } This practice resulted in at least one case where we ended up enabling somet

[PATCH v2 7/8] target/riscv/cpu.c: honor user choice in cpu_cfg_ext_auto_update()

Add a new cpu_cfg_ext_is_user_set() helper to check if an extension was set by the user in the command line. Use it inside cpu_cfg_ext_auto_update() to verify if the user set a certain extension and, if that's the case, do not change its value. This will make us honor user choice instead of overwr

[PATCH v2 6/8] target/riscv: use isa_ext_update_enabled() in init_max_cpu_extensions()

Before adding support to detect if an extension was user set we need to handle how we're enabling extensions in riscv_init_max_cpu_extensions(). object_property_set_bool() calls the set() callback for the property, and we're going to use this callback to set the 'multi_ext_user_opts' hash. This me

[PATCH v2 0/8] riscv: detecting user choice in TCG extensions

Hi, This new version is a rebase on top of the new version of the 'max' CPU series: [PATCH v7 00/12] riscv: add 'max' CPU, deprecate 'any' The changes made from v6 to v7 conflicted with the code from v1 of this series. No changes made aside from trivial conflicts. All patches acked. Changes f

[PATCH v2 8/8] target/riscv/cpu.c: consider user option with RVG

Enabling RVG will enable a set of extensions that we're not checking if the user was okay enabling or not. And in this case we want to error out, instead of ignoring, otherwise we will be inconsistent enabling RVG without all its extensions. After this patch, disabling ifencei or icsr while enabli

[PATCH v2 5/8] target/riscv/cpu.c: introduce RISCVCPUMultiExtConfig

If we want to make better decisions when auto-enabling extensions during realize() we need a way to tell if an user set an extension manually. The RISC-V KVM driver has its own solution via a KVMCPUConfig struct that has an 'user_set' flag that is set during the Property set() callback. The set() c

[PATCH v2 2/8] target/riscv: make CPUCFG() macro public

The RISC-V KVM driver uses a CPUCFG() macro that calculates the offset of a certain field in the struct RISCVCPUConfig. We're going to use this macro in target/riscv/cpu.c as well in the next patches. Make it public. Rename it to CPU_CFG_OFFSET() for more clarity while we're at it. Signed-off-by:

[PATCH v2 1/8] target/riscv/cpu.c: use offset in isa_ext_is_enabled/update_enabled

We'll have future usage for a function where, given an offset of the struct RISCVCPUConfig, the flag is updated to a certain val. Change all existing callers to use edata->ext_enable_offset instead of 'edata'. Signed-off-by: Daniel Henrique Barboza Reviewed-by: Alistair Francis --- target/risc

[PATCH v7 10/12] target/riscv: add 'max' CPU type

The 'max' CPU type is used by tooling to determine what's the most capable CPU a current QEMU version implements. Other archs such as ARM implements this type. Let's add it to RISC-V. What we consider "most capable CPU" in this context are related to ratified, non-vendor extensions. This means tha

[PATCH v7 11/12] avocado, risc-v: add opensbi tests for 'max' CPU

Add smoke tests to ensure that we'll not break the 'max' CPU type when adding new ratified extensions to be enabled. Signed-off-by: Daniel Henrique Barboza Reviewed-by: Alistair Francis --- tests/avocado/riscv_opensbi.py | 16 1 file changed, 16 insertions(+) diff --git a/test

[PATCH v7 08/12] target/riscv/cpu.c: add ADD_UNAVAIL_KVM_PROP_ARRAY() macro

Use a macro in riscv_cpu_add_kvm_properties() to eliminate some of its code repetition, similar to what we're already doing with ADD_CPU_QDEV_PROPERTIES_ARRAY(). Signed-off-by: Daniel Henrique Barboza Reviewed-by: Weiwei Li --- target/riscv/cpu.c | 21 ++--- 1 file changed, 10 i

[PATCH v7 03/12] target/riscv/cpu.c: split kvm prop handling to its own helper

Future patches will split the existing Property arrays even further, and the existing code in riscv_cpu_add_user_properties() will start to scale bad with it because it's dealing with KVM constraints mixed in with TCG constraints. We're going to pay a high price to share a couple of common lines of

[PATCH v7 12/12] target/riscv: deprecate the 'any' CPU type

The 'any' CPU type was introduced in commit dc5bd18fa5725 ("RISC-V CPU Core Definition"), being around since the beginning. It's not an easy CPU to use: it's undocumented and its name doesn't tell users much about what the CPU is supposed to bring. 'git log' doesn't help us either in knowing what w

[PATCH v7 09/12] target/riscv/cpu.c: limit cfg->vext_spec log message

Inside riscv_cpu_validate_v() we're always throwing a log message if the user didn't set a vector version via 'vext_spec'. We're going to include one case with the 'max' CPU where env->vext_ver will be set in the cpu_init(). But that alone will not stop the "vector version is not specified" messag

[PATCH v7 06/12] target/riscv/cpu.c: split non-ratified exts from riscv_cpu_extensions[]

Create a new riscv_cpu_experimental_exts[] to store the non-ratified extensions properties. Once they are ratified we'll move them back to riscv_cpu_extensions[]. riscv_cpu_add_user_properties() and riscv_cpu_add_kvm_properties() are changed to keep adding non-ratified properties to users. Signed

[PATCH v7 07/12] target/riscv/cpu.c: add ADD_CPU_QDEV_PROPERTIES_ARRAY() macro

The code inside riscv_cpu_add_user_properties() became quite repetitive after recent changes. Add a macro to hide the repetition away. Signed-off-by: Daniel Henrique Barboza Reviewed-by: Weiwei Li --- target/riscv/cpu.c | 27 +++ 1 file changed, 11 insertions(+), 16 dele

[PATCH v7 00/12] riscv: add 'max' CPU, deprecate 'any'

Hi, This new version contains a change in patch 4 where, instead of changing every other Property array to use ARRAY_SIZE(), convert riscv_cpu_options[] to use DEFINE_PROP_END_OF_LIST(). This change makes no difference in the code deduplication that is done in the later patches, and will spare us

[PATCH v7 04/12] target/riscv: add DEFINE_PROP_END_OF_LIST() to riscv_cpu_options[]

Add DEFINE_PROP_END_OF_LIST() and eliminate the ARRAY_SIZE() usage when iterating in the riscv_cpu_options[] array, making it similar to what we already do when working with riscv_cpu_extensions[]. We also have a more sophisticated motivation behind this change. In the future we might need to expo

[PATCH v7 02/12] target/riscv/cpu.c: skip 'bool' check when filtering KVM props

After the introduction of riscv_cpu_options[] all properties in riscv_cpu_extensions[] are booleans. This check is now obsolete. Signed-off-by: Daniel Henrique Barboza Reviewed-by: Alistair Francis --- target/riscv/cpu.c | 14 -- 1 file changed, 4 insertions(+), 10 deletions(-) dif

[PATCH v7 05/12] target/riscv/cpu.c: split vendor exts from riscv_cpu_extensions[]

Our goal is to make riscv_cpu_extensions[] hold only ratified, non-vendor extensions. Create a new riscv_cpu_vendor_exts[] array for them, changing riscv_cpu_add_user_properties() and riscv_cpu_add_kvm_properties() accordingly. Signed-off-by: Daniel Henrique Barboza Reviewed-by: Alistair Francis

[PATCH v7 01/12] target/riscv/cpu.c: split CPU options from riscv_cpu_extensions[]

We'll add a new CPU type that will enable a considerable amount of extensions. To make it easier for us we'll do a few cleanups in our existing riscv_cpu_extensions[] array. Start by splitting all CPU non-boolean options from it. Create a new riscv_cpu_options[] array for them. Add all these prope

[PATCH v3 10/14] tcg/ppc: Use prefixed instructions in tcg_out_mem_long

When the offset is out of range of the non-prefixed insn, but fits the 34-bit immediate of the prefixed insn, use that. Reviewed-by: Jordan Niethe Signed-off-by: Richard Henderson --- tcg/ppc/tcg-target.c.inc | 66 1 file changed, 66 insertions(+) diff

[PATCH v3 09/14] tcg/ppc: Use PADDI in tcg_out_movi

PADDI can load 34-bit immediates and 34-bit pc-relative addresses. Reviewed-by: Jordan Niethe Signed-off-by: Richard Henderson --- tcg/ppc/tcg-target.c.inc | 51 1 file changed, 51 insertions(+) diff --git a/tcg/ppc/tcg-target.c.inc b/tcg/ppc/tcg-target

[PATCH v3 11/14] tcg/ppc: Use PLD in tcg_out_movi for constant pool

The prefixed instruction has a pc-relative form to use here. Signed-off-by: Richard Henderson --- tcg/ppc/tcg-target.c.inc | 24 1 file changed, 24 insertions(+) diff --git a/tcg/ppc/tcg-target.c.inc b/tcg/ppc/tcg-target.c.inc index 1aece2cbf7..670811b636 100644 --- a/t

[PATCH v3 06/14] tcg/ppc: Use ADDPCIS in tcg_out_movi_int

Signed-off-by: Richard Henderson --- tcg/ppc/tcg-target.c.inc | 13 + 1 file changed, 13 insertions(+) diff --git a/tcg/ppc/tcg-target.c.inc b/tcg/ppc/tcg-target.c.inc index 36b4f61236..a302bfff2e 100644 --- a/tcg/ppc/tcg-target.c.inc +++ b/tcg/ppc/tcg-target.c.inc @@ -1050,6 +1050,1

[PATCH v3 14/14] RFC tcg/ppc: Disable TCG_REG_TB for Power9/Power10

This may or may not improve performance. It appears to result in slightly larger code, but perhaps not enough to matter. Signed-off-by: Richard Henderson --- tcg/ppc/tcg-target.c.inc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tcg/ppc/tcg-target.c.inc b/tcg/ppc/tcg-target

[PATCH v3 01/14] tcg/ppc: Untabify tcg-target.c.inc

Signed-off-by: Richard Henderson --- tcg/ppc/tcg-target.c.inc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tcg/ppc/tcg-target.c.inc b/tcg/ppc/tcg-target.c.inc index 511e14b180..642d0fd128 100644 --- a/tcg/ppc/tcg-target.c.inc +++ b/tcg/ppc/tcg-target.c.inc @@ -221,7 +

[PATCH v3 02/14] tcg: Add tcg_out_tb_start backend hook

This hook may emit code at the beginning of the TB. Suggested-by: Jordan Niethe Signed-off-by: Richard Henderson --- tcg/tcg.c| 3 +++ tcg/aarch64/tcg-target.c.inc | 5 + tcg/arm/tcg-target.c.inc | 5 + tcg/i386/tcg-target.c.inc| 5 + tcg/

[PATCH v3 07/14] tcg/ppc: Use ADDPCIS for the constant pool

Signed-off-by: Richard Henderson --- tcg/ppc/tcg-target.c.inc | 12 1 file changed, 12 insertions(+) diff --git a/tcg/ppc/tcg-target.c.inc b/tcg/ppc/tcg-target.c.inc index a302bfff2e..a5c1891eb6 100644 --- a/tcg/ppc/tcg-target.c.inc +++ b/tcg/ppc/tcg-target.c.inc @@ -1076,6 +1076,12

[PATCH v3 05/14] tcg/ppc: Use ADDPCIS in tcg_out_tb_start

With ISA v3.0, we can use ADDPCIS instead of BCL+MFLR to load NIP. Signed-off-by: Richard Henderson --- tcg/ppc/tcg-target.c.inc | 25 ++--- 1 file changed, 22 insertions(+), 3 deletions(-) diff --git a/tcg/ppc/tcg-target.c.inc b/tcg/ppc/tcg-target.c.inc index 19004fa568..36

[PATCH v3 08/14] tcg/ppc: Use ADDPCIS in tcg_out_goto_tb

Signed-off-by: Richard Henderson --- tcg/ppc/tcg-target.c.inc | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/tcg/ppc/tcg-target.c.inc b/tcg/ppc/tcg-target.c.inc index a5c1891eb6..b7d1b4f1bb 100644 --- a/tcg/ppc/tcg-target.c.inc +++ b/tcg/ppc/tcg-target.c.inc @@ -2

  1   2   >