Re: [PATCH] hvf: arm: Fix encodings for ID_AA64PFR1_EL1 and debug System registers

2024-05-05 Thread Zenghui Yu
On 2024/5/5 21:18, Alexander Graf wrote: On 03.05.24 19:34, Zenghui Yu wrote: We wrongly encoded ID_AA64PFR1_EL1 using {3,0,0,4,2} in hvf_sreg_match[] so we fail to get the expected ARMCPRegInfo from cp_regs hash table with the wrong key. Fix it with the correct encoding {3,0,0,4,1

[PATCH] hvf: arm: Fix encodings for ID_AA64PFR1_EL1 and debug System registers

2024-05-03 Thread Zenghui Yu
}{V,C}R_EL1 registers are also wrongly encoded with op0 == 14. It happens to work because HVF_SYSREG(CRn, CRm, 14, op1, op2) equals to HVF_SYSREG(CRn, CRm, 2, op1, op2), by definition. But we shouldn't rely on it. Fixes: a1477da3ddeb ("hvf: Add Apple Silicon support") Signed-off-by:

[PATCH] hvf: arm: Remove PL1_WRITE_MASK

2024-04-22 Thread Zenghui Yu
As it had never been used since the first commit a1477da3ddeb ("hvf: Add Apple Silicon support"). Signed-off-by: Zenghui Yu --- target/arm/hvf/hvf.c | 1 - 1 file changed, 1 deletion(-) diff --git a/target/arm/hvf/hvf.c b/target/arm/hvf/hvf.c index 65a5601804..015e96a6d3 100644 --

Re: [PATCH] tcg/aarch64: Fix patching of LDR in tb_target_set_jmp_target

2023-02-04 Thread Zenghui Yu via
On 2023/2/4 1:18, Richard Henderson wrote: 'offset' should be bits [23:5] of LDR instruction, rather than [4:0]. Fixes: d59d83a1c388 ("tcg/aarch64: Reorg goto_tb implementation") Reported-by: Zenghui Yu Signed-off-by: Richard Henderson --- tcg/aarch64/tcg-target.c.inc | 2 +- 1 fi

Re: [PULL 16/22] tcg/aarch64: Reorg goto_tb implementation

