[PULL 09/12] tests/qtest: use g_autofree for test_server_create_chr

From: Alex Bennée Signed-off-by: Alex Bennée Message-Id: <20220524154056.2896913-12-alex.ben...@linaro.org> Signed-off-by: Thomas Huth --- tests/qtest/vhost-user-test.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/tests/qtest/vhost-user-test.c b/tests/qtest/vhost-

[PULL 01/12] s390: Typo fix FLOATING_POINT_SUPPPORT_ENH

From: "Dr. David Alan Gilbert" One less P needed. Signed-off-by: Dr. David Alan Gilbert Message-Id: <20220523115123.150340-1-dgilb...@redhat.com> Signed-off-by: Thomas Huth --- target/s390x/cpu_features_def.h.inc | 2 +- target/s390x/gen-features.c | 6 +++--- target/s390x/tcg/transla

[PULL 00/12] s390x and misc patches

The following changes since commit 1e62a82574fc28e64deca589a23cf55ada2e1a7d: Merge tag 'm68k-for-7.1-pull-request' of https://github.com/vivier/qemu-m68k into staging (2022-06-02 06:30:24 -0700) are available in the Git repository at: https://gitlab.com/thuth/qemu.git tags/pull-request-2022

[PULL 05/12] tests/tcg: Test overflow conditions

From: Gautam Agrawal Add a test to check for overflow conditions in s390x. This patch is based on the following patches : * https://git.qemu.org/?p=qemu.git;a=commitdiff;h=5a2e67a691501 * https://git.qemu.org/?p=qemu.git;a=commitdiff;h=fc6e0d0f2db51 Signed-off-by: Gautam Agrawal Message-Id: <20

[PULL 03/12] target/s390x: kvm: Honor storage keys during emulation

From: Janis Schoetterl-Glausch Storage key controlled protection is currently not honored when emulating instructions. If available, enable key protection for the MEM_OP ioctl, thereby enabling it for the s390_cpu_virt_mem_* functions, when using kvm. As a result, the emulation of the following i

[PULL 12/12] ui: Remove deprecated options "-sdl" and "-curses"

We have "-sdl" and "-curses", but no "-gtk" and no "-cocoa" ... these old-style options are rather confusing than helpful nowadays. Now that the deprecation period is over, let's remove them, so we get a cleaner interface (where "-display" is the only way to select the user interface). Message-Id:

[PULL 06/12] MAINTAINERS: Change my email address

From: Hailiang Zhang The zhang.zhanghaili...@huawei.com email address has been stopped. Change it to my new email address. Signed-off-by: Hailiang Zhang Message-Id: <20211214075424.6920-1-zhanghaili...@xfusion.com> Acked-by: Gonglei Acked-by: Zhang Chen Signed-off-by: Thomas Huth --- MAINTA

[PULL 02/12] hw/s390x/s390-virtio-ccw: Improve the machine description string

The machine name already contains the words "ccw" and "virtio", so using "VirtIO-ccw" in the description likely does not really help the average user to get an idea what this machine type is about. Thus let's switch to "Virtual s390x machine" now, since "virtual machine" should be a familiar term,

[PULL 04/12] MAINTAINERS: Update s390 vhost entries

From: Eric Farman Commit 7a523d96a0 ("virtio-ccw: move vhost_ccw_scsi to a separate file") introduced a new file hw/s390x/vhost-scsi-ccw.c, which received a couple comments [1][2] to update MAINTAINERS that were missed. Fix that by making the vhost CCW entries a wildcard. [1] https://lore.kern

[PULL 10/12] ui: Remove deprecated parameters of the "-display sdl" option

Dropping these deprecated parameters simplifies further refactoring (e.g. QAPIfication is easier without underscores in the name). Message-Id: <20220519155625.1414365-2-th...@redhat.com> Reviewed-by: Daniel P. Berrangé Reviewed-by: Markus Armbruster Signed-off-by: Thomas Huth --- docs/about/de

[PULL 07/12] MAINTAINERS: Update maintainers for Guest x86 HAXM CPUs

