Re: [External] Re: [PATCH 3/5] migration: Introduce unimplemented 'qatzip' compression method

On Fri, Jan 5, 2024 at 3:52 PM Hao Xiang wrote: > > On Fri, Jan 5, 2024 at 12:07 PM Fabiano Rosas wrote: > > > > Bryan Zhang writes: > > > > +cc Yuan Liu, Daniel Berrangé > > > > > Adds support for 'qatzip' as an option for the multifd compression > > > method parameter, but copy-pastes the no-o

Re: [External] Re: [QEMU-devel][RFC PATCH 1/1] backends/hostmem: qapi/qom: Add an ObjectOption for memory-backend-* called HostMemType and its arg 'cxlram'

On Wed, Jan 3, 2024 at 1:56 PM Gregory Price wrote: > > On Sun, Dec 31, 2023 at 11:53:15PM -0800, Ho-Ren (Jack) Chuang wrote: > > Introduce a new configuration option 'host-mem-type=' in the > > '-object memory-backend-ram', allowing users to specify > > from which type of memory to allocate. > >

Re: acpiBitsTest.test_acpi_smbios_bits test intermittently times out

On Sat, Jan 6, 2024 at 10:05 AM Ani Sinha wrote: > > On Sat, Jan 6, 2024 at 12:11 AM Peter Maydell > wrote: > > > > The avocado test acpiBitsTest.test_acpi_smbios_bits seems to be > > flaky in CI -- sometimes it appears to time out. > > > > https://gitlab.com/qemu-project/qemu/-/issues/2077 > >

Re: acpiBitsTest.test_acpi_smbios_bits test intermittently times out

On Sat, Jan 6, 2024 at 12:11 AM Peter Maydell wrote: > > The avocado test acpiBitsTest.test_acpi_smbios_bits seems to be > flaky in CI -- sometimes it appears to time out. > > https://gitlab.com/qemu-project/qemu/-/issues/2077 > has the details (including links to jobs etc). Do you have more data

[PULL v2 0/2] loongarch-to-apply queue

The following changes since commit 0c1eccd368af8805ec0fb11e6cf25d0684d37328: Merge tag 'hw-cpus-20240105' of https://github.com/philmd/qemu into staging (2024-01-05 16:08:58 +) are available in the Git repository at: https://gitlab.com/gaosong/qemu.git tags/pull-loongarch-202

[PULL v2 1/2] target/loongarch/meson: move gdbstub.c to loongarch.ss

gdbstub.c is not specific to TCG and can be used by other accelerators, such as KVM accelerator Reviewed-by: Philippe Mathieu-Daudé Signed-off-by: Song Gao Message-Id: <20240102020200.3462097-1-gaos...@loongson.cn> --- target/loongarch/meson.build | 2 +- 1 file changed, 1 insertion(+), 1 delet

[PULL v2 2/2] target/loongarch: move translate modules to tcg/

Introduce the target/loongarch/tcg directory. Its purpose is to hold the TCG code that is selected by CONFIG_TCG Reviewed-by: Philippe Mathieu-Daudé Signed-off-by: Song Gao Message-Id: <20240102020200.3462097-2-gaos...@loongson.cn> --- target/loongarch/meson.build | 15 +---

Re: [PULL 0/2] loongarch-to-apply queue

in the Git repository at: https://gitlab.com/gaosong/qemu.git tags/pull-loongarch-20240105 for you to fetch changes up to 0cd8b379081fa71c23836052feb65da4685f8ec7: target/loongarch: move translate modules to tcg/ (2024-01-05 09:3

Re: [External] Re: [QEMU-devel][RFC PATCH 1/1] backends/hostmem: qapi/qom: Add an ObjectOption for memory-backend-* called HostMemType and its arg 'cxlram'

On Tue, Jan 2, 2024 at 5:04 AM David Hildenbrand wrote: > > On 01.01.24 08:53, Ho-Ren (Jack) Chuang wrote: > > Introduce a new configuration option 'host-mem-type=' in the > > '-object memory-backend-ram', allowing users to specify > > from which type of memory to allocate. > > > > Users can speci

Re: [External] Re: [PATCH 3/5] migration: Introduce unimplemented 'qatzip' compression method

On Fri, Jan 5, 2024 at 12:07 PM Fabiano Rosas wrote: > > Bryan Zhang writes: > > +cc Yuan Liu, Daniel Berrangé > > > Adds support for 'qatzip' as an option for the multifd compression > > method parameter, but copy-pastes the no-op logic to leave the actual > > methods effectively unimplemented.

[PATCH v4 02/17] target/riscv: make riscv_cpu_is_vendor() public

We'll use this function in target/riscv/cpu.c to implement setters that won't allow vendor CPU options to be changed. Signed-off-by: Daniel Henrique Barboza Reviewed-by: Alistair Francis --- target/riscv/cpu.c | 5 + target/riscv/cpu.h | 1 + target/riscv/tcg/tcg-cpu.c | 5 -

