object_new() cannot fail, and that's fundamental (was: [PATCH v2 1/2] qom/object, qdev: move globals functions to object.c)

Daniel P. Berrangé writes: > CC: Markus since he's had opinions on stuff related to -global in > the past. > > On Wed, Jul 03, 2024 at 05:41:48PM -0300, Daniel Henrique Barboza wrote: >> Next patch will add Accel globals support. This means that globals won't be >> qdev exclusive logic since it'

RE: [PATCH] hw/arm/mps2-tz.c: fix RX/TX interrupts order

Thanks Peter for your time! Marco Palumbi Senior Cryptography Engineer PO Box: 9639 Masdar City, Abu Dhabi, UAE M: +39 349 786 0737 E: marco.palu...@tii.ae  tii.ae This email and any files transmitted with it are strictly confidential and intended solely for the use of the individual or enti

Re: [PATCH RFC v4 0/7] virtio-net: add support for SR-IOV emulation

On Thu, Aug 01, 2024 at 02:37:55PM +0900, Akihiko Odaki wrote: > I don't know much about vDPA-capable device, but as a reference, igb only > has 8 VFs. modern vdpa capable devices have much more than 8 VFs, 8 is a very low number. -- MST

Re: [PATCH v2 4/4] virtio-net: Add support for USO features

On Wed, Jul 31, 2024 at 08:57:52AM -0400, Peter Xu wrote: > Could you elaborate why it would fail if with what I proposed? First I think I was wrong I misunderstood what you said. To summarise, you said: - any new feature depending on another package is off by default - starting qemu on destinati

Re: [PATCH v2 4/4] virtio-net: Add support for USO features

On Fri, Jul 26, 2024 at 07:39:46PM +0200, Thomas Huth wrote: > Anyway, while we're discussing solutions: We are in softfreeze already. > Should we disable the UFO bits in the new 9.1 machine type for the time > being to avoid that more people are running into this problem? At the moment I'm lookin

Re: [PATCH v2 4/4] virtio-net: Add support for USO features

On Tue, Jul 30, 2024 at 02:02:27AM +0900, Akihiko Odaki wrote: > I think it is simpler to analyze the platform dependency and dump it for the > management layer. For example, libvirt can request QEMU to analyze the > platform dependency when it creates a new domain. QEMU will then figure out > that

Re: [PATCH RFC v4 0/7] virtio-net: add support for SR-IOV emulation

