Hi Philippe,
On 2025/7/15 04:04, Philippe Mathieu-Daudé wrote:
> On 14/7/25 18:01, Zenghui Yu wrote:
> > Quoting Peter Maydell:
> >
> > " hvf_sysreg_read_cp() and hvf_sysreg_write_cp() do not check the .access
> > field of the ARMCPRegInfo to ensure that
* From v1 [1]:
- add patch #1, as suggested by Peter
[1] https://lore.kernel.org/r/20250315132030.95209-1-zenghui...@linux.dev
Zenghui Yu (2):
hvf: arm: Add permission check in GIC sysreg handlers
hvf: arm: Emulate ICC_RPR_EL1 accesses properly
target/arm/hvf/hvf.c | 8
1 file
quot;)
Signed-off-by: Zenghui Yu
---
target/arm/hvf/hvf.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/target/arm/hvf/hvf.c b/target/arm/hvf/hvf.c
index 1db0b77fb6..df556626ce 100644
--- a/target/arm/hvf/hvf.c
+++ b/target/arm/hvf/hvf.c
@@ -1368,6 +1368,7 @@ static int hvf_sysreg_read(CPUStat
uot;
Before we add more registers in GIC sysreg handlers, let's get it correct
by adding the .access checks to hvf_sysreg_read_cp() and
hvf_sysreg_write_cp(). With that, a sysreg access with invalid permission
will result in an UNDEFINED exception.
Suggested-by: Peter Maydell
Signed-off-by
r,
let's just remove it from this trace event.
Signed-off-by: Zenghui Yu
---
target/arm/hvf/hvf.c| 2 +-
target/arm/hvf/trace-events | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/target/arm/hvf/hvf.c b/target/arm/hvf/hvf.c
index c9cfcdc08b..8f93e42b34 100644
--
Hi Peter,
Sorry for the long delay..
On 2025/3/21 00:55, Zenghui Yu wrote:
> On 2025/3/19 00:56, Peter Maydell wrote:
> >
> > ICC_RPR_EL1 is a read-only register.
>
> Yup! Writes to it should result in an UNDEFINED exception. I completely
> missed that point..
>
On 2025/3/19 00:56, Peter Maydell wrote:
> On Sat, 15 Mar 2025 at 13:21, Zenghui Yu wrote:
> >
> > Commit a2260983c655 ("hvf: arm: Add support for GICv3") added GICv3 support
> > by implementing emulation for a few system registers. ICC_RPR_EL1 was
> >
Commit a2260983c655 ("hvf: arm: Add support for GICv3") added GICv3 support
by implementing emulation for a few system registers. ICC_RPR_EL1 was
defined but not plugged in the sysreg handlers (for no good reason).
Fix it.
Signed-off-by: Zenghui Yu
---
target/arm/hvf/hvf.c | 2
g just before running each vCPU for the first time,
> the GIC will definitely be fully initialised at that point.
>
> Signed-off-by: Phil Dennis-Jordan
> ---
> target/arm/hvf/hvf.c | 17 ++---
> 1 file changed, 10 insertions(+), 7 deletions(-)
Tested-by: Zenghui Yu
Thanks!
+Cc maintainers and author of [1]
On 2024/9/21 19:33, 贾庆彤 via wrote:
> When start qemu with -rtc base=utc,clock=vm, sometime guest time can
> slower 3s than host.
>
> There's no problem (also didn't be noticed) as we often start ntp
> service, who will adjust our system time.
>
> But let's talk
Hi Alexander,
On 2021/9/16 23:53, Alexander Graf wrote:
+int hvf_arch_init_vcpu(CPUState *cpu)
+{
+ARMCPU *arm_cpu = ARM_CPU(cpu);
+CPUARMState *env = &arm_cpu->env;
+uint32_t sregs_match_len = ARRAY_SIZE(hvf_sreg_match);
+uint32_t sregs_cnt = 0;
+uint64_t pfr;
+hv_retur
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}. With
}{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
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
--
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 |
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;
+
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 th
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
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 Vir
[ +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 thi
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 allowe
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 deal
[ 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} prope
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 and
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);
+ write_regn_el0(pmev
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, 0,
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
ooting in EL2 on the virt board (ie with -machine
virtualization=on).
Reported-by: Zenghui Yu
Signed-off-by: Peter Maydell
Reviewed-by: Zenghui Yu
'-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-ac
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
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(&cpu->env, ARM_FEATURE_V8);
+set_feature(&cpu->env, ARM_FEATURE_NEON);
+set_feature(&cpu->e
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, 6
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
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"
+#
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
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
}
Regardless, thanks for the fix.
Reviewed-and-tested-by: Zenghui Yu
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
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
seen
[+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 Gen
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 01d21
[+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 to get
d=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/
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/
This works for me.
Tested-by: 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.
I
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 wit
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-
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 c
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
note: 'name' was declared 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-
here
g_autofree 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 +--
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 +
here
g_autofree 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
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.
.-. .--
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.
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
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
: 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
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
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.
that we won'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: Pe
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
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?
A
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
.
I don't 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: Ze
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/h
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
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
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
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
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
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 e
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
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 phase
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
Reviewed-by
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
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);
+ write
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
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 its_prerequisites(i
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
LPI (cpuid=%d, intid=%d)",
+ 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
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
writeq(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
xtern struct its_collection *its_create_collection(u32 col_id, u32 target_pe);
Maybe use 'u16 col_id'?
Besides,
Reviewed-by: Zenghui Yu
Thanks
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 */);
+
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
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, b
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 -> v
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: Er
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 -
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
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 GENMAS
ned long n = SZ_64K >> PAGE_SHIFT;
+ 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_p
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 expected
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 and
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
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 b
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 gi
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 a
1 - 100 of 113 matches
Mail list logo
