[PATCH] acpihp: simplify acpi_pcihp_disable_root_bus

From: Ani Sinha Get rid of the static variable that keeps track of whether hotplug has been disabled on the root pci bus. Simply use qbus_is_hotpluggable() api to perform the same check. This eliminates additional if conditional and simplifies the function. Signed-off-by: Ani Sinha --- hw/acpi

Re: [RFC v2 1/2] hw/pci-host/gpex: Allow to generate preserve boot config DSM #5

Hi Eric, 在 2021/10/5 16:53, Eric Auger 写道: Add a 'preserve_config' field in struct GPEXConfig and if set generate the DSM #5 for preserving PCI boot configurations. The DSM presence is needed to expose RMRs. At the moment the DSM generation is not yet enabled. Signed-off-by: Eric Auger ---

Re: [PATCH v2 00/30] tcg/loongarch64: New tcg backend

Hi Richard, On 12/22/21 05:25, Richard Henderson wrote: Version 2: Dropped patch 31, the gitlab-ci change: Found errors in your .gitlab-ci.yml: 'cross-loongarch64-system' job needs 'loongarch64-cross-container' job but 'loongarch64-cross-container' is not in any previous stage 'cross-loongarch6

[PATCH] tests/docker: Add gentoo-loongarch64-cross image and run cross builds in GitLab

"MAKEOPTS=\"-j${J} -l${J}\"" >> /etc/portage/make.conf +echo "EGIT_CLONE_TYPE=shallow" >> /etc/portage/make.conf + +# these features are not supported in Docker +export FEATURES="-ipc-sandbox -network-sandbox" + +# populate Portage tree +GENTOO_M

Re: Fwd: VirtioSound device emulation implementation

Hi, I am sorry for the absence of activity on this. A couple of people very close to me died, and I also got busy with the linux kernel mentorship program for a while. It was a weird year. But I am back on this now. I have the basic functionality of the sound card working. I tested it on an ubunt

Re: [PATCH v5 02/14] hw/core/machine: Introduce CPU cluster topology support