2023-01-31 Thread Zenghui Yu via
On 2023/1/18 7:10, Richard Henderson wrote: +void tb_target_set_jmp_target(const TranslationBlock *tb, int n, + uintptr_t jmp_rx, uintptr_t jmp_rw) +{ +uintptr_t d_addr = tb->jmp_target_addr[n]; +ptrdiff_t d_offset = d_addr - jmp_rx; +tcg_insn_unit insn;

Re: [PATCH v3 2/2] hw/arm/virt: Make accels in GIC finalize logic explicit

2023-01-11 Thread Zenghui Yu via
Hi Alexander, On 2022/12/23 17:01, Alexander Graf wrote: Let's explicitly list out all accelerators that we support when trying to determine the supported set of GIC versions. KVM was already separate, so the only missing one is HVF which simply reuses all of TCG's emulation code and thus has

Re: [PATCH v3 1/2] hw/arm/virt: Consolidate GIC finalize logic

2023-01-11 Thread Zenghui Yu via
through a single state machine to determine which target GIC mode that means for us. After this patch, the only user noticable changes should be consolidated error messages as well as TCG -M virt supporting -smp > 8 automatically. Signed-off-by: Alexander Graf Looks good, Reviewed-by: Zeng

Re: [PATCH 1/2] hw/arm/virt: Consolidate GIC finalize logic

2022-12-20 Thread Zenghui Yu via
On 2022/12/21 7:04, Alexander Graf wrote: diff --git a/include/hw/arm/virt.h b/include/hw/arm/virt.h index c7dd59d7f1..365d19f7a3 100644 --- a/include/hw/arm/virt.h +++ b/include/hw/arm/virt.h @@ -109,12 +109,12 @@ typedef enum VirtMSIControllerType { } VirtMSIControllerType; typedef enum

Re: [PATCH 0/2] hw/arm/virt: Handle HVF in finalize_gic_version()

2022-12-20 Thread Zenghui Yu via
[ +Eric who wrote finalize_gic_version() ] On 2022/12/21 7:04, Alexander Graf wrote: The finalize_gic_version() function tries to determine which GIC version the current accelerator / host combination supports. During the initial HVF porting efforts, I didn't realize that I also had to touch

Re: [PATCH] hvf: arm: Add support for GICv3

2022-12-20 Thread Zenghui Yu via
On 2022/12/20 15:37, Alexander Graf wrote: Hi Zenghui, On 20.12.22 08:14, Zenghui Yu wrote: On 2022/12/20 6:08, Alexander Graf wrote: We currently only support GICv2 emulation. Before looking into it, I think it's worth finalizing the GIC version in the hvf case - only v2 is allowed

Re: [PATCH] hvf: arm: Add support for GICv3

2022-12-19 Thread Zenghui Yu via
On 2022/12/20 6:08, Alexander Graf wrote: We currently only support GICv2 emulation. Before looking into it, I think it's worth finalizing the GIC version in the hvf case - only v2 is allowed and fail early if user selects the unsupported versions. Currently finalize_gic_version() does not

Re: [PATCH] target/arm: Use the max page size in a 2-stage ptw

2022-09-27 Thread Zenghui Yu via
[ Fix Marc's email address ] On 2022/9/13 21:56, Richard Henderson wrote: We had only been reporting the stage2 page size. This causes problems if stage1 is using a larger page size (16k, 2M, etc), but stage2 is using a smaller page size, because cputlb does not set large_page_{addr,mask}

Re: [kvm-unit-tests PATCH v4 07/12] arm: pmu: Basic event counter Tests

2022-09-20 Thread Zenghui Yu via
Hi Eric, On 2022/9/20 17:23, Eric Auger wrote: Hi Zenghui, On 9/19/22 16:30, Zenghui Yu wrote: Hi Eric, A few comments when looking through the PMU test code (2 years after the series was merged). Thank you for reviewing even after this time! Do you want to address the issues yourself

Re: [kvm-unit-tests PATCH v4 10/12] arm: pmu: test 32-bit <-> 64-bit transitions

2022-09-19 Thread Zenghui Yu via
Hi Eric, On 2020/4/3 15:13, Eric Auger wrote: +static void test_chain_promotion(void) +{ [...] + /* start as MEM_ACCESS/CPU_CYCLES and move to CHAIN/MEM_ACCESS */ + pmu_reset(); + write_regn_el0(pmevtyper, 0, MEM_ACCESS | PMEVTYPER_EXCLUDE_EL0); +

Re: [kvm-unit-tests PATCH v4 08/12] arm: pmu: Test SW_INCR event count

2022-09-19 Thread Zenghui Yu via
Hi Eric, On 2020/4/3 15:13, Eric Auger wrote: +static void test_sw_incr(void) +{ + uint32_t events[] = {SW_INCR, SW_INCR}; + int i; + + if (!satisfy_prerequisites(events, ARRAY_SIZE(events))) + return; + + pmu_reset(); + + write_regn_el0(pmevtyper,

Re: [kvm-unit-tests PATCH v4 07/12] arm: pmu: Basic event counter Tests

2022-09-19 Thread Zenghui Yu via
Hi Eric, A few comments when looking through the PMU test code (2 years after the series was merged). On 2020/4/3 15:13, Eric Auger wrote: Adds the following tests: - event-counter-config: test event counter configuration - basic-event-count: - programs counters #0 and #1 to count 2 required

Re: [PATCH for-7.1] target/arm: Don't report Statistical Profiling Extension in ID registers

2022-08-11 Thread Zenghui Yu via
board (ie with -machine virtualization=on). Reported-by: Zenghui Yu Signed-off-by: Peter Maydell Reviewed-by: Zenghui Yu

[PATCH] hw/arm/virt-acpi-build: Present the GICR structure properly for GICv4

2022-08-11 Thread Zenghui Yu via
and '-machine gic-version=4'. While at it, let's convert the remaining hard coded gic_version into enumeration VIRT_GIC_VERSION_2 for consistency. Signed-off-by: Zenghui Yu --- hw/arm/virt-acpi-build.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/hw/arm/virt-acpi-build.c b/hw

Re: [PATCH v6 24/24] target/arm: Define neoverse-n1

2022-08-11 Thread Zenghui Yu via
On 2022/8/11 0:47, Peter Maydell wrote: On Wed, 10 Aug 2022 at 14:14, Zenghui Yu wrote: The r4p1 TRM says that the Neoverse N1 core supports SPE (the value of ID_AA64DFR0.PMSVer is 0b0001) but do we really support SPE emulation in QEMU? The guest immediately received an unexpected exception

Re: [PATCH v6 24/24] target/arm: Define neoverse-n1

2022-08-10 Thread Zenghui Yu via
On 2022/5/7 2:02, Richard Henderson wrote: +static void aarch64_neoverse_n1_initfn(Object *obj) +{ +ARMCPU *cpu = ARM_CPU(obj); + +cpu->dtb_compatible = "arm,neoverse-n1"; +set_feature(>env, ARM_FEATURE_V8); +set_feature(>env, ARM_FEATURE_NEON); +set_feature(>env,

Re: [PATCH 1/3] target/arm: Create kvm_arm_svm_supported

2022-07-25 Thread Zenghui Yu via
Hi Richard, On 2022/7/26 2:14, Richard Henderson wrote: Indication for support for SVE will not depend on whether we perform the query on the main kvm_state or the temp vcpu. Mirror kvm_arm_pauth_supported. Signed-off-by: Richard Henderson --- target/arm/kvm64.c | 7 ++- 1 file changed,

Re: [PATCH v7 01/92] target/arm: Add ID_AA64ZFR0 fields and isar_feature_aa64_sve2

2022-07-25 Thread Zenghui Yu via
Hi Richard, On 2021/5/25 9:02, Richard Henderson wrote: Will be used for SVE2 isa subset enablement. Reviewed-by: Alex Bennée Signed-off-by: Richard Henderson --- v2: Do not read zfr0 from kvm unless sve is available. v7: Move zfr0 read inside existing sve_enabled block. [...] diff --git

Re: [PATCH] target/arm/hvf: Include missing "cpregs.h"

2022-05-26 Thread Zenghui Yu via
On 2022/5/26 0:19, Philippe Mathieu-Daudé wrote: diff --git a/target/arm/hvf/hvf.c b/target/arm/hvf/hvf.c index 86710509d2..1fdc5eef92 100644 --- a/target/arm/hvf/hvf.c +++ b/target/arm/hvf/hvf.c @@ -17,6 +17,7 @@ #include "sysemu/hvf_int.h" #include "sysemu/hw_accel.h" #include "hvf_arm.h"

Re: [PATCH 4/4] target/arm: Use CPTR_TFP with CPTR_EL3 in fp_exception_el

2022-01-29 Thread Zenghui Yu via
On 2022/1/27 14:34, Richard Henderson wrote: Use the named bit rather than a bare extract32. Signed-off-by: Richard Henderson Reviewed-by: Zenghui Yu

Re: [PATCH 2/4] target/arm: Tidy sve_exception_el for CPACR_EL1 access

2022-01-28 Thread Zenghui Yu via
On 2022/1/27 14:34, Richard Henderson wrote: Extract entire fields for ZEN and FPEN, rather than testing specific bits. This makes it easier to follow the code versus the ARM spec. Signed-off-by: Richard Henderson Reviewed-by: Zenghui Yu

Re: [PATCH 3/4] target/arm: Fix {fp,sve}_exception_el for VHE mode running

2022-01-28 Thread Zenghui Yu via
Regardless, thanks for the fix. Reviewed-and-tested-by: Zenghui Yu

Re: [PATCH 1/4] target/arm: Fix sve_zcr_len_for_el for VHE mode running

2022-01-28 Thread Zenghui Yu via
On 2022/1/27 14:34, Richard Henderson wrote: When HCR_EL2.{E2H,TGE} == '11', ZCR_EL1 is unused. Reported-by: Zenghui Yu Signed-off-by: Richard Henderson Reviewed-by: Zenghui Yu

[Q] arm: SVE accesses at EL0 is broken with E2H+TGE?

2022-01-12 Thread Zenghui Yu via
Hi, I've just exercised the SVE emulation in QEMU with | `qemu-system-aarch64 -M virt,virtualization=on,gic-version=3 \ | -cpu max -accel tcg [...]` Since QEMU sets ID_AA64MMFR1_EL1.VH for -cpu max, the Linux guest I use was booting with VHE enabled and running with E2H+TGE. But I've then

Re: GICv3 for MTTCG

2021-05-11 Thread Zenghui Yu
[+Shashi] On 2021/5/12 1:51, Andrey Shinkevich wrote: Dear colleagues, I am looking for ways to accelerate the MTTCG for ARM guest on x86-64 host. The maximum number of CPUs for MTTCG that uses GICv2 is limited by 8: include/hw/intc/arm_gic_common.h:#define GIC_NCPU 8 The version 3 of the

[PATCH] vhost-vdpa: Make vhost_vdpa_get_device_id() static

2021-04-13 Thread Zenghui Yu
As it's only used inside hw/virtio/vhost-vdpa.c. Signed-off-by: Zenghui Yu --- hw/virtio/vhost-vdpa.c | 4 ++-- include/hw/virtio/vhost-vdpa.h | 2 -- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/hw/virtio/vhost-vdpa.c b/hw/virtio/vhost-vdpa.c index 01d2101d09

Re: [PATCH v3] multi-process: Initialize variables declared with g_auto*

2021-04-06 Thread Zenghui Yu
[+Stefan] On 2021/3/12 19:21, Zenghui Yu wrote: Quote docs/devel/style.rst (section "Automatic memory deallocation"): * Variables declared with g_auto* MUST always be initialized, otherwise the cleanup function will use uninitialized stack memory Initialize @name properly

[PATCH] hw/arm/smmuv3: Emulate CFGI_STE_RANGE for an aligned range of StreamIDs

2021-04-02 Thread Zenghui Yu
=0}) instead. Rework the emulation a bit to get rid of the discrepancy with the spec. Signed-off-by: Zenghui Yu --- hw/arm/smmuv3.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c index 3b87324ce2..8705612535 100644 --- a/hw/arm/s

[PATCH] hw/arm/virt-acpi-build: Fix GSIV values of the {GERR, Sync} interrupts

2021-04-02 Thread Zenghui Yu
The GSIV values in SMMUv3 IORT node are not correct as they don't match the SMMUIrq enumeration, which describes the IRQ<->PIN mapping used by our emulated vSMMU. Fixes: a703b4f6c1ee ("hw/arm/virt-acpi-build: Add smmuv3 node in IORT table") Signed-off-by: Zenghui Yu --- hw/arm/v

Re: [PATCH for-6.0] Revert "target/arm: Make number of counters in PMCR follow the CPU"

2021-04-01 Thread Zenghui Yu
This works for me. Tested-by: Zenghui Yu

Re: [PATCH] target/arm: Make number of counters in PMCR follow the CPU

2021-03-31 Thread Zenghui Yu
[+kvmarm, Marc] On 2021/3/12 0:59, Peter Maydell wrote: Currently we give all the v7-and-up CPUs a PMU with 4 counters. This means that we don't provide the 6 counters that are required by the Arm BSA (Base System Architecture) specification if the CPU supports the Virtualization extensions.

Re: [PATCH v3 6/7] hw/arm/smmuv3: Fix SMMU_CMD_CFGI_STE_RANGE handling

2021-03-25 Thread Zenghui Yu
On 2021/3/25 23:09, Auger Eric wrote: Hi Zenghui, On 3/25/21 3:18 PM, Zenghui Yu wrote: which seems to be some bits that we had never taken into account. And what I'm saying is roughly something like below (compile tested), any thoughts? [...] Thanks for spotting this discrepancy

[PATCH] hw/arm/smmuv3: Drop unused CDM_VALID() and is_cd_valid()

2021-03-25 Thread Zenghui Yu
They were introduced in commit 9bde7f0674fe ("hw/arm/smmuv3: Implement translate callback") but never actually used. Drop them. Signed-off-by: Zenghui Yu --- hw/arm/smmuv3-internal.h | 7 --- 1 file changed, 7 deletions(-) diff --git a/hw/arm/smmuv3-internal.h b/hw/arm/smmuv3-

Re: [PATCH v3 6/7] hw/arm/smmuv3: Fix SMMU_CMD_CFGI_STE_RANGE handling

2021-03-25 Thread Zenghui Yu
On 2021/3/9 18:27, Eric Auger wrote: If the whole SID range (32b) is invalidated (SMMU_CMD_CFGI_ALL), @end overflows and we fail to handle the command properly. Once this gets fixed, the current code really is awkward in the sense it loops over the whole range instead of removing the currently

Re: [PATCH v3] multi-process: Initialize variables declared with g_auto*

2021-03-15 Thread Zenghui Yu
On 2021/3/15 13:48, Miroslav Rezanina wrote: Missing declaration without initialization in hw/s390x/s390-pci-vfio.c othwerwise correct. Will you send v4 with missing initialization or should I send then as another patch? I'd prefer the latter so that subsystem maintainers can take the separate

[PATCH v3] multi-process: Initialize variables declared with g_auto*

2021-03-12 Thread Zenghui Yu
lared here g_autofree char *name; ^~~~ Signed-off-by: Zenghui Yu Reviewed-by: Jagannathan Raman Reviewed-by: Philippe Mathieu-Daudé --- * From v2: - Add OS distro and compiler version into commit message - Add Philippe's R-b - Cc: qemu-triv...@nongnu.org

[PATCH v2] multi-process: Initialize variables declared with g_auto*

2021-03-03 Thread Zenghui Yu
char *name; ^~~~ Signed-off-by: Zenghui Yu Reviewed-by: Jagannathan Raman --- * From v1: - Move the suffix iteration out of the loop (Philippe) - Add Jagannathan's R-b hw/remote/memory.c | 5 ++--- hw/remote/proxy.c | 3 +-- 2 files changed, 3 insertions(+), 5

Re: [PATCH] multi-process: Initialize variables declared with g_auto*

2021-03-03 Thread Zenghui Yu
On 2021/3/3 18:17, Daniel P. Berrangé wrote: This is a bit wierd. There should only be risk of uninitialized variable if there is a 'return' or 'goto' statement between the variable declaration and and initialization, which is not the case in either scenario here. What OS distro and compiler +

[PATCH] multi-process: Initialize variables declared with g_auto*

2021-03-02 Thread Zenghui Yu
char *name; ^~~~ Signed-off-by: Zenghui Yu --- hw/remote/memory.c | 3 +-- hw/remote/proxy.c | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/hw/remote/memory.c b/hw/remote/memory.c index 32085b1e05..f5f735c15a 100644 --- a/hw/remote/memory.

Re: [RFC v10 00/25] intel_iommu: expose Shared Virtual Addressing to VMs

2021-02-25 Thread Zenghui Yu
Hi Yi, On 2020/9/10 18:56, Liu Yi L wrote: The high-level architecture for SVA virtualization is as below, the key design of vSVA support is to utilize the dual-stage IOMMU translation ( also known as IOMMU nesting translation) capability in host IOMMU. .-.

[PATCH v2] hw/arm/smmuv3: Fix addr_mask for range-based invalidation

2021-01-29 Thread Zenghui Yu
mmuv3: Get prepared for range invalidation") Signed-off-by: Zenghui Yu --- * From v1: - Fix the compilation error hw/arm/smmuv3.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c index bbca0e9f20..98b99d4fe8 100644 --- a/hw/arm/smmuv3.

Re: [PATCH] hw/arm/smmuv3: Fix addr_mask for range-based invalidation

2021-01-29 Thread Zenghui Yu
Hi Eric, On 2021/1/29 5:30, Auger Eric wrote: Hi Zenghui, On 1/28/21 9:25 AM, Auger Eric wrote: Hi Zenghui, On 12/25/20 10:50 AM, Zenghui Yu wrote: When performing range-based IOTLB invalidation, we should decode the TG field into the corresponding translation granule size so that we can

Re: [PATCH] hw/arm/smmuv3: Fix addr_mask for range-based invalidation

2020-12-25 Thread Zenghui Yu
On 2020/12/25 17:50, Zenghui Yu wrote: @@ -821,6 +821,8 @@ static void smmuv3_notify_iova(IOMMUMemoryRegion *mr, return; } granule = tt->granule_sz; +} else { +guanule = tg * 2 + 10; I'm embarrassed about that. s/guanule/gran

[PATCH] hw/arm/smmuv3: Fix addr_mask for range-based invalidation

2020-12-25 Thread Zenghui Yu
: Get prepared for range invalidation") Signed-off-by: Zenghui Yu --- hw/arm/smmuv3.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c index bbca0e9f20..65231c7d52 100644 --- a/hw/arm/smmuv3.c +++ b/hw/arm/smmuv3.c @@ -801,7 +801,7 @@ s

Re: [RFC v7 12/26] vfio: Set up nested stage mappings

2020-12-24 Thread Zenghui Yu
Hi Eric, On 2020/11/17 2:13, Eric Auger wrote: In nested mode, legacy vfio_iommu_map_notify cannot be used as there is no "caching" mode and we do not trap on map. On Intel, vfio_iommu_map_notify was used to DMA map the RAM through the host single stage. With nested mode, we need to setup the

Re: [PATCH] kvm: Take into account the unaligned section size when preparing bitmap

2020-12-14 Thread Zenghui Yu
Hi Keqian, Peter, On 2020/12/15 15:23, zhukeqian wrote: On 2020/12/14 23:36, Peter Xu wrote: On Mon, Dec 14, 2020 at 10:14:11AM +0800, zhukeqian wrote: [...] Though indeed I must confess I don't know how it worked in general when host page size != target page size, at least for migration.

[PATCH v2] kvm: Take into account the unaligned section size when preparing bitmap

2020-12-14 Thread Zenghui Yu
n't bother with those unaligned bits at the end of bitmap. I don't think this can happen in practice since the upper layer would provide us with the alignment guarantee. But kvm-all shouldn't rely on it. Carefully handle it in case someday we'll hit it. Acked-by: Peter Xu Signed-off-by: Zenghui

Re: [PATCH] kvm: Take into account the unaligned section size when preparing bitmap

2020-12-09 Thread Zenghui Yu
On 2020/12/10 5:09, Peter Xu wrote: On Wed, Dec 09, 2020 at 10:33:41AM +0800, Zenghui Yu wrote: Hi Peter, Thanks for having a look at it. On 2020/12/8 23:16, Peter Xu wrote: Hi, Zenghui, On Tue, Dec 08, 2020 at 07:40:13PM +0800, Zenghui Yu wrote: The kernel KVM_CLEAR_DIRTY_LOG interface

Re: [PATCH] kvm: Take into account the unaligned section size when preparing bitmap

2020-12-09 Thread Zenghui Yu
On 2020/12/10 10:53, zhukeqian wrote: On 2020/12/10 10:08, Peter Xu wrote: Keqian, On Thu, Dec 10, 2020 at 09:46:06AM +0800, zhukeqian wrote: Hi, I see that if start or size is not PAGE aligned, it also clears areas which beyond caller's expectation, so do we also need to consider this?

Re: [PATCH] kvm: Take into account the unaligned section size when preparing bitmap

2020-12-08 Thread Zenghui Yu
Hi Peter, Thanks for having a look at it. On 2020/12/8 23:16, Peter Xu wrote: Hi, Zenghui, On Tue, Dec 08, 2020 at 07:40:13PM +0800, Zenghui Yu wrote: The kernel KVM_CLEAR_DIRTY_LOG interface has align requirement on both the start and the size of the given range of pages. We have been

[PATCH] kvm: Take into account the unaligned section size when preparing bitmap

2020-12-08 Thread Zenghui Yu
think this can happen in practice since the upper layer would provide us with the alignment guarantee. I'm not sure if kvm-all could rely on it. And this patch is mainly intended to address correctness of the specific algorithm used inside kvm_log_clear_one_slot(). Signed-off-by: Zenghui Yu --- accel

[PATCH] pcie_aer: Fix help message of pcie_aer_inject_error command

2020-12-03 Thread Zenghui Yu
There is an interesting typo in the help message of pcie_aer_inject_error command. Use 'tlp' instead of 'tlb' to match the PCIe AER term. Signed-off-by: Zenghui Yu --- hmp-commands.hx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/hmp-commands.hx b/hmp-commands.hx index

[PATCH] vfio: Fix vfio_listener_log_sync function name typo

2020-12-03 Thread Zenghui Yu
There is an obvious typo in the function name of the .log_sync() callback. Spell it correctly. Signed-off-by: Zenghui Yu --- hw/vfio/common.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/hw/vfio/common.c b/hw/vfio/common.c index 6ff1daa763..d360d6f2da 100644 --- a/hw

[RFC] vfio/migration: The way we start dirty tracking for the VFIO container?

2020-12-03 Thread Zenghui Yu
Hi folks, I'm looking at the way we start dirty tracking for the vfio container (we start it at the save_setup stage of a device) and have a few questions about it. Please fix me up if I had missed something obvious. - We may end up with the situation where we try to get dirty bitmap of the

[PATCH] memory: Skip dirty tracking for un-migratable memory regions

2020-11-16 Thread Zenghui Yu
setting dirty_log_mask (DIRTY_MEMORY_MIGRATION). [1] https://lists.gnu.org/archive/html/qemu-devel/2020-11/msg03757.html Signed-off-by: Zenghui Yu --- softmmu/memory.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/softmmu/memory.c b/softmmu/memory.c index 71951fe4dc

Re: [RFC] vfio-pci/migration: Dirty logging of the Memory BAR region?

2020-11-16 Thread Zenghui Yu
On 2020/11/15 23:03, Paolo Bonzini wrote: On 15/11/20 15:31, Zenghui Yu wrote: diff --git a/softmmu/memory.c b/softmmu/memory.c index 71951fe4dc..0958db1a08 100644 --- a/softmmu/memory.c +++ b/softmmu/memory.c @@ -1806,7 +1806,10 @@ bool memory_region_is_ram_device(MemoryRegion *mr) uint8_t

[RFC] vfio-pci/migration: Dirty logging of the Memory BAR region?

2020-11-15 Thread Zenghui Yu
Hi folks, While trying the new vfio-pci migration on my arm64 server, I noticed an error at the very beginning: qemu-system-aarch64: kvm_set_user_memory_region: KVM_SET_USER_MEMORY_REGION failed, slot=5, start=0x80, size=0x10: Invalid argument The reason is that we've registered

Re: [PATCH v26 03/17] vfio: Add save and load functions for VFIO PCI devices

2020-10-21 Thread Zenghui Yu
On 2020/9/25 6:49, Alex Williamson wrote: +} else if (interrupt_type == VFIO_INT_MSIX) { +uint16_t offset; + +msix_load(pdev, f); +offset = pci_default_read_config(pdev, + pdev->msix_cap + PCI_MSIX_FLAGS + 1, 2); +/* load

[PATCH] [RFC] hw/arm/smmuv3: Set the restoration priority of the vSMMUv3 explicitly

2020-10-19 Thread Zenghui Yu
Ensure the vSMMUv3 will be restored before all PCIe devices so that DMA translation can work properly during migration. Signed-off-by: Zenghui Yu --- not sure if anything would actually go wrong... hw/arm/smmuv3.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/arm/smmuv3.c b/hw/arm

Re: [PATCH QEMU v25 00/17] Add migration support for VFIO devices

2020-09-23 Thread Zenghui Yu
On 2020/9/23 7:24, Kirti Wankhede wrote: Patch 4-9: - Generic migration functionality for VFIO device. * This patch set adds functionality for PCI devices, but can be extended to other VFIO devices. * Added all the basic functions required for pre-copy, stop-and-copy and resume

Re: [PATCH v26 03/17] vfio: Add save and load functions for VFIO PCI devices

2020-09-23 Thread Zenghui Yu
Hi Kirti, A few trivial comments from the first read through. On 2020/9/23 7:24, Kirti Wankhede wrote: These functions save and restore PCI device specific data - config space of PCI device. Used VMStateDescription to save and restore interrupt state. Signed-off-by: Kirti Wankhede

Re: [kvm-unit-tests PATCH v7 10/13] arm/arm64: ITS: INT functional tests

2020-04-02 Thread Zenghui Yu
Hi Eric, On 2020/4/2 16:50, Auger Eric wrote: Hi Zenghui, On 3/30/20 12:43 PM, Zenghui Yu wrote: Hi Eric, On 2020/3/20 17:24, Eric Auger wrote: Triggers LPIs through the INT command. the test checks the LPI hits the right CPU and triggers the right LPI intid, ie. the translation is correct

Re: [kvm-unit-tests PATCH v7 13/13] arm/arm64: ITS: pending table migration test

2020-03-30 Thread Zenghui Yu
On 2020/3/30 20:38, Auger Eric wrote: Hi Zenghui, [...] + +    ptr = gicv3_data.redist_base[pe0] + GICR_PENDBASER; +    pendbaser = readq(ptr); +    writeq(pendbaser & ~GICR_PENDBASER_PTZ, ptr); + +    ptr = gicv3_data.redist_base[pe1] + GICR_PENDBASER; +    pendbaser = readq(ptr); +   

Re: [kvm-unit-tests PATCH v7 06/13] arm/arm64: ITS: Introspection tests

2020-03-30 Thread Zenghui Yu
Hi Drew, On 2020/3/30 17:11, Andrew Jones wrote: On Mon, Mar 30, 2020 at 10:46:57AM +0200, Auger Eric wrote: Hi Zenghui, On 3/30/20 10:30 AM, Zenghui Yu wrote: [...] Otherwise I think we will end-up with memory corruption when writing the command queue.  But it seems that everything just

Re: [kvm-unit-tests PATCH v7 13/13] arm/arm64: ITS: pending table migration test

2020-03-30 Thread Zenghui Yu
Hi Eric, On 2020/3/20 17:24, Eric Auger wrote: Add two new migration tests. One testing the migration of a topology where collection were unmapped. The second test checks the migration of the pending table. Signed-off-by: Eric Auger [...] @@ -659,6 +678,15 @@ static int

Re: [kvm-unit-tests PATCH v7 12/13] arm/arm64: ITS: migration tests

2020-03-30 Thread Zenghui Yu
int(dev2, 20); + check_lpi_stats("dev2/eventid=20 triggers LPI 8195 en PE #3 after migration"); typo: s/en PE #3/on PE #3/ Reviewed-by: Zenghui Yu Thanks + + lpi_stats_expect(2, 8196); + its_send_int(dev7, 255); + check_lpi_stats("dev7/eventid=255 trig

Re: [kvm-unit-tests PATCH v7 10/13] arm/arm64: ITS: INT functional tests

2020-03-30 Thread Zenghui Yu
quot;, + lpi_stats.observed.cpu_id, + lpi_stats.observed.lpi_id); + } + } else { + pass = true; + } + report(pass, "%s", msg); +} This patch itself looks good to me, Reviewed-by: Zenghui Yu Thanks

Re: [kvm-unit-tests PATCH v7 09/13] arm/arm64: ITS: Commands

2020-03-30 Thread Zenghui Yu
e_valid(cmd, desc->its_mapd_cmd.valid); + its_fixup_cmd(cmd); + if (desc->verbose) + printf("ITS: MAPD devid=%d size = 0x%x itt=0x%lx valid=%d\n", + desc->its_mapd_cmd.dev->device_id, + size, itt_addr, desc->its_mapd_cmd.valid); + extra line. All of these are trivial things and feel free to ignore them, Reviewed-by: Zenghui Yu Thanks

Re: [kvm-unit-tests PATCH v7 06/13] arm/arm64: ITS: Introspection tests

2020-03-30 Thread Zenghui Yu
cbaser, its_data.base + GITS_CBASER); + + its_data.cmd_write = its_data.cmd_base; + writeq(0, its_data.base + GITS_CWRITER); +} Otherwise this looks good, Reviewed-by: Zenghui Yu Thanks

Re: [kvm-unit-tests PATCH v7 08/13] arm/arm64: ITS: Device and collection Initialization

2020-03-25 Thread Zenghui Yu
xtern struct its_collection *its_create_collection(u32 col_id, u32 target_pe); Maybe use 'u16 col_id'? Besides, Reviewed-by: Zenghui Yu Thanks

Re: [kvm-unit-tests PATCH v6 10/13] arm/arm64: ITS: INT functional tests

2020-03-12 Thread Zenghui Yu
On 2020/3/11 21:51, Eric Auger wrote: +static void test_its_trigger(void) +{ + struct its_collection *col3, *col2; + struct its_device *dev2, *dev7; + + if (its_prerequisites(4)) + return; + + dev2 = its_create_device(2 /* dev id */, 8 /* nb_ites */); +

Re: [kvm-unit-tests PATCH v5 10/13] arm/arm64: ITS: INT functional tests

2020-03-12 Thread Zenghui Yu
Hi Eric, On 2020/3/12 17:59, Auger Eric wrote: Hi Zenghui, On 3/12/20 10:19 AM, Zenghui Yu wrote: On 2020/3/11 22:00, Marc Zyngier wrote: That is still a problem with the ITS. There is no architectural way to report an error, even if the error numbers are architected... One thing we could

Re: [kvm-unit-tests PATCH v5 10/13] arm/arm64: ITS: INT functional tests

2020-03-12 Thread Zenghui Yu
On 2020/3/11 22:00, Marc Zyngier wrote: That is still a problem with the ITS. There is no architectural way to report an error, even if the error numbers are architected... One thing we could do though is to implement the stall model (as described in 5.3.2). It still doesn't give us the error,

Re: [kvm-unit-tests PATCH v5 13/13] arm/arm64: ITS: pending table migration test

2020-03-11 Thread Zenghui Yu
Hi Eric, On 2020/3/10 22:54, Eric Auger wrote: Add two new migration tests. One testing the migration of a topology where collection were unmapped. The second test checks the migration of the pending table. Signed-off-by: Eric Auger --- v4 -> v5: - move stub from header to arm/gic.c v3 ->

Re: [kvm-unit-tests PATCH v5 10/13] arm/arm64: ITS: INT functional tests

2020-03-11 Thread Zenghui Yu
Hi Eric, On 2020/3/10 22:54, Eric Auger wrote: Triggers LPIs through the INT command. the test checks the LPI hits the right CPU and triggers the right LPI intid, ie. the translation is correct. Updates to the config table also are tested, along with inv and invall commands. Signed-off-by:

Re: [kvm-unit-tests PATCH v5 09/13] arm/arm64: ITS: Commands

2020-03-11 Thread Zenghui Yu
Hi Eric, On 2020/3/10 22:54, Eric Auger wrote: Implement main ITS commands. The code is largely inherited from the ITS driver. Signed-off-by: Eric Auger --- v3 -> v4: - device's itt now is a VGA - pass verbose to choose whether we shall print the cmd - use printf instead of report_info v2

Re: [kvm-unit-tests PATCH v5 07/13] arm/arm64: ITS: its_enable_defaults

2020-03-11 Thread Zenghui Yu
On 2020/3/10 22:54, Eric Auger wrote: its_enable_defaults() enable LPIs at distributor level redistributor level and ITS level. gicv3_enable_defaults must be called before. Signed-off-by: Eric Auger Reviewed-by: Zenghui Yu Thanks

Re: [kvm-unit-tests PATCH v5 06/13] arm/arm64: ITS: Introspection tests

2020-03-11 Thread Zenghui Yu
Hi Eric, On 2020/3/10 22:54, Eric Auger wrote: +#define GITS_TYPER_PLPISBIT(0) +#define GITS_TYPER_VLPIS BIT(1) +#define GITS_TYPER_ITT_ENTRY_SIZE GENMASK_ULL(7, 4) +#define GITS_TYPER_ITT_ENTRY_SIZE_SHIFT4 +#define GITS_TYPER_IDBITS

Re: [kvm-unit-tests PATCH v5 05/13] arm/arm64: gicv3: Set the LPI config and pending tables

2020-03-11 Thread Zenghui Yu
FT; + unsigned long order = fls(n); + u64 prop_val; + int cpu; + + assert(!gicv3_redist_base()); I guess you wanted assert(gicv3_redist_base())? With this confirmed, Reviewed-by: Zenghui Yu Thanks + + gicv3_data.lpi_prop = alloc_pages(order); + + /* ID bits = 1

Re: [kvm-unit-tests PATCH v4 00/13] arm/arm64: Add ITS tests

2020-03-10 Thread Zenghui Yu
On 2020/3/9 20:00, Andrew Jones wrote: On Mon, Mar 09, 2020 at 12:57:51PM +0100, Andrew Jones wrote: This looks pretty good to me. It just needs some resquashing cleanups. Does Andre plan to review? I've only been reviewing with respect to the framework, not ITS. If no other reviews are

Re: [kvm-unit-tests PATCH v3 08/14] arm/arm64: ITS: its_enable_defaults

2020-03-04 Thread Zenghui Yu
Hi Eric, On 2020/3/4 22:26, Auger Eric wrote: Hi Zenghui, On 2/7/20 4:20 AM, Zenghui Yu wrote: Hi Eric, On 2020/1/28 18:34, Eric Auger wrote: its_enable_defaults() is the top init function that allocates the command queue and all the requested tables (device, collection, lpi config

Re: [kvm-unit-tests PATCH v3 09/14] arm/arm64: ITS: Device and collection Initialization

2020-02-06 Thread Zenghui Yu
Hi Eric, On 2020/1/28 18:34, Eric Auger wrote: Introduce an helper functions to register - a new device, characterized by its device id and the max number of event IDs that dimension its ITT (Interrupt Translation Table). The function allocates the ITT. - a new collection, characterized

Re: [kvm-unit-tests PATCH v3 08/14] arm/arm64: ITS: its_enable_defaults

2020-02-06 Thread Zenghui Yu
Hi Eric, On 2020/1/28 18:34, Eric Auger wrote: its_enable_defaults() is the top init function that allocates the command queue and all the requested tables (device, collection, lpi config and pending tables), enable LPIs at distributor level and ITS level. gicv3_enable_defaults must be called

Re: [kvm-unit-tests PATCH v3 06/14] arm/arm64: gicv3: Set the LPI config and pending tables

2020-02-06 Thread Zenghui Yu
Hi Eric, On 2020/1/28 18:34, Eric Auger wrote: Allocate the LPI configuration and per re-distributor pending table. Set redistributor's PROPBASER and PENDBASER. The LPIs are enabled by default in the config table. Also introduce a helper routine that allows to set the pending table bit for a

Re: [kvm-unit-tests PATCH v3 05/14] arm/arm64: ITS: Introspection tests

2020-02-06 Thread Zenghui Yu
Hi Eric, On 2020/1/28 18:34, Eric Auger wrote: Detect the presence of an ITS as part of the GICv3 init routine, initialize its base address and read few registers the IIDR, the TYPER to store its dimensioning parameters. Also parse the BASER registers. This is our first ITS test, belonging to

Re: [kvm-unit-tests PATCH v3 04/14] arm/arm64: gicv3: Add some re-distributor defines

2020-02-06 Thread Zenghui Yu
0x0070 +#define GICR_PENDBASER 0x0078 nit: we'd better use tab instead of space. Reviewed-by: Zenghui Yu +#define GICR_CTLR GICD_CTLR +#define GICR_CTLR_ENABLE_LPIS (1UL << 0) + #define ICC_SGI1R_AFFINITY_1_SHIFT16 #define ICC_SGI1

[PATCH v2] compiler.h: Don't use compile-time assert when __NO_INLINE__ is defined

2020-02-05 Thread Zenghui Yu
use the compile-time assert when no functions will be inlined into their callers. Reported-by: Euler Robot Suggested-by: Richard Henderson Signed-off-by: Zenghui Yu --- v2 is actually written by Richard Henderson. v1: https://lore.kernel.org/r/20200205081703.631-1-yuzeng...@huawei.com include/q

Re: [PATCH] memory: Use QEMU_ALWAYS_INLINE to silence compile-time warning

2020-02-05 Thread Zenghui Yu
Hi Richard, On 2020/2/5 18:31, Richard Henderson wrote: On 2/5/20 10:01 AM, Richard Henderson wrote: On 2/5/20 8:17 AM, Zenghui Yu wrote: Our robot reported the following compile-time warning while compiling Qemu with -fno-inline cflags: Why are you doing this? I'm not sure why

[PATCH] memory: Use QEMU_ALWAYS_INLINE to silence compile-time warning

2020-02-05 Thread Zenghui Yu
(size > 1) has already ensured that MO_UB is not involved. Apply QEMU_ALWAYS_INLINE on memop_size() to make sure it will always be inlined while we're using the compile-time assert, so that the compilers won't get confused. Reported-by: Euler Robot Signed-off-by: Zenghui Yu --- Not sure if i

[PATCH] hw/intc/arm_gicv3_kvm: Stop wrongly programming GICR_PENDBASER.PTZ bit

2020-01-19 Thread Zenghui Yu
it. Fixes: 367b9f527bec ("hw/intc/arm_gicv3_kvm: Implement get/put functions") Signed-off-by: Zenghui Yu --- hw/intc/arm_gicv3_kvm.c | 11 --- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/hw/intc/arm_gicv3_kvm.c b/hw/intc/arm_gicv3_kvm.c index 9c7f4ab871..49304ca589

Re: [kvm-unit-tests PATCH 05/16] arm/arm64: ITS: Introspection tests

2019-12-19 Thread Zenghui Yu
On 2019/12/18 16:34, Auger Eric wrote: Hi Zenghui, On 12/18/19 4:46 AM, Zenghui Yu wrote: Hi Eric, I have to admit that this is the first time I've looked into the kvm-unit-tests code, so only some minor comments inline :) no problem. Thank you for looking at this. By the way, with patch

Re: [kvm-unit-tests PATCH 12/16] arm/arm64: ITS: commands

2019-12-19 Thread Zenghui Yu
Hi Eric, On 2019/12/16 22:02, Eric Auger wrote: Implement main ITS commands. The code is largely inherited from the ITS driver. Signed-off-by: Eric Auger --- [...] diff --git a/lib/arm/asm/gic-v3-its.h b/lib/arm/asm/gic-v3-its.h index 245ef61..d074c17 100644 --- a/lib/arm/asm/gic-v3-its.h

Re: [kvm-unit-tests PATCH 11/16] arm/arm64: ITS: Device and collection Initialization

2019-12-19 Thread Zenghui Yu
Hi Eric, On 2019/12/16 22:02, Eric Auger wrote: Introduce an helper functions to register - a new device, characterized by its device id and the max number of event IDs that dimension its ITT (Interrupt Translation Table). The function allocates the ITT. - a new collection,

Re: [kvm-unit-tests PATCH 08/16] arm/arm64: ITS: Init the command queue

2019-12-19 Thread Zenghui Yu
Hi Eric, On 2019/12/16 22:02, Eric Auger wrote: Allocate the command queue and initialize related registers: CBASER, CREADR, CWRITER. The command queue is 64kB. This aims at not bothing with fullness. Signed-off-by: Eric Auger --- lib/arm/asm/gic-v3-its.h | 7 +++

Re: [kvm-unit-tests PATCH 06/16] arm/arm64: ITS: Test BASER

2019-12-19 Thread Zenghui Yu
Hi Eric, On 2019/12/16 22:02, Eric Auger wrote: Add helper routines to parse and set up BASER registers. Add a new test dedicated to BASER accesses. Signed-off-by: Eric Auger --- arm/gic.c| 20 ++ arm/unittests.cfg| 6 +++ lib/arm/asm/gic-v3-its.h | 17

Re: [kvm-unit-tests PATCH 05/16] arm/arm64: ITS: Introspection tests

2019-12-17 Thread Zenghui Yu
Hi Eric, I have to admit that this is the first time I've looked into the kvm-unit-tests code, so only some minor comments inline :) On 2019/12/16 22:02, Eric Auger wrote: Detect the presence of an ITS as part of the GICv3 init routine, initialize its base address and read few registers the

  1   2   >