On 2024/07/31 18:34, Yui Washizu wrote: On 2024/07/15 14:15, Akihiko Odaki wrote: On 2024/05/16 11:00, Yui Washizu wrote: On 2024/04/28 18:05, Akihiko Odaki wrote: Based-on: <20240315-reuse-v9-0-67aa69af4...@daynix.com> ("[PATCH for 9.1 v9 00/11] hw/pci: SR-IOV related fixes and improvement

Re: [PATCH v2 4/4] virtio-net: Add support for USO features

On Wed, Jul 31, 2024 at 08:57:52AM -0400, Peter Xu wrote: > > > > The right solution is to have a tool that can query > > backends, and that given the results from all of the cluster, > > generate a set of parameters that will ensure migration works. > > Kind of like qemu-img, but for migration. >

Re: [PATCH v2 4/4] virtio-net: Add support for USO features

On 2024/08/01 11:28, Jason Wang wrote: On Wed, Jul 31, 2024 at 8:58 PM Peter Xu wrote: On Wed, Jul 31, 2024 at 03:41:00AM -0400, Michael S. Tsirkin wrote: On Wed, Jul 31, 2024 at 08:04:24AM +0100, Daniel P. Berrangé wrote: On Tue, Jul 30, 2024 at 05:32:48PM -0400, Michael S. Tsirkin wrote:

Re: [RFC PATCH] Makefile: trigger re-configure on updated pythondeps

On 31/7/24 16:02, Alex Bennée wrote: If we add additional deps for meson we need to ensure we trigger a reconfigure to make sure everything is set up. Signed-off-by: Alex Bennée --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 02a2575

Re: [PATCH v2 4/4] virtio-net: Add support for USO features

On 2024/07/31 4:11, Peter Xu wrote: On Tue, Jul 30, 2024 at 07:46:12PM +0100, Daniel P. Berrangé wrote: On Tue, Jul 30, 2024 at 02:13:51PM -0400, Peter Xu wrote: On Mon, Jul 29, 2024 at 06:26:41PM +0100, Daniel P. Berrangé wrote: On Mon, Jul 29, 2024 at 01:00:30PM -0400, Peter Xu wrote: On Mo

Re: [PATCH 10/13] tests/avocado/tuxrun_baselines.py: use Avocado's zstd support

On Mon, Jul 29, 2024 at 10:39 AM Philippe Mathieu-Daudé wrote: > > On 26/7/24 15:44, Cleber Rosa wrote: > > Signed-off-by: Cleber Rosa > > --- > > tests/avocado/tuxrun_baselines.py | 16 ++-- > > 1 file changed, 6 insertions(+), 10 deletions(-) > > > > diff --git a/tests/avocado/tu

Re: [PATCH 06/10] tests/avocado/kvm_xen_guest.py: cope with asset RW requirements

On Mon, Dec 11, 2023 at 11:32 AM Philippe Mathieu-Daudé wrote: > > On 8/12/23 20:09, Cleber Rosa wrote: > > Some of these tests actually require the root filesystem image, > > obtained through Avocado's asset feature and kept in a common cache > > location, to be writable. > > > > This makes a dis

Re: [PATCH 09/13] tests/avocado/boot_xen.py: fetch kernel during test setUp()

On Mon, Jul 29, 2024 at 7:01 AM Daniel P. Berrangé wrote: > > On Fri, Jul 26, 2024 at 09:44:34AM -0400, Cleber Rosa wrote: > > The kernel is a common blob used in all tests. By moving it to the > > setUp() method, the "fetch asset" plugin will recognize the kernel and > > attempt to fetch it and

Re: [PATCH 06/13] tests/avocado: use more distinct names for assets

On Mon, Jul 29, 2024 at 7:54 AM Philippe Mathieu-Daudé wrote: > > On 29/7/24 12:49, Daniel P. Berrangé wrote: > > On Fri, Jul 26, 2024 at 09:44:31AM -0400, Cleber Rosa wrote: > >> Avocado's asset system will deposit files in a cache organized either > >> by their original location (the URI) or by

Re: [PATCH 06/13] tests/avocado: use more distinct names for assets

On Mon, Jul 29, 2024 at 6:49 AM Daniel P. Berrangé wrote: > > On Fri, Jul 26, 2024 at 09:44:31AM -0400, Cleber Rosa wrote: > > Avocado's asset system will deposit files in a cache organized either > > by their original location (the URI) or by their names. Because the > > cache (and the "by_name"

Re: [PATCH v2 4/4] virtio-net: Add support for USO features

On Wed, Jul 31, 2024 at 8:58 PM Peter Xu wrote: > > On Wed, Jul 31, 2024 at 03:41:00AM -0400, Michael S. Tsirkin wrote: > > On Wed, Jul 31, 2024 at 08:04:24AM +0100, Daniel P. Berrangé wrote: > > > On Tue, Jul 30, 2024 at 05:32:48PM -0400, Michael S. Tsirkin wrote: > > > > On Tue, Jul 30, 2024 at

Re: [PATCH 03/13] tests/avocado/intel_iommu.py: increase timeout

On Mon, Jul 29, 2024 at 6:30 AM Daniel P. Berrangé wrote: > > On Fri, Jul 26, 2024 at 09:44:28AM -0400, Cleber Rosa wrote: > > Based on many runs, the average run time for these 4 tests is around > > 250 seconds, with 320 seconds being the ceiling. In any way, the > > default 120 seconds timeout

[ANNOUNCE] QEMU 9.1.0-rc0 is now available

Hello, On behalf of the QEMU Team, I'd like to announce the availability of the first release candidate for the QEMU 9.1 release. This release is meant for testing purposes and should not be used in a production environment. http://download.qemu.org/qemu-9.1.0-rc0.tar.xz http://download.qemu.

Re: [PATCH 12/13] Bump avocado to 103.0

On 7/29/24 8:02 AM, Philippe Mathieu-Daudé wrote: Does that restore feature parity for macOS developers? Because this community has been left behind ignored for over 2 years and already looked at alternatives for functional testing. Hi Phillipe, As early as Avocado 102.0,  macOS support is

Re: [RFC 0/2] Identify aliased maps in vdpa SVQ iova_tree

Hi Jonah, On 7/31/2024 7:09 AM, Jonah Palmer wrote: Let me clarify, correct me if I was wrong: 1) IOVA allocator is still implemented via a tree, we just don't need to store how the IOVA is used 2) A dedicated GPA -> IOVA tree, updated via listeners and is used in the datapath SVQ transla

Re: [PULL 00/10] i386, tests/vm changes for QEMU 9.1-rc

On 7/31/24 21:17, Paolo Bonzini wrote: The following changes since commit 4e56e89d6c81589cc47cf5811f570c67889bd18a: Update version for v9.1.0-rc0 release (2024-07-31 16:21:21 +1000) are available in the Git repository at: https://gitlab.com/bonzini/qemu.git tags/for-upstream for you to

Re: [PATCH] bsd-user/x86_64/target_arch_thread.h: Align stack

On Wed, Jul 31, 2024 at 5:03 PM Warner Losh wrote: > Hmmm... All platforms likely need this > Oh, they all have it except x86, both 32 and 64-bit but i386 is > already properly aligned (at least in the > FreeBSD kernel), so maybe that's not needed. > > > On Wed, Jul 31, 2024 at 4:43 PM Ri

Re: [PATCH] bsd-user/main: Allow setting tb-size

On Wed, Jul 31, 2024 at 3:42 PM Philippe Mathieu-Daudé wrote: > On 31/7/24 23:21, Warner Losh wrote: > > On Wed, Jul 31, 2024 at 8:45 AM Ilya Leoshkevich > > wrote: > > > > While qemu-system can set tb-size using -accel tcg,tb-size=n, there > > is no similar kn

Re: [PATCH] bsd-user/x86_64/target_arch_thread.h: Align stack