[PATCH v4 15/17] target/riscv/cpu.c: move 'mvendorid' to riscv_cpu_properties[]

Keep all class properties in riscv_cpu_properties[]. Signed-off-by: Daniel Henrique Barboza --- target/riscv/cpu.c | 69 +- 1 file changed, 37 insertions(+), 32 deletions(-) diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c index 9d4243891c..c725a4

[PATCH v4 01/17] target/riscv/cpu_cfg.h: remove unused fields

user_spec, bext_spec and bext_ver aren't being used. Signed-off-by: Daniel Henrique Barboza Reviewed-by: Alistair Francis --- target/riscv/cpu.h | 1 - target/riscv/cpu_cfg.h | 2 -- 2 files changed, 3 deletions(-) diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h index 44fb0a9ca8..1c5a

[PATCH v4 13/17] target/riscv: move 'cboz_blocksize' to riscv_cpu_properties[]

And remove the now unused kvm_cpu_set_cbomz_blksize() setter. Signed-off-by: Daniel Henrique Barboza Reviewed-by: Alistair Francis --- target/riscv/cpu.c | 38 +- target/riscv/kvm/kvm-cpu.c | 28 2 files changed, 37 insert

[PATCH v4 11/17] target/riscv: move 'cbom_blocksize' to riscv_cpu_properties[]

After adding a KVM finalize() implementation, turn cbom_blocksize into a class property. Follow the same design we used with 'vlen' and 'elen'. The duplicated 'cbom_blocksize' KVM property can be removed from kvm_riscv_add_cpu_user_properties(). Signed-off-by: Daniel Henrique Barboza Reviewed-by

[PATCH v4 10/17] target/riscv: create finalize_features() for KVM

To turn cbom_blocksize and cboz_blocksize into class properties we need KVM specific changes. KVM is creating its own version of these options with a customized setter() that prevents users from picking an invalid value during init() time. This comes at the cost of duplicating each option that KVM

[PATCH v4 07/17] target/riscv: rework 'vext_spec'

The same rework did in 'priv_spec' is done for 'vext_spec'. This time is simpler, since we only accept one value ("v1.0") and we'll always have env->vext_ver set to VEXT_VERSION_1_00_0, thus we don't need helpers to convert string to 'vext_ver' back and forth like we needed for 'priv_spec'. Signed

[PATCH v4 12/17] target/riscv: move 'cbop_blocksize' to riscv_cpu_properties[]

Do the same we did with 'cbom_blocksize' in the previous patch. Signed-off-by: Daniel Henrique Barboza --- target/riscv/cpu.c | 38 +- 1 file changed, 37 insertions(+), 1 deletion(-) diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c index b77d26231c..e3cbe

[PATCH v4 08/17] target/riscv: move 'vlen' to riscv_cpu_properties[]

Turning 'vlen' into a class property will allow its default value to be overwritten by cpu_init() later on, solving the issue we have now where CPU specific settings are getting overwritten by the default. Common validation bits are moved from riscv_cpu_validate_v() to prop_vlen_set() to be shared

[PATCH v4 03/17] target/riscv: move 'pmu-mask' and 'pmu-num' to riscv_cpu_properties[]

Every property in riscv_cpu_options[] will be migrated to riscv_cpu_properties[]. This will make their default values init earlier, allowing cpu_init() functions to overwrite them. We'll also implement common getters and setters that both accelerators will use, allowing them to share validations th

[PATCH v4 05/17] target/riscv: move 'pmp' to riscv_cpu_properties[]

Move 'pmp' to riscv_cpu_properties[], creating a new setter() for it that forbids 'pmp' to be changed in vendor CPUs, like we did with the 'mmu' option. We'll also have to manually set 'pmp = true' to generic CPUs that were still relying on the previous default to set it. Signed-off-by: Daniel He

[PATCH v4 17/17] target/riscv/cpu.c: move 'marchid' to riscv_cpu_properties[]

Keep all class properties in riscv_cpu_properties[]. Signed-off-by: Daniel Henrique Barboza --- target/riscv/cpu.c | 110 +++-- 1 file changed, 57 insertions(+), 53 deletions(-) diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c index 6149f5960e..3870c3

[PATCH v4 14/17] target/riscv: remove riscv_cpu_options[]

The array is empty and can be removed. Signed-off-by: Daniel Henrique Barboza Reviewed-by: Alistair Francis --- target/riscv/cpu.c | 5 - target/riscv/cpu.h | 1 - target/riscv/kvm/kvm-cpu.c | 9 - target/riscv/tcg/tcg-cpu.c | 4 4 files changed, 19 deletions(-)

[PATCH v4 00/17] target/riscv: deprecate riscv_cpu_options[]

Hi, This new version contains changes due to a rebase with current riscv-to-apply.next, after "[PATCH v13 00/26] riscv: RVA22 profiles support" was queued. Most notable change is a new patch (12) that was added to handle 'cbop_blocksize' - zicbop was added by the profile work that just got queued