From: Wenchao Wang Clean up the maintainer list. Reviewed-by: Hang Yuan Signed-off-by: Wenchao Wang Message-Id: [thuth: Note: Colin Xu's address bounces] Signed-off-by: Thomas Huth --- MAINTAINERS | 1 - 1 file changed, 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index ee9693dc3a

[PULL 08/12] qtest/npcm7xx_pwm-test: Fix memory leak in mft_qom_set

From: Miaoqian Lin g_strdup_printf() allocated memory for path, we should free it with g_free() when no longer needed. Signed-off-by: Miaoqian Lin Reviewed-by: Hao Wu Message-Id: <20220531080921.4704-1-linmq...@gmail.com> Signed-off-by: Thomas Huth --- tests/qtest/npcm7xx_pwm-test.c | 3 +++

[PULL 11/12] ui: Switch "-display sdl" to use the QAPI parser

The "-display sdl" option still uses a hand-crafted parser for its parameters since we didn't want to drag an interface we considered somewhat flawed into the QAPI schema. Since the flaws are gone now, it's time to QAPIfy. This introduces the new "DisplaySDL" QAPI struct that is used to hold the p

Re: [RFC PATCH 3/3] hw/openrisc: Add the OpenRISC virtual machine

Hi Stafford, On Thu, Jun 2, 2022 at 9:59 PM Stafford Horne wrote: > On Thu, Jun 02, 2022 at 09:08:52PM +0200, Geert Uytterhoeven wrote: > > On Thu, Jun 2, 2022 at 1:42 PM Joel Stanley wrote: > > > On Fri, 27 May 2022 at 17:27, Stafford Horne wrote: > > > > This patch add the OpenRISC virtual ma

Re: [RFC PATCH v2 0/6] hw/i2c: i2c slave mode support

With this combined I am able to boot up Linux on an emulated Aspeed 2600 evaluation board and have the i2c echo device write into a Linux slave EEPROM. Assuming the echo device is on address 0x42: # echo slave-24c02 0x1064 > /sys/bus/i2c/devices/i2c-15/new_device i2c i2c-15: new_device: I

Changes for building bits on newer gcc 9.4 compiler

Hi josh : Here are the pull requests. Please feel free to review and merge: Main bits module: https://github.com/biosbits/bits/pull/13 Submodules: https://github.com/biosbits/grub/pull/1 https://github.com/biosbits/python/pull/1 https://github.com/biosbits/libffi/pull/1 https://github.com/biosbit

Re: [PATCH 1/1] hw: m25p80: add W# pin and SRWD bit for write protection

Hello Iris, On 5/26/22 04:12, Iris Chen wrote: From: Iris Chen Add the W# pin and SRWD bit which control the status register write ability. may be replace W# by WP# (for write protect) Signed-off-by: Iris Chen --- hw/block/m25p80.c | 72 +++

[PATCH] microvm: turn off io reservations for pcie root ports

The pcie host bridge has no io window on microvm, so io reservations will not work. Signed-off-by: Gerd Hoffmann --- hw/i386/microvm.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/hw/i386/microvm.c b/hw/i386/microvm.c index 4b3b1dd262f1..f01d972f5d28 100644 --- a/hw/i386/microvm.c +

[PATCH] tests/avocado: Prefer max cpu type when using AArch64 virt machine

The max cpu type is the best default cpu type for tests to use when specifying the cpu type for AArch64 mach-virt. Switch all tests to it. Cc: Alex Bennée Signed-off-by: Andrew Jones --- tests/avocado/replay_kernel.py | 2 +- tests/avocado/reverse_debugging.py | 2 +- tests/avocado/tcg_plug

Re: [PATCH] tests/avocado: Prefer max cpu type when using AArch64 virt machine

On Fri, Jun 03, 2022 at 11:25:05AM +0200, Andrew Jones wrote: > The max cpu type is the best default cpu type for tests to use > when specifying the cpu type for AArch64 mach-virt. Switch all > tests to it. Hmm, looking at tests in tests/qtest and tests/vm I see cortex-a57 is still used for a defa

Re: [PATCH] tests/avocado: Prefer max cpu type when using AArch64 virt machine

On Fri, Jun 03 2022, Andrew Jones wrote: > The max cpu type is the best default cpu type for tests to use > when specifying the cpu type for AArch64 mach-virt. Switch all > tests to it. > > Cc: Alex Bennée > Signed-off-by: Andrew Jones > --- > tests/avocado/replay_kernel.py | 2 +- > tests

Re: [PATCH] tests/avocado: Prefer max cpu type when using AArch64 virt machine

On Fri, Jun 03, 2022 at 12:07:13PM +0200, Cornelia Huck wrote: > On Fri, Jun 03 2022, Andrew Jones wrote: > > > The max cpu type is the best default cpu type for tests to use > > when specifying the cpu type for AArch64 mach-virt. Switch all > > tests to it. > > > > Cc: Alex Bennée > > Signed-of

Re: [PATCH v2 00/10] Random cleanup patches

On Sat, May 21, 2022 at 11:55 AM Mark Cave-Ayland < mark.cave-ayl...@ilande.co.uk> wrote: > On 20/05/2022 19:00, Bernhard Beschow wrote: > > > v2: > > * Omit removal of isa_connect_gpio_out() (Mark) > > > > v1: > > This patch series contains random cleanups that I made while studying > the code. >

[PATCH v2] tests: Prefer max cpu type when using AArch64 virt machine

The max cpu type is the best default cpu type for tests to use when specifying the cpu type for AArch64 mach-virt. Switch all tests to it. Cc: Alex Bennée Signed-off-by: Andrew Jones --- tests/avocado/boot_xen.py | 6 +++--- tests/avocado/replay_kernel.py | 2 +- tests/avocado/re

Re: [PATCH v6 5/8] libvduse: Add VDUSE (vDPA Device in Userspace) library

Hi Yongji, On 5/23/22 10:46, Xie Yongji wrote: VDUSE [1] is a linux framework that makes it possible to implement software-emulated vDPA devices in userspace. This adds a library as a subproject to help implementing VDUSE backends in QEMU. [1] https://www.kernel.org/doc/html/latest/userspace-ap

[PATCH v3 1/3] target/riscv: Reorganize riscv_cpu_properties

Because many developers introduced new properties in various ways, the entire riscv_cpu_properties block is getting too complex. This commit reorganizes riscv_cpu_properties for clarity on future. Signed-off-by: Tsukasa OI --- target/riscv/cpu.c | 64 +++-

[PATCH v3 3/3] target/riscv: Deprecate capitalized property names

This commit adds a deprecation note of capitalized property names of RISC-V CPU to documentation. Signed-off-by: Tsukasa OI --- docs/about/deprecated.rst | 10 ++ 1 file changed, 10 insertions(+) diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index a92ae0f162..cfc9ad

[PATCH v3 0/3] target/riscv: Make CPU property names lowercase (w/ capitalized aliases)

v1: v2: v2.1: Hello, This is v3 of the patch to RISC-V CPU property names. See v1 for b

[PATCH v3 2/3] target/riscv: Make CPU property names lowercase

Many CPU properties for RISC-V are in lowercase except those with "capitalized" (or CamelCase) names: - Counters - Zifencei - Zicsr - Zfh - Zfhmin - Zve32f - Zve64f This commit makes lowercase names primary but keeps capitalized names as aliases (for backward compatibility, but with

Re: [PATCH v2] tests: Prefer max cpu type when using AArch64 virt machine

On Fri, Jun 03 2022, Andrew Jones wrote: > The max cpu type is the best default cpu type for tests to use > when specifying the cpu type for AArch64 mach-virt. Switch all > tests to it. > > Cc: Alex Bennée > Signed-off-by: Andrew Jones > --- > tests/avocado/boot_xen.py | 6 +++--- >

Re: [PATCH v10 13/14] vfio-user: handle device interrupts

> On Jun 1, 2022, at 1:26 PM, Alex Williamson > wrote: > > On Wed, 1 Jun 2022 17:00:54 + > Jag Raman wrote: >> >> Hi Alex, >> >> Just to add some more detail, the emulated PCI device in QEMU presently >> maintains a MSIx table (PCIDevice->msix_table) and Pending Bit Array. In the >> pre

[PATCH] gitlab-ci: Fix the build-cfi-aarch64 and build-cfi-ppc64-s390x jobs

The job definitions recently got a second "variables:" section by accident and thus are failing now if one tries to run them. Merge the two sections into one again to fix the issue. And while we're at it, bump the timeout here (70 minutes are currently not enough for the aarch64 job). The jobs are

Debian MinGW cross compilation (was: Re: [PULL 2/3] qga-win32: Add support for NVME but type)

On 24/05/2022 15.38, Daniel P. Berrangé wrote: On Tue, May 24, 2022 at 03:28:37PM +0200, Thomas Huth wrote: ... Daniel, do you remember whether we supported Debian for MinGW cross-compilation in the past? At one time we used to have Debian with the 3rd party 'mxe' builds of mingw added. It b

Re: Debian MinGW cross compilation (was: Re: [PULL 2/3] qga-win32: Add support for NVME but type)

Am 03.06.22 um 14:56 schrieb Thomas Huth: On 24/05/2022 15.38, Daniel P. Berrangé wrote: On Tue, May 24, 2022 at 03:28:37PM +0200, Thomas Huth wrote: ... Daniel, do you remember whether we supported Debian for MinGW cross-compilation in the past? At one time we used to have Debian with the

Re: Debian MinGW cross compilation (was: Re: [PULL 2/3] qga-win32: Add support for NVME but type)

On 03/06/2022 15.09, Stefan Weil wrote: Am 03.06.22 um 14:56 schrieb Thomas Huth: On 24/05/2022 15.38, Daniel P. Berrangé wrote: On Tue, May 24, 2022 at 03:28:37PM +0200, Thomas Huth wrote: ... Daniel, do you remember whether we supported Debian for MinGW cross-compilation in the past? At

about the current status of Multi-process QEMU / out-of-process emulation

Hi All, I saw that you authored the QEMU page for "Multi-process QEMU". ( https://www.qemu.org/docs/master/system/multi-process.html) I'm interested in this feature, but feel a little confused with the command line: + /usr/bin/qemu-system-x86_64\ +

Re: [PATCH 3/3] capstone: Remove the capstone submodule

On 6/2/22 22:21, Thomas Huth wrote: So is capstone disassembly better now with Ubuntu 20.04 or should we still revert the submodule removal? It's better, yes. At least it's giving me disassembly of the system registers. Also, if libvixl is so bad, why do we still have that in the repo? Wel

Re: [PATCH v2] tests: Prefer max cpu type when using AArch64 virt machine

On 6/3/22 7:18 PM, Andrew Jones wrote: The max cpu type is the best default cpu type for tests to use when specifying the cpu type for AArch64 mach-virt. Switch all tests to it. Cc: Alex Bennée Signed-off-by: Andrew Jones --- tests/avocado/boot_xen.py | 6 +++--- tests/avocado/rep

Re: [PATCH] tests/avocado: Prefer max cpu type when using AArch64 virt machine

On 6/3/22 02:25, Andrew Jones wrote: The max cpu type is the best default cpu type for tests to use when specifying the cpu type for AArch64 mach-virt. Switch all tests to it. This won't work without further changes. @@ -147,7 +147,7 @@ def test_aarch64_virt(self): """ :av

Re: [PATCH v2] tests: Prefer max cpu type when using AArch64 virt machine

On 6/3/22 04:18, Andrew Jones wrote: The max cpu type is the best default cpu type for tests to use when specifying the cpu type for AArch64 mach-virt. Switch all tests to it. Cc: Alex Bennée Signed-off-by: Andrew Jones For avoidance of doubt, copying v1 comment to v2: diff --git a/tests/a

Re: [PATCH] target/ppc: fix vbpermd in big endian hosts

On 6/1/22 05:53, matheus.fe...@eldorado.org.br wrote: From: Matheus Ferst The extract64 arguments are not endian dependent as they are only used for bitwise operations. The current behavior in little-endian hosts is correct; since the indexes in VRB are in PowerISA-ordering, we should always inv

Re: [PATCH] tests/avocado: Prefer max cpu type when using AArch64 virt machine

On Fri, Jun 03, 2022 at 06:56:41AM -0700, Richard Henderson wrote: > On 6/3/22 02:25, Andrew Jones wrote: > > The max cpu type is the best default cpu type for tests to use > > when specifying the cpu type for AArch64 mach-virt. Switch all > > tests to it. > > This won't work without further chang

Re: [PATCH 3/3] capstone: Remove the capstone submodule

On 03/06/2022 15.48, Richard Henderson wrote: On 6/2/22 22:21, Thomas Huth wrote: So is capstone disassembly better now with Ubuntu 20.04 or should we still revert the submodule removal? It's better, yes.  At least it's giving me disassembly of the system registers. Also, if libvixl is so ba

Re: [PATCH v2] tests: Prefer max cpu type when using AArch64 virt machine

On Fri, Jun 03, 2022 at 07:04:01AM -0700, Richard Henderson wrote: > On 6/3/22 04:18, Andrew Jones wrote: > > The max cpu type is the best default cpu type for tests to use > > when specifying the cpu type for AArch64 mach-virt. Switch all > > tests to it. > > > > Cc: Alex Bennée > > Signed-off-b

Re: [PULL 00/12] s390x and misc patches

On 6/2/22 23:58, Thomas Huth wrote: The following changes since commit 1e62a82574fc28e64deca589a23cf55ada2e1a7d: Merge tag 'm68k-for-7.1-pull-request' of https://github.com/vivier/qemu-m68k into staging (2022-06-02 06:30:24 -0700) are available in the Git repository at: https://gitlab.c

Re: [PATCH] tests/avocado: Prefer max cpu type when using AArch64 virt machine

On 6/3/22 08:05, Andrew Jones wrote: On Fri, Jun 03, 2022 at 06:56:41AM -0700, Richard Henderson wrote: On 6/3/22 02:25, Andrew Jones wrote: The max cpu type is the best default cpu type for tests to use when specifying the cpu type for AArch64 mach-virt. Switch all tests to it. This won't wo

Fwd: about the current status of Multi-process QEMU / out-of-process emulation

Hello Dongli, Elena, John, and Jagannathan, I'm interested in the "multi-process QEMU" feature and got the kind reply by Mr. Vivier that I may contact you for this. On one of the QEMU docs [1] I saw the command line: + /usr/bin/qemu-system-x86_64\ +

Re: [PATCH v6 02/18] job.h: categorize fields in struct Job

Am 14.03.2022 um 14:36 hat Emanuele Giuseppe Esposito geschrieben: > Categorize the fields in struct Job to understand which ones > need to be protected by the job mutex and which don't. > > Signed-off-by: Emanuele Giuseppe Esposito I suppose it might be a result of moving things back and forth

[RFC PATCH v5 3/4] target/riscv: smstateen check for fcsr

If smstateen is implemented and sstateen0.fcsr is clear then the floating point operations must return illegal instruction exception. Signed-off-by: Mayuresh Chitale --- target/riscv/csr.c | 24 1 file changed, 24 insertions(+) diff --git a/target/riscv/csr.c b/target/r

[RFC PATCH v5 0/4] RISC-V Smstateen support

This series adds support for the Smstateen specification which provides a mechanism plug potential covert channels which are opened by extensions that add to processor state that may not get context-switched. Currently access to AIA registers, *envcfg registers and floating point(fcsr) is controlle

[RFC PATCH v5 1/4] target/riscv: Add smstateen support

Smstateen extension specifies a mechanism to close the potential covert channels that could cause security issues. This patch adds the CSRs defined in the specification and the corresponding predicates and read/write functions. Signed-off-by: Mayuresh Chitale --- target/riscv/cpu.c | 2 +

[RFC PATCH v5 4/4] target/riscv: smstateen check for AIA/IMSIC

If smstateen is implemented then accesses to AIA registers CSRS, IMSIC CSRs and other IMSIC registers is controlled by setting of corresponding bits in mstateen/hstateen registers. Otherwise an illegal instruction trap or virtual instruction trap is generated. Signed-off-by: Mayuresh Chitale ---

[RFC PATCH v5 2/4] target/riscv: smstateen check for h/senvcfg

Accesses to henvcfg, henvcfgh and senvcfg are allowed only if corresponding bit in mstateen0/hstateen0 is enabled. Otherwise an illegal instruction trap is generated. Signed-off-by: Mayuresh Chitale --- target/riscv/csr.c | 84 ++ 1 file changed, 78 in

Re: [PATCH] gitlab-ci: Fix the build-cfi-aarch64 and build-cfi-ppc64-s390x jobs

On 6/3/22 05:48, Thomas Huth wrote: The job definitions recently got a second "variables:" section by accident and thus are failing now if one tries to run them. Merge the two sections into one again to fix the issue. And while we're at it, bump the timeout here (70 minutes are currently not eno

Re: Changes for building bits on newer gcc 9.4 compiler

On an additional note, my changes are not backward compatible with older compiler. The build will break when built with a centos 7 docker/vm/host: /home/anisinha/workspace/bits/build/grub/grub-core/contrib-deps/python/Modules/_ctypes/_ctypes.c: In function '_build_callargs': /home/anisinha/workspa

Re: [PATCH v6 05/18] job.h: add _locked duplicates for job API functions called with and without job_mutex

Am 14.03.2022 um 14:36 hat Emanuele Giuseppe Esposito geschrieben: > In preparation to the job_lock/unlock usage, create _locked > duplicates of some functions, since they will be sometimes called with > job_mutex held (mostly within job.c), > and sometimes without (mostly from JobDrivers using the

Re: [PATCH] gitlab-ci: Fix the build-cfi-aarch64 and build-cfi-ppc64-s390x jobs

On 03/06/2022 18.17, Richard Henderson wrote: On 6/3/22 05:48, Thomas Huth wrote: The job definitions recently got a second "variables:" section by accident and thus are failing now if one tries to run them. Merge the two sections into one again to fix the issue. And while we're at it, bump the

Re: [PATCH v6 34/43] hw/intc: Add LoongArch extioi interrupt controller(EIOINTC)

On 6/1/22 03:25, Xiaojuan Yang wrote: +static uint64_t extioi_readw(void *opaque, hwaddr addr, unsigned size) +{ +LoongArchExtIOI *s = LOONGARCH_EXTIOI(opaque); +unsigned long offset = addr & 0x; +uint32_t index, cpu, ret = 0; + +switch (offset) { +case EXTIOI_NODETYPE_STA

Re: [PATCH v6 06/18] jobs: protect jobs with job_lock/unlock

Am 14.03.2022 um 14:36 hat Emanuele Giuseppe Esposito geschrieben: > Introduce the job locking mechanism through the whole job API, > following the comments in job.h and requirements of job-monitor > (like the functions in job-qmp.c, assume lock is held) and > job-driver (like in mirror.c and all

Re: [PATCH v6 38/43] hw/loongarch: Add LoongArch ls7a rtc device support

On 6/1/22 03:25, Xiaojuan Yang wrote: This patch add ls7a rtc device support. Signed-off-by: Xiaojuan Yang Signed-off-by: Song Gao --- MAINTAINERS| 1 + hw/loongarch/Kconfig | 1 + hw/loongarch/loongson3.c | 3 + hw/rtc/Kconfig | 3 + hw/rtc/ls

Re: [PATCH v6 40/43] hw/loongarch: Add LoongArch power manager support

On 6/1/22 03:25, Xiaojuan Yang wrote: Signed-off-by: Xiaojuan Yang Signed-off-by: Song Gao --- hw/loongarch/loongson3.c | 45 +++- 1 file changed, 44 insertions(+), 1 deletion(-) Acked-by: Richard Henderson +#define PM_BASE 0x1008 +#define PM_SIZ

Re: [PATCH v6 15/18] job: detect change of aiocontext within job coroutine

Am 14.03.2022 um 14:37 hat Emanuele Giuseppe Esposito geschrieben: > From: Paolo Bonzini > > We want to make sure access of job->aio_context is always done > under either BQL or job_mutex. The problem is that using > aio_co_enter(job->aiocontext, job->co) in job_start and job_enter_cond > makes t

Re: [PATCH] disas: Remove libvixl disassembler

On 6/3/22 09:42, Thomas Huth wrote: The disassembly via capstone should be superiour to our old vixl sources nowadays, so let's finally cut this old disassembler out of the QEMU source tree. Signed-off-by: Thomas Huth --- See also the discussions here: - https://lists.gnu.org/archive/html/q

Re: [PATCH] disas: Remove libvixl disassembler

On 03/06/2022 19.26, Claudio Fontana wrote: On 6/3/22 18:42, Thomas Huth wrote: The disassembly via capstone should be superiour to our old vixl sources nowadays, so let's finally cut this old disassembler out of the QEMU source tree. Signed-off-by: Thomas Huth agreed, one thought: at the ti

Re: about the current status of Multi-process QEMU / out-of-process emulation

On Jun 3, 2022, at 11:34 AM, Yu Zhang mailto:yu.zh...@ionos.com>> wrote: Hello Dongli, Elena, John, and Jagannathan, I'm interested in the "multi-process QEMU" feature and got the kind reply by Mr. Vivier that I may contact you for this. On one of the QEMU docs [1] I saw the command line: +

Re: [PATCH RESEND v3 1/8] target/ppc: Implemented vector divide instructions

On 5/25/22 06:49, Lucas Mateus Castro(alqotel) wrote: From: "Lucas Mateus Castro (alqotel)" Implement the following PowerISA v3.1 instructions: vdivsw: Vector Divide Signed Word vdivuw: Vector Divide Unsigned Word vdivsd: Vector Divide Signed Doubleword vdivud: Vector Divide Unsigned Doubleword

Re: [PATCH RESEND v3 3/8] target/ppc: Implemented vector divide extended word

On 5/25/22 06:49, Lucas Mateus Castro(alqotel) wrote: From: "Lucas Mateus Castro (alqotel)" Implement the following PowerISA v3.1 instructions: vdivesw: Vector Divide Extended Signed Word vdiveuw: Vector Divide Extended Unsigned Word Signed-off-by: Lucas Mateus Castro (alqotel) --- target/ppc

Re: [PATCH RESEND v3 7/8] target/ppc: Implemented vector module word/doubleword

On 5/25/22 06:49, Lucas Mateus Castro(alqotel) wrote: From: "Lucas Mateus Castro (alqotel)" Implement the following PowerISA v3.1 instructions: vmodsw: Vector Modulo Signed Word vmoduw: Vector Modulo Unsigned Word vmodsd: Vector Modulo Signed Doubleword vmodud: Vector Modulo Unsigned Doubleword

Re: [PATCH RESEND v3 4/8] host-utils: Implemented unsigned 256-by-128 division

On 5/25/22 06:49, Lucas Mateus Castro(alqotel) wrote: From: "Lucas Mateus Castro (alqotel)" Based on already existing QEMU implementation, created an unsigned 256 bit by 128 bit division needed to implement the vector divide extended unsigned instruction from PowerISA3.1 Signed-off-by: Lucas Ma

[PATCH v4 00/11] QOM'ify PIIX southbridge creation

v4: * Rebase onto https://patchew.org/QEMU/20220530112718.26582-1-philippe.mathieu.da...@gmail.com/ * Cosmetics (fix typo, omit "include") (Mark, Philippe) * Split piix3 and piix4 (Philippe) * s/Found-by/Reported-by/ (Philippe) * Don't alias smbus (Mark) v3: * Rebase onto 'hw/acpi/piix4: remove l

[PATCH v4 03/11] hw/isa/piix4: Move pci_map_irq_fn' near pci_set_irq_fn

The pci_map_irq_fn was implemented below type_init() which made it inaccessible to QOM functions. So move it up. Signed-off-by: Bernhard Beschow Reviewed-by: Mark Cave-Ayland Reviewed-by: Philippe Mathieu-Daudé --- hw/isa/piix4.c | 50 +- 1 file

[PATCH v4 01/11] hw/southbridge/piix: Aggregate all PIIX southbridge type names

TYPE_PIIX3_PCI_DEVICE resides there as already, so add the remaining ones, too. Signed-off-by: Bernhard Beschow Reviewed-by: Mark Cave-Ayland Reviewed-by: Philippe Mathieu-Daudé --- hw/isa/piix3.c| 3 --- include/hw/isa/isa.h | 2 -- include/hw/southbridge/piix.h | 4 +

[PATCH v4 05/11] hw/isa/piix4: Factor out ISABus retrieval from piix4_create()

Modernizes the code. Signed-off-by: Bernhard Beschow Reviewed-by: Mark Cave-Ayland Reviewed-by: Philippe Mathieu-Daudé --- hw/isa/piix4.c| 6 +- hw/mips/malta.c | 3 ++- include/hw/southbridge/piix.h | 2 +- 3 files changed, 4 insertions(+), 7 deletions(-) di

[PATCH v4 10/11] hw/isa/piix3: Factor out ISABus retrieval from piix3_create()

Modernizes the code. Signed-off-by: Bernhard Beschow Reviewed-by: Mark Cave-Ayland --- hw/i386/pc_piix.c | 3 ++- hw/isa/piix3.c| 3 +-- include/hw/southbridge/piix.h | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/hw/i386/pc_piix.c b/hw/i386/p

[PATCH v4 06/11] hw/isa/piix4: QOM'ify PIIX4 PM creation

Just like the real hardware, create the PIIX4 ACPI controller as part of the PIIX4 southbridge. This also mirrors how the IDE and USB functions are already created. Signed-off-by: Bernhard Beschow --- hw/isa/piix4.c| 24 +--- hw/mips/malta.c | 5

[PATCH v4 08/11] hw/isa/piix3: Move pci_map_irq_fn near pci_set_irq_fn

The pci_map_irq_fn was implemented below type_init() which made it inaccessible to QOM functions. So move it up. Signed-off-by: Bernhard Beschow Reviewed-by: Mark Cave-Ayland Reviewed-by: Philippe Mathieu-Daudé --- hw/isa/piix3.c | 22 +++--- 1 file changed, 11 insertions(+), 1

[PATCH v4 02/11] hw/isa/piix4: Use object_initialize_child() for embedded struct

Reported-by: Peter Maydell Signed-off-by: Bernhard Beschow Reviewed-by: Philippe Mathieu-Daudé --- hw/isa/piix4.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/isa/piix4.c b/hw/isa/piix4.c index 9a6d981037..1d04fb6a55 100644 --- a/hw/isa/piix4.c +++ b/hw/isa/piix4.c @@

[PATCH v4 04/11] hw/isa/piix4: QOM'ify PCI device creation and wiring

PCI interrupt wiring and device creation were performed in create() functions which are obsolete. Move these tasks into QOM functions to modernize the code. Signed-off-by: Bernhard Beschow Reviewed-by: Philippe Mathieu-Daudé --- hw/isa/piix4.c | 30 ++ 1 file changed

[PATCH v4 09/11] hw/isa/piix3: QOM'ify PCI device creation and wiring

PCI interrupt wiring was performed in create() functions which are obsolete. Move these tasks into QOM functions to modernize the code. In order to avoid duplicate checking for xen_enabled() the realize methods are now split. Signed-off-by: Bernhard Beschow --- hw/isa/piix3.c | 67 +

[PATCH v4 11/11] hw/isa/piix3: Inline and remove piix3_create()

During the previous changesets piix3_create() became a trivial wrapper around more generic functions. Modernize the code. Signed-off-by: Bernhard Beschow Reviewed-by: Philippe Mathieu-Daudé --- hw/i386/pc_piix.c | 6 +- hw/isa/piix3.c| 13 - include/

[PATCH v4 07/11] hw/isa/piix4: Inline and remove piix4_create()

During the previous changesets piix4_create() became a trivial wrapper around more generic functions. Modernize the code. Signed-off-by: Bernhard Beschow Reviewed-by: Philippe Mathieu-Daudé --- hw/isa/piix4.c| 13 - hw/mips/malta.c | 5 - include/h

Re: [PATCH] hw/nvme: Fix deallocate when metadata is present

On Fri, Jun 03, 2022 at 01:14:40PM -0600, Jonathan Derrick wrote: > When metadata is present in the namespace and deallocates are issued, the > first > deallocate could fail to zero the block range, resulting in another > deallocation to be issued. Normally after the deallocation completes and the

[PULL 03/11] hw/nvme: fix copy cmd for pi enabled namespaces

From: Dmitry Tikhov Current implementation have problem in the read part of copy command. Because there is no metadata mangling before nvme_dif_check invocation, reftag error could be thrown for blocks of namespace that have not been previously written to. Signed-off-by: Dmitry Tikhov Reviewed-

[PULL 00/11] hw/nvme updates

From: Klaus Jensen Hi Peter, The following changes since commit 70e975203f366f2f30daaeb714bb852562b7b72f: Merge tag 'pull-request-2022-06-03' of https://gitlab.com/thuth/qemu into staging (2022-06-03 06:43:38 -0700) are available in the Git repository at: git://git.infradead.org/qemu-nvm

[PULL 01/11] hw/nvme: fix narrowing conversion

From: Dmitry Tikhov Since nlbas is of type int, it does not work with large namespace size values, e.g., 9 TB size of file backing namespace and 8 byte metadata with 4096 bytes lbasz gives negative nlbas value, which is later promoted to negative int64_t type value and results in negative ns->mof

[PULL 06/11] hw/nvme: do not auto-generate eui64

From: Klaus Jensen We cannot provide auto-generated unique or persistent namespace identifiers (EUI64, NGUID, UUID) easily. Since 6.1, namespaces have been assigned a generated EUI64 of the form "52:54:00:". This is will be unique within a QEMU instance, but not globally. Revert that this is ass

[PULL 05/11] hw/nvme: enforce common serial per subsystem

From: Klaus Jensen The Identify Controller Serial Number (SN) is the serial number for the NVM subsystem and must be the same across all controller in the NVM subsystem. Enforce this. Reviewed-by: Christoph Hellwig Reviewed-by: Keith Busch Signed-off-by: Klaus Jensen --- hw/nvme/nvme.h |

[PULL 04/11] hw/nvme: fix smart aen

From: Klaus Jensen Pass the right constant to nvme_smart_event(). The NVME_AER* values hold the bit position in the SMART byte, not the shifted value that we expect it to be in nvme_smart_event(). Fixes: c62720f137df ("hw/block/nvme: trigger async event during injecting smart warning") Acked-by

[PULL 02/11] hw/nvme: add missing return statement

From: Dmitry Tikhov Since there is no return after nvme_dsm_cb invocation, metadata associated with non-zero block range is currently zeroed. Also this behaviour leads to segfault since we schedule iocb->bh two times. First when entering nvme_dsm_cb with iocb->idx == iocb->nr and second because o

[PULL 11/11] hw/nvme: add new command abort case

From: Dmitry Tikhov NVMe command set specification for end-to-end data protection formatted namespace states: o If the Reference Tag Check bit of the PRCHK field is set to ‘1’ and the namespace is formatted for Type 3 protection, then the controller: ▪ should not compar

[PULL 07/11] hw/nvme: do not auto-generate uuid

From: Klaus Jensen Do not default to generate an UUID for namespaces if it is not explicitly specified. This is a technically a breaking change in behavior. However, since the UUID changes on every VM launch, it is not spec compliant and is of little use since the UUID cannot be used reliably an

[PULL 08/11] hw/nvme: do not report null uuid

From: Klaus Jensen Do not report the "null uuid" (all zeros) in the namespace identification descriptors. Reported-by: Luis Chamberlain Reported-by: Christoph Hellwig Reviewed-by: Christoph Hellwig Reviewed-by: Keith Busch Signed-off-by: Klaus Jensen --- hw/nvme/ctrl.c | 17 +++

Re: [PATCH] hw/nvme: Fix deallocate when metadata is present

On Jun 3 13:14, Jonathan Derrick wrote: > When metadata is present in the namespace and deallocates are issued, the > first > deallocate could fail to zero the block range, resulting in another > deallocation to be issued. Normally after the deallocation completes and the > range is checked for z

[PULL 09/11] hw/nvme: bump firmware revision

From: Klaus Jensen The Linux kernel quirks the QEMU NVMe controller pretty heavily because of the namespace identifier mess. Since this is now fixed, bump the firmware revision number to allow the quirk to be disabled for this revision. As of now, bump the firmware revision number to be equal to

[PULL 10/11] hw/nvme: deprecate the use-intel-id compatibility parameter

From: Klaus Jensen Since version 5.2 commit 6eb7a071292a ("hw/block/nvme: change controller pci id"), the emulated NVMe controller has defaulted to a non-Intel PCI identifier. Deprecate the compatibility parameter so we can get rid of it once and for all. Reviewed-by: Philippe Mathieu-Daudé Si

Re: [PATCH v2] hw/nvme: clean up CC register write logic

On Jun 1 15:28, Lukasz Maniak wrote: > On Wed, May 25, 2022 at 09:35:24AM +0200, Klaus Jensen wrote: > > > > +stl_le_p(&n->bar.intms, 0); > > +stl_le_p(&n->bar.intmc, 0); > > +stl_le_p(&n->bar.cc, 0); > > Looks fine, though it seems the NVMe spec says the above registers

[PATCH] Revert "hw/block/nvme: add support for sgl bit bucket descriptor"

From: Klaus Jensen This reverts commit d97eee64fef35655bd06f5c44a07fdb83a6274ae. The emulated controller correctly accounts for not including bit buckets in the controller-to-host data transfer, however it doesn't correctly account for the holes for the on-disk data offsets. Reported-by: Keith

Re: [PATCH v2 04/16] ppc/pnv: change PnvPHB3 to be a PnvPHB backend

On 6/2/22 04:56, Mark Cave-Ayland wrote: On 31/05/2022 22:49, Daniel Henrique Barboza wrote: We need a handful of changes that needs to be done in a single swoop to turn PnvPHB3 into a PnvPHB backend. In the PnvPHB3, since the PnvPHB device implements PCIExpressHost and will hold the PCI bu

Re: [PATCH] hw/nvme: clear aen mask on reset

On May 12 11:30, Klaus Jensen wrote: > From: Klaus Jensen > > The internally maintained AEN mask is not cleared on reset. Fix this. > > Signed-off-by: Klaus Jensen > --- > hw/nvme/ctrl.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/hw/nvme/ctrl.c b/hw/nvme/ctrl.c > index 1e6e0fcad

Re: [PATCH v2] hw/nvme: allow to pass a memory backend object for the CMB

On Apr 19 07:20, Wertenbroek Rick wrote: > Adds the optional -cmbdev= option that takes a QEMU memory backend > -object to be used to for the CMB (Controller Memory Buffer). > This option takes precedence over cmb_size_mb= if both used. > (The size will be deduced from the memory backend option). >

  1   2   >