Hmmm... All platforms likely need this Oh, they all have it except x86, both 32 and 64-bit but i386 is already properly aligned (at least in the FreeBSD kernel), so maybe that's not needed. On Wed, Jul 31, 2024 at 4:43 PM Richard Henderson < richard.hender...@linaro.org> wrote: > On 8/1/

Re: [PATCH v3 16/24] tests/functional: Convert the riscv_opensbi avocado test into a standalone test

On 7/31/24 22:56, Philippe Mathieu-Daudé wrote: On 30/7/24 19:03, Daniel P. Berrangé wrote: From: Thomas Huth The avocado test defined test functions for both, riscv32 and riscv64. Since we can run the whole file with multiple targets in the new framework, we can now consolidate the functions

Re: [PATCH] bsd-user/x86_64/target_arch_thread.h: Align stack

On 8/1/24 00:44, Ilya Leoshkevich wrote: bsd-user qemu-x86_64 almost immediately dies with: qemu: 0x4002201a68: unhandled CPU exception 0xd - aborting on FreeBSD 14.1-RELEASE. This is an instruction that requires alignment: (gdb) x/i 0x4002201a68 0x4002201a68:movaps %

Re: [RFC PATCH] Makefile: trigger re-configure on updated pythondeps

On 8/1/24 00:02, Alex Bennée wrote: If we add additional deps for meson we need to ensure we trigger a reconfigure to make sure everything is set up. Signed-off-by: Alex Bennée --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 02a25758

Re: [PATCH] target/ppc: Set ctx->opcode for decode_insn32()

On 7/31/24 20:07, Ilya Leoshkevich wrote: divdu (without a dot) sometimes updates cr0, even though it shouldn't. The reason is that gen_op_arith_divd() checks Rc(ctx->opcode), which is not initialized. This field is initialized only for instructions that go through decode_legacy(), and not decode

Re: [PATCH v7 4/5] qemu/osdep: Add excluded fd parameter to qemu_close_all_open_fd()