[PATCH v4 16/17] target/riscv/cpu.c: move 'mimpid' to riscv_cpu_properties[]

Keep all class properties in riscv_cpu_properties[]. Signed-off-by: Daniel Henrique Barboza --- target/riscv/cpu.c | 68 -- 1 file changed, 36 insertions(+), 32 deletions(-) diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c index c725a4839d..6149f5

[PATCH v4 06/17] target/riscv: rework 'priv_spec'

'priv_spec' and 'vext_spec' are two string options used as a fancy way of setting integers in the CPU state (cpu->env.priv_ver and cpu->env.vext_ver). It requires us to deal with string parsing and to store them in cpu_cfg. We must support these string options, but we don't need to store them. We

[PATCH v4 04/17] target/riscv: move 'mmu' to riscv_cpu_properties[]

Commit 7f0bdfb5bfc ("target/riscv/cpu.c: remove cfg setup from riscv_cpu_init()") already did some of the work by making some cpu_init() functions to explictly enable their own 'mmu' default. The generic CPUs didn't get update by that commit, so they are still relying on the defaults set by the 'm

[PATCH v4 09/17] target/riscv: move 'elen' to riscv_cpu_properties[]

Do the same thing we did with 'vlen' in the previous patch with 'elen'. Signed-off-by: Daniel Henrique Barboza Reviewed-by: Alistair Francis --- target/riscv/cpu.c | 44 -- target/riscv/tcg/tcg-cpu.c | 5 - 2 files changed, 42 insertions(+), 7 de

Re: [PATCH v5 2/3] tests/qtest: Add STM32L4x5 EXTI QTest testcase