Hi Philippe, Thanks for your review. On 2021/12/29 3:17, Philippe Mathieu-Daudé wrote: Hi, On 12/28/21 10:22, Yanan Wang wrote: The new Cluster-Aware Scheduling support has landed in Linux 5.16, which has been proved to benefit the scheduling performance (e.g. load balance and wake_affine stra

Re: [PATCH 0/3] Fix RVV calling incorrect RFV/RVD check functions bug

於 2021年12月29日 週三 上午10:13寫道： > From: Frank Chang > > For vector widening and narrowing floating-point instructions, we should > use require_scale_rvf() instead of require_rvf() to check whether the > correspond RVF/RVD is enabled if either source or destination > floating-point operand is double-

[PATCH 17/17] target/riscv: rvv-1.0: Allow Zve32f extension to be turned on

From: Frank Chang Signed-off-by: Frank Chang --- target/riscv/cpu.c | 1 + 1 file changed, 1 insertion(+) diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c index 5e98860a09..2b54c64f56 100644 --- a/target/riscv/cpu.c +++ b/target/riscv/cpu.c @@ -636,6 +636,7 @@ static Property riscv_cpu_pro

[PATCH 15/17] target/riscv: rvv-1.0: Add Zve32f support for widening type-convert insns

From: Frank Chang Vector widening conversion instructions are provided to and from all supported integer EEWs for Zve32f extension. Signed-off-by: Frank Chang --- target/riscv/insn_trans/trans_rvv.c.inc | 18 ++ 1 file changed, 18 insertions(+) diff --git a/target/riscv/insn_t

[PATCH 13/17] target/riscv: rvv-1.0: Add Zve32f support for scalar fp insns

From: Frank Chang Zve32f extension requires the scalar processor to implement the F extension and implement all vector floating-point instructions for floating-point operands with EEW=32 (i.e., no widening floating-point operations). Signed-off-by: Frank Chang --- target/riscv/insn_trans/trans

[PATCH 14/17] target/riscv: rvv-1.0: Add Zve32f support for single-width fp reduction insns

From: Frank Chang Vector single-width floating-point reduction operations for EEW=32 are supported for Zve32f extension. Signed-off-by: Frank Chang --- target/riscv/insn_trans/trans_rvv.c.inc | 1 + 1 file changed, 1 insertion(+) diff --git a/target/riscv/insn_trans/trans_rvv.c.inc b/target/

[PATCH 16/17] target/riscv: rvv-1.0: Add Zve32f support for narrowing type-convert insns

From: Frank Chang Vector narrowing conversion instructions are provided to and from all supported integer EEWs for Zve32f extension. Signed-off-by: Frank Chang --- target/riscv/insn_trans/trans_rvv.c.inc | 3 +++ 1 file changed, 3 insertions(+) diff --git a/target/riscv/insn_trans/trans_rvv.c

[PATCH 09/17] target/riscv: rvv-1.0: Add Zve64f support for narrowing type-convert insns

From: Frank Chang Vector narrowing conversion instructions are provided to and from all supported integer EEWs for Zve64f extension. Signed-off-by: Frank Chang --- target/riscv/insn_trans/trans_rvv.c.inc | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/target/riscv/

[PATCH 10/17] target/riscv: rvv-1.0: Allow Zve64f extension to be turned on

From: Frank Chang Signed-off-by: Frank Chang --- target/riscv/cpu.c | 1 + 1 file changed, 1 insertion(+) diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c index 01239620ca..38cd11a8ae 100644 --- a/target/riscv/cpu.c +++ b/target/riscv/cpu.c @@ -636,6 +636,7 @@ static Property riscv_cpu_pro

[PATCH 06/17] target/riscv: rvv-1.0: Add Zve64f support for scalar fp insns

From: Frank Chang Zve64f extension requires the scalar processor to implement the F extension and implement all vector floating-point instructions for floating-point operands with EEW=32 (i.e., no widening floating-point operations). Signed-off-by: Frank Chang --- target/riscv/insn_trans/trans

[PATCH 07/17] target/riscv: rvv-1.0: Add Zve64f support for single-width fp reduction insns

From: Frank Chang Vector single-width floating-point reduction operations for EEW=32 are supported for Zve64f extension. Signed-off-by: Frank Chang --- target/riscv/insn_trans/trans_rvv.c.inc | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/target/riscv/insn_trans/trans_rv

[PATCH 08/17] target/riscv: rvv-1.0: Add Zve64f support for widening type-convert insns

From: Frank Chang Vector widening conversion instructions are provided to and from all supported integer EEWs for Zve64f extension. Signed-off-by: Frank Chang --- target/riscv/insn_trans/trans_rvv.c.inc | 32 +++-- 1 file changed, 25 insertions(+), 7 deletions(-) diff --gi

[PATCH 12/17] target/riscv: rvv-1.0: Add Zve32f support for configuration insns

From: Frank Chang All Zve* extensions support the vector configuration instructions. Signed-off-by: Frank Chang --- target/riscv/insn_trans/trans_rvv.c.inc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/target/riscv/insn_trans/trans_rvv.c.inc b/target/riscv/insn_trans

[PATCH 05/17] target/riscv: rvv-1.0: Add Zve64f support for vsmul.vv and vsmul.vx insns

From: Frank Chang All Zve* extensions support all vector fixed-point arithmetic instructions, except that vsmul.vv and vsmul.vx are not supported for EEW=64 in Zve64*. Signed-off-by: Frank Chang --- target/riscv/insn_trans/trans_rvv.c.inc | 27 +++-- 1 file changed, 25 inse

[PATCH 04/17] target/riscv: rvv-1.0: Add Zve64f support for vmulh variant insns

From: Frank Chang All Zve* extensions support all vector integer instructions, except that the vmulh integer multiply variants that return the high word of the product (vmulh.vv, vmulh.vx, vmulhu.vv, vmulhu.vx, vmulhsu.vv, vmulhsu.vx) are not included for EEW=64 in Zve64*. Signed-off-by: Frank C

[PATCH 02/17] target/riscv: rvv-1.0: Add Zve64f support for configuration insns

From: Frank Chang All Zve* extensions support the vector configuration instructions. Signed-off-by: Frank Chang --- target/riscv/insn_trans/trans_rvv.c.inc | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/target/riscv/insn_trans/trans_rvv.c.inc b/target/riscv/insn_tra

[PATCH 11/17] target/riscv: rvv-1.0: Add Zve32f extension into RISC-V

From: Frank Chang Signed-off-by: Frank Chang --- target/riscv/cpu.c| 4 ++-- target/riscv/cpu.h| 1 + target/riscv/cpu_helper.c | 2 +- target/riscv/csr.c| 2 +- target/riscv/translate.c | 2 ++ 5 files changed, 7 insertions(+), 4 deletions(-) diff --git a/target/riscv

[PATCH 03/17] target/riscv: rvv-1.0: Add Zve64f support for load and store insns

From: Frank Chang All Zve* extensions support all vector load and store instructions, except Zve64* extensions do not support EEW=64 for index values when XLEN=32. Signed-off-by: Frank Chang --- target/riscv/insn_trans/trans_rvv.c.inc | 17 + 1 file changed, 13 insertions(+), 4

[PATCH 01/17] target/riscv: rvv-1.0: Add Zve64f extension into RISC-V

From: Frank Chang Signed-off-by: Frank Chang --- target/riscv/cpu.c| 4 target/riscv/cpu.h| 1 + target/riscv/cpu_helper.c | 5 - target/riscv/csr.c| 6 +- target/riscv/translate.c | 2 ++ 5 files changed, 16 insertions(+), 2 deletions(-) diff --git a/targ

[PATCH 00/17] Add RISC-V RVV Zve32f and Zve64f extensions

From: Frank Chang In RVV v1.0 spec, several Zve* vector extensions for embedded processors are defined in Chapter 18.2: https://github.com/riscv/riscv-v-spec/blob/v1.0/v-spec.adoc#zve-vector-extensions-for-embedded-processors This patchset implements Zve32f and Zve64f extensions. The port is av

[RFC PATCH] ui/vnc.c: Fixed a deadlock bug.

The GDB statck is as follows: (gdb) bt 0 __lll_lock_wait (futex=futex@entry=0x56211df20360, private=0) at lowlevellock.c:52 1 0x7f263caf20a3 in __GI___pthread_mutex_lock (mutex=0x56211df20360) at ../nptl/pthread_mutex_lock.c:80 2 0x56211a757364 in qemu_mutex_lock_impl (mutex=0x56211df2

[PATCH 3/3] target/riscv: rvv-1.0: Call the correct RVF/RVD check funtion for narrowing fp/int type-convert insns

From: Frank Chang vfncvt.f.xu.w, vfncvt.f.x.w convert double-width integer to single-width floating-point. Therefore, should use require_rvf() to check whether RVF/RVD is enabled. vfncvt.f.f.w, vfncvt.rod.f.f.w convert double-width floating-point to single-width integer. Therefore, should use re

[PATCH 2/3] target/riscv: rvv-1.0: Call the correct RVF/RVD check funtion for widening fp/int type-convert insns

From: Frank Chang vfwcvt.xu.f.v, vfwcvt.x.f.v, vfwcvt.rtz.xu.f.v and vfwcvt.rtz.x.f.v convert single-width floating-point to double-width integer. Therefore, should use require_rvf() to check whether RVF/RVD is enabled. vfwcvt.f.xu.v, vfwcvt.f.x.v convert single-width integer to double-width flo

[PATCH 1/3] target/riscv: rvv-1.0: Call the correct RVF/RVD check funtion for widening fp insns

From: Frank Chang Vector widening floating-point instructions should use require_scale_rvf() instead of require_rvf() to check whether RVF/RVD is enabled. --- target/riscv/insn_trans/trans_rvv.c.inc | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/target/riscv/ins

[PATCH 0/3] Fix RVV calling incorrect RFV/RVD check functions bug

From: Frank Chang For vector widening and narrowing floating-point instructions, we should use require_scale_rvf() instead of require_rvf() to check whether the correspond RVF/RVD is enabled if either source or destination floating-point operand is double-width of SEW. Otherwise, illegal instruct

Re: [PATCH v5 03/14] hw/core/machine: Wrap target specific parameters together

On 2021/12/29 3:23, Philippe Mathieu-Daudé wrote: On 12/28/21 10:22, Yanan Wang wrote: Wrap the CPU target specific parameters together into a single variable except generic sockets/cores/threads, to make related code lines shorter and more concise. No functional change intended. Signed-off-

RE: [PATCH] migration/colo.c: Add missed return in error handling

> -Original Message- > From: Rao, Lei > Sent: Tuesday, December 28, 2021 3:35 PM > To: Zhang, Chen ; zhanghaili...@xfusion.com; > quint...@redhat.com; dgilb...@redhat.com > Cc: qemu-devel@nongnu.org; Rao, Lei > Subject: [PATCH] migration/colo.c: Add missed return in error handling > >

Re: [PATCH v3 kvm/queue 06/16] KVM: Implement fd-based memory using MEMFD_OPS interfaces

On Fri, Dec 24, 2021, Chao Peng wrote: > On Fri, Dec 24, 2021 at 12:09:47AM +0100, Paolo Bonzini wrote: > > On 12/23/21 19:34, Sean Christopherson wrote: > > > > select HAVE_KVM_PM_NOTIFIER if PM > > > > + select MEMFD_OPS > > > MEMFD_OPS is a weird Kconfig name given that it's not ju

Re: [PATCH v3 kvm/queue 05/16] KVM: Maintain ofs_tree for fast memslot lookup by file offset

On Fri, Dec 24, 2021, Chao Peng wrote: > On Thu, Dec 23, 2021 at 06:02:33PM +, Sean Christopherson wrote: > > On Thu, Dec 23, 2021, Chao Peng wrote: > > > Similar to hva_tree for hva range, maintain interval tree ofs_tree for > > > offset range of a fd-based memslot so the lookup by offset rang

[PATCH 15/17] ppc/pnv: Introduce user creatable pnv-phb4 devices

This patch introduces pnv-phb4 user creatable devices that are created in a similar manner as pnv-phb3 devices, allowing the user to interact with the PHBs directly instead of creating PCI Express Controllers that will create a certain amount of PHBs per controller index. First thing we need is to

[PATCH 14/17] Revert "ppc/pnv: Introduce support for user created PHB4 devices"

The upcoming code that allows for user creatable pnv-phb4 devices relies on finding the correct pnv-phb4-pec controller to associate with. At this moment the code that added support for user creatable pnv-phb4-pec devices does not update chip9->pecs[] and pec->chip->num_pecs after pnv_pec_realize()

[PATCH 16/17] pnv_phb4.c: do not set 'root-bus' as bus name

This change has the same motivation as the one done for pnv-phb3-root-bus buses previously. Defaulting every bus to 'root-bus' makes it impossible to attach root ports to specific buses and it doesn't allow for custom bus naming because we're ignoring the 'id' value when registering the root bus.

[PATCH 12/17] pnv_phb4_pec.c: use 'default_enabled()' to init stack->phb

The next step before enabling user creatable pnv-phb4 devices is to decople the init of the stack->phb object from pnv_pec_stk_instance_init(). First, use 'defaults_enabled()' inside pnv_pec_realize() to create the stack->phb object, while removing the equivalent object_initiate_child() call from

[PATCH 13/17] pnv_phb4.h: turn phb into a pointer in struct PnvPhb4PecStack

At this moment, stack->phb is the plain PnvPHB4 device itself instead of a pointer to the device. This will present a problem when adding user creatable devices because we can't deal with this struct and the realize() callback from the user creatable device. We can't get rid of this attribute, sim

[PATCH 09/17] pnv_phb4_pec.c: move pnv_pec_phb_offset() to pnv_phb4.c

The logic inside pnv_pec_phb_offset() wiil be useful in the next patch to determine the stack that should contain a PHB4 device. Move the function to pnv_phb4.c and make it public since there's no pnv_phb4_pec.h header. While we're at it, add 'stack_index' as a parameter and make the function retu

[PATCH 17/17] pnv_phb4.c: change TYPE_PNV_PHB4_ROOT_BUS name

Similar to what was happening with pnv-phb3 buses, TYPE_PNV_PHB4_ROOT_BUS set to "pnv-phb4-root-bus" is a bit too long for a default root bus name. The usual default name for theses buses in QEMU are 'pcie', but we want to make a distinction between pnv-phb4 buses and other PCIE buses, at least as

[PATCH 11/17] pnv_phb4_pec.c: use pnv_pec_get_phb_id() in pnv_pec_dt_xscom()

Relying on stack->phb to write the xscom DT of the PEC is something that we won't be able to do with user creatable pnv-phb4 devices. Hopefully, this can be done by using pnv_pec_get_phb_id(), which is already used by pnv_pec_realize() to set the phb-id of the stack. Use the same idea in pnv_pec_d

[PATCH 10/17] pnv_phb4.c: introduce pnv_pec_init_stack_xscom()

The XSCOM address space of the stack must be populated after the initialization of its associated PHB4 is completed. At this moment this is always true because stk_realize() will always succeeds the realize of stack->phb, but that will not be the case with user creatable pnv-phb4 devices. Create a

[PATCH 08/17] pnv_phb4.c: introduce pnv_phb4_set_stack_phb_props()

We want to be able to support user creatable pnv-phb4 objects to allow users to instantiate a powernv9 machine similar to what it is done with powernv8. The main difference is that pnv-phb3 devs are attached directly to the system bus and can be created in the command line. PCI devices such as roo

[PATCH 07/17] pnv_phb4.c: check if root port exists in rc_config functions

pnv_phb4_rc_config_read() and pnv_phb4_rc_config_write() are asserting the existence of the root port. The root port is now optional, and there will be cases where a pnv-phb4 device won't have a root port attached. Instead of asserting, check if the root port exists before read/writing into it. S

[PATCH 03/17] pnv_phb3.h: change TYPE_PNV_PHB3_ROOT_BUS name

The TYPE_PNV_PHB3_ROOT_BUS name is used as the default bus name when the dev has no 'id'. However, pnv-phb3-root-bus is a bit too long to be used as a bus name. Most common QEMU buses and PCI controllers are named based on their bus type (e.g. pSeries spapr-pci-host-bridge is called 'pci'). The mo

[PATCH 05/17] pnv.c: simplify pnv_phb_attach_root_port()

The root port 'chassis' and 'slot' attributes are being set in the realize() callback of phb3_root_port and phb4_root_port. Remove the unneeded 'chassis' and 'slot' setting from pnv_phb_attach_root_port(). Signed-off-by: Daniel Henrique Barboza --- hw/ppc/pnv.c | 10 -- 1 file changed,

[PATCH 06/17] pnv_phb4.c: attach default root port in phb4 realize()

We're adding the default pnv_phb4_root_port in pnv_chip_power9_pec_realize() by going into each stack, from eack pec, accessing the stack PHB and adding the port. This will be an annoyance when trying to implement user creatable PHB4 devices because, when that happens, stack->phb is not guaranteed

[PATCH 04/17] pnv_phb4.c: add unique chassis and slot for pnv_phb4_root_port

A similar situation as described previously with pnv_phb3_root_port devices also happens with pnv_phb4_root_ports. The solution is the same: assign an unique chassis/slot combo for them. Signed-off-by: Daniel Henrique Barboza --- hw/pci-host/pnv_phb4.c | 15 +++ 1 file changed, 15 i

[PATCH 01/17] pnv_phb3.c: add unique chassis and slot for pnv_phb3_root_port

When creating a pnv_phb3_root_port using the command line, the first root port is created successfully, but the second fails with the following error: qemu-system-ppc64: -device pnv-phb3-root-port,bus=phb3-root.0,id=pcie.3: Can't add chassis slot, error -16 This error comes from the realize() fun

[PATCH 02/17] pnv_phb3.c: do not set 'root-bus' as bus name

All pnv-phb3-root-bus buses are being created as 'root-bus'. This makes it impossible to, for example, add a pnv-phb3-root-port in a specific root bus, since they all have the same name. By default the device will be parented by the pnv-phb3 device that precedeced it in the QEMU command line. More

[PATCH 00/17] ppc/pnv: enable pnv-phb4 user devices

Hi, This series implements pnv-phb4 user devices for the powernv9 machine. It also includes a couple of pnv-phb3 and pnv-phb3-root-port fixes that were also applied for the pnv4 equivalents. During the enablement I had to rollback from the previously added support for user creatable pnv-phb4-pec

Re: [PATCH v5 06/14] tests/unit/test-smp-parse: Keep default MIN/MAX CPUs in machine_base_class_init

On 12/28/21 10:22, Yanan Wang wrote: > Most machine types in test-smp-parse will be OK to have the default > MIN/MAX CPUs except "smp-generic-invalid", let's keep the default > values in machine_base_class_init which will be inherited. And if > we hope a different value for a specific machine, modi

Re: [PATCH v5 04/14] tests/unit/test-smp-parse: Add testcases for CPU clusters

On 12/28/21 10:22, Yanan Wang wrote: > Add testcases for parsing of the four-level CPU topology hierarchy, > ie sockets/clusters/cores/threads, which will be supported on ARM > virt machines. > > Signed-off-by: Yanan Wang > --- > tests/unit/test-smp-parse.c | 130

Re: [PATCH v5 03/14] hw/core/machine: Wrap target specific parameters together

On 12/28/21 10:22, Yanan Wang wrote: > Wrap the CPU target specific parameters together into a single > variable except generic sockets/cores/threads, to make related > code lines shorter and more concise. > > No functional change intended. > > Signed-off-by: Yanan Wang > --- > hw/core/machine-

Re: [PATCH v5 02/14] hw/core/machine: Introduce CPU cluster topology support

Hi, On 12/28/21 10:22, Yanan Wang wrote: > The new Cluster-Aware Scheduling support has landed in Linux 5.16, > which has been proved to benefit the scheduling performance (e.g. > load balance and wake_affine strategy) on both x86_64 and AArch64. > > So now in Linux 5.16 we have four-level arch-n

Re: [PATCH v5 01/14] qemu-options: Improve readability of SMP related Docs

On 12/28/21 10:22, Yanan Wang wrote: > We have a description in qemu-options.hx for each CPU topology > parameter to explain what it exactly means, and also an extra > declaration for the target-specific one, e.g. "for PC only" > when describing "dies", and "for PC, it's on one die" when > describi

[PATCH] hw/arm/virt: KVM: Enable PAuth when supported by the host

Add basic support for Pointer Authentication when running a KVM guest and that the host supports it, loosely based on the SVE support. Although the feature is enabled by default when the host advertises it, it is possible to disable it by setting the 'pauth=off' CPU property. Tested on an Apple M

Re: [PATCH] tests/tcg: Use $cpu in configure.sh

On 12/24/21 22:21, Richard Henderson wrote: > Use $cpu instead of $ARCH, which has been removed from > the top-level configure. > > Fixes: 823eb013452e Fixes: 823eb013452 ("configure, meson: move ARCH to meson.build") Reviewed-by: Philippe Mathieu-Daudé Tested-by: Philippe Mathieu-Daudé > Sig

Re: [PATCH] tests/tcg/hppa: Add float reference files

On 12/28/21 17:02, Philippe Mathieu-Daudé wrote: > Generated on PA8900 (PA-RISC 2.0). > > Signed-off-by: Philippe Mathieu-Daudé > --- > tests/tcg/hppa/float_convs.ref | 748 > tests/tcg/hppa/float_madds.ref | 768 + > 2 files chang

[PATCH] tests/tcg/hppa: Add float reference files

Generated on PA8900 (PA-RISC 2.0). Signed-off-by: Philippe Mathieu-Daudé --- tests/tcg/hppa/float_convs.ref | 748 tests/tcg/hppa/float_madds.ref | 768 + 2 files changed, 1516 insertions(+) create mode 100644 tests/tcg/hppa/float

Re: [PATCH v5 07/14] MAINTAINERS: Self-recommended as reviewer of "Machine core"

On 12/28/21 10:22, Yanan Wang wrote: > I've built interests in the generic machine subsystem and > have also been working on projects related to this part, > self-recommand myself as a reviewer so that I can help to > review some patches familiar to me, and have a chance to > learn more continuousl

Re: [PATCH v5 05/14] tests/unit/test-smp-parse: No need to explicitly zero MachineClass members

On 12/28/21 10:22, Yanan Wang wrote: > The default value of the MachineClass members is 0, which > means we don't have to explicitly zero them. Also the value > of "mc->smp_props.prefer_sockets" will be taken care of by > smp_parse_test(), we don't necessarily need the statement > in machine_base_c

Re: [PATCH 1/4] acpi: fix QEMU crash when started with SLIC table

On Monday, 27 December 2021 22:31:17 MSK Igor Mammedov wrote: > if QEMU is started with used provided SLIC table blob, > > -acpitable sig=SLIC,oem_id='CRASH > ',oem_table_id="ME",oem_rev=2210,asl_compiler_id="",asl_compiler_rev=00 > 00,data=/dev/null it will assert with: > > hw/acpi/a

Re: [PATCH v2 0/5] block-job: drop BlockJob.blk

27.12.2021 15:13, Nikta Lapshin wrote: On 12/24/21 18:35, Vladimir Sementsov-Ogievskiy wrote: Hi all! v2: rebase on master, fix iostest 283 Block jobs usually operate with several block nodes, and better to handle them symmetrically, than use one from s->common.blk and one from s->target (or

Re: [PATCH 6/6] migration: Test for ram capabilities

24.12.2021 14:11, Nikita Lapshin wrote: Use scripts/analyze-migration.py to split migration stream into sections and analyze its output. Signed-off-by: Nikita Lapshin --- .../tests/migrate-ram-capabilities-test | 96 +++ .../tests/migrate-ram-capabilities-test.out |

Re: [PATCH 5/6] migration: analyze-migration script changed

24.12.2021 14:11, Nikita Lapshin wrote: This script is used for RAM capabilities test. But it cannot work in case of no vm description in migration stream. So new flag is added to allow work this script with ram-only migration stream. Signed-off-by: Nikita Lapshin --- scripts/analyze-migratio

Re: [PATCH 4/6] migration: Add ram-only capability

24.12.2021 14:11, Nikita Lapshin wrote: If this capability is enabled migration stream will have RAM section only. Signed-off-by: Nikita Lapshin --- migration/migration.c | 20 +++- migration/migration.h | 1 + migration/savevm.c| 11 ++- qapi/migration.json

Re: [PATCH 1/6] migration: is_ram changed to is_iterable

24.12.2021 14:11, Nikita Lapshin wrote: For new migration capabilities upcoming we need to use something like is_ram for this purpose. This member of struction is true not only for RAM so it should be renamed. Signed-off-by: Nikita Lapshin Reviewed-by: Vladimir Sementsov-Ogievskiy -- Best re

Re: [PATCH 3/6] migration: Add no-ram capability

24.12.2021 14:11, Nikita Lapshin wrote: This capability disable RAM section in migration stream. Signed-off-by: Nikita Lapshin Probably we need some checks that new capability is not used together with ram-related capabilities, but that could be a separate patch. Reviewed-by: Vladimir Semen

[PATCH v2] hw/sd: Add SDHC support for SD card SPI-mode

From: Frank Chang In SPI-mode, SD card's OCR register: Card Capacity Status (CCS) bit is not set to 1 correclty when the assigned SD image size is larger than 2GB (SDHC). This will cause the SD card to be indentified as SDSC incorrectly. CCS bit should be set to 1 if we are using SDHC. Also, as

Re: [PATCH 2/6] migration: should_skip() implemented

Better subject: "migration: implement should_skip()" 24.12.2021 14:11, Nikita Lapshin wrote: For next changes it is convenient to make all decisions about sections skipping in one function. Signed-off-by: Nikita Lapshin Reviewed-by: Vladimir Sementsov-Ogievskiy -- Best regards, Vladimir

[PATCH v2] target/ppc: do not silence snan in xscvspdpn

From: Matheus Ferst The non-signalling versions of VSX scalar convert to shorter/longer precision insns doesn't silence SNaNs in the hardware. To better match this behavior, use the non-arithmatic conversion of helper_todouble instead of float32_to_float64. A test is added to prevent future regre

Re: [PATCH] target/ppc: Fix e6500 boot

>From: "Fabiano Rosas" faro...@linux.ibm.com >To: "ma...@locati.it" ma...@locati.it, c...@kaod.org >Cc: danielhb...@gmail.com, qemu-...@nongnu.org, qemu-devel@nongnu.org, >bala...@eik.bme.hu >Date: Mon, 27 Dec 2021 17:05:46 -0300 >Subject: Re: [PATCH] target/ppc: Fix e6500 boot > >"ma...@locati.it

Re: [PATCH v4 00/10] ARM virt: Introduce CPU clusters topology support

I have sent a v5 with four new patches added, so this v4 can be ignored. v5: https://patchew.org/QEMU/20211228092221.21068-1-wangyana...@huawei.com/ Thanks, Yanan On 2021/11/21 20:24, Yanan Wang wrote: Hi, This series introduces the new CPU clusters topology parameter and enable the support fo

Re: [PATCH] hw/sd: Add SDHC support for SD card SPI-mode

On 12/28/21 02:50, frank.ch...@sifive.com wrote: > From: Frank Chang > > In SPI-mode, SD card's OCR register: Card Capacity Status (CCS) bit > is not set to 1 correclty when the assigned SD image size is larger > than 2GB (SDHC). This will cause the SD card to be indentified as SDSC > incorrectly

Re: [PATCH 2/2] hw/dma: sifive_pdma: permit 4/8-byte access size of PDMA registers

On 12/28/21 01:52, Jim Shu wrote: > It's obvious that PDMA support 64-bit access of 64-bit registers, and > in previous commit, we confirm that PDMA support 32-bit access of both > 32/64-bit registers. Thus, we configure 32/64-bit memory access of > PDMA registers as valid in general. > > Signed-o

Re: [PATCH 1/2] hw/dma: sifive_pdma: support high 32-bit access of 64-bit register

Hi Jim and Frank, On 12/28/21 01:52, Jim Shu wrote: > Real PDMA support high 32-bit read/write memory access of 64-bit > register. > > The following result is PDMA tested in U-Boot on Unmatched board: > > 1. Real PDMA is allowed high 32-bit read/write to 64-bit register. > => mw.l 0x300 0x0

[PATCH v5 12/14] tests/acpi/bios-tables-test: Allow changes to virt/PPTT file

List test/data/acpi/virt/PPTT as the expected files allowed to be changed in tests/qtest/bios-tables-test-allowed-diff.h Signed-off-by: Yanan Wang --- tests/qtest/bios-tables-test-allowed-diff.h | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/qtest/bios-tables-test-allowed-diff.h b/te

[PATCH v5 14/14] tests/acpi/bios-table-test: Update expected virt/PPTT file

Run ./tests/data/acpi/rebuild-expected-aml.sh from build directory to update PPTT binary. Also empty bios-tables-test-allowed-diff.h. The disassembled differences between actual and expected PPTT: /* * Intel ACPI Component Architecture * AML/ASL+ Disassembler version 20180810 (64-bit version

[PATCH v5 13/14] hw/arm/virt-acpi-build: Support cluster level in PPTT generation

Support cluster level in generation of ACPI Processor Properties Topology Table (PPTT) for ARM virt machines. Signed-off-by: Yanan Wang --- hw/arm/virt-acpi-build.c | 15 +++ 1 file changed, 15 insertions(+) diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c index 3ce7

[PATCH v5 11/14] hw/arm/virt-acpi-build: Make an ARM specific PPTT generator

We have a generic build_pptt() in hw/acpi/aml-build.c but it's currently only used in ARM acpi initialization. Now we are going to support the new CPU cluster parameter which is currently only supported by ARM, it won't be a very good idea to add it to the generic build_pptt() as it will make the c

[PATCH v5 08/14] hw/arm/virt: Support clusters on ARM virt machines

In implementations of ARM64 architecture, at most there could be a CPU topology hierarchy like "sockets/dies/clusters/cores/threads" defined. For example, some ARM64 server chip Kunpeng 920 totally has 2 sockets, 2 NUMA nodes (also represent CPU dies range) in each socket, 6 clusters in each NUMA n

[PATCH v5 10/14] hw/acpi/aml-build: Improve scalability of PPTT generation

Currently we generate a PPTT table of n-level processor hierarchy with n-level loops in build_pptt(). It works fine as now there are only three CPU topology parameters. But the code may become less scalable with the processor hierarchy levels increasing. This patch only improves the scalability of

[PATCH v5 05/14] tests/unit/test-smp-parse: No need to explicitly zero MachineClass members

The default value of the MachineClass members is 0, which means we don't have to explicitly zero them. Also the value of "mc->smp_props.prefer_sockets" will be taken care of by smp_parse_test(), we don't necessarily need the statement in machine_base_class_init() either. Signed-off-by: Yanan Wang

[PATCH v5 07/14] MAINTAINERS: Self-recommended as reviewer of "Machine core"

I've built interests in the generic machine subsystem and have also been working on projects related to this part, self-recommand myself as a reviewer so that I can help to review some patches familiar to me, and have a chance to learn more continuously. Signed-off-by: Yanan Wang --- MAINTAINERS

[PATCH v5 09/14] hw/arm/virt: Support cluster level in DT cpu-map

Support one cluster level between core and physical package in the cpu-map of Arm/virt devicetree. This is also consistent with Linux Doc "Documentation/devicetree/bindings/cpu/cpu-topology.txt". Signed-off-by: Yanan Wang --- hw/arm/virt.c | 15 --- 1 file changed, 8 insertions(+), 7

[PATCH v5 06/14] tests/unit/test-smp-parse: Keep default MIN/MAX CPUs in machine_base_class_init

Most machine types in test-smp-parse will be OK to have the default MIN/MAX CPUs except "smp-generic-invalid", let's keep the default values in machine_base_class_init which will be inherited. And if we hope a different value for a specific machine, modify it in its own initialization function. Si

[PATCH v5 03/14] hw/core/machine: Wrap target specific parameters together

Wrap the CPU target specific parameters together into a single variable except generic sockets/cores/threads, to make related code lines shorter and more concise. No functional change intended. Signed-off-by: Yanan Wang --- hw/core/machine-smp.c | 17 ++--- 1 file changed, 10 insert

[PATCH v5 01/14] qemu-options: Improve readability of SMP related Docs

We have a description in qemu-options.hx for each CPU topology parameter to explain what it exactly means, and also an extra declaration for the target-specific one, e.g. "for PC only" when describing "dies", and "for PC, it's on one die" when describing "cores". Now we are going to introduce one

[PATCH v5 04/14] tests/unit/test-smp-parse: Add testcases for CPU clusters

Add testcases for parsing of the four-level CPU topology hierarchy, ie sockets/clusters/cores/threads, which will be supported on ARM virt machines. Signed-off-by: Yanan Wang --- tests/unit/test-smp-parse.c | 130 ++-- 1 file changed, 123 insertions(+), 7 deletion

[PATCH v5 02/14] hw/core/machine: Introduce CPU cluster topology support

The new Cluster-Aware Scheduling support has landed in Linux 5.16, which has been proved to benefit the scheduling performance (e.g. load balance and wake_affine strategy) on both x86_64 and AArch64. So now in Linux 5.16 we have four-level arch-neutral CPU topology definition like below and a new

[PATCH v5 00/14] ARM virt: Introduce CPU clusters topology support

Hi, This series introduces the new CPU clusters topology parameter and enable the support for it on ARM virt machines. Background and descriptions: The new Cluster-Aware Scheduling support has landed in Linux 5.16, which has been proved to benefit the scheduling performance (e.g. load balance and

Re: [PATCH v1 2/2] hw/arm/aspeed_ast2600: create i3c instance

On Thu, Dec 23, 2021 at 9:54 PM Cédric Le Goater wrote: > > On 12/22/21 10:23, Troy Lee wrote: > > This patch includes i3c instance in ast2600 soc. > > > > Signed-off-by: Troy Lee > > Looks good but it is based on the QEMU aspeed branch for OpenBMC. > You should rebase on upstream. > > Thanks, >

Re: [PATCH v1 1/2] hw/misc: Implementating dummy AST2600 I3C model

Hi, On Thu, Dec 23, 2021 at 9:48 PM Cédric Le Goater wrote: > > > Hello, > > On 12/22/21 10:23, Troy Lee wrote: > > Introduce a dummy AST2600 I3C model. > > > > Aspeed 2600 SDK enables I3C support by default. The I3C driver will try > > to reset the device controller and setup through device addr