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
--
}{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
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
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 IID
ult case in load_memop() while need_swap (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
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 i
O_UB ^
MO_BSWAP). Let's carefully don't 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/
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
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
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:
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:
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
[+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
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
xtern struct its_collection *its_create_collection(u32 col_id, u32 target_pe);
Maybe use 'u16 col_id'?
Besides,
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
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
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
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
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
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
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 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
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
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
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
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
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:
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 -
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:
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
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/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 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 */);
+
omment a bit.
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..4
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
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/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
[+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
This works for me.
Tested-by: 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/
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/
[+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
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
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-
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
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
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
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 +--
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.
.-. .--
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
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
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.
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
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
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
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
.
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
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
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
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
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
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.
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
: 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
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
, QEMU exits
with "kvm_set_irq: Invalid argument".
For the series:
Tested-by: Zenghui Yu
together with [2], [3].
Best Regards
Eric
References:
[1] Can we boot a 512U kvm guest?
https://patchwork.kernel.org/patch/11091501/
[2] [PATCH] KVM: arm/arm64: vgic: Allow more than 256
qemu exits with "kvm_set_irq: Invalid argument"
message.
Signed-off-by: Eric Auger
Reported-by: Zenghui Yu
---
hw/intc/arm_gic_kvm.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/hw/intc/arm_gic_kvm.c b/hw/intc/arm_gic_kvm.c
index b56fda144f..889293e9
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
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 +++
lib/arm/gic-v3-its.c
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, characterized
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
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
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
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 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/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
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
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!
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
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
> >
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..
>
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
--
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
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
* 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
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
Zenghui Yu (2):
hw/intc/arm_gicv3_kvm: Remove writes to ICPENDR registers
hw/intc/arm_gicv3_kvm: Write all 1's to clear enable/active
hw/intc/arm_gicv3_kvm.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
--
2.34.1
://docs.kernel.org/virt/kvm/devices/arm-vgic-v3.html
Signed-off-by: Zenghui Yu
---
hw/intc/arm_gicv3_kvm.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/hw/intc/arm_gicv3_kvm.c b/hw/intc/arm_gicv3_kvm.c
index 8ed88e7429..f798a6e28c 100644
--- a/hw/intc/arm_gicv3_kvm.c
+++ b/hw
atus.
Signed-off-by: Zenghui Yu
---
hw/intc/arm_gicv3_kvm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/intc/arm_gicv3_kvm.c b/hw/intc/arm_gicv3_kvm.c
index f798a6e28c..6166283cd1 100644
--- a/hw/intc/arm_gicv3_kvm.c
+++ b/hw/intc/arm_gicv3_kvm.c
@@ -295,7 +295,7 @@ static
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
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
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
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
'-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
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
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
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
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;
+
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
1 - 100 of 116 matches
Mail list logo
