Re: [PATCH] gitlab-ci: Replace build_script -> step_script in Cirrus jobs

On 16/08/2024 23.32, Philippe Mathieu-Daudé wrote: Long due upgrade, see [1]: In GitLab Runner 13.2 a translation for step_script to build_script was added to the custom executor. In 14.0 the build_script stage will be replaced with step_script. We are using GitLab 17 [2]! This remove

Re: [PATCH 2/2] hw/char: sifive_uart: Print uart charecters async

On Thu, Aug 15, 2024 at 6:27 PM Mark Cave-Ayland wrote: > > On 15/08/2024 02:54, Alistair Francis wrote: > > > The current approach of using qemu_chr_fe_write() and ignoring the > > return values results in dropped charecters [1]. > > > > Let's update the SiFive UART to use a async sifive_uart_xmi

Re: [PATCH RFC V3 06/29] arm/virt,kvm: Pre-create disabled possible vCPUs @machine init

On 6/14/24 9:36 AM, Salil Mehta wrote: In the ARMv8 architecture, the GIC must know all the CPUs it is connected to during its initialization, and this cannot change afterward. This must be ensured during the initialization of the VGIC as well in KVM, which requires all vCPUs to be created and pr

Re: [PATCH] .gitlab-ci.d/windows.yml: Disable the qtests in the MSYS2 job

On 16/08/2024 19.18, Philippe Mathieu-Daudé wrote: On 16/8/24 18:40, Thomas Huth wrote: On 16/08/2024 18.34, Philippe Mathieu-Daudé wrote: On 16/8/24 17:37, Thomas Huth wrote: The qtests are broken since a while in the MSYS2 job in the gitlab-CI, likely due to some changes in the MSYS2 environ

Re: [PATCH 3/3] tests/acpi: Add expected ACPI SRAT AML file for RISC-V

On Fri, Aug 9, 2024 at 12:50 PM Haibo Xu wrote: > > As per the step 5 in the process documented in bios-tables-test.c, > generate the expected ACPI SRAT AML data file for RISC-V using the > rebuild-expected-aml.sh script and update the > bios-tables-test-allowed-diff.h. > > This is a new file bein

[PULL 0/1] riscv-to-apply queue

The following changes since commit 2eefd4fcec4b8fe41ceee2a8f00cdec1fe81b75c: Merge tag 'pull-maintainer-9.1-rc3-160824-1' of https://gitlab.com/stsquad/qemu into staging (2024-08-17 16:46:45 +1000) are available in the Git repository at: https://github.com/alistair23/qemu.git tags/pull-risc

[PULL 1/1] Revert "hw/riscv/virt.c: imsics DT: add '#msi-cells'"

From: Andrew Jones This reverts commit f42cdf2ea5b3a1dc369792d7acbf9cd3e5c90815. Linux does not properly handle '#msi-cells=<0>' when searching for MSI controllers for PCI devices which results in the devices being unable to use MSIs. A patch for Linux has been sent[1] but until it, or something

Re: [PATCH 5/8] hw/pci-host/designware: Keep host reference in DesignwarePCIEViewport

Hi Phil, I think the title of this patch is also a bit misleading. The host reference is not present only in DesigwarePCIEViewport, it's also present, for instance, in DesignwarePCIERoot after the previous patch. This is also a back-pointer to host, so how about something like: "Add a back-point

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

On 2024/08/18 16:03, Michael S. Tsirkin wrote: On Sun, Aug 18, 2024 at 02:04:29PM +0900, Akihiko Odaki wrote: On 2024/08/09 21:50, Fabiano Rosas wrote: Peter Xu writes: On Thu, Aug 08, 2024 at 10:47:28AM -0400, Michael S. Tsirkin wrote: On Thu, Aug 08, 2024 at 10:15:36AM -0400, Peter Xu wro

Re: [PATCH 7/8] hw/pci-host/designware: Move MSI registers from root func to host bridge

Hi Phil On 10/12/23 9:18 AM, Philippe Mathieu-Daudé wrote: The MSI registers belong the the host bridge. Move the DesignwarePCIEMSI field to the host bridge state. I would say MSI registers are more tied to the PCI/PCIe network side than to the host side. The MSI registers control if an interr

Re: [PATCH 6/8] hw/pci-host/designware: Move viewports from root func to host bridge