On 7/31/24 18:48, Clément Léger wrote: @@ -823,8 +824,34 @@ static bool qemu_close_all_open_fd_proc(void) dfd = dirfd(dir); for (de = readdir(dir); de; de = readdir(dir)) { +bool close_fd = true; + +if (de->d_name[0] == '.') { +continue; +}

Re: [PATCH v7 2/5] qemu/osdep: Split qemu_close_all_open_fd() and add fallback

On 7/31/24 18:48, Clément Léger wrote: In order to make it cleaner, split qemu_close_all_open_fd() logic into multiple subfunctions (close with close_range(), with /proc/self/fd and fallback). Signed-off-by: Clément Léger --- util/oslib-posix.c | 50 ++--

Re: [PATCH] bsd-user/main: Allow setting tb-size

On 31/7/24 23:21, Warner Losh wrote: On Wed, Jul 31, 2024 at 8:45 AM Ilya Leoshkevich > wrote: While qemu-system can set tb-size using -accel tcg,tb-size=n, there is no similar knob for qemu-bsd-user. Add one in a way similar to how one-insn-per-tb is alrea

Re: [PATCH] MAINTAINERS: Add my hexagon git tree

On 31/7/24 22:39, Brian Cain wrote: Add my git tree for hexagon. Note that the branch is "hex-next" and not "hex.next" as had been used previously. But I'll keep the "hex.next" branch in sync with "hex-next" until this commit lands to avoid confusion. Signed-off-by: Brian Cain --- MAINTAINE

[PATCH-for-9.1? v2 2/4] hw/sd/sdhci: Reduce variables scope in get_adma_description()

The 'adma1' variable is only used in the SDHC_CTRL_ADMA1_32 case, and 'adma2' in SDHC_CTRL_ADMA2_32. Add braces in the switch case to use local declarations. Do the same in the SDHC_CTRL_ADMA2_64 case because we'll add a local variable there in the next commit. Replace 0xF000 -> ~0xfff to alig

[PATCH-for-9.1? v2 3/4] hw/sd/sdhci: Read ADMA2_64 descriptor with a single dma_memory_read()

Instead of 3 consecutive dma_memory_read() calls, use a packed structure to read the descriptor in a single call. Signed-off-by: Philippe Mathieu-Daudé --- hw/sd/sdhci.c | 22 +- 1 file changed, 13 insertions(+), 9 deletions(-) diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c inde

[PATCH-for-9.1? v2 1/4] hw/sd/sdhci: Reduce variables scope in sdhci_do_adma()

All variables are only used within the for loop. Declare them within it. In particular this resets 'dscr' on each iteration. Signed-off-by: Philippe Mathieu-Daudé --- hw/sd/sdhci.c | 15 +++ 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c i

[PATCH-for-9.1? v2 0/4] hw/sd/sdhci: Check ADMA descriptors can be accessed

Since v1: - split patch - do not return MemTxResult from get_adma_description() - single DMA read in SDHC_CTRL_ADMA2_64 case Based-on: <20240730092138.32443-5-phi...@linaro.org> Philippe Mathieu-Daudé (4): hw/sd/sdhci: Reduce variables scope in sdhci_do_adma() hw/sd/sdhci: Reduce variables sc

[PATCH-for-9.1? v2 4/4] hw/sd/sdhci: Check ADMA descriptors can be accessed

Since malicious guest can write invalid addresses to the ADMASYSADDR register, we need to check whether the descriptor could be correctly filled or not. Cc: qemu-sta...@nongnu.org Fixes: d7dfca0807 ("hw/sdhci: introduce standard SD host controller") Signed-off-by: Philippe Mathieu-Daudé --- hw/s

Re: [PATCH] bsd-user/main: Allow setting tb-size

On Wed, Jul 31, 2024 at 8:45 AM Ilya Leoshkevich wrote: > While qemu-system can set tb-size using -accel tcg,tb-size=n, there > is no similar knob for qemu-bsd-user. Add one in a way similar to how > one-insn-per-tb is already handled. > Cool! Are you using bsd-user and need this for some reason

Re: [PATCH v2] hw/acpi: Add vmclock device

On Wed, Jul 31, 2024 at 01:23:49AM +0100, David Woodhouse wrote: > On 30 July 2024 21:45:53 BST, "Michael S. Tsirkin" wrote: > >On Tue, Jul 30, 2024 at 08:04:17PM +0100, David Woodhouse wrote: > >> On 30 July 2024 18:53:18 BST, "Michael S. Tsirkin" wrote: > >> >We don't want to manually sync head

Re: [PATCH] target/xtensa: Correct assert condition in handle_interrupt()

On 31/7/24 19:22, Peter Maydell wrote: In commit ad18376b90c8101 we added an assert that the level value was in-bounds for the array we're about to index into. However, the assert condition is wrong -- env->config->interrupt_vector is an array of uint32_t, so we should bounds check the index aga

Re: [PATCH] hw/i386/amd_iommu: Don't leak memory in amdvi_update_iotlb()

On 31/7/24 19:00, Peter Maydell wrote: In amdvi_update_iotlb() we will only put a new entry in the hash table if to_cache.perm is not IOMMU_NONE. However we allocate the memory for the new AMDVIIOTLBEntry and for the hash table key regardless. This means that in the IOMMU_NONE case we will leak

Re: [PATCH 6/7] hw/ide/pci.c: Remove dead code from bmdma_prepare_buf()

On 31/7/24 17:13, Kevin Wolf wrote: Am 31.07.2024 um 16:36 hat Peter Maydell geschrieben: Coverity notes that the code at the end of the loop in bmdma_prepare_buf() is unreachable. This is because in commit 9fbf0fa81fca8f527 ("ide: remove hardcoded 2GiB transactional limit") we removed the only

Re: [PATCH 5/7] hw/block/fdc-isa: Assert that isa_fdc_get_drive_max_chs() found something

On 31/7/24 16:36, Peter Maydell wrote: Coverity complains about an overflow in isa_fdc_get_drive_max_chs() that can happen if the loop over fd_formats never finds a match, because we initialize *maxc to 0 and then at the end of the function decrement it. This can't ever actually happen because f

Re: [PATCH 2/7] block/gluster: Use g_autofree for string in qemu_gluster_parse_json()

On 31/7/24 16:36, Peter Maydell wrote: In the loop in qemu_gluster_parse_json() we do: char *str = NULL; for(...) { str = g_strdup_printf(...); ... if (various errors) { goto out; } ... g_free(str); str = NULL;

Re: [PATCH] bsd-user/main: Allow setting tb-size

On 31/7/24 16:45, Ilya Leoshkevich wrote: While qemu-system can set tb-size using -accel tcg,tb-size=n, there is no similar knob for qemu-bsd-user. Add one in a way similar to how one-insn-per-tb is already handled. Suggested-by: Philippe Mathieu-Daudé Signed-off-by: Ilya Leoshkevich --- bsd

[PATCH] MAINTAINERS: Add my hexagon git tree

Add my git tree for hexagon. Note that the branch is "hex-next" and not "hex.next" as had been used previously. But I'll keep the "hex.next" branch in sync with "hex-next" until this commit lands to avoid confusion. Signed-off-by: Brian Cain --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+

[PATCH] hw/ppc: Implement -dtb support for PowerNV

Currently any device tree passed with -dtb option in QEMU, was ignored by the PowerNV code. Read and pass the passed -dtb to the kernel, thus enabling easier debugging with custom DTBs. The existing behaviour when -dtb is 'not' passed, is preserved as-is. But when a '-dtb' is passed, it complete

Re: [PATCH v5 13/13] docs/specs: add riscv-iommu

On 7/19/24 6:34 AM, Alistair Francis wrote: On Tue, Jul 9, 2024 at 3:37 AM Daniel Henrique Barboza wrote: Add a simple guideline to use the existing RISC-V IOMMU support we just added. This doc will be updated once we add the riscv-iommu-sys device. Signed-off-by: Daniel Henrique Barboza

Re: [RFC PATCH] hw/ppc: Implement -dtb support for PowerNV

Hi Cedric, On 24/07/31 04:43PM, Cédric Le Goater wrote: > Hello Aditya, > > On 7/31/24 15:22, Aditya Gupta wrote: > > Currently any device tree passed with -dtb option in QEMU, was ignored > > by the PowerNV code. > > > > Read and pass the passed -dtb to the kernel, thus enabling easier > > debu

Re: [PATCH] target/xtensa: Correct assert condition in handle_interrupt()

On Wed, Jul 31, 2024 at 10:22 AM Peter Maydell wrote: > > In commit ad18376b90c8101 we added an assert that the level value was > in-bounds for the array we're about to index into. However, the > assert condition is wrong -- env->config->interrupt_vector is an > array of uint32_t, so we should bo

[PATCH] target/xtensa: Correct assert condition in handle_interrupt()

In commit ad18376b90c8101 we added an assert that the level value was in-bounds for the array we're about to index into. However, the assert condition is wrong -- env->config->interrupt_vector is an array of uint32_t, so we should bounds check the index against ARRAY_SIZE(...), not against sizeof(

Re: [PATCH v5 11/13] hw/riscv/riscv-iommu: Add another irq for mrif notifications

On 7/31/24 1:50 PM, Andrew Jones wrote: On Wed, Jul 31, 2024 at 01:27:09PM GMT, Daniel Henrique Barboza wrote: Hi Jason, On 7/23/24 12:25 PM, Jason Chien wrote: Hi Daniel, On 2024/7/9 上午 01:34, Daniel Henrique Barboza wrote: From: Andrew Jones And add mrif notification trace. Signed-o

Re: [PATCH] target/hexagon/idef-parser: Remove self-assignment

On 7/31/2024 12:07 PM, Peter Maydell wrote: On Thu, 13 Jul 2023 at 17:21, Brian Cain wrote: -Original Message- From: Anton Johansson Sent: Thursday, July 13, 2023 7:09 AM To: qemu-devel@nongnu.org Cc: Brian Cain ; peter.mayd...@linaro.org Subject: [PATCH] target/hexagon/idef-parse

Re: [PATCH] target/hexagon/idef-parser: Remove self-assignment

On Thu, 13 Jul 2023 at 17:21, Brian Cain wrote: > > > > > -Original Message- > > From: Anton Johansson > > Sent: Thursday, July 13, 2023 7:09 AM > > To: qemu-devel@nongnu.org > > Cc: Brian Cain ; peter.mayd...@linaro.org > > Subject: [PATCH] target/hexagon/idef-parser: Remove self-assignm

[PATCH] hw/i386/amd_iommu: Don't leak memory in amdvi_update_iotlb()

In amdvi_update_iotlb() we will only put a new entry in the hash table if to_cache.perm is not IOMMU_NONE. However we allocate the memory for the new AMDVIIOTLBEntry and for the hash table key regardless. This means that in the IOMMU_NONE case we will leak the memory we alloacted. Move the alloc

Re: [PATCH v5 11/13] hw/riscv/riscv-iommu: Add another irq for mrif notifications

On Wed, Jul 31, 2024 at 01:27:09PM GMT, Daniel Henrique Barboza wrote: > Hi Jason, > > > On 7/23/24 12:25 PM, Jason Chien wrote: > > Hi Daniel, > > > > On 2024/7/9 上午 01:34, Daniel Henrique Barboza wrote: > > > From: Andrew Jones > > > > > > And add mrif notification trace. > > > > > > Signed

Re: [PATCH-for-9.1 5/5] hw/sd/sdhci: Check ADMA descriptors can be accessed

On 30/7/24 11:21, Philippe Mathieu-Daudé wrote: Since malicious guest can write invalid addresses to the ADMASYSADDR register, we need to check whether the descriptor could be correctly filled or not. Cc: qemu-sta...@nongnu.org Fixes: d7dfca0807 ("hw/sdhci: introduce standard SD host controller"

RE: [PATCH] target/hexagon: switch to dc set_props() list

> -Original Message- > From: Brian Cain > Sent: Tuesday, July 30, 2024 7:13 PM > To: qemu-devel@nongnu.org > Cc: bc...@quicinc.com; quic_mathb...@quicinc.com; > sidn...@quicinc.com; quic_mlie...@quicinc.com; > ltaylorsimp...@gmail.com > Subject: [PATCH] target/hexagon: switch to dc set_

RE: [PATCH] target/hexagon: define a v66 CPU

> -Original Message- > From: Brian Cain > Sent: Tuesday, July 30, 2024 7:10 PM > To: qemu-devel@nongnu.org > Cc: bc...@quicinc.com; quic_mathb...@quicinc.com; > sidn...@quicinc.com; quic_mlie...@quicinc.com; > ltaylorsimp...@gmail.com > Subject: [PATCH] target/hexagon: define a v66 CPU

Re: [PATCH v5 11/13] hw/riscv/riscv-iommu: Add another irq for mrif notifications

Hi Jason, On 7/23/24 12:25 PM, Jason Chien wrote: Hi Daniel, On 2024/7/9 上午 01:34, Daniel Henrique Barboza wrote: From: Andrew Jones And add mrif notification trace. Signed-off-by: Andrew Jones Reviewed-by: Daniel Henrique Barboza Reviewed-by: Frank Chang ---   hw/riscv/riscv-iommu-pci.

Re: [PATCH] target/arm: Handle denormals correctly for FMOPA (widening)

On Tue, 30 Jul 2024 at 16:58, Peter Maydell wrote: > > The FMOPA (widening) SME instruction takes pairs of half-precision > floating point values, widens them to single-precision, does a > two-way dot product and accumulates the results into a > single-precision destination. We don't quite correc

Re: [PATCH 0/3] virtio-gpu-gl: Improve OpenGL and related display error messages

On Wed, Jul 31, 2024 at 7:42 PM Peter Maydell wrote: > If you try to use the virtio-gpu-gl device, the error messages > we produce are not very specific, which can leave users confused > about what they need to do (see the issue > https://gitlab.com/qemu-project/qemu/-/issues/2443 for an example)

[PATCH 3/3] ui/console: Note in '-display help' that some backends support suboptions

Currently '-display help' only prints the available backends. Some of those backends support suboptions (e.g. '-display gtk,gl=on'). Mention that in the help output, and point the user to where they might be able to find more information about the suboptions. The new output looks like this: $ qemu

[PATCH 2/3] system/vl.c: Expand OpenGL related errors

Expand the OpenGL related error messages we produce for various "OpenGL not present/not supported" cases, to hopefully guide the user towards how to fix things. Now if the user tries to enable GL on a backend that doesn't support it the error message is a bit more precise: $ qemu-system-aarch64 -

[PATCH 0/3] virtio-gpu-gl: Improve OpenGL and related display error messages

If you try to use the virtio-gpu-gl device, the error messages we produce are not very specific, which can leave users confused about what they need to do (see the issue https://gitlab.com/qemu-project/qemu/-/issues/2443 for an example). This patchset tries to improve those errors: (1) Trying to

[PATCH 1/3] hw/display/virtio-gpu: Improve "opengl is not available" error message

If the user tries to use the virtio-gpu-gl device but the display backend doesn't have OpenGL support enabled, we currently print a rather uninformative error message: $ qemu-system-aarch64 -M virt -device virtio-gpu-gl qemu-system-aarch64: -device virtio-gpu-gl: opengl is not available Since Ope

Re: [PATCH] util: retry open() when it gets interrupted by a signal

Hi Daniel, > > > > The experienced logfile entry is: > > > > > > > > qemu-system-x86_64: -device > > > > virtio-blk-pci,bus=pci.0,addr=0x7,drive=libvirt-2-format,id=virtio-disk0,bootindex=2,write-cache=on,serial=1b990c4d13b74a4e90ea: > > > > Could not open '/dev/drbd1003': Interrupted system cal

Re: [PATCH] util: retry open() when it gets interrupted by a signal

On Wed, Jul 31, 2024 at 04:24:45PM +0100, Peter Maydell wrote: > On Wed, 31 Jul 2024 at 16:21, Daniel P. Berrangé wrote: > > > > On Wed, Jul 31, 2024 at 03:32:52PM +0100, Peter Maydell wrote: > > > This is why we have the RETRY_ON_EINTR() macro, right? > > > > > > Currently we have some places tha

Re: [PATCH v1] target/i386: Always set leaf 0x1f

On 7/31/2024 4:49 PM, John Levon wrote: On Wed, Jul 31, 2024 at 03:02:15PM +0800, Xiaoyao Li wrote: Windows does not expect 0x1f to be present for any CPU model. But if it is exposed to the guest, it expects non-zero values. Please fix Windows! A ticket has been filed with MSFT, we are awar

Re: [PATCH 7/7] block/ssh.c: Don't double-check that characters are hex digits

On Wed, 31 Jul 2024 at 16:21, Kevin Wolf wrote: > > Am 31.07.2024 um 16:36 hat Peter Maydell geschrieben: > > In compare_fingerprint() we effectively check whether the characters > > in the fingerprint are valid hex digits twice: first we do so with > > qemu_isxdigit(), but then the hex2decimal()

Re: [PATCH] util: retry open() when it gets interrupted by a signal

On Wed, 31 Jul 2024 at 16:21, Daniel P. Berrangé wrote: > > On Wed, Jul 31, 2024 at 03:32:52PM +0100, Peter Maydell wrote: > > This is why we have the RETRY_ON_EINTR() macro, right? > > > > Currently we have some places that call qemu_open_old() inside > > RETRY_ON_EINTR -- we should decide whethe

Re: [PATCH 7/7] block/ssh.c: Don't double-check that characters are hex digits

Am 31.07.2024 um 16:36 hat Peter Maydell geschrieben: > In compare_fingerprint() we effectively check whether the characters > in the fingerprint are valid hex digits twice: first we do so with > qemu_isxdigit(), but then the hex2decimal() function also has a code > path where it effectively detect

Re: [PATCH] util: retry open() when it gets interrupted by a signal

On Wed, Jul 31, 2024 at 03:32:52PM +0100, Peter Maydell wrote: > On Wed, 31 Jul 2024 at 15:11, Daniel P. Berrangé wrote: > > > > On Wed, Jul 31, 2024 at 03:25:24PM +0200, Philipp Reisner wrote: > > > As with many syscalls, open() might be interrupted by a signal. > > > > > > The experienced logfil

[PATCH] util: use RETRY_ON_EINTR() on open() more consistently

As with many syscalls, open() might be interrupted by a signal. The call trace img_open_file() blk_new_open() raw_open() raw_open_common() qemu_open() qemu_open_internal() qemu_open_cloexec() Ended up in calling open() without a retry loop around it. The

Re: [PATCH 6/7] hw/ide/pci.c: Remove dead code from bmdma_prepare_buf()

Am 31.07.2024 um 16:36 hat Peter Maydell geschrieben: > Coverity notes that the code at the end of the loop in > bmdma_prepare_buf() is unreachable. This is because in commit > 9fbf0fa81fca8f527 ("ide: remove hardcoded 2GiB transactional limit") > we removed the only codepath in the loop which cou

Re: [PATCH 3/7] hw/block/pflash_cfi01: Don't decrement pfl->counter below 0

Am 31.07.2024 um 16:36 hat Peter Maydell geschrieben: > In pflash_write() Coverity points out that we can decrement the > unsigned pfl->counter below zero, which makes it wrap around. In > fact this is harmless, because if pfl->counter is 0 at this point we > also increment pfl->wcycle to 3, and t

Re: [PATCH 1/7] block/vdi.c: Avoid potential overflow when calculating size of write

Am 31.07.24 um 16:36 schrieb Peter Maydell: In vdi_co_pwritev() we multiply a sector count by SECTOR_SIZE to get the size to write in bytes. Coverity notes that this means that we do the multiply as a 32x32->32 multiply before converting to 64 bits, which has the potential to overflow. This is

Re: [PATCH 2/7] block/gluster: Use g_autofree for string in qemu_gluster_parse_json()

Am 31.07.2024 um 16:36 hat Peter Maydell geschrieben: > In the loop in qemu_gluster_parse_json() we do: > > char *str = NULL; > for(...) { > str = g_strdup_printf(...); > ... > if (various errors) { > goto out; > } > ... > g_free(

Re: [PATCH 1/7] block/vdi.c: Avoid potential overflow when calculating size of write

Am 31.07.2024 um 16:36 hat Peter Maydell geschrieben: > In vdi_co_pwritev() we multiply a sector count by SECTOR_SIZE to > get the size to write in bytes. Coverity notes that this means that > we do the multiply as a 32x32->32 multiply before converting to > 64 bits, which has the potential to over

Re: [PATCH 4/7] hw/ide/atapi: Be explicit that assigning to s->lcyl truncates

Am 31.07.2024 um 16:36 hat Peter Maydell geschrieben: > In ide_atapi_cmd_reply_end() we calculate a 16-bit size, and then > assign its two halves to s->lcyl and s->hcyl like this: > >s->lcyl = size; >s->hcyl = size >> 8; > > Coverity warns that the first line here can over

Re: [PATCH 5/7] hw/block/fdc-isa: Assert that isa_fdc_get_drive_max_chs() found something

Am 31.07.2024 um 16:36 hat Peter Maydell geschrieben: > Coverity complains about an overflow in isa_fdc_get_drive_max_chs() > that can happen if the loop over fd_formats never finds a match, > because we initialize *maxc to 0 and then at the end of the > function decrement it. > > This can't ever

Re: [PATCH 5/7] hw/block/fdc-isa: Assert that isa_fdc_get_drive_max_chs() found something

Peter Maydell writes: > Coverity complains about an overflow in isa_fdc_get_drive_max_chs() > that can happen if the loop over fd_formats never finds a match, > because we initialize *maxc to 0 and then at the end of the > function decrement it. > > This can't ever actually happen because fd_form

[PATCH] util: retry open() when it gets interrupted by a signal

As with many syscalls, open() might be interrupted by a signal. The experienced logfile entry is: qemu-system-x86_64: -device virtio-blk-pci,bus=pci.0,addr=0x7,drive=libvirt-2-format,id=virtio-disk0,bootindex=2,write-cache=on,serial=1b990c4d13b74a4e90ea: Could not open '/dev/drbd1003': Interrup

Re: [RFC PATCH] hw/ppc: Implement -dtb support for PowerNV

On 7/31/24 15:51, Aditya Gupta wrote: Hi Daniel, Thank you for the review. On 24/07/31 02:34PM, Daniel P. Berrangé wrote: On Wed, Jul 31, 2024 at 06:52:35PM +0530, Aditya Gupta wrote: Currently any device tree passed with -dtb option in QEMU, was ignored by the PowerNV code. Read and pass th

Re: [PATCH 4/7] hw/ide/atapi: Be explicit that assigning to s->lcyl truncates

On Wed, 31 Jul 2024 at 15:47, Markus Armbruster wrote: > > Peter Maydell writes: > > > In ide_atapi_cmd_reply_end() we calculate a 16-bit size, and then > > assign its two halves to s->lcyl and s->hcyl like this: > > > >s->lcyl = size; > >s->hcyl = size >> 8; > > > > Cover

Re: [PATCH 4/7] hw/ide/atapi: Be explicit that assigning to s->lcyl truncates

Peter Maydell writes: > In ide_atapi_cmd_reply_end() we calculate a 16-bit size, and then > assign its two halves to s->lcyl and s->hcyl like this: > >s->lcyl = size; >s->hcyl = size >> 8; > > Coverity warns that the first line here can overflow the > 8-bit s->lcyl variabl

[PATCH] bsd-user/main: Allow setting tb-size

While qemu-system can set tb-size using -accel tcg,tb-size=n, there is no similar knob for qemu-bsd-user. Add one in a way similar to how one-insn-per-tb is already handled. Suggested-by: Philippe Mathieu-Daudé Signed-off-by: Ilya Leoshkevich --- bsd-user/main.c | 9 + 1 file changed, 9

[PATCH] bsd-user/x86_64/target_arch_thread.h: Align stack

bsd-user qemu-x86_64 almost immediately dies with: qemu: 0x4002201a68: unhandled CPU exception 0xd - aborting on FreeBSD 14.1-RELEASE. This is an instruction that requires alignment: (gdb) x/i 0x4002201a68 0x4002201a68:movaps %xmm0,-0x40(%rbp) and the argument is not alig

Re: [RFC PATCH] hw/ppc: Implement -dtb support for PowerNV

Hello Aditya, On 7/31/24 15:22, Aditya Gupta wrote: Currently any device tree passed with -dtb option in QEMU, was ignored by the PowerNV code. Read and pass the passed -dtb to the kernel, thus enabling easier debugging with custom DTBs. I thought we had enough controls with the QEMU command

Re: [PATCH] qdev-monitor: QAPIfy QMP device_add

On Wed, 31 Jul 2024 at 09:59, Peter Krempa wrote: > > On Tue, Jul 09, 2024 at 16:27:22 +0200, Markus Armbruster wrote: > > Stefan Hajnoczi writes: > > > > > The QMP device_add monitor command converts the QDict arguments to > > > QemuOpts and then back again to QDict. This process only supports s

[PATCH 7/7] block/ssh.c: Don't double-check that characters are hex digits

In compare_fingerprint() we effectively check whether the characters in the fingerprint are valid hex digits twice: first we do so with qemu_isxdigit(), but then the hex2decimal() function also has a code path where it effectively detects an invalid digit and returns -1. This causes Coverity to com

[PATCH 3/7] hw/block/pflash_cfi01: Don't decrement pfl->counter below 0

In pflash_write() Coverity points out that we can decrement the unsigned pfl->counter below zero, which makes it wrap around. In fact this is harmless, because if pfl->counter is 0 at this point we also increment pfl->wcycle to 3, and the wcycle == 3 handling doesn't look at counter; the only way

[PATCH 4/7] hw/ide/atapi: Be explicit that assigning to s->lcyl truncates

In ide_atapi_cmd_reply_end() we calculate a 16-bit size, and then assign its two halves to s->lcyl and s->hcyl like this: s->lcyl = size; s->hcyl = size >> 8; Coverity warns that the first line here can overflow the 8-bit s->lcyl variable. This is true, and in this case we'r

[PATCH 6/7] hw/ide/pci.c: Remove dead code from bmdma_prepare_buf()

Coverity notes that the code at the end of the loop in bmdma_prepare_buf() is unreachable. This is because in commit 9fbf0fa81fca8f527 ("ide: remove hardcoded 2GiB transactional limit") we removed the only codepath in the loop which could "break" out of it, but didn't notice that this meant we sho

[PATCH 5/7] hw/block/fdc-isa: Assert that isa_fdc_get_drive_max_chs() found something

Coverity complains about an overflow in isa_fdc_get_drive_max_chs() that can happen if the loop over fd_formats never finds a match, because we initialize *maxc to 0 and then at the end of the function decrement it. This can't ever actually happen because fd_formats has at least one entry for each

[PATCH 1/7] block/vdi.c: Avoid potential overflow when calculating size of write

In vdi_co_pwritev() we multiply a sector count by SECTOR_SIZE to get the size to write in bytes. Coverity notes that this means that we do the multiply as a 32x32->32 multiply before converting to 64 bits, which has the potential to overflow. This is very unlikely to happen, since the block map ha

[PATCH 2/7] block/gluster: Use g_autofree for string in qemu_gluster_parse_json()

In the loop in qemu_gluster_parse_json() we do: char *str = NULL; for(...) { str = g_strdup_printf(...); ... if (various errors) { goto out; } ... g_free(str); str = NULL; } return 0; out: various cleanups;

[PATCH 0/7] block: Miscellaneous minor Coverity fixes

This patchset is a collection of fixes for minor Coverity reported issues. In all cases, there isn't a user-visible problem, but the Coverity issue pointed up somewhere where we could clean up the code or make it a bit more obvious to a human reader what the intent was. Only lightly tested (with "

Re: [PATCH] util: retry open() when it gets interrupted by a signal

On Wed, 31 Jul 2024 at 15:11, Daniel P. Berrangé wrote: > > On Wed, Jul 31, 2024 at 03:25:24PM +0200, Philipp Reisner wrote: > > As with many syscalls, open() might be interrupted by a signal. > > > > The experienced logfile entry is: > > > > qemu-system-x86_64: -device > > virtio-blk-pci,bus=pci

  1   2   >