On 5/1/24 11:24, Daniel P. Berrangé wrote: On Thu, Jan 04, 2024 at 01:37:22PM +, inesvarhol wrote: Le jeudi 4 janvier 2024 à 14:05, Philippe Mathieu-Daudé a écrit : Hello, +static void test_edge_selector(void) +{ + enable_nvic_irq(EXTI0_IRQ); + + / Configure EXTI line 0 irq on rising e

[PATCH v3 3/5] target/riscv: Add cycle & instret privilege mode filtering definitions

From: Kaiwen Xue This adds the definitions for ISA extension smcntrpmf. Signed-off-by: Kaiwen Xue Signed-off-by: Atish Patra --- target/riscv/cpu.h | 6 ++ target/riscv/cpu_bits.h | 29 + 2 files changed, 35 insertions(+) diff --git a/target/riscv/cpu.h

[PATCH v3 4/5] target/riscv: Add cycle & instret privilege mode filtering support

From: Kaiwen Xue QEMU only calculates dummy cycles and instructions, so there is no actual means to stop the icount in QEMU. Hence this patch merely adds the functionality of accessing the cfg registers, and cause no actual effects on the counting of cycle and instret counters. Signed-off-by: At

Re: [v2 3/5] target/riscv: Add cycle & instret privilege mode filtering definitions

On Thu, Jan 4, 2024 at 6:46 PM Alistair Francis wrote: > > On Fri, Dec 29, 2023 at 12:08 PM Atish Patra wrote: > > > > From: Kaiwen Xue > > > > This adds the definitions for ISA extension smcntrpmf. > > > > Signed-off-by: Kaiwen Xue > > Signed-off-by: Atish Patra > > --- > > target/riscv/cpu.

[PATCH v3 2/5] target/riscv: Add cycle & instret privilege mode filtering properties

From: Kaiwen Xue This adds the properties for ISA extension smcntrpmf. Patches implementing it will follow. Signed-off-by: Atish Patra Signed-off-by: Kaiwen Xue --- target/riscv/cpu.c | 2 ++ target/riscv/cpu_cfg.h | 1 + 2 files changed, 3 insertions(+) diff --git a/target/riscv/cpu.c b

[PATCH v3 0/5] Add ISA extension smcntrpmf support

This patch series adds the support for RISC-V ISA extension smcntrpmf (cycle and privilege mode filtering) [1]. It is based on Kevin's earlier work but improves it by actually implement privilege mode filtering by tracking the privilege mode switches. This enables the privilege mode filtering for m

[PATCH v3 5/5] target/riscv: Implement privilege mode filtering for cycle/instret

Privilege mode filtering can also be emulated for cycle/instret by tracking host_ticks/icount during each privilege mode switch. This patch implements that for both cycle/instret and mhpmcounters. The first one requires Smcntrpmf while the other one requires Sscofpmf to be enabled. The cycle/instr

[PATCH v3 1/5] target/riscv: Fix the predicate functions for mhpmeventhX CSRs

mhpmeventhX CSRs are available for RV32. The predicate function should check that first before checking sscofpmf extension. Fixes: 14664483457b ("target/riscv: Add sscofpmf extension support") Reviewed-by: Daniel Henrique Barboza Reviewed-by: Alistair Francis Signed-off-by: Atish Patra --- tar

Re: [PATCH v9 0/9] Unified CPU type check

Hi Gavin, On 13/12/23 11:54, Gavin Shan wrote: On 12/13/23 20:08, Philippe Mathieu-Daudé wrote: On 12/12/23 05:55, Gavin Shan wrote: On 12/4/23 10:47, Gavin Shan wrote: This series bases on Phil's repository because the prepatory commits have been queued to the branch.    https://gitlab.com/

Re: [PATCH v9 3/9] machine: Improve is_cpu_type_supported()

On 4/12/23 01:47, Gavin Shan wrote: It's no sense to check the CPU type when mc->valid_cpu_types[0] is NULL, which is a program error. Raise an assert on this. A precise hint for the error message is given when mc->valid_cpu_types[0] is the only valid entry. Besides, enumeration on mc->valid_cpu

Re: [PATCH] hw/audio/sb16: Do not migrate qdev properties

On 5/1/24 02:59, Peter Xu wrote: On Thu, Jan 04, 2024 at 05:48:18PM +0100, Philippe Mathieu-Daudé wrote: If there are no objections I'll queue this patch (fixing the typo reported by Zoltan). Yes feel free to. Thanks, Thanks, merged as commit fa293f8125.

Re: [PATCH] hw/m68k/mcf5206: Embed m5206_timer_state in m5206_mbar_state

On 21/12/23 13:29, Thomas Huth wrote: There's no need to explicitely allocate the memory here, we can simply embed it into the m5206_mbar_state instead. Signed-off-by: Thomas Huth --- hw/m68k/mcf5206.c | 20 1 file changed, 8 insertions(+), 12 deletions(-) Patch merged

Re: [PATCH v2] hw/net/can/sja1000: fix bug for single acceptance filter and standard frame

On 4/1/24 00:14, Pavel Pisa wrote: From: Pavel Pisa A CAN sja1000 standard frame filter mask has been computed and applied incorrectly for standard frames when single Acceptance Filter Mode (MOD_AFM = 1) has been selected. The problem has not been found by Linux kernel testing because it uses d

Re: [PATCH 3/5] migration: Introduce unimplemented 'qatzip' compression method

Bryan Zhang writes: +cc Yuan Liu, Daniel Berrangé > Adds support for 'qatzip' as an option for the multifd compression > method parameter, but copy-pastes the no-op logic to leave the actual > methods effectively unimplemented. This is in preparation of a > subsequent commit that will implement

[PULL 2/6] chardev/char.c: fix "abstract device type" error message

Current error message: qemu-system-x86_64: -chardev spice,id=foo: Parameter 'driver' expects an abstract device type while in fact the meaning is in reverse, -chardev expects a non-abstract device type. Fixes: 777357d758d9 ("chardev: qom-ify" 2016-12-07) Signed-off-by: Michael Tokarev Reviewe

[PULL 1/6] target/riscv: Fix mcycle/minstret increment behavior

From: Xu Lu The mcycle/minstret counter's stop flag is mistakenly updated on a copy on stack. Thus the counter increments even when the CY/IR bit in the mcountinhibit register is set. This commit corrects its behavior. Fixes: 3780e33732f88 (target/riscv: Support mcycle/minstret write operation)

[PULL 6/6] docs: use "buses" rather than "busses"

From: Samuel Tardieu If "busses" might be encountered as a plural of "bus" (5 instances), the correct spelling is "buses" (26 instances). Fixing those 5 instances makes the doc more consistent. Signed-off-by: Samuel Tardieu Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Pavel Pisa Reviewed-

[PULL 0/6] Trivial patches for 2024-01-05

The following changes since commit 0c1eccd368af8805ec0fb11e6cf25d0684d37328: Merge tag 'hw-cpus-20240105' of https://github.com/philmd/qemu into staging (2024-01-05 16:08:58 +) are available in the Git repository at: https://gitlab.com/mjt0k/qemu.git tags/pull-trivial-patche

[PULL 5/6] edu: fix DMA range upper bound check

From: Max Erenberg The edu_check_range function checks that start <= end1 < end2, where end1 is the upper bound (exclusive) of the guest-supplied DMA range and end2 is the upper bound (exclusive) of the device's allowed DMA range. When the guest tries to transfer exactly DMA_SIZE (4096) bytes, en

[PULL 4/6] hw/net: cadence_gem: Fix MDIO_OP_xxx values

From: Bin Meng Testing upstream U-Boot with 'sifive_u' machine we see: => dhcp ethernet@1009: PHY present at 0 Could not get PHY for ethernet@1009: addr 0 phy_connect failed This has been working till QEMU 8.1 but broken since QEMU 8.2. Fixes: 1b09eeb122aa ("hw/net/cadence_gem:

[PULL 3/6] audio/audio.c: remove trailing newline in error_setg

error_setg() appends newline to the formatted message. Fixes: cb94ff5f80c5 ("audio: propagate Error * out of audio_init") Signed-off-by: Michael Tokarev Reviewed-by: Philippe Mathieu-Daudé --- audio/audio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/audio/audio.c b/audi

CI "pages" job failing with incomprehensible error message from htags

https://gitlab.com/qemu-project/qemu/-/jobs/5871592479 failed with $ htags -anT --tree-view=filetree -m qemu_init -t "Welcome to the QEMU sourcecode" htags: Negative exec line limit = -371 Does anybody have any idea what this is about ? thanks -- PMM

Re: [PULL 00/71] HW core patches for 2024-01-05

nto staging > > (2024-01-04 19:55:20 +) > > > > are available in the Git repository at: > > > >https://github.com/philmd/qemu.git tags/hw-cpus-20240105 > > > > for you to fetch changes up to a318da6b3f6a88e6cfd6953c519def9457e8962

acpiBitsTest.test_acpi_smbios_bits test intermittently times out

The avocado test acpiBitsTest.test_acpi_smbios_bits seems to be flaky in CI -- sometimes it appears to time out. https://gitlab.com/qemu-project/qemu/-/issues/2077 has the details (including links to jobs etc). As far as I can see, the test is still running when after about a minute it gets timed

KVM/QEMU Community Call 9th Jan Agenda Items

Hi, The KVM/QEMU community call is at: https://meet.jit.si/kvmcallmeeting @ 9/1/2024 14:00 UTC If anyone has any agenda items please reply to this thread. -- Alex Bennée Virtualisation Tech Lead @ Linaro

Re: [PATCH v3 3/6] target/riscv: Add helper functions to calculate current number of masked bits for pointer masking

On Fri, Jan 05, 2024 at 10:33:40AM +0300, Alexey Baturo wrote: I think you're right, thanks. I'll add a check for M-mode as well and I guess I'll have to rename the function. Any ideas on the proper and self-describing name? Since all we care for is whether virtual memory is enabled and in effe

Re: [PATCH v3 5/6] target/riscv: Update address modify functions to take into account pointer masking

On Fri, Jan 05, 2024 at 10:29:35AM +0300, Alexey Baturo wrote: +addr = addr << pmlen; +if (signext) { +addr = (target_long)addr >> pmlen; +} else { +addr = addr >> pmlen; Could you please elaborate a bit more on your concern here? I believe this code works as intended

[PATCH v3 2/4] tests/qtest/migration: Add infrastructure to skip tests on older QEMUs

We can run the migration tests with two different QEMU binaries to test migration compatibility between QEMU versions. This means we'll be running the tests with an older QEMU in either source or destination. We need to avoid trying to test functionality that is unknown to the older QEMU. This cou

[PATCH v3 0/4] migration & CI: Add a CI job for migration compat testing

Here's the second half of adding a migration compatibility test to CI. We've already added support for running the full set of migration tests with two QEMU binaries since commit 5050ad2a380 ("tests/qtest/migration: Support more than one QEMU binary"), now what's left is adding it to the CI. I in

[PATCH v3 3/4] ci: Add a migration compatibility test job

The migration tests have support for being passed two QEMU binaries to test migration compatibility. Add a CI job that builds the lastest release of QEMU and another job that uses that version plus an already present build of the current version and run the migration tests with the two, both as so

[PATCH v3 4/4] [NOT FOR MERGE] tests/qtest/migration: Adapt tests to use older QEMUs

[This patch is not necessary anymore after 8.2 has been released] Add the 'since' annotations to recently added tests and adapt the postcopy test to use the older "uri" API when needed. Signed-off-by: Fabiano Rosas --- tests/qtest/migration-test.c | 34 +++--- 1 file

[PATCH v3 1/4] tests/qtest: Add a helper to query the QEMU version

Reviewed-by: Thomas Huth Signed-off-by: Fabiano Rosas --- tests/qtest/libqtest.h | 10 ++ tests/qtest/libqtest.c | 24 2 files changed, 34 insertions(+) diff --git a/tests/qtest/libqtest.h b/tests/qtest/libqtest.h index 6e3d3525bf..5ec758242b 100644 --- a/tests/

Re: [PATCH v2 2/3] hw/arm/armv7m: alias the NVIC "num-prio-bits" property

Peter Maydell writes: There's a comment in include/hw/arm/armv7m.h which documents all the GPIO inputs, QOM properties, etc, that this device has -- that also needs a line adding to it for this property. Thanks Peter for your review. I'll send a v3 containing the requested change after Inè

Re: [PATCH v2 3/3] hw/arm/socs: configure priority bits for existing SOCs

On Wed, 3 Jan 2024 at 15:53, Samuel Tardieu wrote: > > Update the number of priority bits for a number of existing > SoCs according to their technical documentation: > > - STM32F100/F205/F405/L4x5: 4 bits > - Stellaris (Sandstorm/Fury): 3 bits > > Signed-off-by: Samuel Tardieu Reviewed-by: Peter

Re: [PATCH] docs: use "buses" rather than "busses"

On Wed, 3 Jan 2024 at 17:28, Samuel Tardieu wrote: > > If "busses" might be encountered as a plural of "bus" (5 instances), > the correct spelling is "buses" (26 instances). Fixing those 5 > instances makes the doc more consistent. > > Signed-off-by: Samuel Tardieu Applied to target-arm.next, th

Re: [PATCH v2 2/3] hw/arm/armv7m: alias the NVIC "num-prio-bits" property

On Wed, 3 Jan 2024 at 15:53, Samuel Tardieu wrote: > > A SoC will not have a direct access to the NVIC embedded in its ARM > core. By aliasing the "num-prio-bits" property similarly to what is > done for the "num-irq" one, a SoC can easily configure it on its > armv7m instance. > > Signed-off-by:

Re: [PATCH v2 1/3] hw/intc/armv7m_nvic: add "num-prio-bits" property

On Wed, 3 Jan 2024 at 15:53, Samuel Tardieu wrote: > > Cortex-M NVIC can have a different number of priority bits. > Cortex-M0/M0+/M1 devices must use 2 or more bits, while devices based > on ARMv7m and up must use 3 or more bits. > > This adds a "num-prio-bits" property which will get sensible de

Re: [PATCH] arm_gic: Implement GICC_AIAR, GICC_AEOIR and GICC_AHPPIR

On Wed, 20 Dec 2023 at 06:47, Andrei Homescu wrote: > > From: Arve Hjønnevåg > > Implement aliased registers so group 1 interrupts can be used in secure > mode. Hi; thanks for this patch. > GICC_AEOIR is only implemented as a direct alias to GICC_EOIR for now as > gic_complete_irq does not curr

Re: [PATCH-for-9.0 03/25] memory: Have memory_region_init_rom_nomigrate() handler return a boolean

Hi Peter, On 5/1/24 15:57, Peter Maydell wrote: On Fri, 5 Jan 2024 at 14:46, Philippe Mathieu-Daudé wrote: On 21/11/23 13:10, Manos Pitsidianakis wrote: On Mon, 20 Nov 2023 23:32, Philippe Mathieu-Daudé wrote: Following the example documented since commit e3fe3988d7 ("error: Document Error

Re: [PULL 00/71] HW core patches for 2024-01-05

github.com/philmd/qemu.git tags/hw-cpus-20240105 for you to fetch changes up to a318da6b3f6a88e6cfd6953c519def9457e8962f: target/sparc: Simplify qemu_irq_ack (2024-01-05 16:20:15 +0100) HW core patch queue - Unify CPU QOM type che

Re: Question about CXL emulation in QEMU

"周童" <273415...@qq.com> writes: > Dear Experts, (add maintainers to CC) > > I am writing to seek your assistance about CXL emulation in QEMU. I am Zhou > Tong and I am researching how to use QEMU > to simulate CXL over Ethernet。 > > I want to implement remote registration of CXL.mem devices bas

Re: [PATCH] i386/sev: Nitpick at the error message's output

Hyman Huang writes: > The incorrect error message was produced as a result of > the return number being disregarded on the sev_kvm_init > failure path. > > For instance, when a user's failure to launch a SEV guest > is caused by an incorrect IOCTL, the following message is > reported: > > kvm: se

Re: [PATCH] hw/arm: add cache controller for Freescale i.MX6

On Tue, 19 Dec 2023 at 10:55, Nikita Ostrenkov wrote: > > Signed-off-by: Nikita Ostrenkov > --- > hw/arm/Kconfig| 1 + > hw/arm/fsl-imx6.c | 3 +++ > 2 files changed, 4 insertions(+) > Applied to target-arm.next, thanks. -- PMM

Re: [PATCH] i386/sev: Nitpick at the error message's output

On Sat, Jan 06, 2024 at 12:09:55AM +0800, Hyman Huang wrote: > The incorrect error message was produced as a result of > the return number being disregarded on the sev_kvm_init > failure path. > > For instance, when a user's failure to launch a SEV guest > is caused by an incorrect IOCTL, the foll

Re: [PATCH v6 02/11] virtio-gpu: Configure new feature flag context_create_with_flags for virglrenderer

Huang Rui writes: > Configure a new feature flag (context_create_with_flags) for > virglrenderer. > > Originally-by: Antonio Caggiano > Signed-off-by: Huang Rui Reviewed-by: Alex Bennée -- Alex Bennée Virtualisation Tech Lead @ Linaro

[PATCH] i386/sev: Nitpick at the error message's output

The incorrect error message was produced as a result of the return number being disregarded on the sev_kvm_init failure path. For instance, when a user's failure to launch a SEV guest is caused by an incorrect IOCTL, the following message is reported: kvm: sev_kvm_init: failed to initialize ret=-

Re: [PATCH v6 11/11] virtio-gpu: make blob scanout use dmabuf fd

Alex Bennée writes: > Huang Rui writes: > >> From: Robert Beckett >> >> This relies on a virglrenderer change to include the dmabuf fd when >> returning resource info. >> > >> +static void virgl_cmd_set_scanout_blob(VirtIOGPU *g, >> + struct virtio_gpu_ctr

Re: [PULL 00/26] Migration 20240104 patches

On Thu, 4 Jan 2024 at 04:33, wrote: > > From: Peter Xu > > The following changes since commit 7425b6277f12e82952cede1f531bfc689bf77fb1: > > Merge tag 'tracing-pull-request' of https://gitlab.com/stefanha/qemu into > staging (2023-12-27 05:15:32 -0500) > > are available in the Git repository at

[PULL 63/71] hw: Simplify memory_region_init_ram() calls

Mechanical change using the following coccinelle script: @@ expression mr, owner, arg3, arg4, errp; @@ - memory_region_init_ram(mr, owner, arg3, arg4, &errp); if ( - errp + !memory_region_init_ram(mr, owner, arg3, arg4, &errp) ) { ... return; } and removi

[PULL 45/71] memory: Have memory_region_init_ram_nomigrate() handler return a boolean

Following the example documented since commit e3fe3988d7 ("error: Document Error API usage rules"), have memory_region_init_ram_nomigrate return a boolean indicating whether an error is set or not. Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Manos Pitsidianakis Reviewed-by: Peter Xu Revi

[PULL 62/71] misc: Simplify qemu_prealloc_mem() calls

Since qemu_prealloc_mem() returns whether or not an error occured, we don't need to check the @errp pointer. Remove local_err uses when we can return directly. Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Manos Pitsidianakis Reviewed-by: Gavin Shan Message-Id: <20231120213301.24349-20-phi

[PULL 52/71] memory: Simplify memory_region_init_rom_device_nomigrate() calls

Mechanical change using the following coccinelle script: @@ expression mr, owner, arg3, arg4, arg5, arg6, errp; @@ - memory_region_init_rom_device_nomigrate(mr, owner, arg3, arg4, arg5, arg6, &errp); if ( - errp + !memory_region_init_rom_device_nomigrate(mr, owner, arg3, arg4, a

[PULL 16/71] target/openrisc: Use generic cpu_list()

From: Gavin Shan Before it's applied: [gshan@gshan q]$ ./build/qemu-or1k -cpu ? Available CPUs: or1200 any After it's applied: [gshan@gshan q]$ ./build/qemu-or1k -cpu ? Available CPUs: any or1200 Signed-off-by: Gavin Shan Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Richard Hend

[PULL 61/71] util/oslib: Have qemu_prealloc_mem() handler return a boolean

Following the example documented since commit e3fe3988d7 ("error: Document Error API usage rules"), have qemu_prealloc_mem() return a boolean indicating whether an error is set or not. Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Peter Xu Reviewed-by: Gavin Shan Message-Id: <2023112021330

[PULL 67/71] hw/nvram: Simplify memory_region_init_rom_device() calls

Mechanical change using the following coccinelle script: @@ expression mr, owner, arg3, arg4, arg5, arg6, errp; @@ - memory_region_init_rom_device(mr, owner, arg3, arg4, arg5, arg6, &errp); if ( - errp + !memory_region_init_rom_device(mr, owner, arg3, arg4, arg5, arg6, &errp)

[PULL 60/71] backends: Reduce variable scope in host_memory_backend_memory_complete

Reduce the &local_err variable use and remove the 'out:' label. Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Manos Pitsidianakis Reviewed-by: Gavin Shan Message-Id: <20231120213301.24349-18-phi...@linaro.org> --- backends/hostmem.c | 8 1 file changed, 4 insertions(+), 4 deletio

[PULL 39/71] hw/arm/bcm2836: Use ARM_CPU 'mp-affinity' property

The 'mp-affinity' property is present since commit 15a21fe028 ("target-arm: Add mp-affinity property for ARM CPU class"). Use it and remove a /* TODO */ comment. Since all ARM CPUs have this property, use &error_abort, because this call can not fail. Signed-off-by: Philippe Mathieu-Daudé Reviewed

[PULL 38/71] hw/arm/bcm2836: Simplify use of 'reset-cbar' property

bcm2836_realize() is called by - bcm2836_class_init() which sets: bc->cpu_type = ARM_CPU_TYPE_NAME("cortex-a7") - bcm2837_class_init() which sets: bc->cpu_type = ARM_CPU_TYPE_NAME("cortex-a53") Both Cortex-A7 / A53 have the ARM_FEATURE_CBAR set. If it isn't, then this is a programmin

[PULL 70/71] hw/net/can/sja1000: fix bug for single acceptance filter and standard frame

From: Pavel Pisa A CAN sja1000 standard frame filter mask has been computed and applied incorrectly for standard frames when single Acceptance Filter Mode (MOD_AFM = 1) has been selected. The problem has not been found by Linux kernel testing because it uses dual filter mode (MOD_AFM = 0) and lea

[PULL 51/71] memory: Have memory_region_init_rom_device_nomigrate() return a boolean

Following the example documented since commit e3fe3988d7 ("error: Document Error API usage rules"), have memory_region_init_rom_device_nomigrate() return a boolean indicating whether an error is set or not. Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Peter Xu Reviewed-by: Gavin Shan Mess

[PULL 65/71] hw/sparc: Simplify memory_region_init_ram_nomigrate() calls

Mechanical change using the following coccinelle script: @@ expression mr, owner, arg3, arg4, errp; @@ - memory_region_init_ram_nomigrate(mr, owner, arg3, arg4, &errp); if ( - errp + !memory_region_init_ram_nomigrate(mr, owner, arg3, arg4, &errp) ) { ... retur

[PULL 66/71] hw/misc: Simplify memory_region_init_ram_from_fd() calls

Mechanical change using the following coccinelle script: @@ expression mr, owner, arg3, arg4, arg5, arg6, arg7, errp; @@ - memory_region_init_ram_from_fd(mr, owner, arg3, arg4, arg5, arg6, arg7, &errp); if ( - errp + !memory_region_init_ram_from_fd(mr, owner, arg3, arg4, arg5, a

[PULL 14/71] target/m68k: Use generic cpu_list()

From: Gavin Shan Before it's applied: [gshan@gshan q]$ ./build/qemu-system-m68k -cpu ? cfv4e m5206 m5208 m68000 m68010 m68020 m68030 m68040 m68060 any After it's applied: [gshan@gshan q]$ ./build/qemu-system-m68k -cpu ? Available CPUs: any cfv4e m5206 m5208 m68000 m68010 m68020

[PULL 23/71] hw/core: Add machine_class_default_cpu_type()

Add a helper to return a machine default CPU type. If this machine is restricted to a single CPU type, use it as default, obviously. Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Richard Henderson Message-Id: <20231116163726.28952-1-phi...@linaro.org> --- include/hw/boards.h | 6 ++ h

[PULL 44/71] memory: Have memory_region_init_ram_flags_nomigrate() return a boolean

Following the example documented since commit e3fe3988d7 ("error: Document Error API usage rules"), have memory_region_init_ram_nomigrate return a boolean indicating whether an error is set or not. Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Manos Pitsidianakis Reviewed-by: Peter Xu Revi

[PULL 25/71] machine: Introduce helper is_cpu_type_supported()

From: Gavin Shan The logic, to check if the specified CPU type is supported in machine_run_board_init(), is independent enough. Factor it out into helper is_cpu_type_supported(). machine_run_board_init() looks a bit clean with this. Since we're here, @machine_class is renamed to @mc to avoid mult

[PULL 50/71] memory: Have memory_region_init_rom() handler return a boolean

Following the example documented since commit e3fe3988d7 ("error: Document Error API usage rules"), have memory_region_init_rom() return a boolean indicating whether an error is set or not. Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Manos Pitsidianakis Reviewed-by: Gavin Shan Message-Id

[PULL 68/71] hw/pci-host/raven: Propagate error in raven_realize()

When an Error** reference is available, it is better to propagate local errors, rather then using generic ones, which might terminate the whole QEMU process. Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Manos Pitsidianakis Reviewed-by: Gavin Shan Message-Id: <20231120213301.24349-26-phi..

[PULL 17/71] target/riscv: Use generic cpu_list()

From: Gavin Shan Before it's applied: [gshan@gshan q]$ ./build/qemu-system-riscv64 -cpu ? any max rv64 shakti-c sifive-e51 sifive-u54 thead-c906 veyron-v1 x-rv128 After it's applied: [gshan@gshan q]$ ./build/qemu-system-riscv64 -cpu ? Available CPUs: any max rv64 shakti-c sifive-e51

[PULL 41/71] hw: Simplify accesses to the CPUState::'start-powered-off' property

The 'start-powered-off' property has been added to ARM CPUs in commit 5de164304a ("arm: Allow secondary KVM CPUs to be booted via PSCI"), then eventually got generalized to all CPUs in commit c1b701587e ("target/arm: Move start-powered-off property to generic CPUState"). Since all CPUs have it, no

[PULL 35/71] hw/cpu/core: Cleanup unused included header in core.c

From: Zhao Liu Remove unused header (qemu/module.h and sysemu/cpus.h) in core.c, and reorder the remaining header files (except qemu/osdep.h) in alphabetical order. Tested by "./configure" and then "make". Signed-off-by: Zhao Liu Reviewed-by: Philippe Mathieu-Daudé Message-ID: <20231127145611

[PULL 48/71] memory: Simplify memory_region_init_ram_from_fd() calls

Mechanical change using the following coccinelle script: @@ expression mr, owner, arg3, arg4, arg5, arg6, arg7, errp; @@ - memory_region_init_ram_from_fd(mr, owner, arg3, arg4, arg5, arg6, arg7, &errp); if ( - errp + !memory_region_init_ram_from_fd(mr, owner, arg3, arg4, arg5, a

  1   2   3   >