Hi Phil, On 10/12/23 9:18 AM, Philippe Mathieu-Daudé wrote: As mentioned in previous commit, the PCI root function is irrelevant for the ViewPorts. Move the fields to the host bridge state. This is a migration compatibility break for the machines using the i.MX7 SoC (currently the mcimx7d-sabre

Re: [PATCH 4/8] hw/pci-host/designware: Hoist host controller in root function #0

Hi Phil, I think the title of this patch is bit misleading. You're not moving host into root, but rather adding a reference of host inside the root. Maybe change it to something like: "Add a back-pointer to the host in the root"? On 10/12/23 9:18 AM, Philippe Mathieu-Daudé wrote: There is a

Re: [PATCH 8/8] hw/pci-host/designware: Create ViewPorts during host bridge realization

Hi Phil, On 10/12/23 9:18 AM, Philippe Mathieu-Daudé wrote: ViewPorts are managed by the host bridge part, so create them when the host bridge is realized. The host bridge become the nit: becomes owner of the memory regions. The PCI root function realize() method now only contains PCI spec

Re: [PATCH 3/8] hw/pci-host/designware: Add 'host_mem' variable for clarity

Hi Phil, On 10/12/23 9:18 AM, Philippe Mathieu-Daudé wrote: designware_pcie_root_realize() uses get_system_memory() as the "host side memory region", as opposed to the "PCI side" one. Introduce the 'host_mem' variable for clarity. Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Peter Maydel

Re: [PATCH 1/8] hw/pci-host/designware: Declare CPU QOM types using DEFINE_TYPES() macro

Hi Phil, On 10/12/23 9:18 AM, Philippe Mathieu-Daudé wrote: When multiple QOM types are registered in the same file, it is simpler to use the the DEFINE_TYPES() macro. In particular because type array declared with such macro are easier to review. Remove a pointless structure declaration in "de

Re: [PATCH v3 2/3] hw/acpi: Upgrade ACPI SPCR table to support SPCR table version 4 format

Hi Jee Heng, On Mon, Aug 12, 2024 at 10:22:22PM -0700, Sia Jee Heng wrote: > Update the SPCR table to accommodate the SPCR Table version 4 [1]. > The SPCR table has been modified to adhere to the version 4 format [2]. > > [1]: > https://learn.microsoft.com/en-us/windows-hardware/drivers/serports

Re: [PATCH 2/8] hw/pci-host/designware: Initialize root function in host bridge realize

Hi Phil, On 10/12/23 9:18 AM, Philippe Mathieu-Daudé wrote: There are no root function properties exposed by the host bridge, so using a 2-step QOM creation isn't really useful. Simplify by creating the root function when the host bridge is realized. Signed-off-by: Philippe Mathieu-Daudé ---

Re: [PATCH v7 0/7] Add Rust build support, ARM PL011 device impl

On 8/16/2024 4:17 PM, Manos Pitsidianakis wrote: On Fri, 16 Aug 2024, 11:06 Junjie Mao, > wrote: On 8/15/2024 7:42 PM, Manos Pitsidianakis wrote: > Outstanding issues > == > > Outstanding issues that are not blocking for mer

Re: [PATCH 3/3] tests/acpi: Add expected ACPI SRAT AML file for RISC-V

On Fri, Aug 9, 2024 at 12:50 PM Haibo Xu wrote: > > As per the step 5 in the process documented in bios-tables-test.c, > generate the expected ACPI SRAT AML data file for RISC-V using the > rebuild-expected-aml.sh script and update the > bios-tables-test-allowed-diff.h. > > This is a new file bein

Re: [PATCH 2/3] tests/qtest/bios-tables-test.c: Enable numamem testing for RISC-V

On Fri, Aug 9, 2024 at 12:50 PM Haibo Xu wrote: > > Add ACPI SRAT table test case for RISC-V when NUMA was enabled. > > Signed-off-by: Haibo Xu Acked-by: Alistair Francis Alistair > --- > tests/qtest/bios-tables-test.c | 28 > 1 file changed, 28 insertions(+) > >

Re: [PATCH 1/3] tests/acpi: Add empty ACPI SRAT data file for RISC-V

On Fri, Aug 9, 2024 at 12:50 PM Haibo Xu wrote: > > As per process documented (steps 1-3) in bios-tables-test.c, add > empty AML data file for RISC-V ACPI SRAT table and add the entry > in bios-tables-test-allowed-diff.h. > > Signed-off-by: Haibo Xu Acked-by: Alistair Francis Alistair > --- >

Re: [PATCH v5 4/5] target/riscv: Add Smrnmi mnret instruction.

On Fri, Aug 9, 2024 at 6:12 PM Tommy Wu wrote: > > This patch adds a new instruction `mnret`. `mnret` is an M-mode-only > instruction that uses the values in `mnepc` and `mnstatus` to return to the > program counter, privilege mode, and virtualization mode of the > interrupted context. > > Signed-

Re: [PATCH v5 1/5] target/riscv: Add `ext_smrnmi` in the RISCVCPUConfig.

On Fri, Aug 9, 2024 at 6:12 PM Tommy Wu wrote: > > The boolean variable `ext_smrnmi` is used to determine whether the > Smrnmi extension exists. > > Signed-off-by: Frank Chang > Signed-off-by: Tommy Wu Reviewed-by: Alistair Francis Alistair > --- > target/riscv/cpu_cfg.h | 1 + > 1 file cha

Re: [PATCH v2 09/17] bsd-user: Add RISC-V thread setup and initialization support

On 8/17/24 03:09, Ajeet Singh wrote: From: Mark Corbin Implemented functions for setting up and initializing threads in the RISC-V architecture. The 'target_thread_set_upcall' function sets up the stack pointer, program counter, and function argument for new threads. The 'target_thread_init' fu

Re: [PATCH v2 07/17] bsd-user: Add RISC-V signal trampoline setup function

On 8/17/24 03:09, Ajeet Singh wrote: From: Mark Corbin Implemented the `setup_sigtramp` function for setting up the signal trampoline code in the RISC-V architecture. Signed-off-by: Mark Corbin Signed-off-by: Ajeet Singh Reviewed-by: Richard Henderson --- bsd-user/riscv/target_arch_sigtra

Re: [PATCH v2 01/17] bsd-user: Implement RISC-V CPU initialization and main loop

On 8/17/24 03:09, Ajeet Singh wrote: From: Mark Corbin Added the initial implementation for RISC-V CPU initialization and main loop. This includes setting up the general-purpose registers and program counter based on the provided target architecture definitions. Signed-off-by: Mark Corbin Sig

Re: [PATCH v1 05/15] tcg/riscv: Add riscv vset{i}vli support

On 2024/8/19 10:35, Richard Henderson wrote: On 8/19/24 11:34, LIU Zhiwei wrote: @@ -1914,6 +2029,11 @@ static void tcg_out_vec_op(TCGContext *s, TCGOpcode opc, const TCGArg args[TCG_MAX_OP_ARGS], const int const_args[TCG_MAX_OP_ARGS])

Re: [PATCH for-9.2 v3 0/6] target/sparc: emulate floating point queue when raising fp traps -- CORRECTION

On 8/18/24 10:03, Carl Hauser wrote: I changed translate.c:4597 from return true; to return advance_pc(dc); and it worked. Whoops, yes indeed. Thanks for the catch. r~

Re: [PATCH v1 05/15] tcg/riscv: Add riscv vset{i}vli support

On 8/19/24 11:34, LIU Zhiwei wrote: @@ -1914,6 +2029,11 @@ static void tcg_out_vec_op(TCGContext *s, TCGOpcode opc, const TCGArg args[TCG_MAX_OP_ARGS], const int const_args[TCG_MAX_OP_ARGS])   { +    TCGType type = vecl + TCG_TYPE_V64; + +

Re: [RFC] Virtualizing tagged disaggregated memory capacity (app specific, multi host shared)

On 24/08/15 05:22PM, Jonathan Cameron wrote: > Introduction > > > If we think application specific memory (including inter-host shared memory) > is > a thing, it will also be a thing people want to use with virtual machines, > potentially nested. So how do we present it at the Host t

Re: [PATCH v1 06/15] tcg/riscv: Implement vector load/store

On 2024/8/14 17:01, Richard Henderson wrote: On 8/13/24 21:34, LIU Zhiwei wrote: @@ -827,14 +850,59 @@ static void tcg_out_ldst(TCGContext *s, RISCVInsn opc, TCGReg data,   static void tcg_out_ld(TCGContext *s, TCGType type, TCGReg arg, TCGReg arg1, intptr_t arg2)   {

Re: [PATCH v1 05/15] tcg/riscv: Add riscv vset{i}vli support

On 2024/8/14 16:24, Richard Henderson wrote: On 8/13/24 21:34, LIU Zhiwei wrote: From: TANG Tiancheng In RISC-V, vector operations require initial configuration using the vset{i}vl{i} instruction. This instruction:    1. Sets the vector length (vl) in bytes    2. Configures the vtype regist

Re: [PATCH for-9.1 1/2] Revert "hw/riscv/virt.c: imsics DT: add '#msi-cells'"

On Sat, Aug 17, 2024 at 2:08 AM Andrew Jones wrote: > > This reverts commit f42cdf2ea5b3a1dc369792d7acbf9cd3e5c90815. > > Linux does not properly handle '#msi-cells=<0>' when searching for > MSI controllers for PCI devices which results in the devices being > unable to use MSIs. A patch for Linux

Re: [PATCH 2/2] hw/riscv/virt: Introduce strict-dt

On Sat, Aug 17, 2024 at 2:08 AM Andrew Jones wrote: > > Older firmwares and OS kernels which use deprecated device tree > properties or are missing support for new properties may not be > tolerant of fully compliant device trees. When divergence to the > bindings specifications is harmless for new

Re: [PATCH for-9.2 v6 03/12] hw/riscv: add RISC-V IOMMU base emulation

On 8/17/24 8:34 AM, Andrew Jones wrote: On Thu, Aug 01, 2024 at 12:43:24PM GMT, Daniel Henrique Barboza wrote: From: Tomasz Jeznach The RISC-V IOMMU specification is now ratified as-per the RISC-V international process. The latest frozen specifcation can be found at: https://github.com/ris

Re: Ping: Re: [PATCH v9 09/10] hw/nvme: add reservation protocal command

On Aug 6 04:56, 卢长奇 wrote: > Hi; > > Klaus, Does the test method in the above email work properly? > I assume it will; I was on conference and was catching up all of last week. I'll take action on this this week. > On 2024/7/26 17:53, 卢长奇 wrote: > > Hi; > > > > You can test it in spdk. > > Fi

Re: [PATCH v3 0/5] AWS Nitro Enclave emulation support

Thanks for the reviews. I have now posted a v4 at: https://mail.gnu.org/archive/html/qemu-devel/2024-08/msg02675.html Regards, Dorjoy

[PATCH v4 1/6] machine/nitro-enclave: New machine type for AWS Nitro Enclaves

AWS nitro enclaves[1] is an Amazon EC2[2] feature that allows creating isolated execution environments, called enclaves, from Amazon EC2 instances which are used for processing highly sensitive data. Enclaves have no persistent storage and no external networking. The enclave VMs are based on Firecr

[PATCH v4 4/6] machine/nitro-enclave: Add built-in Nitro Secure Module device

AWS Nitro Enclaves have built-in Nitro Secure Module (NSM) device which is used for stripped down TPM functionality like attestation. This commit adds the built-in NSM device in the nitro-enclave machine type. In Nitro Enclaves, all the PCRs start in a known zero state and the first 16 PCRs are lo

[PATCH v4 2/6] machine/nitro-enclave: Add vhost-user-vsock device

AWS Nitro Enclaves have built-in vhost-vsock device support which enables applications in enclave VMs to communicate with the parent EC2 VM over vsock. The enclave VMs have dynamic CID while the parent always has CID 3. In QEMU, the vsock emulation for nitro enclave is added using vhost-user-vsock

[PATCH v4 6/6] docs/nitro-enclave: Documentation for nitro-enclave machine type

--- docs/system/i386/nitro-enclave.rst | 82 ++ 1 file changed, 82 insertions(+) create mode 100644 docs/system/i386/nitro-enclave.rst diff --git a/docs/system/i386/nitro-enclave.rst b/docs/system/i386/nitro-enclave.rst new file mode 100644 index 00..291a8ae3

[PATCH v4 5/6] crypto: Support SHA384 hash when using glib

QEMU requires minimum glib version 2.66.0 as per the root meson.build file and per glib documentation[1] G_CHECKSUM_SHA384 is available since 2.51. [1] https://docs.gtk.org/glib/enum.ChecksumType.html Signed-off-by: Dorjoy Chowdhury --- crypto/hash-glib.c | 2 +- 1 file changed, 1 insertion(+),

[PATCH v4 0/6] AWS Nitro Enclave emulation support

This is v4 submission for AWS Nitro Enclave emulation in QEMU. From the QEMU side the implementation for nitro enclaves is complete. v3 is at: https://mail.gnu.org/archive/html/qemu-devel/2024-08/msg01594.html Changes in v4: - fixed error_setv assertion failed. I could not reproduce this but

[PATCH v4 3/6] device/virtio-nsm: Support for Nitro Secure Module device

Nitro Secure Module (NSM)[1] device is used in AWS Nitro Enclaves for stripped down TPM functionality like cryptographic attestation. The requests to and responses from NSM device are CBOR[2] encoded. This commit adds support for NSM device in QEMU. Although related to AWS Nitro Enclaves, the viri

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

On Sun, Aug 18, 2024 at 02:04:29PM +0900, Akihiko Odaki wrote: > On 2024/08/09 21:50, Fabiano Rosas wrote: > > Peter Xu writes: > > > > > On Thu, Aug 08, 2024 at 10:47:28AM -0400, Michael S. Tsirkin wrote: > > > > On Thu, Aug 08, 2024 at 10:15:36AM -0400, Peter Xu wrote: > > > > > On Thu, Aug 08,