* [XEN v2 00/12] Arm: Enable GICv3 for AArch32 (v8R)
@ 2022-10-31 15:13 Ayan Kumar Halder
2022-10-31 15:13 ` [XEN v2 01/12] xen/Arm: vGICv3: Sysreg emulation is applicable for Aarch64 only Ayan Kumar Halder
` (11 more replies)
0 siblings, 12 replies; 59+ messages in thread
From: Ayan Kumar Halder @ 2022-10-31 15:13 UTC (permalink / raw)
To: xen-devel
Cc: sstabellini, stefanos, julien, Volodymyr_Babchuk,
bertrand.marquis, burzalodowa, Ayan Kumar Halder
Hi All,
Please find the following patches to enable GICv3 for AArch32.
This is a pre-requisite to support Xen on Cortex-R52 (AArch32-v8R system)
Let me know your thoughts.
Changes from v1 :-
1. Updated in the changelog for each of the patches.
Ayan Kumar Halder (12):
xen/Arm: vGICv3: Sysreg emulation is applicable for Aarch64 only
xen/Arm: GICv3: Move the macros to compute the affnity level to
arm64/arm32
xen/Arm: vreg: Support vreg_reg64_* helpers on Aarch32
xen/Arm: vGICv3: Adapt emulation of GICR_TYPER for AArch32
xen/Arm: GICv3: Fix GICR_{PENDBASER, PROPBASER} emulation on 32-bit
host
xen/Arm: vGICv3: Fix emulation of ICC_SGI1R on AArch32
xen/Arm: GICv3: Define ICH_LR<n>_EL2 on AArch32
xen/Arm: GICv3: Define ICH_AP0R<n> and ICH_AP1R<n> for AArch32
xen/Arm: GICv3: Define GIC registers for AArch32
xen/Arm: GICv3: Use ULL instead of UL for 64bits
xen/Arm: GICv3: Define macros to read/write 64 bit
xen/Arm: GICv3: Enable GICv3 for AArch32
SUPPORT.md | 6 +
xen/arch/arm/Kconfig | 4 +-
xen/arch/arm/gic-v3-lpi.c | 8 +-
xen/arch/arm/gic-v3.c | 132 ++++++++++-----------
xen/arch/arm/include/asm/arm32/io.h | 21 ++++
xen/arch/arm/include/asm/arm32/processor.h | 5 +
xen/arch/arm/include/asm/arm32/sysregs.h | 18 ++-
xen/arch/arm/include/asm/arm64/processor.h | 8 ++
xen/arch/arm/include/asm/arm64/sysregs.h | 3 +
xen/arch/arm/include/asm/cpregs.h | 69 +++++++++++
xen/arch/arm/include/asm/cpufeature.h | 1 +
xen/arch/arm/include/asm/gic_v3_defs.h | 24 ++--
xen/arch/arm/include/asm/gic_v3_its.h | 2 +-
xen/arch/arm/include/asm/processor.h | 6 -
xen/arch/arm/include/asm/vreg.h | 88 ++++----------
xen/arch/arm/vgic-v3-its.c | 17 +--
xen/arch/arm/vgic-v3.c | 16 ++-
17 files changed, 255 insertions(+), 173 deletions(-)
--
2.17.1
^ permalink raw reply [flat|nested] 59+ messages in thread
* [XEN v2 01/12] xen/Arm: vGICv3: Sysreg emulation is applicable for Aarch64 only
2022-10-31 15:13 [XEN v2 00/12] Arm: Enable GICv3 for AArch32 (v8R) Ayan Kumar Halder
@ 2022-10-31 15:13 ` Ayan Kumar Halder
2022-10-31 17:43 ` Michal Orzel
2022-10-31 15:13 ` [XEN v2 02/12] xen/Arm: GICv3: Move the macros to compute the affnity level to arm64/arm32 Ayan Kumar Halder
` (10 subsequent siblings)
11 siblings, 1 reply; 59+ messages in thread
From: Ayan Kumar Halder @ 2022-10-31 15:13 UTC (permalink / raw)
To: xen-devel
Cc: sstabellini, stefanos, julien, Volodymyr_Babchuk,
bertrand.marquis, burzalodowa, Ayan Kumar Halder
Refer ARM DDI 0487G.b ID072021, EC==0b011000 is supported for Aarch64 state
only. Thus, vgic_v3_emulate_sysreg is enabled for CONFIG_ARM_64 only.
Signed-off-by: Ayan Kumar Halder <ayankuma@amd.com>
---
Changes from -
v1 - 1. Updated the commit message.
xen/arch/arm/vgic-v3.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 015446be17..3f4509dcd3 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -1519,6 +1519,7 @@ static bool vgic_v3_emulate_sgi1r(struct cpu_user_regs *regs, uint64_t *r,
}
}
+#ifdef CONFIG_ARM_64
static bool vgic_v3_emulate_sysreg(struct cpu_user_regs *regs, union hsr hsr)
{
struct hsr_sysreg sysreg = hsr.sysreg;
@@ -1539,6 +1540,7 @@ static bool vgic_v3_emulate_sysreg(struct cpu_user_regs *regs, union hsr hsr)
return false;
}
}
+#endif
static bool vgic_v3_emulate_cp64(struct cpu_user_regs *regs, union hsr hsr)
{
@@ -1562,8 +1564,10 @@ static bool vgic_v3_emulate_reg(struct cpu_user_regs *regs, union hsr hsr)
{
switch (hsr.ec)
{
+#ifdef CONFIG_ARM_64
case HSR_EC_SYSREG:
return vgic_v3_emulate_sysreg(regs, hsr);
+#endif
case HSR_EC_CP15_64:
return vgic_v3_emulate_cp64(regs, hsr);
default:
--
2.17.1
^ permalink raw reply related [flat|nested] 59+ messages in thread
* [XEN v2 02/12] xen/Arm: GICv3: Move the macros to compute the affnity level to arm64/arm32
2022-10-31 15:13 [XEN v2 00/12] Arm: Enable GICv3 for AArch32 (v8R) Ayan Kumar Halder
2022-10-31 15:13 ` [XEN v2 01/12] xen/Arm: vGICv3: Sysreg emulation is applicable for Aarch64 only Ayan Kumar Halder
@ 2022-10-31 15:13 ` Ayan Kumar Halder
2022-10-31 17:53 ` Michal Orzel
2022-11-02 8:46 ` Julien Grall
2022-10-31 15:13 ` [XEN v2 03/12] xen/Arm: vreg: Support vreg_reg64_* helpers on Aarch32 Ayan Kumar Halder
` (9 subsequent siblings)
11 siblings, 2 replies; 59+ messages in thread
From: Ayan Kumar Halder @ 2022-10-31 15:13 UTC (permalink / raw)
To: xen-devel
Cc: sstabellini, stefanos, julien, Volodymyr_Babchuk,
bertrand.marquis, burzalodowa, Ayan Kumar Halder
Refer https://elixir.bootlin.com/linux/v6.1-rc1/source/arch/arm64/ \
include/asm/cputype.h#L14 , for the macros specific for arm64.
Refer https://elixir.bootlin.com/linux/v6.1-rc1/source/arch/arm/include/ \
asm/cputype.h#L54 , for the macros specific for arm32.
MPIDR_LEVEL_SHIFT() differs between 64 and 32 bit.
For 64 bit :-
aff_lev3 aff_lev2 aff_lev1 aff_lev0
|________|________|________|________|________|
40 32 24 16 8 0
For 32 bit :-
aff_lev3 aff_lev2 aff_lev1 aff_lev0
|________|________|________|________|
32 24 16 8 0
Signed-off-by: Ayan Kumar Halder <ayankuma@amd.com>
---
Changes from :-
v1 - 1. Rearranged the macro defines so that the common code (between arm32
and arm64) is placed in "arm/include/asm/processor.h".
xen/arch/arm/include/asm/arm32/processor.h | 5 +++++
xen/arch/arm/include/asm/arm64/processor.h | 8 ++++++++
xen/arch/arm/include/asm/processor.h | 6 ------
3 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/xen/arch/arm/include/asm/arm32/processor.h b/xen/arch/arm/include/asm/arm32/processor.h
index 4e679f3273..82aa7f8d9d 100644
--- a/xen/arch/arm/include/asm/arm32/processor.h
+++ b/xen/arch/arm/include/asm/arm32/processor.h
@@ -56,6 +56,11 @@ struct cpu_user_regs
uint32_t pad1; /* Doubleword-align the user half of the frame */
};
+/*
+ * Macros to extract affinity level. Picked from kernel
+ */
+#define MPIDR_LEVEL_SHIFT(level) (MPIDR_LEVEL_BITS * (level))
+
#endif
#endif /* __ASM_ARM_ARM32_PROCESSOR_H */
diff --git a/xen/arch/arm/include/asm/arm64/processor.h b/xen/arch/arm/include/asm/arm64/processor.h
index c749f80ad9..295483a9dd 100644
--- a/xen/arch/arm/include/asm/arm64/processor.h
+++ b/xen/arch/arm/include/asm/arm64/processor.h
@@ -84,6 +84,14 @@ struct cpu_user_regs
uint64_t sp_el1, elr_el1;
};
+/*
+ * Macros to extract affinity level. picked from kernel
+ */
+#define MPIDR_LEVEL_BITS_SHIFT 3
+
+#define MPIDR_LEVEL_SHIFT(level) \
+ (((1 << (level)) >> 1) << MPIDR_LEVEL_BITS_SHIFT)
+
#undef __DECL_REG
#endif /* __ASSEMBLY__ */
diff --git a/xen/arch/arm/include/asm/processor.h b/xen/arch/arm/include/asm/processor.h
index 1dd81d7d52..ecfb62bbbe 100644
--- a/xen/arch/arm/include/asm/processor.h
+++ b/xen/arch/arm/include/asm/processor.h
@@ -122,13 +122,7 @@
/*
* Macros to extract affinity level. picked from kernel
*/
-
-#define MPIDR_LEVEL_BITS_SHIFT 3
#define MPIDR_LEVEL_MASK ((1 << MPIDR_LEVEL_BITS) - 1)
-
-#define MPIDR_LEVEL_SHIFT(level) \
- (((1 << (level)) >> 1) << MPIDR_LEVEL_BITS_SHIFT)
-
#define MPIDR_AFFINITY_LEVEL(mpidr, level) \
(((mpidr) >> MPIDR_LEVEL_SHIFT(level)) & MPIDR_LEVEL_MASK)
--
2.17.1
^ permalink raw reply related [flat|nested] 59+ messages in thread
* [XEN v2 03/12] xen/Arm: vreg: Support vreg_reg64_* helpers on Aarch32
2022-10-31 15:13 [XEN v2 00/12] Arm: Enable GICv3 for AArch32 (v8R) Ayan Kumar Halder
2022-10-31 15:13 ` [XEN v2 01/12] xen/Arm: vGICv3: Sysreg emulation is applicable for Aarch64 only Ayan Kumar Halder
2022-10-31 15:13 ` [XEN v2 02/12] xen/Arm: GICv3: Move the macros to compute the affnity level to arm64/arm32 Ayan Kumar Halder
@ 2022-10-31 15:13 ` Ayan Kumar Halder
2022-11-02 8:52 ` Michal Orzel
2022-11-02 9:02 ` Julien Grall
2022-10-31 15:13 ` [XEN v2 04/12] xen/Arm: vGICv3: Adapt emulation of GICR_TYPER for AArch32 Ayan Kumar Halder
` (8 subsequent siblings)
11 siblings, 2 replies; 59+ messages in thread
From: Ayan Kumar Halder @ 2022-10-31 15:13 UTC (permalink / raw)
To: xen-devel
Cc: sstabellini, stefanos, julien, Volodymyr_Babchuk,
bertrand.marquis, burzalodowa, Ayan Kumar Halder
In some situations (eg GICR_TYPER), the hypervior may need to emulate
64bit registers in aarch32 mode. In such situations, the hypervisor may
need to read/modify the lower or upper 32 bits of the 64 bit register.
In aarch32, 'unsigned long' is 32 bits. Thus, we cannot use it for 64 bit
registers.
The correct approach is to typecast 'mask' based on the size of register access
(ie uint32_t or uint64_t) instead of using 'unsigned long' as it will not
generate the correct mask for the upper 32 bits of a 64 bit register.
Also, 'val' needs to be typecasted so that it can correctly update the upper/
lower 32 bits of a 64 bit register.
Signed-off-by: Ayan Kumar Halder <ayankuma@amd.com>
---
Changes from :-
v1 - 1. Remove vreg_reg_extract(), vreg_reg_update(), vreg_reg_setbits() and
vreg_reg_clearbits(). Moved the implementation to vreg_reg##sz##_*.
'mask' and 'val' is now using uint##sz##_t.
xen/arch/arm/include/asm/vreg.h | 88 ++++++++-------------------------
1 file changed, 20 insertions(+), 68 deletions(-)
diff --git a/xen/arch/arm/include/asm/vreg.h b/xen/arch/arm/include/asm/vreg.h
index f26a70d024..122ea79b65 100644
--- a/xen/arch/arm/include/asm/vreg.h
+++ b/xen/arch/arm/include/asm/vreg.h
@@ -89,107 +89,59 @@ static inline bool vreg_emulate_sysreg(struct cpu_user_regs *regs, union hsr hsr
* The check on the size supported by the register has to be done by
* the caller of vreg_regN_*.
*
- * vreg_reg_* should never be called directly. Instead use the vreg_regN_*
- * according to size of the emulated register
- *
* Note that the alignment fault will always be taken in the guest
* (see B3.12.7 DDI0406.b).
*/
-static inline register_t vreg_reg_extract(unsigned long reg,
- unsigned int offset,
- enum dabt_size size)
-{
- reg >>= 8 * offset;
- reg &= VREG_REG_MASK(size);
-
- return reg;
-}
-
-static inline void vreg_reg_update(unsigned long *reg, register_t val,
- unsigned int offset,
- enum dabt_size size)
-{
- unsigned long mask = VREG_REG_MASK(size);
- int shift = offset * 8;
-
- *reg &= ~(mask << shift);
- *reg |= ((unsigned long)val & mask) << shift;
-}
-
-static inline void vreg_reg_setbits(unsigned long *reg, register_t bits,
- unsigned int offset,
- enum dabt_size size)
-{
- unsigned long mask = VREG_REG_MASK(size);
- int shift = offset * 8;
-
- *reg |= ((unsigned long)bits & mask) << shift;
-}
-
-static inline void vreg_reg_clearbits(unsigned long *reg, register_t bits,
- unsigned int offset,
- enum dabt_size size)
-{
- unsigned long mask = VREG_REG_MASK(size);
- int shift = offset * 8;
-
- *reg &= ~(((unsigned long)bits & mask) << shift);
-}
/* N-bit register helpers */
#define VREG_REG_HELPERS(sz, offmask) \
static inline register_t vreg_reg##sz##_extract(uint##sz##_t reg, \
const mmio_info_t *info)\
{ \
- return vreg_reg_extract(reg, info->gpa & (offmask), \
- info->dabt.size); \
+ unsigned int offset = info->gpa & (offmask); \
+ \
+ reg >>= 8 * offset; \
+ reg &= VREG_REG_MASK(info->dabt.size); \
+ \
+ return reg; \
} \
\
static inline void vreg_reg##sz##_update(uint##sz##_t *reg, \
register_t val, \
const mmio_info_t *info) \
{ \
- unsigned long tmp = *reg; \
- \
- vreg_reg_update(&tmp, val, info->gpa & (offmask), \
- info->dabt.size); \
+ unsigned int offset = info->gpa & (offmask); \
+ uint##sz##_t mask = VREG_REG_MASK(info->dabt.size); \
+ int shift = offset * 8; \
\
- *reg = tmp; \
+ *reg &= ~(mask << shift); \
+ *reg |= ((uint##sz##_t)val & mask) << shift; \
} \
\
static inline void vreg_reg##sz##_setbits(uint##sz##_t *reg, \
register_t bits, \
const mmio_info_t *info) \
{ \
- unsigned long tmp = *reg; \
- \
- vreg_reg_setbits(&tmp, bits, info->gpa & (offmask), \
- info->dabt.size); \
+ unsigned int offset = info->gpa & (offmask); \
+ uint##sz##_t mask = VREG_REG_MASK(info->dabt.size); \
+ int shift = offset * 8; \
\
- *reg = tmp; \
+ *reg |= ((uint##sz##_t)bits & mask) << shift; \
} \
\
static inline void vreg_reg##sz##_clearbits(uint##sz##_t *reg, \
register_t bits, \
const mmio_info_t *info) \
{ \
- unsigned long tmp = *reg; \
+ unsigned int offset = info->gpa & (offmask); \
+ uint##sz##_t mask = VREG_REG_MASK(info->dabt.size); \
+ int shift = offset * 8; \
\
- vreg_reg_clearbits(&tmp, bits, info->gpa & (offmask), \
- info->dabt.size); \
- \
- *reg = tmp; \
+ *reg &= ~(((uint##sz##_t)bits & mask) << shift); \
}
-/*
- * 64 bits registers are only supported on platform with 64-bit long.
- * This is also allow us to optimize the 32 bit case by using
- * unsigned long rather than uint64_t
- */
-#if BITS_PER_LONG == 64
-VREG_REG_HELPERS(64, 0x7);
-#endif
VREG_REG_HELPERS(32, 0x3);
+VREG_REG_HELPERS(64, 0x7);
#undef VREG_REG_HELPERS
--
2.17.1
^ permalink raw reply related [flat|nested] 59+ messages in thread
* [XEN v2 04/12] xen/Arm: vGICv3: Adapt emulation of GICR_TYPER for AArch32
2022-10-31 15:13 [XEN v2 00/12] Arm: Enable GICv3 for AArch32 (v8R) Ayan Kumar Halder
` (2 preceding siblings ...)
2022-10-31 15:13 ` [XEN v2 03/12] xen/Arm: vreg: Support vreg_reg64_* helpers on Aarch32 Ayan Kumar Halder
@ 2022-10-31 15:13 ` Ayan Kumar Halder
2022-11-06 18:04 ` Julien Grall
2022-10-31 15:13 ` [XEN v2 05/12] xen/Arm: GICv3: Fix GICR_{PENDBASER, PROPBASER} emulation on 32-bit host Ayan Kumar Halder
` (7 subsequent siblings)
11 siblings, 1 reply; 59+ messages in thread
From: Ayan Kumar Halder @ 2022-10-31 15:13 UTC (permalink / raw)
To: xen-devel
Cc: sstabellini, stefanos, julien, Volodymyr_Babchuk,
bertrand.marquis, burzalodowa, Ayan Kumar Halder
v->arch.vmpidr is assigned to uint64_t variable. This is to enable left shifts
for Aarch32 so that one can extract affinity bits.
This is then assigned to 'typer' so that the affinity bits form the upper 32 bits.
Refer Arm IHI 0069H ID020922,
The upper 32 bits of GICR_TYPER represent the affinity
whereas the lower 32 bits represent the other bits (eg processor
number, etc).
Signed-off-by: Ayan Kumar Halder <ayankuma@amd.com>
---
Changes from :-
1. v1 - Assigned v->arch.vmpidr to "uint64_t vmpdir". Then, we can use
MPIDR_AFFINITY_LEVEL macros to extract the affinity value.
xen/arch/arm/vgic-v3.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 3f4509dcd3..e5e6f2c573 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -191,13 +191,15 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu *v, mmio_info_t *info,
case VREG64(GICR_TYPER):
{
uint64_t typer, aff;
+ uint64_t vmpidr = v->arch.vmpidr;
if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
- aff = (MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 3) << 56 |
- MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 2) << 48 |
- MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 1) << 40 |
- MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 0) << 32);
+ aff = (MPIDR_AFFINITY_LEVEL(vmpidr, 3) << 56 |
+ MPIDR_AFFINITY_LEVEL(vmpidr, 2) << 48 |
+ MPIDR_AFFINITY_LEVEL(vmpidr, 1) << 40 |
+ MPIDR_AFFINITY_LEVEL(vmpidr, 0) << 32);
typer = aff;
+
/* We use the VCPU ID as the redistributor ID in bits[23:8] */
typer |= v->vcpu_id << GICR_TYPER_PROC_NUM_SHIFT;
--
2.17.1
^ permalink raw reply related [flat|nested] 59+ messages in thread
* [XEN v2 05/12] xen/Arm: GICv3: Fix GICR_{PENDBASER, PROPBASER} emulation on 32-bit host
2022-10-31 15:13 [XEN v2 00/12] Arm: Enable GICv3 for AArch32 (v8R) Ayan Kumar Halder
` (3 preceding siblings ...)
2022-10-31 15:13 ` [XEN v2 04/12] xen/Arm: vGICv3: Adapt emulation of GICR_TYPER for AArch32 Ayan Kumar Halder
@ 2022-10-31 15:13 ` Ayan Kumar Halder
2022-11-02 10:26 ` Michal Orzel
2022-11-06 18:05 ` Julien Grall
2022-10-31 15:13 ` [XEN v2 06/12] xen/Arm: vGICv3: Fix emulation of ICC_SGI1R on AArch32 Ayan Kumar Halder
` (6 subsequent siblings)
11 siblings, 2 replies; 59+ messages in thread
From: Ayan Kumar Halder @ 2022-10-31 15:13 UTC (permalink / raw)
To: xen-devel
Cc: sstabellini, stefanos, julien, Volodymyr_Babchuk,
bertrand.marquis, burzalodowa, Ayan Kumar Halder
'unsigned long long' is defined as 64 bit across both aarch32 and aarch64.
So, use 'ULL' for 64 bit word instead of UL which is 32 bits for aarch32.
GICR_PENDBASER and GICR_PROPBASER both are 64 bit registers.
Signed-off-by: Ayan Kumar Halder <ayankuma@amd.com>
---
Changes from -
v1 - 1. Extract the bug fix for incorrect bit clearing (GICR_PENDBASER_PTZ)
into a separate patch fix.
https://patchwork.kernel.org/project/xen-devel/patch/20221027185555.46125-1-ayankuma@amd.com/
xen/arch/arm/include/asm/gic_v3_defs.h | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/xen/arch/arm/include/asm/gic_v3_defs.h b/xen/arch/arm/include/asm/gic_v3_defs.h
index 728e28d5e5..48a1bc401e 100644
--- a/xen/arch/arm/include/asm/gic_v3_defs.h
+++ b/xen/arch/arm/include/asm/gic_v3_defs.h
@@ -134,15 +134,15 @@
#define GICR_PROPBASER_OUTER_CACHEABILITY_SHIFT 56
#define GICR_PROPBASER_OUTER_CACHEABILITY_MASK \
- (7UL << GICR_PROPBASER_OUTER_CACHEABILITY_SHIFT)
+ (7ULL << GICR_PROPBASER_OUTER_CACHEABILITY_SHIFT)
#define GICR_PROPBASER_SHAREABILITY_SHIFT 10
#define GICR_PROPBASER_SHAREABILITY_MASK \
- (3UL << GICR_PROPBASER_SHAREABILITY_SHIFT)
+ (3ULL << GICR_PROPBASER_SHAREABILITY_SHIFT)
#define GICR_PROPBASER_INNER_CACHEABILITY_SHIFT 7
#define GICR_PROPBASER_INNER_CACHEABILITY_MASK \
- (7UL << GICR_PROPBASER_INNER_CACHEABILITY_SHIFT)
+ (7ULL << GICR_PROPBASER_INNER_CACHEABILITY_SHIFT)
#define GICR_PROPBASER_RES0_MASK \
- (GENMASK(63, 59) | GENMASK(55, 52) | GENMASK(6, 5))
+ (GENMASK_ULL(63, 59) | GENMASK_ULL(55, 52) | GENMASK_ULL(6, 5))
#define GICR_PENDBASER_SHAREABILITY_SHIFT 10
#define GICR_PENDBASER_INNER_CACHEABILITY_SHIFT 7
@@ -152,11 +152,11 @@
#define GICR_PENDBASER_INNER_CACHEABILITY_MASK \
(7UL << GICR_PENDBASER_INNER_CACHEABILITY_SHIFT)
#define GICR_PENDBASER_OUTER_CACHEABILITY_MASK \
- (7UL << GICR_PENDBASER_OUTER_CACHEABILITY_SHIFT)
-#define GICR_PENDBASER_PTZ BIT(62, UL)
+ (7ULL << GICR_PENDBASER_OUTER_CACHEABILITY_SHIFT)
+#define GICR_PENDBASER_PTZ BIT(62, ULL)
#define GICR_PENDBASER_RES0_MASK \
- (BIT(63, UL) | GENMASK(61, 59) | GENMASK(55, 52) | \
- GENMASK(15, 12) | GENMASK(6, 0))
+ (BIT(63, ULL) | GENMASK_ULL(61, 59) | GENMASK_ULL(55, 52) | \
+ GENMASK_ULL(15, 12) | GENMASK_ULL(6, 0))
#define DEFAULT_PMR_VALUE 0xff
--
2.17.1
^ permalink raw reply related [flat|nested] 59+ messages in thread
* [XEN v2 06/12] xen/Arm: vGICv3: Fix emulation of ICC_SGI1R on AArch32
2022-10-31 15:13 [XEN v2 00/12] Arm: Enable GICv3 for AArch32 (v8R) Ayan Kumar Halder
` (4 preceding siblings ...)
2022-10-31 15:13 ` [XEN v2 05/12] xen/Arm: GICv3: Fix GICR_{PENDBASER, PROPBASER} emulation on 32-bit host Ayan Kumar Halder
@ 2022-10-31 15:13 ` Ayan Kumar Halder
2022-11-02 10:41 ` Michal Orzel
2022-10-31 15:13 ` [XEN v2 07/12] xen/Arm: GICv3: Define ICH_LR<n>_EL2 " Ayan Kumar Halder
` (5 subsequent siblings)
11 siblings, 1 reply; 59+ messages in thread
From: Ayan Kumar Halder @ 2022-10-31 15:13 UTC (permalink / raw)
To: xen-devel
Cc: sstabellini, stefanos, julien, Volodymyr_Babchuk,
bertrand.marquis, burzalodowa, Ayan Kumar Halder
Refer Arm IHI 0069H ID020922, 12.5.23, ICC_SGI1R is a 64 bit register on
Aarch32 systems. Thus, the prototype needs to change to reflect this.
The reason being 'register_t' is defined as 'u32' on AArch32.
Signed-off-by: Ayan Kumar Halder <ayankuma@amd.com>
---
Changes from :-
v1 - 1. Updated the commit message.
xen/arch/arm/vgic-v3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index e5e6f2c573..1bae76a1e1 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -1477,7 +1477,7 @@ write_reserved:
return 1;
}
-static bool vgic_v3_to_sgi(struct vcpu *v, register_t sgir)
+static bool vgic_v3_to_sgi(struct vcpu *v, uint64_t sgir)
{
int virq;
int irqmode;
--
2.17.1
^ permalink raw reply related [flat|nested] 59+ messages in thread
* [XEN v2 07/12] xen/Arm: GICv3: Define ICH_LR<n>_EL2 on AArch32
2022-10-31 15:13 [XEN v2 00/12] Arm: Enable GICv3 for AArch32 (v8R) Ayan Kumar Halder
` (5 preceding siblings ...)
2022-10-31 15:13 ` [XEN v2 06/12] xen/Arm: vGICv3: Fix emulation of ICC_SGI1R on AArch32 Ayan Kumar Halder
@ 2022-10-31 15:13 ` Ayan Kumar Halder
2022-11-03 12:13 ` Michal Orzel
2022-11-06 18:19 ` Julien Grall
2022-10-31 15:13 ` [XEN v2 08/12] xen/Arm: GICv3: Define ICH_AP0R<n> and ICH_AP1R<n> for AArch32 Ayan Kumar Halder
` (4 subsequent siblings)
11 siblings, 2 replies; 59+ messages in thread
From: Ayan Kumar Halder @ 2022-10-31 15:13 UTC (permalink / raw)
To: xen-devel
Cc: sstabellini, stefanos, julien, Volodymyr_Babchuk,
bertrand.marquis, burzalodowa, Ayan Kumar Halder
Refer "Arm IHI 0069H ID020922", 12.4.6, Interrupt Controller List Registers
AArch64 System register ICH_LR<n>_EL2 bits [31:0] are architecturally
mapped to AArch32 System register ICH_LR<n>[31:0].
AArch64 System register ICH_LR<n>_EL2 bits [63:32] are architecturally
mapped to AArch32 System register ICH_LRC<n>[31:0].
Defined ICH_LR<0...15>_EL2 and ICH_LRC<0...15>_EL2 for Aarch32.
For AArch32, the link register is stored as :-
(((uint64_t) ICH_LRC<0...15>_EL2) << 32) | ICH_LR<0...15>_EL2
Also, ICR_LR macros need to be modified as ULL is 64 bits for AArch32 and
AArch64.
Signed-off-by: Ayan Kumar Halder <ayankuma@amd.com>
---
Changes from :-
v1 - 1. Moved the coproc register definitions to asm/cpregs.h.
2. Use GENMASK(31, 0) to represent 0xFFFFFFFF
3. Use READ_CP32()/WRITE_CP32() instead of READ_SYSREG()/WRITE_SYSREG().
4. Multi-line macro definitions should be enclosed within ({ }).
xen/arch/arm/gic-v3.c | 132 +++++++++++------------
xen/arch/arm/include/asm/arm32/sysregs.h | 17 +++
xen/arch/arm/include/asm/arm64/sysregs.h | 3 +
xen/arch/arm/include/asm/cpregs.h | 42 ++++++++
xen/arch/arm/include/asm/gic_v3_defs.h | 6 +-
5 files changed, 131 insertions(+), 69 deletions(-)
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 018fa0dfa0..8b4b168e78 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -73,37 +73,37 @@ static inline void gicv3_save_lrs(struct vcpu *v)
switch ( gicv3_info.nr_lrs )
{
case 16:
- v->arch.gic.v3.lr[15] = READ_SYSREG(ICH_LR15_EL2);
+ v->arch.gic.v3.lr[15] = READ_SYSREG_LR(15);
case 15:
- v->arch.gic.v3.lr[14] = READ_SYSREG(ICH_LR14_EL2);
+ v->arch.gic.v3.lr[14] = READ_SYSREG_LR(14);
case 14:
- v->arch.gic.v3.lr[13] = READ_SYSREG(ICH_LR13_EL2);
+ v->arch.gic.v3.lr[13] = READ_SYSREG_LR(13);
case 13:
- v->arch.gic.v3.lr[12] = READ_SYSREG(ICH_LR12_EL2);
+ v->arch.gic.v3.lr[12] = READ_SYSREG_LR(12);
case 12:
- v->arch.gic.v3.lr[11] = READ_SYSREG(ICH_LR11_EL2);
+ v->arch.gic.v3.lr[11] = READ_SYSREG_LR(11);
case 11:
- v->arch.gic.v3.lr[10] = READ_SYSREG(ICH_LR10_EL2);
+ v->arch.gic.v3.lr[10] = READ_SYSREG_LR(10);
case 10:
- v->arch.gic.v3.lr[9] = READ_SYSREG(ICH_LR9_EL2);
+ v->arch.gic.v3.lr[9] = READ_SYSREG_LR(9);
case 9:
- v->arch.gic.v3.lr[8] = READ_SYSREG(ICH_LR8_EL2);
+ v->arch.gic.v3.lr[8] = READ_SYSREG_LR(8);
case 8:
- v->arch.gic.v3.lr[7] = READ_SYSREG(ICH_LR7_EL2);
+ v->arch.gic.v3.lr[7] = READ_SYSREG_LR(7);
case 7:
- v->arch.gic.v3.lr[6] = READ_SYSREG(ICH_LR6_EL2);
+ v->arch.gic.v3.lr[6] = READ_SYSREG_LR(6);
case 6:
- v->arch.gic.v3.lr[5] = READ_SYSREG(ICH_LR5_EL2);
+ v->arch.gic.v3.lr[5] = READ_SYSREG_LR(5);
case 5:
- v->arch.gic.v3.lr[4] = READ_SYSREG(ICH_LR4_EL2);
+ v->arch.gic.v3.lr[4] = READ_SYSREG_LR(4);
case 4:
- v->arch.gic.v3.lr[3] = READ_SYSREG(ICH_LR3_EL2);
+ v->arch.gic.v3.lr[3] = READ_SYSREG_LR(3);
case 3:
- v->arch.gic.v3.lr[2] = READ_SYSREG(ICH_LR2_EL2);
+ v->arch.gic.v3.lr[2] = READ_SYSREG_LR(2);
case 2:
- v->arch.gic.v3.lr[1] = READ_SYSREG(ICH_LR1_EL2);
+ v->arch.gic.v3.lr[1] = READ_SYSREG_LR(1);
case 1:
- v->arch.gic.v3.lr[0] = READ_SYSREG(ICH_LR0_EL2);
+ v->arch.gic.v3.lr[0] = READ_SYSREG_LR(0);
break;
default:
BUG();
@@ -120,37 +120,37 @@ static inline void gicv3_restore_lrs(const struct vcpu *v)
switch ( gicv3_info.nr_lrs )
{
case 16:
- WRITE_SYSREG(v->arch.gic.v3.lr[15], ICH_LR15_EL2);
+ WRITE_SYSREG_LR(15, v->arch.gic.v3.lr[15]);
case 15:
- WRITE_SYSREG(v->arch.gic.v3.lr[14], ICH_LR14_EL2);
+ WRITE_SYSREG_LR(14, v->arch.gic.v3.lr[14]);
case 14:
- WRITE_SYSREG(v->arch.gic.v3.lr[13], ICH_LR13_EL2);
+ WRITE_SYSREG_LR(13, v->arch.gic.v3.lr[13]);
case 13:
- WRITE_SYSREG(v->arch.gic.v3.lr[12], ICH_LR12_EL2);
+ WRITE_SYSREG_LR(12, v->arch.gic.v3.lr[12]);
case 12:
- WRITE_SYSREG(v->arch.gic.v3.lr[11], ICH_LR11_EL2);
+ WRITE_SYSREG_LR(11, v->arch.gic.v3.lr[11]);
case 11:
- WRITE_SYSREG(v->arch.gic.v3.lr[10], ICH_LR10_EL2);
+ WRITE_SYSREG_LR(10, v->arch.gic.v3.lr[10]);
case 10:
- WRITE_SYSREG(v->arch.gic.v3.lr[9], ICH_LR9_EL2);
+ WRITE_SYSREG_LR(9, v->arch.gic.v3.lr[9]);
case 9:
- WRITE_SYSREG(v->arch.gic.v3.lr[8], ICH_LR8_EL2);
+ WRITE_SYSREG_LR(8, v->arch.gic.v3.lr[8]);
case 8:
- WRITE_SYSREG(v->arch.gic.v3.lr[7], ICH_LR7_EL2);
+ WRITE_SYSREG_LR(7, v->arch.gic.v3.lr[7]);
case 7:
- WRITE_SYSREG(v->arch.gic.v3.lr[6], ICH_LR6_EL2);
+ WRITE_SYSREG_LR(6, v->arch.gic.v3.lr[6]);
case 6:
- WRITE_SYSREG(v->arch.gic.v3.lr[5], ICH_LR5_EL2);
+ WRITE_SYSREG_LR(5, v->arch.gic.v3.lr[5]);
case 5:
- WRITE_SYSREG(v->arch.gic.v3.lr[4], ICH_LR4_EL2);
+ WRITE_SYSREG_LR(4, v->arch.gic.v3.lr[4]);
case 4:
- WRITE_SYSREG(v->arch.gic.v3.lr[3], ICH_LR3_EL2);
+ WRITE_SYSREG_LR(3, v->arch.gic.v3.lr[3]);
case 3:
- WRITE_SYSREG(v->arch.gic.v3.lr[2], ICH_LR2_EL2);
+ WRITE_SYSREG_LR(2, v->arch.gic.v3.lr[2]);
case 2:
- WRITE_SYSREG(v->arch.gic.v3.lr[1], ICH_LR1_EL2);
+ WRITE_SYSREG_LR(1, v->arch.gic.v3.lr[1]);
case 1:
- WRITE_SYSREG(v->arch.gic.v3.lr[0], ICH_LR0_EL2);
+ WRITE_SYSREG_LR(0, v->arch.gic.v3.lr[0]);
break;
default:
BUG();
@@ -161,22 +161,22 @@ static uint64_t gicv3_ich_read_lr(int lr)
{
switch ( lr )
{
- case 0: return READ_SYSREG(ICH_LR0_EL2);
- case 1: return READ_SYSREG(ICH_LR1_EL2);
- case 2: return READ_SYSREG(ICH_LR2_EL2);
- case 3: return READ_SYSREG(ICH_LR3_EL2);
- case 4: return READ_SYSREG(ICH_LR4_EL2);
- case 5: return READ_SYSREG(ICH_LR5_EL2);
- case 6: return READ_SYSREG(ICH_LR6_EL2);
- case 7: return READ_SYSREG(ICH_LR7_EL2);
- case 8: return READ_SYSREG(ICH_LR8_EL2);
- case 9: return READ_SYSREG(ICH_LR9_EL2);
- case 10: return READ_SYSREG(ICH_LR10_EL2);
- case 11: return READ_SYSREG(ICH_LR11_EL2);
- case 12: return READ_SYSREG(ICH_LR12_EL2);
- case 13: return READ_SYSREG(ICH_LR13_EL2);
- case 14: return READ_SYSREG(ICH_LR14_EL2);
- case 15: return READ_SYSREG(ICH_LR15_EL2);
+ case 0: return READ_SYSREG_LR(0);
+ case 1: return READ_SYSREG_LR(1);
+ case 2: return READ_SYSREG_LR(2);
+ case 3: return READ_SYSREG_LR(3);
+ case 4: return READ_SYSREG_LR(4);
+ case 5: return READ_SYSREG_LR(5);
+ case 6: return READ_SYSREG_LR(6);
+ case 7: return READ_SYSREG_LR(7);
+ case 8: return READ_SYSREG_LR(8);
+ case 9: return READ_SYSREG_LR(9);
+ case 10: return READ_SYSREG_LR(10);
+ case 11: return READ_SYSREG_LR(11);
+ case 12: return READ_SYSREG_LR(12);
+ case 13: return READ_SYSREG_LR(13);
+ case 14: return READ_SYSREG_LR(14);
+ case 15: return READ_SYSREG_LR(15);
default:
BUG();
}
@@ -187,52 +187,52 @@ static void gicv3_ich_write_lr(int lr, uint64_t val)
switch ( lr )
{
case 0:
- WRITE_SYSREG(val, ICH_LR0_EL2);
+ WRITE_SYSREG_LR(0, val);
break;
case 1:
- WRITE_SYSREG(val, ICH_LR1_EL2);
+ WRITE_SYSREG_LR(1, val);
break;
case 2:
- WRITE_SYSREG(val, ICH_LR2_EL2);
+ WRITE_SYSREG_LR(2, val);
break;
case 3:
- WRITE_SYSREG(val, ICH_LR3_EL2);
+ WRITE_SYSREG_LR(3, val);
break;
case 4:
- WRITE_SYSREG(val, ICH_LR4_EL2);
+ WRITE_SYSREG_LR(4, val);
break;
case 5:
- WRITE_SYSREG(val, ICH_LR5_EL2);
+ WRITE_SYSREG_LR(5, val);
break;
case 6:
- WRITE_SYSREG(val, ICH_LR6_EL2);
+ WRITE_SYSREG_LR(6, val);
break;
case 7:
- WRITE_SYSREG(val, ICH_LR7_EL2);
+ WRITE_SYSREG_LR(7, val);
break;
case 8:
- WRITE_SYSREG(val, ICH_LR8_EL2);
+ WRITE_SYSREG_LR(8, val);
break;
case 9:
- WRITE_SYSREG(val, ICH_LR9_EL2);
+ WRITE_SYSREG_LR(9, val);
break;
case 10:
- WRITE_SYSREG(val, ICH_LR10_EL2);
+ WRITE_SYSREG_LR(10, val);
break;
case 11:
- WRITE_SYSREG(val, ICH_LR11_EL2);
+ WRITE_SYSREG_LR(11, val);
break;
case 12:
- WRITE_SYSREG(val, ICH_LR12_EL2);
+ WRITE_SYSREG_LR(12, val);
break;
case 13:
- WRITE_SYSREG(val, ICH_LR13_EL2);
+ WRITE_SYSREG_LR(13, val);
break;
case 14:
- WRITE_SYSREG(val, ICH_LR14_EL2);
+ WRITE_SYSREG_LR(14, val);
break;
case 15:
- WRITE_SYSREG(val, ICH_LR15_EL2);
+ WRITE_SYSREG_LR(15, val);
break;
default:
return;
@@ -417,12 +417,12 @@ static void gicv3_dump_state(const struct vcpu *v)
if ( v == current )
{
for ( i = 0; i < gicv3_info.nr_lrs; i++ )
- printk(" HW_LR[%d]=%lx\n", i, gicv3_ich_read_lr(i));
+ printk(" HW_LR[%d]=%llx\n", i, gicv3_ich_read_lr(i));
}
else
{
for ( i = 0; i < gicv3_info.nr_lrs; i++ )
- printk(" VCPU_LR[%d]=%lx\n", i, v->arch.gic.v3.lr[i]);
+ printk(" VCPU_LR[%d]=%llx\n", i, v->arch.gic.v3.lr[i]);
}
}
diff --git a/xen/arch/arm/include/asm/arm32/sysregs.h b/xen/arch/arm/include/asm/arm32/sysregs.h
index 6841d5de43..8a9a014bef 100644
--- a/xen/arch/arm/include/asm/arm32/sysregs.h
+++ b/xen/arch/arm/include/asm/arm32/sysregs.h
@@ -62,6 +62,23 @@
#define READ_SYSREG(R...) READ_SYSREG32(R)
#define WRITE_SYSREG(V, R...) WRITE_SYSREG32(V, R)
+#define ICH_LR_REG(INDEX) ICH_LR ## INDEX ## _EL2
+#define ICH_LRC_REG(INDEX) ICH_LRC ## INDEX ## _EL2
+
+#define READ_SYSREG_LR(INDEX) ({ \
+ uint64_t _val; \
+ uint32_t _lrc = READ_CP32(ICH_LRC_REG(INDEX)); \
+ uint32_t _lr = READ_CP32(ICH_LR_REG(INDEX)); \
+ \
+ _val = ((uint64_t) _lrc << 32) | _lr; \
+ _val; })
+
+#define WRITE_SYSREG_LR(INDEX, V) ({ \
+ uint64_t _val = (V); \
+ WRITE_CP32(_val & GENMASK(31, 0), ICH_LR_REG(INDEX)); \
+ WRITE_CP32(_val >> 32, ICH_LRC_REG(INDEX)); \
+});
+
/* MVFR2 is not defined on ARMv7 */
#define MVFR2_MAYBE_UNDEFINED
diff --git a/xen/arch/arm/include/asm/arm64/sysregs.h b/xen/arch/arm/include/asm/arm64/sysregs.h
index 54670084c3..353f0eea29 100644
--- a/xen/arch/arm/include/asm/arm64/sysregs.h
+++ b/xen/arch/arm/include/asm/arm64/sysregs.h
@@ -471,6 +471,9 @@
#define READ_SYSREG(name) READ_SYSREG64(name)
#define WRITE_SYSREG(v, name) WRITE_SYSREG64(v, name)
+#define ICH_LR_REG(index) ICH_LR ## index ## _EL2
+#define WRITE_SYSREG_LR(index, v) WRITE_SYSREG(v, ICH_LR_REG(index))
+#define READ_SYSREG_LR(index) READ_SYSREG(ICH_LR_REG(index))
#endif /* _ASM_ARM_ARM64_SYSREGS_H */
diff --git a/xen/arch/arm/include/asm/cpregs.h b/xen/arch/arm/include/asm/cpregs.h
index 6daf2b1a30..4421dd49ac 100644
--- a/xen/arch/arm/include/asm/cpregs.h
+++ b/xen/arch/arm/include/asm/cpregs.h
@@ -362,6 +362,48 @@
#define MVFR0_EL1 MVFR0
#define MVFR1_EL1 MVFR1
#define MVFR2_EL1 MVFR2
+
+#define ___CP32(a,b,c,d,e) a,b,c,d,e
+#define __LR0_EL2(x) ___CP32(p15,4,c12,c12,x)
+#define __LR8_EL2(x) ___CP32(p15,4,c12,c13,x)
+
+#define __LRC0_EL2(x) ___CP32(p15,4,c12,c14,x)
+#define __LRC8_EL2(x) ___CP32(p15,4,c12,c15,x)
+
+#define ICH_LR0_EL2 __LR0_EL2(0)
+#define ICH_LR1_EL2 __LR0_EL2(1)
+#define ICH_LR2_EL2 __LR0_EL2(2)
+#define ICH_LR3_EL2 __LR0_EL2(3)
+#define ICH_LR4_EL2 __LR0_EL2(4)
+#define ICH_LR5_EL2 __LR0_EL2(5)
+#define ICH_LR6_EL2 __LR0_EL2(6)
+#define ICH_LR7_EL2 __LR0_EL2(7)
+#define ICH_LR8_EL2 __LR8_EL2(0)
+#define ICH_LR9_EL2 __LR8_EL2(1)
+#define ICH_LR10_EL2 __LR8_EL2(2)
+#define ICH_LR11_EL2 __LR8_EL2(3)
+#define ICH_LR12_EL2 __LR8_EL2(4)
+#define ICH_LR13_EL2 __LR8_EL2(5)
+#define ICH_LR14_EL2 __LR8_EL2(6)
+#define ICH_LR15_EL2 __LR8_EL2(7)
+
+#define ICH_LRC0_EL2 __LRC0_EL2(0)
+#define ICH_LRC1_EL2 __LRC0_EL2(1)
+#define ICH_LRC2_EL2 __LRC0_EL2(2)
+#define ICH_LRC3_EL2 __LRC0_EL2(3)
+#define ICH_LRC4_EL2 __LRC0_EL2(4)
+#define ICH_LRC5_EL2 __LRC0_EL2(5)
+#define ICH_LRC6_EL2 __LRC0_EL2(6)
+#define ICH_LRC7_EL2 __LRC0_EL2(7)
+#define ICH_LRC8_EL2 __LRC8_EL2(0)
+#define ICH_LRC9_EL2 __LRC8_EL2(1)
+#define ICH_LRC10_EL2 __LRC8_EL2(2)
+#define ICH_LRC11_EL2 __LRC8_EL2(3)
+#define ICH_LRC12_EL2 __LRC8_EL2(4)
+#define ICH_LRC13_EL2 __LRC8_EL2(5)
+#define ICH_LRC14_EL2 __LRC8_EL2(6)
+#define ICH_LRC15_EL2 __LRC8_EL2(7)
+
#endif
#endif
diff --git a/xen/arch/arm/include/asm/gic_v3_defs.h b/xen/arch/arm/include/asm/gic_v3_defs.h
index 48a1bc401e..87115f8b25 100644
--- a/xen/arch/arm/include/asm/gic_v3_defs.h
+++ b/xen/arch/arm/include/asm/gic_v3_defs.h
@@ -185,9 +185,9 @@
#define ICH_LR_HW_SHIFT 61
#define ICH_LR_GRP_MASK 0x1
#define ICH_LR_GRP_SHIFT 60
-#define ICH_LR_MAINTENANCE_IRQ (1UL<<41)
-#define ICH_LR_GRP1 (1UL<<60)
-#define ICH_LR_HW (1UL<<61)
+#define ICH_LR_MAINTENANCE_IRQ (1ULL<<41)
+#define ICH_LR_GRP1 (1ULL<<60)
+#define ICH_LR_HW (1ULL<<61)
#define ICH_VTR_NRLRGS 0x3f
#define ICH_VTR_PRIBITS_MASK 0x7
--
2.17.1
^ permalink raw reply related [flat|nested] 59+ messages in thread
* [XEN v2 08/12] xen/Arm: GICv3: Define ICH_AP0R<n> and ICH_AP1R<n> for AArch32
2022-10-31 15:13 [XEN v2 00/12] Arm: Enable GICv3 for AArch32 (v8R) Ayan Kumar Halder
` (6 preceding siblings ...)
2022-10-31 15:13 ` [XEN v2 07/12] xen/Arm: GICv3: Define ICH_LR<n>_EL2 " Ayan Kumar Halder
@ 2022-10-31 15:13 ` Ayan Kumar Halder
2022-11-03 12:35 ` Michal Orzel
2022-10-31 15:13 ` [XEN v2 09/12] xen/Arm: GICv3: Define GIC registers " Ayan Kumar Halder
` (3 subsequent siblings)
11 siblings, 1 reply; 59+ messages in thread
From: Ayan Kumar Halder @ 2022-10-31 15:13 UTC (permalink / raw)
To: xen-devel
Cc: sstabellini, stefanos, julien, Volodymyr_Babchuk,
bertrand.marquis, burzalodowa, Ayan Kumar Halder
Refer "Arm IHI 0069H ID020922",
12.7.1 - Interrupt Controller Hyp Active Priorities Group0 Registers 0-3
12.7.2 - Interrupt Controller Hyp Active Priorities Group1 Registers 0-3
Signed-off-by: Ayan Kumar Halder <ayankuma@amd.com>
---
Changes from :-
v1 - 1. Moved coproc register definition to asm/cpregs.h.
xen/arch/arm/include/asm/arm32/sysregs.h | 1 -
xen/arch/arm/include/asm/cpregs.h | 11 +++++++++++
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/include/asm/arm32/sysregs.h b/xen/arch/arm/include/asm/arm32/sysregs.h
index 8a9a014bef..1b2915a526 100644
--- a/xen/arch/arm/include/asm/arm32/sysregs.h
+++ b/xen/arch/arm/include/asm/arm32/sysregs.h
@@ -81,7 +81,6 @@
/* MVFR2 is not defined on ARMv7 */
#define MVFR2_MAYBE_UNDEFINED
-
#endif /* __ASSEMBLY__ */
#endif /* __ASM_ARM_ARM32_SYSREGS_H */
diff --git a/xen/arch/arm/include/asm/cpregs.h b/xen/arch/arm/include/asm/cpregs.h
index 4421dd49ac..bfabee0bc3 100644
--- a/xen/arch/arm/include/asm/cpregs.h
+++ b/xen/arch/arm/include/asm/cpregs.h
@@ -404,6 +404,17 @@
#define ICH_LRC14_EL2 __LRC8_EL2(6)
#define ICH_LRC15_EL2 __LRC8_EL2(7)
+#define __AP0Rx_EL2(x) ___CP32(p15,4,c12,c8,x)
+#define ICH_AP0R0_EL2 __AP0Rx_EL2(0)
+#define ICH_AP0R1_EL2 __AP0Rx_EL2(1)
+#define ICH_AP0R2_EL2 __AP0Rx_EL2(2)
+#define ICH_AP0R3_EL2 __AP0Rx_EL2(3)
+
+#define __AP1Rx_EL2(x) ___CP32(p15,4,c12,c9,x)
+#define ICH_AP1R0_EL2 __AP1Rx_EL2(0)
+#define ICH_AP1R1_EL2 __AP1Rx_EL2(1)
+#define ICH_AP1R2_EL2 __AP1Rx_EL2(2)
+#define ICH_AP1R3_EL2 __AP1Rx_EL2(3)
#endif
#endif
--
2.17.1
^ permalink raw reply related [flat|nested] 59+ messages in thread
* [XEN v2 09/12] xen/Arm: GICv3: Define GIC registers for AArch32
2022-10-31 15:13 [XEN v2 00/12] Arm: Enable GICv3 for AArch32 (v8R) Ayan Kumar Halder
` (7 preceding siblings ...)
2022-10-31 15:13 ` [XEN v2 08/12] xen/Arm: GICv3: Define ICH_AP0R<n> and ICH_AP1R<n> for AArch32 Ayan Kumar Halder
@ 2022-10-31 15:13 ` Ayan Kumar Halder
2022-11-03 15:08 ` Michal Orzel
2022-10-31 15:13 ` [XEN v2 10/12] xen/Arm: GICv3: Use ULL instead of UL for 64bits Ayan Kumar Halder
` (2 subsequent siblings)
11 siblings, 1 reply; 59+ messages in thread
From: Ayan Kumar Halder @ 2022-10-31 15:13 UTC (permalink / raw)
To: xen-devel
Cc: sstabellini, stefanos, julien, Volodymyr_Babchuk,
bertrand.marquis, burzalodowa, Ayan Kumar Halder
Refer "Arm IHI 0069H ID020922"
12.5.23 ICC_SGI1R, Interrupt Controller Software Generated Interrupt
Group 1 Register
12.5.12 ICC_HSRE, Interrupt Controller Hyp System Register Enable register
12.7.10 ICH_VTR, Interrupt Controller VGIC Type Register
12.7.5 ICH_HCR, Interrupt Controller Hyp Control Register
12.5.20 ICC_PMR, Interrupt Controller Interrupt Priority Mask Register
12.5.24 ICC_SRE, Interrupt Controller System Register Enable register
12.5.7 ICC_DIR, Interrupt Controller Deactivate Interrupt Register
12.5.9 ICC_EOIR1, Interrupt Controller End Of Interrupt Register 1
12.5.14 ICC_IAR1, Interrupt Controller Interrupt Acknowledge Register 1
12.5.5 ICC_BPR1, Interrupt Controller Binary Point Register 1
12.5.6 ICC_CTLR, Interrupt Controller Control Register
12.5.16 ICC_IGRPEN1, Interrupt Controller Interrupt Group 1 Enable register
12.7.9 ICH_VMCR, Interrupt Controller Virtual Machine Control Register
Signed-off-by: Ayan Kumar Halder <ayankuma@amd.com>
---
Changes from :-
v1 - 1. Moved coproc regs definition to asm/cpregs.h
xen/arch/arm/include/asm/cpregs.h | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/xen/arch/arm/include/asm/cpregs.h b/xen/arch/arm/include/asm/cpregs.h
index bfabee0bc3..62b63f4cef 100644
--- a/xen/arch/arm/include/asm/cpregs.h
+++ b/xen/arch/arm/include/asm/cpregs.h
@@ -415,6 +415,22 @@
#define ICH_AP1R1_EL2 __AP1Rx_EL2(1)
#define ICH_AP1R2_EL2 __AP1Rx_EL2(2)
#define ICH_AP1R3_EL2 __AP1Rx_EL2(3)
+
+#define ICC_SGI1R_EL1 p15,0,c12
+
+#define ICC_SRE_EL2 p15,4,c12,c9,5
+#define ICH_VTR_EL2 p15,4,c12,c11,1
+#define ICH_HCR_EL2 p15,4,c12,c11,0
+
+#define ICC_PMR_EL1 p15,0,c4,c6,0
+#define ICC_SRE_EL1 p15,0,c12,c12,5
+#define ICC_DIR_EL1 p15,0,c12,c11,1
+#define ICC_EOIR1_EL1 p15,0,c12,c12,1
+#define ICC_IAR1_EL1 p15,0,c12,c12,0
+#define ICC_BPR1_EL1 p15,0,c12,c12,3
+#define ICC_CTLR_EL1 p15,0,c12,c12,4
+#define ICC_IGRPEN1_EL1 p15,0,c12,c12,7
+#define ICH_VMCR_EL2 p15,4,c12,c11,7
#endif
#endif
--
2.17.1
^ permalink raw reply related [flat|nested] 59+ messages in thread
* [XEN v2 10/12] xen/Arm: GICv3: Use ULL instead of UL for 64bits
2022-10-31 15:13 [XEN v2 00/12] Arm: Enable GICv3 for AArch32 (v8R) Ayan Kumar Halder
` (8 preceding siblings ...)
2022-10-31 15:13 ` [XEN v2 09/12] xen/Arm: GICv3: Define GIC registers " Ayan Kumar Halder
@ 2022-10-31 15:13 ` Ayan Kumar Halder
2022-11-01 10:03 ` Xenia Ragiadakou
2022-10-31 15:13 ` [XEN v2 11/12] xen/Arm: GICv3: Define macros to read/write 64 bit Ayan Kumar Halder
2022-10-31 15:13 ` [XEN v2 12/12] xen/Arm: GICv3: Enable GICv3 for AArch32 Ayan Kumar Halder
11 siblings, 1 reply; 59+ messages in thread
From: Ayan Kumar Halder @ 2022-10-31 15:13 UTC (permalink / raw)
To: xen-devel
Cc: sstabellini, stefanos, julien, Volodymyr_Babchuk,
bertrand.marquis, burzalodowa, Ayan Kumar Halder
"unsigned long long" is defined as 64 bits on AArch64 and AArch32
Thus, one should this instead of "unsigned long" which is 32 bits
on AArch32.
Also use 'PRIx64' instead of 'lx' or 'llx' to print uint64_t.
Signed-off-by: Ayan Kumar Halder <ayankuma@amd.com>
---
Changed from :-
v1 - 1. Replace PRIu64 with PRIx64 so that the values are printed in hex as
desired.
2. Use ULL in GITS_BASER_RO_MASK as MMIO registers are always unsigned.
xen/arch/arm/gic-v3-lpi.c | 8 ++++----
xen/arch/arm/gic-v3.c | 4 ++--
xen/arch/arm/include/asm/gic_v3_defs.h | 2 +-
xen/arch/arm/include/asm/gic_v3_its.h | 2 +-
xen/arch/arm/vgic-v3-its.c | 17 +++++++++--------
5 files changed, 17 insertions(+), 16 deletions(-)
diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
index 61d90eb386..9ca74bc321 100644
--- a/xen/arch/arm/gic-v3-lpi.c
+++ b/xen/arch/arm/gic-v3-lpi.c
@@ -134,7 +134,7 @@ void gicv3_set_redist_address(paddr_t address, unsigned int redist_id)
uint64_t gicv3_get_redist_address(unsigned int cpu, bool use_pta)
{
if ( use_pta )
- return per_cpu(lpi_redist, cpu).redist_addr & GENMASK(51, 16);
+ return per_cpu(lpi_redist, cpu).redist_addr & GENMASK_ULL(51, 16);
else
return per_cpu(lpi_redist, cpu).redist_id << 16;
}
@@ -253,7 +253,7 @@ static int gicv3_lpi_allocate_pendtable(unsigned int cpu)
return -ENOMEM;
/* Make sure the physical address can be encoded in the register. */
- if ( virt_to_maddr(pendtable) & ~GENMASK(51, 16) )
+ if ( virt_to_maddr(pendtable) & ~GENMASK_ULL(51, 16) )
{
xfree(pendtable);
return -ERANGE;
@@ -281,7 +281,7 @@ static int gicv3_lpi_set_pendtable(void __iomem *rdist_base)
return -ENOMEM;
}
- ASSERT(!(virt_to_maddr(pendtable) & ~GENMASK(51, 16)));
+ ASSERT(!(virt_to_maddr(pendtable) & ~GENMASK_ULL(51, 16)));
val = GIC_BASER_CACHE_RaWaWb << GICR_PENDBASER_INNER_CACHEABILITY_SHIFT;
val |= GIC_BASER_CACHE_SameAsInner << GICR_PENDBASER_OUTER_CACHEABILITY_SHIFT;
@@ -329,7 +329,7 @@ static int gicv3_lpi_set_proptable(void __iomem * rdist_base)
return -ENOMEM;
/* Make sure the physical address can be encoded in the register. */
- if ( (virt_to_maddr(table) & ~GENMASK(51, 12)) )
+ if ( (virt_to_maddr(table) & ~GENMASK_ULL(51, 12)) )
{
xfree(table);
return -ERANGE;
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 8b4b168e78..d8ce0f46c6 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -417,12 +417,12 @@ static void gicv3_dump_state(const struct vcpu *v)
if ( v == current )
{
for ( i = 0; i < gicv3_info.nr_lrs; i++ )
- printk(" HW_LR[%d]=%llx\n", i, gicv3_ich_read_lr(i));
+ printk(" HW_LR[%d]=%" PRIx64 "\n", i, gicv3_ich_read_lr(i));
}
else
{
for ( i = 0; i < gicv3_info.nr_lrs; i++ )
- printk(" VCPU_LR[%d]=%llx\n", i, v->arch.gic.v3.lr[i]);
+ printk(" VCPU_LR[%d]=%" PRIx64 "\n", i, v->arch.gic.v3.lr[i]);
}
}
diff --git a/xen/arch/arm/include/asm/gic_v3_defs.h b/xen/arch/arm/include/asm/gic_v3_defs.h
index 87115f8b25..3a24bd4825 100644
--- a/xen/arch/arm/include/asm/gic_v3_defs.h
+++ b/xen/arch/arm/include/asm/gic_v3_defs.h
@@ -195,7 +195,7 @@
#define ICH_SGI_IRQMODE_SHIFT 40
#define ICH_SGI_IRQMODE_MASK 0x1
-#define ICH_SGI_TARGET_OTHERS 1UL
+#define ICH_SGI_TARGET_OTHERS 1ULL
#define ICH_SGI_TARGET_LIST 0
#define ICH_SGI_IRQ_SHIFT 24
#define ICH_SGI_IRQ_MASK 0xf
diff --git a/xen/arch/arm/include/asm/gic_v3_its.h b/xen/arch/arm/include/asm/gic_v3_its.h
index fae3f6ecef..5ae50b18ea 100644
--- a/xen/arch/arm/include/asm/gic_v3_its.h
+++ b/xen/arch/arm/include/asm/gic_v3_its.h
@@ -38,7 +38,7 @@
#define GITS_PIDR2 GICR_PIDR2
/* Register bits */
-#define GITS_VALID_BIT BIT(63, UL)
+#define GITS_VALID_BIT BIT(63, ULL)
#define GITS_CTLR_QUIESCENT BIT(31, UL)
#define GITS_CTLR_ENABLE BIT(0, UL)
diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 58d939b85f..c5e02b2c41 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -96,13 +96,13 @@ typedef uint16_t coll_table_entry_t;
* in the lowest 5 bits of the word.
*/
typedef uint64_t dev_table_entry_t;
-#define DEV_TABLE_ITT_ADDR(x) ((x) & GENMASK(51, 8))
+#define DEV_TABLE_ITT_ADDR(x) ((x) & GENMASK_ULL(51, 8))
#define DEV_TABLE_ITT_SIZE(x) (BIT(((x) & GENMASK(4, 0)) + 1, UL))
#define DEV_TABLE_ENTRY(addr, bits) \
(((addr) & GENMASK(51, 8)) | (((bits) - 1) & GENMASK(4, 0)))
#define GITS_BASER_RO_MASK (GITS_BASER_TYPE_MASK | \
- (0x1fL << GITS_BASER_ENTRY_SIZE_SHIFT))
+ (0x1ULL << GITS_BASER_ENTRY_SIZE_SHIFT))
/*
* The physical address is encoded slightly differently depending on
@@ -112,10 +112,10 @@ typedef uint64_t dev_table_entry_t;
static paddr_t get_baser_phys_addr(uint64_t reg)
{
if ( reg & BIT(9, UL) )
- return (reg & GENMASK(47, 16)) |
+ return (reg & GENMASK_ULL(47, 16)) |
((reg & GENMASK(15, 12)) << 36);
else
- return reg & GENMASK(47, 12);
+ return reg & GENMASK_ULL(47, 12);
}
/* Must be called with the ITS lock held. */
@@ -414,7 +414,7 @@ static int update_lpi_property(struct domain *d, struct pending_irq *p)
if ( !d->arch.vgic.rdists_enabled )
return 0;
- addr = d->arch.vgic.rdist_propbase & GENMASK(51, 12);
+ addr = d->arch.vgic.rdist_propbase & GENMASK_ULL(51, 12);
ret = access_guest_memory_by_ipa(d, addr + p->irq - LPI_OFFSET,
&property, sizeof(property), false);
@@ -897,7 +897,8 @@ out_unlock:
static void dump_its_command(uint64_t *command)
{
- gdprintk(XENLOG_WARNING, " cmd 0x%02lx: %016lx %016lx %016lx %016lx\n",
+ gdprintk(XENLOG_WARNING, " cmd 0x%" PRIx64 ": %" PRIx64
+ "%" PRIx64 "%" PRIx64 "%" PRIx64 "\n",
its_cmd_get_command(command),
command[0], command[1], command[2], command[3]);
}
@@ -909,7 +910,7 @@ static void dump_its_command(uint64_t *command)
*/
static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its)
{
- paddr_t addr = its->cbaser & GENMASK(51, 12);
+ paddr_t addr = its->cbaser & GENMASK_ULL(51, 12);
uint64_t command[4];
ASSERT(spin_is_locked(&its->vcmd_lock));
@@ -1122,7 +1123,7 @@ read_as_zero_64:
read_impl_defined:
printk(XENLOG_G_DEBUG
- "%pv: vGITS: RAZ on implementation defined register offset %#04lx\n",
+ "%pv: vGITS: RAZ on implementation defined register offset %" PRIx64 "#04llx\n",
v, info->gpa & 0xffff);
*r = 0;
return 1;
--
2.17.1
^ permalink raw reply related [flat|nested] 59+ messages in thread
* [XEN v2 11/12] xen/Arm: GICv3: Define macros to read/write 64 bit
2022-10-31 15:13 [XEN v2 00/12] Arm: Enable GICv3 for AArch32 (v8R) Ayan Kumar Halder
` (9 preceding siblings ...)
2022-10-31 15:13 ` [XEN v2 10/12] xen/Arm: GICv3: Use ULL instead of UL for 64bits Ayan Kumar Halder
@ 2022-10-31 15:13 ` Ayan Kumar Halder
2022-11-01 7:08 ` Xenia Ragiadakou
2022-10-31 15:13 ` [XEN v2 12/12] xen/Arm: GICv3: Enable GICv3 for AArch32 Ayan Kumar Halder
11 siblings, 1 reply; 59+ messages in thread
From: Ayan Kumar Halder @ 2022-10-31 15:13 UTC (permalink / raw)
To: xen-devel
Cc: sstabellini, stefanos, julien, Volodymyr_Babchuk,
bertrand.marquis, burzalodowa, Ayan Kumar Halder
Defined readq_relaxed()/writeq_relaxed() to read and write 64 bit regs.
This uses ldrd/strd instructions.
Signed-off-by: Ayan Kumar Halder <ayankuma@amd.com>
---
Changes from :-
v1 - 1. Use ldrd/strd for readq_relaxed()/writeq_relaxed().
2. No need to use le64_to_cpu() as the returned byte order is already in cpu
endianess.
xen/arch/arm/include/asm/arm32/io.h | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/xen/arch/arm/include/asm/arm32/io.h b/xen/arch/arm/include/asm/arm32/io.h
index 73a879e9fb..d9d19ad764 100644
--- a/xen/arch/arm/include/asm/arm32/io.h
+++ b/xen/arch/arm/include/asm/arm32/io.h
@@ -72,6 +72,22 @@ static inline u32 __raw_readl(const volatile void __iomem *addr)
return val;
}
+static inline u64 __raw_readq(const volatile void __iomem *addr)
+{
+ u64 val;
+ asm volatile("ldrd %Q1, %R1, %0"
+ : "+Qo" (*(volatile u64 __force *)addr),
+ "=r" (val));
+ return val;
+}
+
+static inline void __raw_writeq(u64 val, const volatile void __iomem *addr)
+{
+ asm volatile("strd %Q1, %R1, %0"
+ : "+Q" (*(volatile u64 __force *)addr)
+ : "r" (val));
+}
+
#define __iormb() rmb()
#define __iowmb() wmb()
@@ -80,17 +96,22 @@ static inline u32 __raw_readl(const volatile void __iomem *addr)
__raw_readw(c)); __r; })
#define readl_relaxed(c) ({ u32 __r = le32_to_cpu((__force __le32) \
__raw_readl(c)); __r; })
+#define readq_relaxed(c) ({ u64 __r = le64_to_cpu((__force __le64) \
+ __raw_readq(c)); __r; })
#define writeb_relaxed(v,c) __raw_writeb(v,c)
#define writew_relaxed(v,c) __raw_writew((__force u16) cpu_to_le16(v),c)
#define writel_relaxed(v,c) __raw_writel((__force u32) cpu_to_le32(v),c)
+#define writeq_relaxed(v,c) __raw_writeq((__force u64) cpu_to_le64(v),c)
#define readb(c) ({ u8 __v = readb_relaxed(c); __iormb(); __v; })
#define readw(c) ({ u16 __v = readw_relaxed(c); __iormb(); __v; })
#define readl(c) ({ u32 __v = readl_relaxed(c); __iormb(); __v; })
+#define readq(c) ({ u64 __v = readq_relaxed(c); __iormb(); __v; })
#define writeb(v,c) ({ __iowmb(); writeb_relaxed(v,c); })
#define writew(v,c) ({ __iowmb(); writew_relaxed(v,c); })
#define writel(v,c) ({ __iowmb(); writel_relaxed(v,c); })
+#define writeq(v,c) ({ __iowmb(); writeq_relaxed(v,c); })
#endif /* _ARM_ARM32_IO_H */
--
2.17.1
^ permalink raw reply related [flat|nested] 59+ messages in thread
* [XEN v2 12/12] xen/Arm: GICv3: Enable GICv3 for AArch32
2022-10-31 15:13 [XEN v2 00/12] Arm: Enable GICv3 for AArch32 (v8R) Ayan Kumar Halder
` (10 preceding siblings ...)
2022-10-31 15:13 ` [XEN v2 11/12] xen/Arm: GICv3: Define macros to read/write 64 bit Ayan Kumar Halder
@ 2022-10-31 15:13 ` Ayan Kumar Halder
2022-11-04 9:55 ` Michal Orzel
2022-11-06 18:39 ` Julien Grall
11 siblings, 2 replies; 59+ messages in thread
From: Ayan Kumar Halder @ 2022-10-31 15:13 UTC (permalink / raw)
To: xen-devel
Cc: sstabellini, stefanos, julien, Volodymyr_Babchuk,
bertrand.marquis, burzalodowa, Ayan Kumar Halder
Refer ARM DDI 0487G.b ID072021,
D13.2.86 -
ID_PFR1_EL1, AArch32 Processor Feature Register 1
GIC, bits[31:28] == 0b0001 for GIC3.0 on Aarch32
One can now enable GICv3 on AArch32 systems. However, ITS is not supported.
The reason being currently we are trying to validate GICv3 on an AArch32_v8R
system. Refer ARM DDI 0568A.c ID110520, B1.3.1,
"A Generic Interrupt Controller (GIC) implemented with an Armv8-R PE must not
implement LPI support."
Updated SUPPORT.md.
Signed-off-by: Ayan Kumar Halder <ayankuma@amd.com>
---
Changed from :-
v1 - 1. Remove "ARM_64 || ARM_32" as it is always true.
2. Updated SUPPORT.md.
SUPPORT.md | 6 ++++++
xen/arch/arm/Kconfig | 4 ++--
xen/arch/arm/include/asm/cpufeature.h | 1 +
3 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/SUPPORT.md b/SUPPORT.md
index cf2ddfacaf..0137855c66 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -82,6 +82,12 @@ Extension to the GICv3 interrupt controller to support MSI.
Status: Experimental
+### ARM/GICv3 + AArch32 ARM v8
+
+GICv3 is supported on AArch32 ARMv8 (besides AArch64)
+
+ Status: Supported, not security supported
+
## Guest Type
### x86/PV
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 1fe5faf847..7c3c6eb3bd 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -41,7 +41,7 @@ config ARM_EFI
config GICV3
bool "GICv3 driver"
- depends on ARM_64 && !NEW_VGIC
+ depends on !NEW_VGIC
default y
---help---
@@ -50,7 +50,7 @@ config GICV3
config HAS_ITS
bool "GICv3 ITS MSI controller support (UNSUPPORTED)" if UNSUPPORTED
- depends on GICV3 && !NEW_VGIC
+ depends on GICV3 && !NEW_VGIC && !ARM_32
config HVM
def_bool y
diff --git a/xen/arch/arm/include/asm/cpufeature.h b/xen/arch/arm/include/asm/cpufeature.h
index c86a2e7f29..c62cf6293f 100644
--- a/xen/arch/arm/include/asm/cpufeature.h
+++ b/xen/arch/arm/include/asm/cpufeature.h
@@ -33,6 +33,7 @@
#define cpu_has_aarch32 (cpu_has_arm || cpu_has_thumb)
#ifdef CONFIG_ARM_32
+#define cpu_has_gicv3 (boot_cpu_feature32(gic) >= 1)
#define cpu_has_gentimer (boot_cpu_feature32(gentimer) == 1)
/*
* On Armv7, the value 0 is used to indicate that PMUv2 is not
--
2.17.1
^ permalink raw reply related [flat|nested] 59+ messages in thread
* Re: [XEN v2 01/12] xen/Arm: vGICv3: Sysreg emulation is applicable for Aarch64 only
2022-10-31 15:13 ` [XEN v2 01/12] xen/Arm: vGICv3: Sysreg emulation is applicable for Aarch64 only Ayan Kumar Halder
@ 2022-10-31 17:43 ` Michal Orzel
2022-11-02 8:51 ` Julien Grall
0 siblings, 1 reply; 59+ messages in thread
From: Michal Orzel @ 2022-10-31 17:43 UTC (permalink / raw)
To: Ayan Kumar Halder, xen-devel
Cc: sstabellini, stefanos, julien, Volodymyr_Babchuk,
bertrand.marquis, burzalodowa
Hi Ayan,
On 31/10/2022 16:13, Ayan Kumar Halder wrote:
>
>
> Refer ARM DDI 0487G.b ID072021, EC==0b011000 is supported for Aarch64 state
I think when adding new code we should be taking the latest spec (which is I.a) as a base +
you are lacking the information \wrt page number, table, whatever contains this information
within ARM ARM.
Apart from that, wouldn't it be easier for those reading the commit to just write e.g.:
"Sysreg emulation is 64-bit specific, so guard the calls to vgic_v3_emulate_sysreg
as well as the function itself with #ifdef CONFIG_ARM_64."
Placing EC code in such statement is not very helpful.
~Michal
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [XEN v2 02/12] xen/Arm: GICv3: Move the macros to compute the affnity level to arm64/arm32
2022-10-31 15:13 ` [XEN v2 02/12] xen/Arm: GICv3: Move the macros to compute the affnity level to arm64/arm32 Ayan Kumar Halder
@ 2022-10-31 17:53 ` Michal Orzel
2022-11-01 8:58 ` Michal Orzel
2022-11-02 8:46 ` Julien Grall
1 sibling, 1 reply; 59+ messages in thread
From: Michal Orzel @ 2022-10-31 17:53 UTC (permalink / raw)
To: Ayan Kumar Halder, xen-devel
Cc: sstabellini, stefanos, julien, Volodymyr_Babchuk,
bertrand.marquis, burzalodowa
Hi Ayan,
On 31/10/2022 16:13, Ayan Kumar Halder wrote:
>
>
> Refer https://elixir.bootlin.com/linux/v6.1-rc1/source/arch/arm64/ \
You should not split the link as it is becoming unusable in that form.
> include/asm/cputype.h#L14 , for the macros specific for arm64.
>
> Refer https://elixir.bootlin.com/linux/v6.1-rc1/source/arch/arm/include/ \
Same here.
> asm/cputype.h#L54 , for the macros specific for arm32.
>
> MPIDR_LEVEL_SHIFT() differs between 64 and 32 bit.
> For 64 bit :-
>
> aff_lev3 aff_lev2 aff_lev1 aff_lev0
> |________|________|________|________|________|
> 40 32 24 16 8 0
>
> For 32 bit :-
>
> aff_lev3 aff_lev2 aff_lev1 aff_lev0
> |________|________|________|________|
> 32 24 16 8 0
>
Where did you get this info from?
FWICS by looking at ARM ARM DDI 0487I.a D17-6118,
"Aff3 is not supported in AArch32 state."
> Signed-off-by: Ayan Kumar Halder <ayankuma@amd.com>
> ---
>
> Changes from :-
> v1 - 1. Rearranged the macro defines so that the common code (between arm32
> and arm64) is placed in "arm/include/asm/processor.h".
>
> xen/arch/arm/include/asm/arm32/processor.h | 5 +++++
> xen/arch/arm/include/asm/arm64/processor.h | 8 ++++++++
> xen/arch/arm/include/asm/processor.h | 6 ------
> 3 files changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/xen/arch/arm/include/asm/arm32/processor.h b/xen/arch/arm/include/asm/arm32/processor.h
> index 4e679f3273..82aa7f8d9d 100644
> --- a/xen/arch/arm/include/asm/arm32/processor.h
> +++ b/xen/arch/arm/include/asm/arm32/processor.h
> @@ -56,6 +56,11 @@ struct cpu_user_regs
> uint32_t pad1; /* Doubleword-align the user half of the frame */
> };
>
> +/*
> + * Macros to extract affinity level. Picked from kernel
> + */
No need for a multiline comment here and everywhere else.
> +#define MPIDR_LEVEL_SHIFT(level) (MPIDR_LEVEL_BITS * (level))
> +
> #endif
>
> #endif /* __ASM_ARM_ARM32_PROCESSOR_H */
> diff --git a/xen/arch/arm/include/asm/arm64/processor.h b/xen/arch/arm/include/asm/arm64/processor.h
> index c749f80ad9..295483a9dd 100644
> --- a/xen/arch/arm/include/asm/arm64/processor.h
> +++ b/xen/arch/arm/include/asm/arm64/processor.h
> @@ -84,6 +84,14 @@ struct cpu_user_regs
> uint64_t sp_el1, elr_el1;
> };
>
> +/*
> + * Macros to extract affinity level. picked from kernel
> + */
> +#define MPIDR_LEVEL_BITS_SHIFT 3
> +
> +#define MPIDR_LEVEL_SHIFT(level) \
> + (((1 << (level)) >> 1) << MPIDR_LEVEL_BITS_SHIFT)
> +
You should move these macros below __DECL_REG as they do not require having it defined.
> #undef __DECL_REG
>
> #endif /* __ASSEMBLY__ */
> diff --git a/xen/arch/arm/include/asm/processor.h b/xen/arch/arm/include/asm/processor.h
> index 1dd81d7d52..ecfb62bbbe 100644
> --- a/xen/arch/arm/include/asm/processor.h
> +++ b/xen/arch/arm/include/asm/processor.h
> @@ -122,13 +122,7 @@
> /*
> * Macros to extract affinity level. picked from kernel
> */
> -
> -#define MPIDR_LEVEL_BITS_SHIFT 3
> #define MPIDR_LEVEL_MASK ((1 << MPIDR_LEVEL_BITS) - 1)
> -
> -#define MPIDR_LEVEL_SHIFT(level) \
> - (((1 << (level)) >> 1) << MPIDR_LEVEL_BITS_SHIFT)
> -
> #define MPIDR_AFFINITY_LEVEL(mpidr, level) \
> (((mpidr) >> MPIDR_LEVEL_SHIFT(level)) & MPIDR_LEVEL_MASK)
>
> --
> 2.17.1
>
>
~Michal
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [XEN v2 11/12] xen/Arm: GICv3: Define macros to read/write 64 bit
2022-10-31 15:13 ` [XEN v2 11/12] xen/Arm: GICv3: Define macros to read/write 64 bit Ayan Kumar Halder
@ 2022-11-01 7:08 ` Xenia Ragiadakou
2022-11-01 9:50 ` Julien Grall
0 siblings, 1 reply; 59+ messages in thread
From: Xenia Ragiadakou @ 2022-11-01 7:08 UTC (permalink / raw)
To: Ayan Kumar Halder, xen-devel
Cc: sstabellini, stefanos, julien, Volodymyr_Babchuk, bertrand.marquis
Hi Ayan,
On 10/31/22 17:13, Ayan Kumar Halder wrote:
> Defined readq_relaxed()/writeq_relaxed() to read and write 64 bit regs.
> This uses ldrd/strd instructions.
>
> Signed-off-by: Ayan Kumar Halder <ayankuma@amd.com>
> ---
>
> Changes from :-
> v1 - 1. Use ldrd/strd for readq_relaxed()/writeq_relaxed().
> 2. No need to use le64_to_cpu() as the returned byte order is already in cpu
> endianess.
>
> xen/arch/arm/include/asm/arm32/io.h | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/xen/arch/arm/include/asm/arm32/io.h b/xen/arch/arm/include/asm/arm32/io.h
> index 73a879e9fb..d9d19ad764 100644
> --- a/xen/arch/arm/include/asm/arm32/io.h
> +++ b/xen/arch/arm/include/asm/arm32/io.h
> @@ -72,6 +72,22 @@ static inline u32 __raw_readl(const volatile void __iomem *addr)
> return val;
> }
>
> +static inline u64 __raw_readq(const volatile void __iomem *addr)
> +{
> + u64 val;
> + asm volatile("ldrd %Q1, %R1, %0"
> + : "+Qo" (*(volatile u64 __force *)addr),
> + "=r" (val));
> + return val;
> +}
> +
> +static inline void __raw_writeq(u64 val, const volatile void __iomem *addr)
> +{
> + asm volatile("strd %Q1, %R1, %0"
> + : "+Q" (*(volatile u64 __force *)addr)
> + : "r" (val));
> +}
> +
> #define __iormb() rmb()
> #define __iowmb() wmb()
>
> @@ -80,17 +96,22 @@ static inline u32 __raw_readl(const volatile void __iomem *addr)
> __raw_readw(c)); __r; })
> #define readl_relaxed(c) ({ u32 __r = le32_to_cpu((__force __le32) \
> __raw_readl(c)); __r; })
> +#define readq_relaxed(c) ({ u64 __r = le64_to_cpu((__force __le64) \
> + __raw_readq(c)); __r; })
>
> #define writeb_relaxed(v,c) __raw_writeb(v,c)
> #define writew_relaxed(v,c) __raw_writew((__force u16) cpu_to_le16(v),c)
> #define writel_relaxed(v,c) __raw_writel((__force u32) cpu_to_le32(v),c)
> +#define writeq_relaxed(v,c) __raw_writeq((__force u64) cpu_to_le64(v),c)
>
> #define readb(c) ({ u8 __v = readb_relaxed(c); __iormb(); __v; })
> #define readw(c) ({ u16 __v = readw_relaxed(c); __iormb(); __v; })
> #define readl(c) ({ u32 __v = readl_relaxed(c); __iormb(); __v; })
> +#define readq(c) ({ u64 __v = readq_relaxed(c); __iormb(); __v; })
>
> #define writeb(v,c) ({ __iowmb(); writeb_relaxed(v,c); })
> #define writew(v,c) ({ __iowmb(); writew_relaxed(v,c); })
> #define writel(v,c) ({ __iowmb(); writel_relaxed(v,c); })
> +#define writeq(v,c) ({ __iowmb(); writeq_relaxed(v,c); })
>
> #endif /* _ARM_ARM32_IO_H */
AFAIU, ldrd/strd accesses to MMIO are not guaranteed to be 64-bit
single-copy atomic. So, as Julien suggested, you still need to use a
different name to reflect this.
Also, having nested virtualization in mind, since these instructions
can't be virtualized, maybe it would be better to avoid using them for
MMIO accesses.
--
Xenia
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [XEN v2 02/12] xen/Arm: GICv3: Move the macros to compute the affnity level to arm64/arm32
2022-10-31 17:53 ` Michal Orzel
@ 2022-11-01 8:58 ` Michal Orzel
2022-11-01 11:32 ` Ayan Kumar Halder
0 siblings, 1 reply; 59+ messages in thread
From: Michal Orzel @ 2022-11-01 8:58 UTC (permalink / raw)
To: Ayan Kumar Halder, xen-devel
Cc: sstabellini, stefanos, julien, Volodymyr_Babchuk,
bertrand.marquis, burzalodowa
On 31/10/2022 18:53, Michal Orzel wrote:
>
>
> Hi Ayan,
>
> On 31/10/2022 16:13, Ayan Kumar Halder wrote:
>>
>>
>> Refer https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.bootlin.com%2Flinux%2Fv6.1-rc1%2Fsource%2Farch%2Farm64%2F&data=05%7C01%7Cmichal.orzel%40amd.com%7C0b2a0d1537104c2391d008dabb68eabb%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638028356554609284%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RhhL0XWxLJsO7vsP0DoP1QMvUMwGV%2F4FPJwAyvStj4k%3D&reserved=0 \
> You should not split the link as it is becoming unusable in that form.
>
>> include/asm/cputype.h#L14 , for the macros specific for arm64.
>>
>> Refer https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.bootlin.com%2Flinux%2Fv6.1-rc1%2Fsource%2Farch%2Farm%2Finclude%2F&data=05%7C01%7Cmichal.orzel%40amd.com%7C0b2a0d1537104c2391d008dabb68eabb%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638028356554609284%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=gLsNWm5%2BSyy51rn%2BA6H8PrWg8Yv%2BERicyyDjshOd3hc%3D&reserved=0 \
> Same here.
>
>> asm/cputype.h#L54 , for the macros specific for arm32.
>>
>> MPIDR_LEVEL_SHIFT() differs between 64 and 32 bit.
>> For 64 bit :-
>>
>> aff_lev3 aff_lev2 aff_lev1 aff_lev0
>> |________|________|________|________|________|
>> 40 32 24 16 8 0
>>
>> For 32 bit :-
>>
>> aff_lev3 aff_lev2 aff_lev1 aff_lev0
>> |________|________|________|________|
>> 32 24 16 8 0
>>
>
> Where did you get this info from?
> FWICS by looking at ARM ARM DDI 0487I.a D17-6118,
> "Aff3 is not supported in AArch32 state."
We're talking about arm32 and not AArch32. My bad.
Nevertheless, looking at ARM ARM DDI 0406C.d B4-1644,
MPIDR for Armv7A/R also does not have aff3.
>
>
>> Signed-off-by: Ayan Kumar Halder <ayankuma@amd.com>
>> ---
>>
>> Changes from :-
>> v1 - 1. Rearranged the macro defines so that the common code (between arm32
>> and arm64) is placed in "arm/include/asm/processor.h".
>>
>> xen/arch/arm/include/asm/arm32/processor.h | 5 +++++
>> xen/arch/arm/include/asm/arm64/processor.h | 8 ++++++++
>> xen/arch/arm/include/asm/processor.h | 6 ------
>> 3 files changed, 13 insertions(+), 6 deletions(-)
>>
>> diff --git a/xen/arch/arm/include/asm/arm32/processor.h b/xen/arch/arm/include/asm/arm32/processor.h
>> index 4e679f3273..82aa7f8d9d 100644
>> --- a/xen/arch/arm/include/asm/arm32/processor.h
>> +++ b/xen/arch/arm/include/asm/arm32/processor.h
>> @@ -56,6 +56,11 @@ struct cpu_user_regs
>> uint32_t pad1; /* Doubleword-align the user half of the frame */
>> };
>>
>> +/*
>> + * Macros to extract affinity level. Picked from kernel
>> + */
> No need for a multiline comment here and everywhere else.
>
>> +#define MPIDR_LEVEL_SHIFT(level) (MPIDR_LEVEL_BITS * (level))
>> +
>> #endif
>>
>> #endif /* __ASM_ARM_ARM32_PROCESSOR_H */
>> diff --git a/xen/arch/arm/include/asm/arm64/processor.h b/xen/arch/arm/include/asm/arm64/processor.h
>> index c749f80ad9..295483a9dd 100644
>> --- a/xen/arch/arm/include/asm/arm64/processor.h
>> +++ b/xen/arch/arm/include/asm/arm64/processor.h
>> @@ -84,6 +84,14 @@ struct cpu_user_regs
>> uint64_t sp_el1, elr_el1;
>> };
>>
>> +/*
>> + * Macros to extract affinity level. picked from kernel
>> + */
>> +#define MPIDR_LEVEL_BITS_SHIFT 3
>> +
>> +#define MPIDR_LEVEL_SHIFT(level) \
>> + (((1 << (level)) >> 1) << MPIDR_LEVEL_BITS_SHIFT)
>> +
> You should move these macros below __DECL_REG as they do not require having it defined.
>
>> #undef __DECL_REG
>>
>> #endif /* __ASSEMBLY__ */
>> diff --git a/xen/arch/arm/include/asm/processor.h b/xen/arch/arm/include/asm/processor.h
>> index 1dd81d7d52..ecfb62bbbe 100644
>> --- a/xen/arch/arm/include/asm/processor.h
>> +++ b/xen/arch/arm/include/asm/processor.h
>> @@ -122,13 +122,7 @@
>> /*
>> * Macros to extract affinity level. picked from kernel
>> */
>> -
>> -#define MPIDR_LEVEL_BITS_SHIFT 3
>> #define MPIDR_LEVEL_MASK ((1 << MPIDR_LEVEL_BITS) - 1)
>> -
>> -#define MPIDR_LEVEL_SHIFT(level) \
>> - (((1 << (level)) >> 1) << MPIDR_LEVEL_BITS_SHIFT)
>> -
>> #define MPIDR_AFFINITY_LEVEL(mpidr, level) \
>> (((mpidr) >> MPIDR_LEVEL_SHIFT(level)) & MPIDR_LEVEL_MASK)
>>
>> --
>> 2.17.1
>>
>>
>
> ~Michal
>
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [XEN v2 11/12] xen/Arm: GICv3: Define macros to read/write 64 bit
2022-11-01 7:08 ` Xenia Ragiadakou
@ 2022-11-01 9:50 ` Julien Grall
2022-11-01 10:59 ` Ayan Kumar Halder
0 siblings, 1 reply; 59+ messages in thread
From: Julien Grall @ 2022-11-01 9:50 UTC (permalink / raw)
To: Xenia Ragiadakou, Ayan Kumar Halder, xen-devel
Cc: sstabellini, stefanos, Volodymyr_Babchuk, bertrand.marquis
Hi,
On 01/11/2022 07:08, Xenia Ragiadakou wrote:
> On 10/31/22 17:13, Ayan Kumar Halder wrote:
>> Defined readq_relaxed()/writeq_relaxed() to read and write 64 bit regs.
>> This uses ldrd/strd instructions.
>>
>> Signed-off-by: Ayan Kumar Halder <ayankuma@amd.com>
>> ---
>>
>> Changes from :-
>> v1 - 1. Use ldrd/strd for readq_relaxed()/writeq_relaxed().
>> 2. No need to use le64_to_cpu() as the returned byte order is already
>> in cpu
>> endianess.
>>
>> xen/arch/arm/include/asm/arm32/io.h | 21 +++++++++++++++++++++
>> 1 file changed, 21 insertions(+)
>>
>> diff --git a/xen/arch/arm/include/asm/arm32/io.h
>> b/xen/arch/arm/include/asm/arm32/io.h
>> index 73a879e9fb..d9d19ad764 100644
>> --- a/xen/arch/arm/include/asm/arm32/io.h
>> +++ b/xen/arch/arm/include/asm/arm32/io.h
>> @@ -72,6 +72,22 @@ static inline u32 __raw_readl(const volatile void
>> __iomem *addr)
>> return val;
>> }
>> +static inline u64 __raw_readq(const volatile void __iomem *addr)
>> +{
>> + u64 val;
>> + asm volatile("ldrd %Q1, %R1, %0"
>> + : "+Qo" (*(volatile u64 __force *)addr),
>> + "=r" (val));
>> + return val;
>> +}
>> +
>> +static inline void __raw_writeq(u64 val, const volatile void __iomem
>> *addr)
>> +{
>> + asm volatile("strd %Q1, %R1, %0"
>> + : "+Q" (*(volatile u64 __force *)addr)
>> + : "r" (val));
>> +}
>> +
>> #define __iormb() rmb()
>> #define __iowmb() wmb()
>> @@ -80,17 +96,22 @@ static inline u32 __raw_readl(const volatile void
>> __iomem *addr)
>> __raw_readw(c)); __r; })
>> #define readl_relaxed(c) ({ u32 __r = le32_to_cpu((__force __le32) \
>> __raw_readl(c)); __r; })
>> +#define readq_relaxed(c) ({ u64 __r = le64_to_cpu((__force __le64) \
>> + __raw_readq(c)); __r; })
>> #define writeb_relaxed(v,c) __raw_writeb(v,c)
>> #define writew_relaxed(v,c) __raw_writew((__force u16)
>> cpu_to_le16(v),c)
>> #define writel_relaxed(v,c) __raw_writel((__force u32)
>> cpu_to_le32(v),c)
>> +#define writeq_relaxed(v,c) __raw_writeq((__force u64)
>> cpu_to_le64(v),c)
>> #define readb(c) ({ u8 __v = readb_relaxed(c);
>> __iormb(); __v; })
>> #define readw(c) ({ u16 __v = readw_relaxed(c);
>> __iormb(); __v; })
>> #define readl(c) ({ u32 __v = readl_relaxed(c);
>> __iormb(); __v; })
>> +#define readq(c) ({ u64 __v = readq_relaxed(c);
>> __iormb(); __v; })
>> #define writeb(v,c) ({ __iowmb(); writeb_relaxed(v,c); })
>> #define writew(v,c) ({ __iowmb(); writew_relaxed(v,c); })
>> #define writel(v,c) ({ __iowmb(); writel_relaxed(v,c); })
>> +#define writeq(v,c) ({ __iowmb(); writeq_relaxed(v,c); })
>> #endif /* _ARM_ARM32_IO_H */
>
> AFAIU, ldrd/strd accesses to MMIO are not guaranteed to be 64-bit
> single-copy atomic. So, as Julien suggested, you still need to use a
> different name to reflect this.
> Also, having nested virtualization in mind, since these instructions
> can't be virtualized, maybe it would be better to avoid using them for
> MMIO accesses.
+1. The previous version was actually using 32-bit access and it is not
clear to me why the new version is using 64-bit access.
Cheers,
--
Julien Grall
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [XEN v2 10/12] xen/Arm: GICv3: Use ULL instead of UL for 64bits
2022-10-31 15:13 ` [XEN v2 10/12] xen/Arm: GICv3: Use ULL instead of UL for 64bits Ayan Kumar Halder
@ 2022-11-01 10:03 ` Xenia Ragiadakou
2022-11-01 14:43 ` Ayan Kumar Halder
0 siblings, 1 reply; 59+ messages in thread
From: Xenia Ragiadakou @ 2022-11-01 10:03 UTC (permalink / raw)
To: Ayan Kumar Halder, xen-devel
Cc: sstabellini, stefanos, julien, Volodymyr_Babchuk, bertrand.marquis
Hi Ayan,
On 10/31/22 17:13, Ayan Kumar Halder wrote:
> "unsigned long long" is defined as 64 bits on AArch64 and AArch32
> Thus, one should this instead of "unsigned long" which is 32 bits
> on AArch32.
>
> Also use 'PRIx64' instead of 'lx' or 'llx' to print uint64_t.
>
> Signed-off-by: Ayan Kumar Halder <ayankuma@amd.com>
> ---
>
> Changed from :-
> v1 - 1. Replace PRIu64 with PRIx64 so that the values are printed in hex as
> desired.
> 2. Use ULL in GITS_BASER_RO_MASK as MMIO registers are always unsigned.
>
> xen/arch/arm/gic-v3-lpi.c | 8 ++++----
> xen/arch/arm/gic-v3.c | 4 ++--
> xen/arch/arm/include/asm/gic_v3_defs.h | 2 +-
> xen/arch/arm/include/asm/gic_v3_its.h | 2 +-
> xen/arch/arm/vgic-v3-its.c | 17 +++++++++--------
> 5 files changed, 17 insertions(+), 16 deletions(-)
>
> diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
> index 61d90eb386..9ca74bc321 100644
> --- a/xen/arch/arm/gic-v3-lpi.c
> +++ b/xen/arch/arm/gic-v3-lpi.c
> @@ -134,7 +134,7 @@ void gicv3_set_redist_address(paddr_t address, unsigned int redist_id)
> uint64_t gicv3_get_redist_address(unsigned int cpu, bool use_pta)
> {
> if ( use_pta )
> - return per_cpu(lpi_redist, cpu).redist_addr & GENMASK(51, 16);
> + return per_cpu(lpi_redist, cpu).redist_addr & GENMASK_ULL(51, 16);
> else
> return per_cpu(lpi_redist, cpu).redist_id << 16;
> }
> @@ -253,7 +253,7 @@ static int gicv3_lpi_allocate_pendtable(unsigned int cpu)
> return -ENOMEM;
>
> /* Make sure the physical address can be encoded in the register. */
> - if ( virt_to_maddr(pendtable) & ~GENMASK(51, 16) )
> + if ( virt_to_maddr(pendtable) & ~GENMASK_ULL(51, 16) )
> {
> xfree(pendtable);
> return -ERANGE;
> @@ -281,7 +281,7 @@ static int gicv3_lpi_set_pendtable(void __iomem *rdist_base)
> return -ENOMEM;
> }
>
> - ASSERT(!(virt_to_maddr(pendtable) & ~GENMASK(51, 16)));
> + ASSERT(!(virt_to_maddr(pendtable) & ~GENMASK_ULL(51, 16)));
>
> val = GIC_BASER_CACHE_RaWaWb << GICR_PENDBASER_INNER_CACHEABILITY_SHIFT;
> val |= GIC_BASER_CACHE_SameAsInner << GICR_PENDBASER_OUTER_CACHEABILITY_SHIFT;
> @@ -329,7 +329,7 @@ static int gicv3_lpi_set_proptable(void __iomem * rdist_base)
> return -ENOMEM;
>
> /* Make sure the physical address can be encoded in the register. */
> - if ( (virt_to_maddr(table) & ~GENMASK(51, 12)) )
> + if ( (virt_to_maddr(table) & ~GENMASK_ULL(51, 12)) )
> {
> xfree(table);
> return -ERANGE;
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index 8b4b168e78..d8ce0f46c6 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -417,12 +417,12 @@ static void gicv3_dump_state(const struct vcpu *v)
> if ( v == current )
> {
> for ( i = 0; i < gicv3_info.nr_lrs; i++ )
> - printk(" HW_LR[%d]=%llx\n", i, gicv3_ich_read_lr(i));
> + printk(" HW_LR[%d]=%" PRIx64 "\n", i, gicv3_ich_read_lr(i));
> }
> else
> {
> for ( i = 0; i < gicv3_info.nr_lrs; i++ )
> - printk(" VCPU_LR[%d]=%llx\n", i, v->arch.gic.v3.lr[i]);
> + printk(" VCPU_LR[%d]=%" PRIx64 "\n", i, v->arch.gic.v3.lr[i]);
> }
> }
>
> diff --git a/xen/arch/arm/include/asm/gic_v3_defs.h b/xen/arch/arm/include/asm/gic_v3_defs.h
> index 87115f8b25..3a24bd4825 100644
> --- a/xen/arch/arm/include/asm/gic_v3_defs.h
> +++ b/xen/arch/arm/include/asm/gic_v3_defs.h
> @@ -195,7 +195,7 @@
>
> #define ICH_SGI_IRQMODE_SHIFT 40
> #define ICH_SGI_IRQMODE_MASK 0x1
> -#define ICH_SGI_TARGET_OTHERS 1UL
> +#define ICH_SGI_TARGET_OTHERS 1ULL
> #define ICH_SGI_TARGET_LIST 0
> #define ICH_SGI_IRQ_SHIFT 24
> #define ICH_SGI_IRQ_MASK 0xf
> diff --git a/xen/arch/arm/include/asm/gic_v3_its.h b/xen/arch/arm/include/asm/gic_v3_its.h
> index fae3f6ecef..5ae50b18ea 100644
> --- a/xen/arch/arm/include/asm/gic_v3_its.h
> +++ b/xen/arch/arm/include/asm/gic_v3_its.h
> @@ -38,7 +38,7 @@
> #define GITS_PIDR2 GICR_PIDR2
>
> /* Register bits */
> -#define GITS_VALID_BIT BIT(63, UL)
> +#define GITS_VALID_BIT BIT(63, ULL)
>
> #define GITS_CTLR_QUIESCENT BIT(31, UL)
> #define GITS_CTLR_ENABLE BIT(0, UL)
It seems that you forgot GITS_BASER_INDIRECT, that is BIT(62, UL).
> diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
> index 58d939b85f..c5e02b2c41 100644
> --- a/xen/arch/arm/vgic-v3-its.c
> +++ b/xen/arch/arm/vgic-v3-its.c
> @@ -96,13 +96,13 @@ typedef uint16_t coll_table_entry_t;
> * in the lowest 5 bits of the word.
> */
> typedef uint64_t dev_table_entry_t;
> -#define DEV_TABLE_ITT_ADDR(x) ((x) & GENMASK(51, 8))
> +#define DEV_TABLE_ITT_ADDR(x) ((x) & GENMASK_ULL(51, 8))
> #define DEV_TABLE_ITT_SIZE(x) (BIT(((x) & GENMASK(4, 0)) + 1, UL))
> #define DEV_TABLE_ENTRY(addr, bits) \
> (((addr) & GENMASK(51, 8)) | (((bits) - 1) & GENMASK(4, 0)))
>
> #define GITS_BASER_RO_MASK (GITS_BASER_TYPE_MASK | \
> - (0x1fL << GITS_BASER_ENTRY_SIZE_SHIFT))
> + (0x1ULL << GITS_BASER_ENTRY_SIZE_SHIFT))
You have accidently dropped 'f' from the mask.
I noticed that you change to ULL only a part of GENMASK and BIT
occurences, I cannot see why. Maybe I m missing sth.
Also, with patch [XEN v2 12/12] xen/Arm: GICv3: Enable GICv3 for
AArch32, you disable ITS support for arm32, so it seems that those
changes in ITS related files are not required (not that do any harm to
have).
>
> /*
> * The physical address is encoded slightly differently depending on
> @@ -112,10 +112,10 @@ typedef uint64_t dev_table_entry_t;
> static paddr_t get_baser_phys_addr(uint64_t reg)
> {
> if ( reg & BIT(9, UL) )
> - return (reg & GENMASK(47, 16)) |
> + return (reg & GENMASK_ULL(47, 16)) |
> ((reg & GENMASK(15, 12)) << 36);
> else
> - return reg & GENMASK(47, 12);
> + return reg & GENMASK_ULL(47, 12);
> }
>
> /* Must be called with the ITS lock held. */
> @@ -414,7 +414,7 @@ static int update_lpi_property(struct domain *d, struct pending_irq *p)
> if ( !d->arch.vgic.rdists_enabled )
> return 0;
>
> - addr = d->arch.vgic.rdist_propbase & GENMASK(51, 12);
> + addr = d->arch.vgic.rdist_propbase & GENMASK_ULL(51, 12);
>
> ret = access_guest_memory_by_ipa(d, addr + p->irq - LPI_OFFSET,
> &property, sizeof(property), false);
> @@ -897,7 +897,8 @@ out_unlock:
>
> static void dump_its_command(uint64_t *command)
> {
> - gdprintk(XENLOG_WARNING, " cmd 0x%02lx: %016lx %016lx %016lx %016lx\n",
> + gdprintk(XENLOG_WARNING, " cmd 0x%" PRIx64 ": %" PRIx64
> + "%" PRIx64 "%" PRIx64 "%" PRIx64 "\n",
> its_cmd_get_command(command),
> command[0], command[1], command[2], command[3]);
> }
> @@ -909,7 +910,7 @@ static void dump_its_command(uint64_t *command)
> */
> static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its)
> {
> - paddr_t addr = its->cbaser & GENMASK(51, 12);
> + paddr_t addr = its->cbaser & GENMASK_ULL(51, 12);
> uint64_t command[4];
>
> ASSERT(spin_is_locked(&its->vcmd_lock));
> @@ -1122,7 +1123,7 @@ read_as_zero_64:
>
> read_impl_defined:
> printk(XENLOG_G_DEBUG
> - "%pv: vGITS: RAZ on implementation defined register offset %#04lx\n",
> + "%pv: vGITS: RAZ on implementation defined register offset %" PRIx64 "#04llx\n",
> v, info->gpa & 0xffff);
> *r = 0;
> return 1;
--
Xenia
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [XEN v2 11/12] xen/Arm: GICv3: Define macros to read/write 64 bit
2022-11-01 9:50 ` Julien Grall
@ 2022-11-01 10:59 ` Ayan Kumar Halder
2022-11-01 11:57 ` Julien Grall
0 siblings, 1 reply; 59+ messages in thread
From: Ayan Kumar Halder @ 2022-11-01 10:59 UTC (permalink / raw)
To: Julien Grall, Xenia Ragiadakou, xen-devel
Cc: sstabellini, stefanos, Volodymyr_Babchuk, bertrand.marquis
On 01/11/2022 09:50, Julien Grall wrote:
> Hi,
Hi Xenia, Julien,
I have few clarifications.
>
> On 01/11/2022 07:08, Xenia Ragiadakou wrote:
>> On 10/31/22 17:13, Ayan Kumar Halder wrote:
>>> Defined readq_relaxed()/writeq_relaxed() to read and write 64 bit regs.
>>> This uses ldrd/strd instructions.
>>>
>>> Signed-off-by: Ayan Kumar Halder <ayankuma@amd.com>
>>> ---
>>>
>>> Changes from :-
>>> v1 - 1. Use ldrd/strd for readq_relaxed()/writeq_relaxed().
>>> 2. No need to use le64_to_cpu() as the returned byte order is
>>> already in cpu
>>> endianess.
>>>
>>> xen/arch/arm/include/asm/arm32/io.h | 21 +++++++++++++++++++++
>>> 1 file changed, 21 insertions(+)
>>>
>>> diff --git a/xen/arch/arm/include/asm/arm32/io.h
>>> b/xen/arch/arm/include/asm/arm32/io.h
>>> index 73a879e9fb..d9d19ad764 100644
>>> --- a/xen/arch/arm/include/asm/arm32/io.h
>>> +++ b/xen/arch/arm/include/asm/arm32/io.h
>>> @@ -72,6 +72,22 @@ static inline u32 __raw_readl(const volatile void
>>> __iomem *addr)
>>> return val;
>>> }
>>> +static inline u64 __raw_readq(const volatile void __iomem *addr)
Rename this to __raw_readq_nonatomic()
>>> +{
>>> + u64 val;
>>> + asm volatile("ldrd %Q1, %R1, %0"
>>> + : "+Qo" (*(volatile u64 __force *)addr),
>>> + "=r" (val));
>>> + return val;
>>> +}
>>> +
>>> +static inline void __raw_writeq(u64 val, const volatile void
>>> __iomem *addr)
Rename to __raw_writeq_nonatomic()
>>> +{
>>> + asm volatile("strd %Q1, %R1, %0"
>>> + : "+Q" (*(volatile u64 __force *)addr)
>>> + : "r" (val));
>>> +}
>>> +
>>> #define __iormb() rmb()
>>> #define __iowmb() wmb()
>>> @@ -80,17 +96,22 @@ static inline u32 __raw_readl(const volatile
>>> void __iomem *addr)
>>> __raw_readw(c)); __r; })
>>> #define readl_relaxed(c) ({ u32 __r = le32_to_cpu((__force __le32) \
>>> __raw_readl(c)); __r; })
>>> +#define readq_relaxed(c) ({ u64 __r = le64_to_cpu((__force __le64) \
>>> + __raw_readq(c)); __r; })
>>> #define writeb_relaxed(v,c) __raw_writeb(v,c)
>>> #define writew_relaxed(v,c) __raw_writew((__force u16)
>>> cpu_to_le16(v),c)
>>> #define writel_relaxed(v,c) __raw_writel((__force u32)
>>> cpu_to_le32(v),c)
>>> +#define writeq_relaxed(v,c) __raw_writeq((__force u64)
>>> cpu_to_le64(v),c)
>>> #define readb(c) ({ u8 __v = readb_relaxed(c);
>>> __iormb(); __v; })
>>> #define readw(c) ({ u16 __v = readw_relaxed(c);
>>> __iormb(); __v; })
>>> #define readl(c) ({ u32 __v = readl_relaxed(c);
>>> __iormb(); __v; })
>>> +#define readq(c) ({ u64 __v = readq_relaxed(c);
>>> __iormb(); __v; })
>>> #define writeb(v,c) ({ __iowmb(); writeb_relaxed(v,c); })
>>> #define writew(v,c) ({ __iowmb(); writew_relaxed(v,c); })
>>> #define writel(v,c) ({ __iowmb(); writel_relaxed(v,c); })
>>> +#define writeq(v,c) ({ __iowmb(); writeq_relaxed(v,c); })
>>> #endif /* _ARM_ARM32_IO_H */
>>
>> AFAIU, ldrd/strd accesses to MMIO are not guaranteed to be 64-bit
>> single-copy atomic. So, as Julien suggested, you still need to use a
>> different name to reflect this.
Yes you are correct, ldrd/strd for system ram are guaranteed to be
atomic. Here we are accessing MMIO, so atomicity is not guaranteed.
I wasn't very sure if {read/write}*_relaxed are always atomic.
Does this look correct ?
#define writeq_relaxed(v,c) __raw_writeq_nonatomic((__force u64)
cpu_to_le64(v),c)
#define readq_relaxed(c) ({ u64 __r = le64_to_cpu((__force __le64) \
__raw_readq_nonatomic(c)); __r; })
We can remove "#define readq()/writeq() ..." as they are not used.
>> Also, having nested virtualization in mind, since these instructions
>> can't be virtualized, maybe it would be better to avoid using them
>> for MMIO accesses.
Does nested virtualization apply to Arm ?
Reading https://wiki.xenproject.org/wiki/Nested_Virtualization_in_Xen ,
I find two points of interest
"Only 64-bit hypervisors are supported at this time."
"See below for more details on tested hypervisior / guest combinations,
and known issues on Intel CPUs"
Thus, I understand that nested virtualization is supported only on x86
machines and that too 64bit only. Thus, it does not apply to AArch32.
Let me know if I misunderstood something.
>
> +1. The previous version was actually using 32-bit access and it is
> not clear to me why the new version is using 64-bit access.
IMO, I made a mistake in my previous patch of using 2 32bit access for a
64 bit register.
ldrd/strd is not supported for AArch32 guests in EL1 mode when they
access emulated MMIO region (which traps to EL2).
However, ldrd/strd is supported for AArch32 hypervisors running in EL2 mode.
Let me know if I am missing something.
- Ayan
>
> Cheers,
>
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [XEN v2 02/12] xen/Arm: GICv3: Move the macros to compute the affnity level to arm64/arm32
2022-11-01 8:58 ` Michal Orzel
@ 2022-11-01 11:32 ` Ayan Kumar Halder
0 siblings, 0 replies; 59+ messages in thread
From: Ayan Kumar Halder @ 2022-11-01 11:32 UTC (permalink / raw)
To: Michal Orzel, xen-devel
Cc: sstabellini, stefanos, julien, Volodymyr_Babchuk,
bertrand.marquis, burzalodowa
On 01/11/2022 08:58, Michal Orzel wrote:
>
> On 31/10/2022 18:53, Michal Orzel wrote:
>>
>> Hi Ayan,
Hi Michal,
>>
>> On 31/10/2022 16:13, Ayan Kumar Halder wrote:
>>>
>>> Refer https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.bootlin.com%2Flinux%2Fv6.1-rc1%2Fsource%2Farch%2Farm64%2F&data=05%7C01%7Cmichal.orzel%40amd.com%7C0b2a0d1537104c2391d008dabb68eabb%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638028356554609284%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RhhL0XWxLJsO7vsP0DoP1QMvUMwGV%2F4FPJwAyvStj4k%3D&reserved=0 \
>> You should not split the link as it is becoming unusable in that form.
>>
>>> include/asm/cputype.h#L14 , for the macros specific for arm64.
>>>
>>> Refer https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.bootlin.com%2Flinux%2Fv6.1-rc1%2Fsource%2Farch%2Farm%2Finclude%2F&data=05%7C01%7Cmichal.orzel%40amd.com%7C0b2a0d1537104c2391d008dabb68eabb%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638028356554609284%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=gLsNWm5%2BSyy51rn%2BA6H8PrWg8Yv%2BERicyyDjshOd3hc%3D&reserved=0 \
>> Same here.
>>
>>> asm/cputype.h#L54 , for the macros specific for arm32.
>>>
>>> MPIDR_LEVEL_SHIFT() differs between 64 and 32 bit.
>>> For 64 bit :-
>>>
>>> aff_lev3 aff_lev2 aff_lev1 aff_lev0
>>> |________|________|________|________|________|
>>> 40 32 24 16 8 0
>>>
>>> For 32 bit :-
>>>
>>> aff_lev3 aff_lev2 aff_lev1 aff_lev0
>>> |________|________|________|________|
>>> 32 24 16 8 0
>>>
>> Where did you get this info from?
>> FWICS by looking at ARM ARM DDI 0487I.a D17-6118,
>> "Aff3 is not supported in AArch32 state."
> We're talking about arm32 and not AArch32. My bad.
> Nevertheless, looking at ARM ARM DDI 0406C.d B4-1644,
> MPIDR for Armv7A/R also does not have aff3.
I was illustrating how the bits are represented in software
Refer
https://elixir.bootlin.com/linux/latest/source/drivers/irqchip/irq-gic-v3.c#L625
I was trying to depict how "u64
<https://elixir.bootlin.com/linux/latest/C/ident/u64> aff
<https://elixir.bootlin.com/linux/latest/C/ident/aff>" bit
representation differs between arm32 and arm64.
- Ayan
>
>>
>>> Signed-off-by: Ayan Kumar Halder <ayankuma@amd.com>
>>> ---
>>>
>>> Changes from :-
>>> v1 - 1. Rearranged the macro defines so that the common code (between arm32
>>> and arm64) is placed in "arm/include/asm/processor.h".
>>>
>>> xen/arch/arm/include/asm/arm32/processor.h | 5 +++++
>>> xen/arch/arm/include/asm/arm64/processor.h | 8 ++++++++
>>> xen/arch/arm/include/asm/processor.h | 6 ------
>>> 3 files changed, 13 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/xen/arch/arm/include/asm/arm32/processor.h b/xen/arch/arm/include/asm/arm32/processor.h
>>> index 4e679f3273..82aa7f8d9d 100644
>>> --- a/xen/arch/arm/include/asm/arm32/processor.h
>>> +++ b/xen/arch/arm/include/asm/arm32/processor.h
>>> @@ -56,6 +56,11 @@ struct cpu_user_regs
>>> uint32_t pad1; /* Doubleword-align the user half of the frame */
>>> };
>>>
>>> +/*
>>> + * Macros to extract affinity level. Picked from kernel
>>> + */
>> No need for a multiline comment here and everywhere else.
>>
>>> +#define MPIDR_LEVEL_SHIFT(level) (MPIDR_LEVEL_BITS * (level))
>>> +
>>> #endif
>>>
>>> #endif /* __ASM_ARM_ARM32_PROCESSOR_H */
>>> diff --git a/xen/arch/arm/include/asm/arm64/processor.h b/xen/arch/arm/include/asm/arm64/processor.h
>>> index c749f80ad9..295483a9dd 100644
>>> --- a/xen/arch/arm/include/asm/arm64/processor.h
>>> +++ b/xen/arch/arm/include/asm/arm64/processor.h
>>> @@ -84,6 +84,14 @@ struct cpu_user_regs
>>> uint64_t sp_el1, elr_el1;
>>> };
>>>
>>> +/*
>>> + * Macros to extract affinity level. picked from kernel
>>> + */
>>> +#define MPIDR_LEVEL_BITS_SHIFT 3
>>> +
>>> +#define MPIDR_LEVEL_SHIFT(level) \
>>> + (((1 << (level)) >> 1) << MPIDR_LEVEL_BITS_SHIFT)
>>> +
>> You should move these macros below __DECL_REG as they do not require having it defined.
>>
>>> #undef __DECL_REG
>>>
>>> #endif /* __ASSEMBLY__ */
>>> diff --git a/xen/arch/arm/include/asm/processor.h b/xen/arch/arm/include/asm/processor.h
>>> index 1dd81d7d52..ecfb62bbbe 100644
>>> --- a/xen/arch/arm/include/asm/processor.h
>>> +++ b/xen/arch/arm/include/asm/processor.h
>>> @@ -122,13 +122,7 @@
>>> /*
>>> * Macros to extract affinity level. picked from kernel
>>> */
>>> -
>>> -#define MPIDR_LEVEL_BITS_SHIFT 3
>>> #define MPIDR_LEVEL_MASK ((1 << MPIDR_LEVEL_BITS) - 1)
>>> -
>>> -#define MPIDR_LEVEL_SHIFT(level) \
>>> - (((1 << (level)) >> 1) << MPIDR_LEVEL_BITS_SHIFT)
>>> -
>>> #define MPIDR_AFFINITY_LEVEL(mpidr, level) \
>>> (((mpidr) >> MPIDR_LEVEL_SHIFT(level)) & MPIDR_LEVEL_MASK)
>>>
>>> --
>>> 2.17.1
>>>
>>>
>> ~Michal
>>
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [XEN v2 11/12] xen/Arm: GICv3: Define macros to read/write 64 bit
2022-11-01 10:59 ` Ayan Kumar Halder
@ 2022-11-01 11:57 ` Julien Grall
2022-11-01 14:23 ` Xenia Ragiadakou
0 siblings, 1 reply; 59+ messages in thread
From: Julien Grall @ 2022-11-01 11:57 UTC (permalink / raw)
To: Ayan Kumar Halder, Xenia Ragiadakou, xen-devel
Cc: sstabellini, stefanos, Volodymyr_Babchuk, bertrand.marquis
Hi Ayan,
On 01/11/2022 10:59, Ayan Kumar Halder wrote:
>
> On 01/11/2022 09:50, Julien Grall wrote:
>> Hi,
>
> Hi Xenia, Julien,
>
> I have few clarifications.
>
>>
>> On 01/11/2022 07:08, Xenia Ragiadakou wrote:
>>> On 10/31/22 17:13, Ayan Kumar Halder wrote:
>>>> Defined readq_relaxed()/writeq_relaxed() to read and write 64 bit regs.
>>>> This uses ldrd/strd instructions.
>>>>
>>>> Signed-off-by: Ayan Kumar Halder <ayankuma@amd.com>
>>>> ---
>>>>
>>>> Changes from :-
>>>> v1 - 1. Use ldrd/strd for readq_relaxed()/writeq_relaxed().
>>>> 2. No need to use le64_to_cpu() as the returned byte order is
>>>> already in cpu
>>>> endianess.
>>>>
>>>> xen/arch/arm/include/asm/arm32/io.h | 21 +++++++++++++++++++++
>>>> 1 file changed, 21 insertions(+)
>>>>
>>>> diff --git a/xen/arch/arm/include/asm/arm32/io.h
>>>> b/xen/arch/arm/include/asm/arm32/io.h
>>>> index 73a879e9fb..d9d19ad764 100644
>>>> --- a/xen/arch/arm/include/asm/arm32/io.h
>>>> +++ b/xen/arch/arm/include/asm/arm32/io.h
>>>> @@ -72,6 +72,22 @@ static inline u32 __raw_readl(const volatile void
>>>> __iomem *addr)
>>>> return val;
>>>> }
>>>> +static inline u64 __raw_readq(const volatile void __iomem *addr)
> Rename this to __raw_readq_nonatomic()
>>>> +{
>>>> + u64 val;
>>>> + asm volatile("ldrd %Q1, %R1, %0"
>>>> + : "+Qo" (*(volatile u64 __force *)addr),
>>>> + "=r" (val));
>>>> + return val;
>>>> +}
>>>> +
>>>> +static inline void __raw_writeq(u64 val, const volatile void
>>>> __iomem *addr)
> Rename to __raw_writeq_nonatomic()
>>>> +{
>>>> + asm volatile("strd %Q1, %R1, %0"
>>>> + : "+Q" (*(volatile u64 __force *)addr)
>>>> + : "r" (val));
>>>> +}
>>>> +
>>>> #define __iormb() rmb()
>>>> #define __iowmb() wmb()
>>>> @@ -80,17 +96,22 @@ static inline u32 __raw_readl(const volatile
>>>> void __iomem *addr)
>>>> __raw_readw(c)); __r; })
>>>> #define readl_relaxed(c) ({ u32 __r = le32_to_cpu((__force __le32) \
>>>> __raw_readl(c)); __r; })
>>>> +#define readq_relaxed(c) ({ u64 __r = le64_to_cpu((__force __le64) \
>>>> + __raw_readq(c)); __r; })
>>>> #define writeb_relaxed(v,c) __raw_writeb(v,c)
>>>> #define writew_relaxed(v,c) __raw_writew((__force u16)
>>>> cpu_to_le16(v),c)
>>>> #define writel_relaxed(v,c) __raw_writel((__force u32)
>>>> cpu_to_le32(v),c)
>>>> +#define writeq_relaxed(v,c) __raw_writeq((__force u64)
>>>> cpu_to_le64(v),c)
>>>> #define readb(c) ({ u8 __v = readb_relaxed(c);
>>>> __iormb(); __v; })
>>>> #define readw(c) ({ u16 __v = readw_relaxed(c);
>>>> __iormb(); __v; })
>>>> #define readl(c) ({ u32 __v = readl_relaxed(c);
>>>> __iormb(); __v; })
>>>> +#define readq(c) ({ u64 __v = readq_relaxed(c);
>>>> __iormb(); __v; })
>>>> #define writeb(v,c) ({ __iowmb(); writeb_relaxed(v,c); })
>>>> #define writew(v,c) ({ __iowmb(); writew_relaxed(v,c); })
>>>> #define writel(v,c) ({ __iowmb(); writel_relaxed(v,c); })
>>>> +#define writeq(v,c) ({ __iowmb(); writeq_relaxed(v,c); })
>>>> #endif /* _ARM_ARM32_IO_H */
>>>
>>> AFAIU, ldrd/strd accesses to MMIO are not guaranteed to be 64-bit
>>> single-copy atomic. So, as Julien suggested, you still need to use a
>>> different name to reflect this.
>
> Yes you are correct, ldrd/strd for system ram are guaranteed to be
> atomic. Here we are accessing MMIO, so atomicity is not guaranteed.
>
> I wasn't very sure if {read/write}*_relaxed are always atomic.
All the current use are atomic.
> #define writeq_relaxed(v,c) __raw_writeq_nonatomic((__force u64)
> cpu_to_le64(v),c)
>
> #define readq_relaxed(c) ({ u64 __r = le64_to_cpu((__force __le64) \
> __raw_readq_nonatomic(c)); __r; })
>
> We can remove "#define readq()/writeq() ..." as they are not used.
>
>>> Also, having nested virtualization in mind, since these instructions
>>> can't be virtualized, maybe it would be better to avoid using them
>>> for MMIO accesses.
>
> Does nested virtualization apply to Arm ?
This is supported by the Architecture although not implemented in Xen.
>
> Reading https://wiki.xenproject.org/wiki/Nested_Virtualization_in_Xen ,
> I find two points of interest
>
> "Only 64-bit hypervisors are supported at this time."
>
> "See below for more details on tested hypervisior / guest combinations,
> and known issues on Intel CPUs"
>
> Thus, I understand that nested virtualization is supported only on x86
> machines and that too 64bit only. Thus, it does not apply to AArch32.
The wiki page is describing the case where another hypervisor is running
on top of Xen. But there is no support necessary in Xen to run it on top
of another hypervisor.
I haven't looked whether the architecture allows to use nested on 32-bit
though...
>
> Let me know if I misunderstood something.
>
>>
>> +1. The previous version was actually using 32-bit access and it is
>> not clear to me why the new version is using 64-bit access.
>
> IMO, I made a mistake in my previous patch of using 2 32bit access for a
> 64 bit register.
>
> ldrd/strd is not supported for AArch32 guests in EL1 mode when they
> access emulated MMIO region (which traps to EL2).
>
> However, ldrd/strd is supported for AArch32 hypervisors running in EL2
> mode.
That's not what I understood from previous discussion [1]. ldrd/strd
would be atomic on system RAM but there is no guarantee they would be
for MMIO access.
I know this was Andre's interpretation. However, the HW architects may
have interpreted the same way...
So I think we should be convervative in Xen. AFAICT, in the case of
GICv3, we don't need the atomicity for the 64-bit registers. Therefore,
I would rather prefer if we introduce an helper that do two 32-bit read.
Cheers,
[1]
https://lore.kernel.org/xen-devel/20221027153632.0cf7d004@donnerap.cambridge.arm.com/
--
Julien Grall
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [XEN v2 11/12] xen/Arm: GICv3: Define macros to read/write 64 bit
2022-11-01 11:57 ` Julien Grall
@ 2022-11-01 14:23 ` Xenia Ragiadakou
0 siblings, 0 replies; 59+ messages in thread
From: Xenia Ragiadakou @ 2022-11-01 14:23 UTC (permalink / raw)
To: Julien Grall, Ayan Kumar Halder, xen-devel
Cc: sstabellini, stefanos, Volodymyr_Babchuk, bertrand.marquis
On 11/1/22 13:57, Julien Grall wrote:
> Hi Ayan,
>
> On 01/11/2022 10:59, Ayan Kumar Halder wrote:
>>
>> On 01/11/2022 09:50, Julien Grall wrote:
>>> Hi,
>>
>> Hi Xenia, Julien,
>>
>> I have few clarifications.
>>
>>>
>>> On 01/11/2022 07:08, Xenia Ragiadakou wrote:
>>>> On 10/31/22 17:13, Ayan Kumar Halder wrote:
>>>>> Defined readq_relaxed()/writeq_relaxed() to read and write 64 bit
>>>>> regs.
>>>>> This uses ldrd/strd instructions.
>>>>>
>>>>> Signed-off-by: Ayan Kumar Halder <ayankuma@amd.com>
>>>>> ---
>>>>>
>>>>> Changes from :-
>>>>> v1 - 1. Use ldrd/strd for readq_relaxed()/writeq_relaxed().
>>>>> 2. No need to use le64_to_cpu() as the returned byte order is
>>>>> already in cpu
>>>>> endianess.
>>>>>
>>>>> xen/arch/arm/include/asm/arm32/io.h | 21 +++++++++++++++++++++
>>>>> 1 file changed, 21 insertions(+)
>>>>>
>>>>> diff --git a/xen/arch/arm/include/asm/arm32/io.h
>>>>> b/xen/arch/arm/include/asm/arm32/io.h
>>>>> index 73a879e9fb..d9d19ad764 100644
>>>>> --- a/xen/arch/arm/include/asm/arm32/io.h
>>>>> +++ b/xen/arch/arm/include/asm/arm32/io.h
>>>>> @@ -72,6 +72,22 @@ static inline u32 __raw_readl(const volatile
>>>>> void __iomem *addr)
>>>>> return val;
>>>>> }
>>>>> +static inline u64 __raw_readq(const volatile void __iomem *addr)
>> Rename this to __raw_readq_nonatomic()
>>>>> +{
>>>>> + u64 val;
>>>>> + asm volatile("ldrd %Q1, %R1, %0"
>>>>> + : "+Qo" (*(volatile u64 __force *)addr),
>>>>> + "=r" (val));
>>>>> + return val;
>>>>> +}
>>>>> +
>>>>> +static inline void __raw_writeq(u64 val, const volatile void
>>>>> __iomem *addr)
>> Rename to __raw_writeq_nonatomic()
>>>>> +{
>>>>> + asm volatile("strd %Q1, %R1, %0"
>>>>> + : "+Q" (*(volatile u64 __force *)addr)
>>>>> + : "r" (val));
>>>>> +}
>>>>> +
>>>>> #define __iormb() rmb()
>>>>> #define __iowmb() wmb()
>>>>> @@ -80,17 +96,22 @@ static inline u32 __raw_readl(const volatile
>>>>> void __iomem *addr)
>>>>> __raw_readw(c)); __r; })
>>>>> #define readl_relaxed(c) ({ u32 __r = le32_to_cpu((__force __le32) \
>>>>> __raw_readl(c)); __r; })
>>>>> +#define readq_relaxed(c) ({ u64 __r = le64_to_cpu((__force __le64) \
>>>>> + __raw_readq(c)); __r; })
>>>>> #define writeb_relaxed(v,c) __raw_writeb(v,c)
>>>>> #define writew_relaxed(v,c) __raw_writew((__force u16)
>>>>> cpu_to_le16(v),c)
>>>>> #define writel_relaxed(v,c) __raw_writel((__force u32)
>>>>> cpu_to_le32(v),c)
>>>>> +#define writeq_relaxed(v,c) __raw_writeq((__force u64)
>>>>> cpu_to_le64(v),c)
>>>>> #define readb(c) ({ u8 __v = readb_relaxed(c);
>>>>> __iormb(); __v; })
>>>>> #define readw(c) ({ u16 __v = readw_relaxed(c);
>>>>> __iormb(); __v; })
>>>>> #define readl(c) ({ u32 __v = readl_relaxed(c);
>>>>> __iormb(); __v; })
>>>>> +#define readq(c) ({ u64 __v = readq_relaxed(c);
>>>>> __iormb(); __v; })
>>>>> #define writeb(v,c) ({ __iowmb();
>>>>> writeb_relaxed(v,c); })
>>>>> #define writew(v,c) ({ __iowmb();
>>>>> writew_relaxed(v,c); })
>>>>> #define writel(v,c) ({ __iowmb();
>>>>> writel_relaxed(v,c); })
>>>>> +#define writeq(v,c) ({ __iowmb(); writeq_relaxed(v,c); })
>>>>> #endif /* _ARM_ARM32_IO_H */
>>>>
>>>> AFAIU, ldrd/strd accesses to MMIO are not guaranteed to be 64-bit
>>>> single-copy atomic. So, as Julien suggested, you still need to use a
>>>> different name to reflect this.
>>
>> Yes you are correct, ldrd/strd for system ram are guaranteed to be
>> atomic. Here we are accessing MMIO, so atomicity is not guaranteed.
>>
>> I wasn't very sure if {read/write}*_relaxed are always atomic.
>
> All the current use are atomic.
>> #define writeq_relaxed(v,c) __raw_writeq_nonatomic((__force u64)
>> cpu_to_le64(v),c)
>>
>> #define readq_relaxed(c) ({ u64 __r = le64_to_cpu((__force __le64) \
>> __raw_readq_nonatomic(c));
>> __r; })
>>
>> We can remove "#define readq()/writeq() ..." as they are not used.
>>
>>>> Also, having nested virtualization in mind, since these instructions
>>>> can't be virtualized, maybe it would be better to avoid using them
>>>> for MMIO accesses.
>>
>> Does nested virtualization apply to Arm ?
>
> This is supported by the Architecture although not implemented in Xen.
>
>>
>> Reading https://wiki.xenproject.org/wiki/Nested_Virtualization_in_Xen
>> , I find two points of interest
>>
>> "Only 64-bit hypervisors are supported at this time."
>>
>> "See below for more details on tested hypervisior / guest
>> combinations, and known issues on Intel CPUs"
>>
>> Thus, I understand that nested virtualization is supported only on x86
>> machines and that too 64bit only. Thus, it does not apply to AArch32.
>
> The wiki page is describing the case where another hypervisor is running
> on top of Xen. But there is no support necessary in Xen to run it on top
> of another hypervisor.
>
> I haven't looked whether the architecture allows to use nested on 32-bit
> though...
>
To clarify... what I had in mind was an aarch32 XEN (guest) hosted by an
aarch64 hypervisor.
>>
>> Let me know if I misunderstood something.
>>
>>>
>>> +1. The previous version was actually using 32-bit access and it is
>>> not clear to me why the new version is using 64-bit access.
>>
>> IMO, I made a mistake in my previous patch of using 2 32bit access for
>> a 64 bit register.
>>
>> ldrd/strd is not supported for AArch32 guests in EL1 mode when they
>> access emulated MMIO region (which traps to EL2).
>>
>> However, ldrd/strd is supported for AArch32 hypervisors running in EL2
>> mode.
>
> That's not what I understood from previous discussion [1]. ldrd/strd
> would be atomic on system RAM but there is no guarantee they would be
> for MMIO access.
>
> I know this was Andre's interpretation. However, the HW architects may
> have interpreted the same way...
>
> So I think we should be convervative in Xen. AFAICT, in the case of
> GICv3, we don't need the atomicity for the 64-bit registers. Therefore,
> I would rather prefer if we introduce an helper that do two 32-bit read.
>
> Cheers,
>
> [1]
> https://lore.kernel.org/xen-devel/20221027153632.0cf7d004@donnerap.cambridge.arm.com/
>
>
--
Xenia
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [XEN v2 10/12] xen/Arm: GICv3: Use ULL instead of UL for 64bits
2022-11-01 10:03 ` Xenia Ragiadakou
@ 2022-11-01 14:43 ` Ayan Kumar Halder
2022-11-02 8:10 ` Xenia Ragiadakou
0 siblings, 1 reply; 59+ messages in thread
From: Ayan Kumar Halder @ 2022-11-01 14:43 UTC (permalink / raw)
To: Xenia Ragiadakou, xen-devel
Cc: sstabellini, stefanos, julien, Volodymyr_Babchuk, bertrand.marquis
On 01/11/2022 10:03, Xenia Ragiadakou wrote:
> Hi Ayan,
Hi Xenia,
>
> On 10/31/22 17:13, Ayan Kumar Halder wrote:
>> "unsigned long long" is defined as 64 bits on AArch64 and AArch32
>> Thus, one should this instead of "unsigned long" which is 32 bits
>> on AArch32.
>>
>> Also use 'PRIx64' instead of 'lx' or 'llx' to print uint64_t.
>>
>> Signed-off-by: Ayan Kumar Halder <ayankuma@amd.com>
>> ---
>>
>> Changed from :-
>> v1 - 1. Replace PRIu64 with PRIx64 so that the values are printed in
>> hex as
>> desired.
>> 2. Use ULL in GITS_BASER_RO_MASK as MMIO registers are always unsigned.
>>
>> xen/arch/arm/gic-v3-lpi.c | 8 ++++----
>> xen/arch/arm/gic-v3.c | 4 ++--
>> xen/arch/arm/include/asm/gic_v3_defs.h | 2 +-
>> xen/arch/arm/include/asm/gic_v3_its.h | 2 +-
>> xen/arch/arm/vgic-v3-its.c | 17 +++++++++--------
>> 5 files changed, 17 insertions(+), 16 deletions(-)
>>
>> diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
>> index 61d90eb386..9ca74bc321 100644
>> --- a/xen/arch/arm/gic-v3-lpi.c
>> +++ b/xen/arch/arm/gic-v3-lpi.c
>> @@ -134,7 +134,7 @@ void gicv3_set_redist_address(paddr_t address,
>> unsigned int redist_id)
>> uint64_t gicv3_get_redist_address(unsigned int cpu, bool use_pta)
>> {
>> if ( use_pta )
>> - return per_cpu(lpi_redist, cpu).redist_addr & GENMASK(51, 16);
>> + return per_cpu(lpi_redist, cpu).redist_addr &
>> GENMASK_ULL(51, 16);
>> else
>> return per_cpu(lpi_redist, cpu).redist_id << 16;
>> }
>> @@ -253,7 +253,7 @@ static int gicv3_lpi_allocate_pendtable(unsigned
>> int cpu)
>> return -ENOMEM;
>> /* Make sure the physical address can be encoded in the
>> register. */
>> - if ( virt_to_maddr(pendtable) & ~GENMASK(51, 16) )
>> + if ( virt_to_maddr(pendtable) & ~GENMASK_ULL(51, 16) )
>> {
>> xfree(pendtable);
>> return -ERANGE;
>> @@ -281,7 +281,7 @@ static int gicv3_lpi_set_pendtable(void __iomem
>> *rdist_base)
>> return -ENOMEM;
>> }
>> - ASSERT(!(virt_to_maddr(pendtable) & ~GENMASK(51, 16)));
>> + ASSERT(!(virt_to_maddr(pendtable) & ~GENMASK_ULL(51, 16)));
>> val = GIC_BASER_CACHE_RaWaWb <<
>> GICR_PENDBASER_INNER_CACHEABILITY_SHIFT;
>> val |= GIC_BASER_CACHE_SameAsInner <<
>> GICR_PENDBASER_OUTER_CACHEABILITY_SHIFT;
>> @@ -329,7 +329,7 @@ static int gicv3_lpi_set_proptable(void __iomem *
>> rdist_base)
>> return -ENOMEM;
>> /* Make sure the physical address can be encoded in the
>> register. */
>> - if ( (virt_to_maddr(table) & ~GENMASK(51, 12)) )
>> + if ( (virt_to_maddr(table) & ~GENMASK_ULL(51, 12)) )
>> {
>> xfree(table);
>> return -ERANGE;
>> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
>> index 8b4b168e78..d8ce0f46c6 100644
>> --- a/xen/arch/arm/gic-v3.c
>> +++ b/xen/arch/arm/gic-v3.c
>> @@ -417,12 +417,12 @@ static void gicv3_dump_state(const struct vcpu *v)
>> if ( v == current )
>> {
>> for ( i = 0; i < gicv3_info.nr_lrs; i++ )
>> - printk(" HW_LR[%d]=%llx\n", i, gicv3_ich_read_lr(i));
>> + printk(" HW_LR[%d]=%" PRIx64 "\n", i,
>> gicv3_ich_read_lr(i));
>> }
>> else
>> {
>> for ( i = 0; i < gicv3_info.nr_lrs; i++ )
>> - printk(" VCPU_LR[%d]=%llx\n", i, v->arch.gic.v3.lr[i]);
>> + printk(" VCPU_LR[%d]=%" PRIx64 "\n", i,
>> v->arch.gic.v3.lr[i]);
>> }
>> }
>> diff --git a/xen/arch/arm/include/asm/gic_v3_defs.h
>> b/xen/arch/arm/include/asm/gic_v3_defs.h
>> index 87115f8b25..3a24bd4825 100644
>> --- a/xen/arch/arm/include/asm/gic_v3_defs.h
>> +++ b/xen/arch/arm/include/asm/gic_v3_defs.h
>> @@ -195,7 +195,7 @@
>> #define ICH_SGI_IRQMODE_SHIFT 40
>> #define ICH_SGI_IRQMODE_MASK 0x1
>> -#define ICH_SGI_TARGET_OTHERS 1UL
>> +#define ICH_SGI_TARGET_OTHERS 1ULL
>> #define ICH_SGI_TARGET_LIST 0
>> #define ICH_SGI_IRQ_SHIFT 24
>> #define ICH_SGI_IRQ_MASK 0xf
>> diff --git a/xen/arch/arm/include/asm/gic_v3_its.h
>> b/xen/arch/arm/include/asm/gic_v3_its.h
>> index fae3f6ecef..5ae50b18ea 100644
>> --- a/xen/arch/arm/include/asm/gic_v3_its.h
>> +++ b/xen/arch/arm/include/asm/gic_v3_its.h
Changes not required as ITS is not supported on AArch32 v8R GIC.
>> @@ -38,7 +38,7 @@
>> #define GITS_PIDR2 GICR_PIDR2
>> /* Register bits */
>> -#define GITS_VALID_BIT BIT(63, UL)
>> +#define GITS_VALID_BIT BIT(63, ULL)
>> #define GITS_CTLR_QUIESCENT BIT(31, UL)
>> #define GITS_CTLR_ENABLE BIT(0, UL)
>
> It seems that you forgot GITS_BASER_INDIRECT, that is BIT(62, UL).
>
>> diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
>> index 58d939b85f..c5e02b2c41 100644
>> --- a/xen/arch/arm/vgic-v3-its.c
>> +++ b/xen/arch/arm/vgic-v3-its.c
Changes not required as ITS is not supported on AArch32 v8R GIC.
>> @@ -96,13 +96,13 @@ typedef uint16_t coll_table_entry_t;
>> * in the lowest 5 bits of the word.
>> */
>> typedef uint64_t dev_table_entry_t;
>> -#define DEV_TABLE_ITT_ADDR(x) ((x) & GENMASK(51, 8))
>> +#define DEV_TABLE_ITT_ADDR(x) ((x) & GENMASK_ULL(51, 8))
>> #define DEV_TABLE_ITT_SIZE(x) (BIT(((x) & GENMASK(4, 0)) + 1, UL))
>> #define DEV_TABLE_ENTRY(addr, bits) \
>> (((addr) & GENMASK(51, 8)) | (((bits) - 1) & GENMASK(4, 0)))
>> #define GITS_BASER_RO_MASK (GITS_BASER_TYPE_MASK | \
>> - (0x1fL <<
>> GITS_BASER_ENTRY_SIZE_SHIFT))
>> + (0x1ULL <<
>> GITS_BASER_ENTRY_SIZE_SHIFT))
>
> You have accidently dropped 'f' from the mask.
Yes, actually I intentionally dropped it.
AFAIU, 'fL' represent a floating point literal. This does not make sense
are the MMIO registers are always unsigned long (32 bit) or unsigned
long long (64 bit).
So, I corrected it.
>
> I noticed that you change to ULL only a part of GENMASK and BIT
> occurences, I cannot see why. Maybe I m missing sth.
Actually, I am trying to change only where the shift exceeds 32 bits.
>
> Also, with patch [XEN v2 12/12] xen/Arm: GICv3: Enable GICv3 for
> AArch32, you disable ITS support for arm32, so it seems that those
> changes in ITS related files are not required (not that do any harm to
> have).
Sorry, this is my mistake. I should not have changed gic_v3_its.h or
vgic-v3-its.c as they are not used for AArch32 v8R GIC.
I will fix this in v3.
- Ayan
>
>> /*
>> * The physical address is encoded slightly differently depending on
>> @@ -112,10 +112,10 @@ typedef uint64_t dev_table_entry_t;
>> static paddr_t get_baser_phys_addr(uint64_t reg)
>> {
>> if ( reg & BIT(9, UL) )
>> - return (reg & GENMASK(47, 16)) |
>> + return (reg & GENMASK_ULL(47, 16)) |
>> ((reg & GENMASK(15, 12)) << 36);
>> else
>> - return reg & GENMASK(47, 12);
>> + return reg & GENMASK_ULL(47, 12);
>> }
>> /* Must be called with the ITS lock held. */
>> @@ -414,7 +414,7 @@ static int update_lpi_property(struct domain *d,
>> struct pending_irq *p)
>> if ( !d->arch.vgic.rdists_enabled )
>> return 0;
>> - addr = d->arch.vgic.rdist_propbase & GENMASK(51, 12);
>> + addr = d->arch.vgic.rdist_propbase & GENMASK_ULL(51, 12);
>> ret = access_guest_memory_by_ipa(d, addr + p->irq - LPI_OFFSET,
>> &property, sizeof(property),
>> false);
>> @@ -897,7 +897,8 @@ out_unlock:
>> static void dump_its_command(uint64_t *command)
>> {
>> - gdprintk(XENLOG_WARNING, " cmd 0x%02lx: %016lx %016lx %016lx
>> %016lx\n",
>> + gdprintk(XENLOG_WARNING, " cmd 0x%" PRIx64 ": %" PRIx64
>> + "%" PRIx64 "%" PRIx64 "%" PRIx64 "\n",
>> its_cmd_get_command(command),
>> command[0], command[1], command[2], command[3]);
>> }
>> @@ -909,7 +910,7 @@ static void dump_its_command(uint64_t *command)
>> */
>> static int vgic_its_handle_cmds(struct domain *d, struct virt_its
>> *its)
>> {
>> - paddr_t addr = its->cbaser & GENMASK(51, 12);
>> + paddr_t addr = its->cbaser & GENMASK_ULL(51, 12);
>> uint64_t command[4];
>> ASSERT(spin_is_locked(&its->vcmd_lock));
>> @@ -1122,7 +1123,7 @@ read_as_zero_64:
>> read_impl_defined:
>> printk(XENLOG_G_DEBUG
>> - "%pv: vGITS: RAZ on implementation defined register
>> offset %#04lx\n",
>> + "%pv: vGITS: RAZ on implementation defined register
>> offset %" PRIx64 "#04llx\n",
>> v, info->gpa & 0xffff);
>> *r = 0;
>> return 1;
>
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [XEN v2 10/12] xen/Arm: GICv3: Use ULL instead of UL for 64bits
2022-11-01 14:43 ` Ayan Kumar Halder
@ 2022-11-02 8:10 ` Xenia Ragiadakou
0 siblings, 0 replies; 59+ messages in thread
From: Xenia Ragiadakou @ 2022-11-02 8:10 UTC (permalink / raw)
To: Ayan Kumar Halder, xen-devel
Cc: sstabellini, stefanos, julien, Volodymyr_Babchuk, bertrand.marquis
On 11/1/22 16:43, Ayan Kumar Halder wrote:
>
> On 01/11/2022 10:03, Xenia Ragiadakou wrote:
>> Hi Ayan,
> Hi Xenia,
>>
>> On 10/31/22 17:13, Ayan Kumar Halder wrote:
>>> "unsigned long long" is defined as 64 bits on AArch64 and AArch32
>>> Thus, one should this instead of "unsigned long" which is 32 bits
>>> on AArch32.
>>>
>>> Also use 'PRIx64' instead of 'lx' or 'llx' to print uint64_t.
>>>
>>> Signed-off-by: Ayan Kumar Halder <ayankuma@amd.com>
>>> ---
>>>
>>> Changed from :-
>>> v1 - 1. Replace PRIu64 with PRIx64 so that the values are printed in
>>> hex as
>>> desired.
>>> 2. Use ULL in GITS_BASER_RO_MASK as MMIO registers are always unsigned.
>>>
>>> xen/arch/arm/gic-v3-lpi.c | 8 ++++----
>>> xen/arch/arm/gic-v3.c | 4 ++--
>>> xen/arch/arm/include/asm/gic_v3_defs.h | 2 +-
>>> xen/arch/arm/include/asm/gic_v3_its.h | 2 +-
>>> xen/arch/arm/vgic-v3-its.c | 17 +++++++++--------
>>> 5 files changed, 17 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
>>> index 61d90eb386..9ca74bc321 100644
>>> --- a/xen/arch/arm/gic-v3-lpi.c
>>> +++ b/xen/arch/arm/gic-v3-lpi.c
>>> @@ -134,7 +134,7 @@ void gicv3_set_redist_address(paddr_t address,
>>> unsigned int redist_id)
>>> uint64_t gicv3_get_redist_address(unsigned int cpu, bool use_pta)
>>> {
>>> if ( use_pta )
>>> - return per_cpu(lpi_redist, cpu).redist_addr & GENMASK(51, 16);
>>> + return per_cpu(lpi_redist, cpu).redist_addr &
>>> GENMASK_ULL(51, 16);
>>> else
>>> return per_cpu(lpi_redist, cpu).redist_id << 16;
>>> }
>>> @@ -253,7 +253,7 @@ static int gicv3_lpi_allocate_pendtable(unsigned
>>> int cpu)
>>> return -ENOMEM;
>>> /* Make sure the physical address can be encoded in the
>>> register. */
>>> - if ( virt_to_maddr(pendtable) & ~GENMASK(51, 16) )
>>> + if ( virt_to_maddr(pendtable) & ~GENMASK_ULL(51, 16) )
>>> {
>>> xfree(pendtable);
>>> return -ERANGE;
>>> @@ -281,7 +281,7 @@ static int gicv3_lpi_set_pendtable(void __iomem
>>> *rdist_base)
>>> return -ENOMEM;
>>> }
>>> - ASSERT(!(virt_to_maddr(pendtable) & ~GENMASK(51, 16)));
>>> + ASSERT(!(virt_to_maddr(pendtable) & ~GENMASK_ULL(51, 16)));
>>> val = GIC_BASER_CACHE_RaWaWb <<
>>> GICR_PENDBASER_INNER_CACHEABILITY_SHIFT;
>>> val |= GIC_BASER_CACHE_SameAsInner <<
>>> GICR_PENDBASER_OUTER_CACHEABILITY_SHIFT;
>>> @@ -329,7 +329,7 @@ static int gicv3_lpi_set_proptable(void __iomem *
>>> rdist_base)
>>> return -ENOMEM;
>>> /* Make sure the physical address can be encoded in the
>>> register. */
>>> - if ( (virt_to_maddr(table) & ~GENMASK(51, 12)) )
>>> + if ( (virt_to_maddr(table) & ~GENMASK_ULL(51, 12)) )
>>> {
>>> xfree(table);
>>> return -ERANGE;
>>> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
>>> index 8b4b168e78..d8ce0f46c6 100644
>>> --- a/xen/arch/arm/gic-v3.c
>>> +++ b/xen/arch/arm/gic-v3.c
>>> @@ -417,12 +417,12 @@ static void gicv3_dump_state(const struct vcpu *v)
>>> if ( v == current )
>>> {
>>> for ( i = 0; i < gicv3_info.nr_lrs; i++ )
>>> - printk(" HW_LR[%d]=%llx\n", i, gicv3_ich_read_lr(i));
>>> + printk(" HW_LR[%d]=%" PRIx64 "\n", i,
>>> gicv3_ich_read_lr(i));
>>> }
>>> else
>>> {
>>> for ( i = 0; i < gicv3_info.nr_lrs; i++ )
>>> - printk(" VCPU_LR[%d]=%llx\n", i, v->arch.gic.v3.lr[i]);
>>> + printk(" VCPU_LR[%d]=%" PRIx64 "\n", i,
>>> v->arch.gic.v3.lr[i]);
>>> }
>>> }
>>> diff --git a/xen/arch/arm/include/asm/gic_v3_defs.h
>>> b/xen/arch/arm/include/asm/gic_v3_defs.h
>>> index 87115f8b25..3a24bd4825 100644
>>> --- a/xen/arch/arm/include/asm/gic_v3_defs.h
>>> +++ b/xen/arch/arm/include/asm/gic_v3_defs.h
>>> @@ -195,7 +195,7 @@
>>> #define ICH_SGI_IRQMODE_SHIFT 40
>>> #define ICH_SGI_IRQMODE_MASK 0x1
>>> -#define ICH_SGI_TARGET_OTHERS 1UL
>>> +#define ICH_SGI_TARGET_OTHERS 1ULL
>>> #define ICH_SGI_TARGET_LIST 0
>>> #define ICH_SGI_IRQ_SHIFT 24
>>> #define ICH_SGI_IRQ_MASK 0xf
>>> diff --git a/xen/arch/arm/include/asm/gic_v3_its.h
>>> b/xen/arch/arm/include/asm/gic_v3_its.h
>>> index fae3f6ecef..5ae50b18ea 100644
>>> --- a/xen/arch/arm/include/asm/gic_v3_its.h
>>> +++ b/xen/arch/arm/include/asm/gic_v3_its.h
> Changes not required as ITS is not supported on AArch32 v8R GIC.
>>> @@ -38,7 +38,7 @@
>>> #define GITS_PIDR2 GICR_PIDR2
>>> /* Register bits */
>>> -#define GITS_VALID_BIT BIT(63, UL)
>>> +#define GITS_VALID_BIT BIT(63, ULL)
>>> #define GITS_CTLR_QUIESCENT BIT(31, UL)
>>> #define GITS_CTLR_ENABLE BIT(0, UL)
>>
>> It seems that you forgot GITS_BASER_INDIRECT, that is BIT(62, UL).
>>
>>> diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
>>> index 58d939b85f..c5e02b2c41 100644
>>> --- a/xen/arch/arm/vgic-v3-its.c
>>> +++ b/xen/arch/arm/vgic-v3-its.c
> Changes not required as ITS is not supported on AArch32 v8R GIC.
>>> @@ -96,13 +96,13 @@ typedef uint16_t coll_table_entry_t;
>>> * in the lowest 5 bits of the word.
>>> */
>>> typedef uint64_t dev_table_entry_t;
>>> -#define DEV_TABLE_ITT_ADDR(x) ((x) & GENMASK(51, 8))
>>> +#define DEV_TABLE_ITT_ADDR(x) ((x) & GENMASK_ULL(51, 8))
>>> #define DEV_TABLE_ITT_SIZE(x) (BIT(((x) & GENMASK(4, 0)) + 1, UL))
>>> #define DEV_TABLE_ENTRY(addr, bits) \
>>> (((addr) & GENMASK(51, 8)) | (((bits) - 1) & GENMASK(4, 0)))
>>> #define GITS_BASER_RO_MASK (GITS_BASER_TYPE_MASK | \
>>> - (0x1fL <<
>>> GITS_BASER_ENTRY_SIZE_SHIFT))
>>> + (0x1ULL <<
>>> GITS_BASER_ENTRY_SIZE_SHIFT))
>>
>> You have accidently dropped 'f' from the mask.
>
> Yes, actually I intentionally dropped it.
>
> AFAIU, 'fL' represent a floating point literal. This does not make sense
> are the MMIO registers are always unsigned long (32 bit) or unsigned
> long long (64 bit).
Probably you got a bit confused. Here f is just a hex digit. The
expression cannot be a hex floating point literal because there is no
exponent part.
>
> So, I corrected it.
>
>>
>> I noticed that you change to ULL only a part of GENMASK and BIT
>> occurences, I cannot see why. Maybe I m missing sth.
> Actually, I am trying to change only where the shift exceeds 32 bits.
>>
>> Also, with patch [XEN v2 12/12] xen/Arm: GICv3: Enable GICv3 for
>> AArch32, you disable ITS support for arm32, so it seems that those
>> changes in ITS related files are not required (not that do any harm to
>> have).
>
> Sorry, this is my mistake. I should not have changed gic_v3_its.h or
> vgic-v3-its.c as they are not used for AArch32 v8R GIC.
>
> I will fix this in v3.
>
> - Ayan
>
>>
>>> /*
>>> * The physical address is encoded slightly differently depending on
>>> @@ -112,10 +112,10 @@ typedef uint64_t dev_table_entry_t;
>>> static paddr_t get_baser_phys_addr(uint64_t reg)
>>> {
>>> if ( reg & BIT(9, UL) )
>>> - return (reg & GENMASK(47, 16)) |
>>> + return (reg & GENMASK_ULL(47, 16)) |
>>> ((reg & GENMASK(15, 12)) << 36);
>>> else
>>> - return reg & GENMASK(47, 12);
>>> + return reg & GENMASK_ULL(47, 12);
>>> }
>>> /* Must be called with the ITS lock held. */
>>> @@ -414,7 +414,7 @@ static int update_lpi_property(struct domain *d,
>>> struct pending_irq *p)
>>> if ( !d->arch.vgic.rdists_enabled )
>>> return 0;
>>> - addr = d->arch.vgic.rdist_propbase & GENMASK(51, 12);
>>> + addr = d->arch.vgic.rdist_propbase & GENMASK_ULL(51, 12);
>>> ret = access_guest_memory_by_ipa(d, addr + p->irq - LPI_OFFSET,
>>> &property, sizeof(property),
>>> false);
>>> @@ -897,7 +897,8 @@ out_unlock:
>>> static void dump_its_command(uint64_t *command)
>>> {
>>> - gdprintk(XENLOG_WARNING, " cmd 0x%02lx: %016lx %016lx %016lx
>>> %016lx\n",
>>> + gdprintk(XENLOG_WARNING, " cmd 0x%" PRIx64 ": %" PRIx64
>>> + "%" PRIx64 "%" PRIx64 "%" PRIx64 "\n",
>>> its_cmd_get_command(command),
>>> command[0], command[1], command[2], command[3]);
>>> }
>>> @@ -909,7 +910,7 @@ static void dump_its_command(uint64_t *command)
>>> */
>>> static int vgic_its_handle_cmds(struct domain *d, struct virt_its
>>> *its)
>>> {
>>> - paddr_t addr = its->cbaser & GENMASK(51, 12);
>>> + paddr_t addr = its->cbaser & GENMASK_ULL(51, 12);
>>> uint64_t command[4];
>>> ASSERT(spin_is_locked(&its->vcmd_lock));
>>> @@ -1122,7 +1123,7 @@ read_as_zero_64:
>>> read_impl_defined:
>>> printk(XENLOG_G_DEBUG
>>> - "%pv: vGITS: RAZ on implementation defined register
>>> offset %#04lx\n",
>>> + "%pv: vGITS: RAZ on implementation defined register
>>> offset %" PRIx64 "#04llx\n",
>>> v, info->gpa & 0xffff);
>>> *r = 0;
>>> return 1;
>>
--
Xenia
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [XEN v2 02/12] xen/Arm: GICv3: Move the macros to compute the affnity level to arm64/arm32
2022-10-31 15:13 ` [XEN v2 02/12] xen/Arm: GICv3: Move the macros to compute the affnity level to arm64/arm32 Ayan Kumar Halder
2022-10-31 17:53 ` Michal Orzel
@ 2022-11-02 8:46 ` Julien Grall
2022-11-02 9:57 ` Xenia Ragiadakou
1 sibling, 1 reply; 59+ messages in thread
From: Julien Grall @ 2022-11-02 8:46 UTC (permalink / raw)
To: Ayan Kumar Halder, xen-devel
Cc: sstabellini, stefanos, Volodymyr_Babchuk, bertrand.marquis, burzalodowa
Hi,
Title: The macros you are moving are not GICv3 specific.
On 31/10/2022 15:13, Ayan Kumar Halder wrote:
> Refer https://elixir.bootlin.com/linux/v6.1-rc1/source/arch/arm64/ \
> include/asm/cputype.h#L14 , for the macros specific for arm64.
>
> Refer https://elixir.bootlin.com/linux/v6.1-rc1/source/arch/arm/include/ \
> asm/cputype.h#L54 , for the macros specific for arm32.
>
> MPIDR_LEVEL_SHIFT() differs between 64 and 32 bit. > For 64 bit :-
>
> aff_lev3 aff_lev2 aff_lev1 aff_lev0
> |________|________|________|________|________|
> 40 32 24 16 8 0
>
> For 32 bit :-
>
> aff_lev3 aff_lev2 aff_lev1 aff_lev0
> |________|________|________|________|
> 32 24 16 8 0
As discussed with Michal, AFF3 doesn't exist for 32-bit. So it is not
clear to me what we are gaining by moving the macros.
Cheers,
--
Julien Grall
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [XEN v2 01/12] xen/Arm: vGICv3: Sysreg emulation is applicable for Aarch64 only
2022-10-31 17:43 ` Michal Orzel
@ 2022-11-02 8:51 ` Julien Grall
0 siblings, 0 replies; 59+ messages in thread
From: Julien Grall @ 2022-11-02 8:51 UTC (permalink / raw)
To: Michal Orzel, Ayan Kumar Halder, xen-devel
Cc: sstabellini, stefanos, Volodymyr_Babchuk, bertrand.marquis, burzalodowa
On 31/10/2022 17:43, Michal Orzel wrote:
> Hi Ayan,
>
> On 31/10/2022 16:13, Ayan Kumar Halder wrote:
>>
>>
>> Refer ARM DDI 0487G.b ID072021, EC==0b011000 is supported for Aarch64 state
>
> I think when adding new code we should be taking the latest spec (which is I.a) as a base +
> you are lacking the information \wrt page number, table, whatever contains this information
> within ARM ARM.
+1.
>
> Apart from that, wouldn't it be easier for those reading the commit to just write e.g.:
> "Sysreg emulation is 64-bit specific, so guard the calls to vgic_v3_emulate_sysreg
> as well as the function itself with #ifdef CONFIG_ARM_64."
This read better. What matter is the emulation is 64-bit specific, not
that the EC doesn't exist on 32-bit (BTW, in theory 32-bit could have
re-used it for a different purpose...).
Cheers,
--
Julien Grall
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [XEN v2 03/12] xen/Arm: vreg: Support vreg_reg64_* helpers on Aarch32
2022-10-31 15:13 ` [XEN v2 03/12] xen/Arm: vreg: Support vreg_reg64_* helpers on Aarch32 Ayan Kumar Halder
@ 2022-11-02 8:52 ` Michal Orzel
2022-11-02 9:08 ` Julien Grall
2022-11-02 9:02 ` Julien Grall
1 sibling, 1 reply; 59+ messages in thread
From: Michal Orzel @ 2022-11-02 8:52 UTC (permalink / raw)
To: Ayan Kumar Halder, xen-devel
Cc: sstabellini, stefanos, julien, Volodymyr_Babchuk,
bertrand.marquis, burzalodowa
Hi Ayan,
On 31/10/2022 16:13, Ayan Kumar Halder wrote:
>
>
> In some situations (eg GICR_TYPER), the hypervior may need to emulate
> 64bit registers in aarch32 mode. In such situations, the hypervisor may
> need to read/modify the lower or upper 32 bits of the 64 bit register.
>
> In aarch32, 'unsigned long' is 32 bits. Thus, we cannot use it for 64 bit
> registers.
>
> The correct approach is to typecast 'mask' based on the size of register access
> (ie uint32_t or uint64_t) instead of using 'unsigned long' as it will not
> generate the correct mask for the upper 32 bits of a 64 bit register.
> Also, 'val' needs to be typecasted so that it can correctly update the upper/
> lower 32 bits of a 64 bit register.
>
> Signed-off-by: Ayan Kumar Halder <ayankuma@amd.com>
> ---
>
> Changes from :-
> v1 - 1. Remove vreg_reg_extract(), vreg_reg_update(), vreg_reg_setbits() and
> vreg_reg_clearbits(). Moved the implementation to vreg_reg##sz##_*.
> 'mask' and 'val' is now using uint##sz##_t.
>
> xen/arch/arm/include/asm/vreg.h | 88 ++++++++-------------------------
> 1 file changed, 20 insertions(+), 68 deletions(-)
>
> diff --git a/xen/arch/arm/include/asm/vreg.h b/xen/arch/arm/include/asm/vreg.h
> index f26a70d024..122ea79b65 100644
> --- a/xen/arch/arm/include/asm/vreg.h
> +++ b/xen/arch/arm/include/asm/vreg.h
> @@ -89,107 +89,59 @@ static inline bool vreg_emulate_sysreg(struct cpu_user_regs *regs, union hsr hsr
> * The check on the size supported by the register has to be done by
> * the caller of vreg_regN_*.
> *
> - * vreg_reg_* should never be called directly. Instead use the vreg_regN_*
> - * according to size of the emulated register
> - *
> * Note that the alignment fault will always be taken in the guest
> * (see B3.12.7 DDI0406.b).
> */
> -static inline register_t vreg_reg_extract(unsigned long reg,
> - unsigned int offset,
> - enum dabt_size size)
> -{
> - reg >>= 8 * offset;
> - reg &= VREG_REG_MASK(size);
> -
> - return reg;
> -}
> -
> -static inline void vreg_reg_update(unsigned long *reg, register_t val,
> - unsigned int offset,
> - enum dabt_size size)
> -{
> - unsigned long mask = VREG_REG_MASK(size);
> - int shift = offset * 8;
> -
> - *reg &= ~(mask << shift);
> - *reg |= ((unsigned long)val & mask) << shift;
> -}
> -
> -static inline void vreg_reg_setbits(unsigned long *reg, register_t bits,
> - unsigned int offset,
> - enum dabt_size size)
> -{
> - unsigned long mask = VREG_REG_MASK(size);
> - int shift = offset * 8;
> -
> - *reg |= ((unsigned long)bits & mask) << shift;
> -}
> -
> -static inline void vreg_reg_clearbits(unsigned long *reg, register_t bits,
> - unsigned int offset,
> - enum dabt_size size)
> -{
> - unsigned long mask = VREG_REG_MASK(size);
> - int shift = offset * 8;
> -
> - *reg &= ~(((unsigned long)bits & mask) << shift);
> -}
>
> /* N-bit register helpers */
> #define VREG_REG_HELPERS(sz, offmask) \
> static inline register_t vreg_reg##sz##_extract(uint##sz##_t reg, \
> const mmio_info_t *info)\
> { \
> - return vreg_reg_extract(reg, info->gpa & (offmask), \
> - info->dabt.size); \
> + unsigned int offset = info->gpa & (offmask); \
In all the other helpers you are also defining the variables to store shift and mask,
no matter the number of uses. I know that this is a left over from the removed helpers,
but since you are modifying the file you could improve consistency and define them
here as well.
> + \
> + reg >>= 8 * offset; \
> + reg &= VREG_REG_MASK(info->dabt.size); \
> + \
> + return reg; \
> } \
> \
> static inline void vreg_reg##sz##_update(uint##sz##_t *reg, \
> register_t val, \
> const mmio_info_t *info) \
> { \
> - unsigned long tmp = *reg; \
> - \
> - vreg_reg_update(&tmp, val, info->gpa & (offmask), \
> - info->dabt.size); \
> + unsigned int offset = info->gpa & (offmask); \
> + uint##sz##_t mask = VREG_REG_MASK(info->dabt.size); \
> + int shift = offset * 8; \
> \
> - *reg = tmp; \
> + *reg &= ~(mask << shift); \
> + *reg |= ((uint##sz##_t)val & mask) << shift; \
> } \
> \
> static inline void vreg_reg##sz##_setbits(uint##sz##_t *reg, \
> register_t bits, \
> const mmio_info_t *info) \
> { \
> - unsigned long tmp = *reg; \
> - \
> - vreg_reg_setbits(&tmp, bits, info->gpa & (offmask), \
> - info->dabt.size); \
> + unsigned int offset = info->gpa & (offmask); \
> + uint##sz##_t mask = VREG_REG_MASK(info->dabt.size); \
> + int shift = offset * 8; \
> \
> - *reg = tmp; \
> + *reg |= ((uint##sz##_t)bits & mask) << shift; \
> } \
> \
> static inline void vreg_reg##sz##_clearbits(uint##sz##_t *reg, \
> register_t bits, \
> const mmio_info_t *info) \
> { \
> - unsigned long tmp = *reg; \
> + unsigned int offset = info->gpa & (offmask); \
> + uint##sz##_t mask = VREG_REG_MASK(info->dabt.size); \
> + int shift = offset * 8; \
> \
> - vreg_reg_clearbits(&tmp, bits, info->gpa & (offmask), \
> - info->dabt.size); \
> - \
> - *reg = tmp; \
> + *reg &= ~(((uint##sz##_t)bits & mask) << shift); \
> }
>
> -/*
> - * 64 bits registers are only supported on platform with 64-bit long.
> - * This is also allow us to optimize the 32 bit case by using
> - * unsigned long rather than uint64_t
> - */
> -#if BITS_PER_LONG == 64
> -VREG_REG_HELPERS(64, 0x7);
> -#endif
> VREG_REG_HELPERS(32, 0x3);
> +VREG_REG_HELPERS(64, 0x7);
No need for the movement. 64 should stay as it was before 32 and you should only
remove the guards.
>
> #undef VREG_REG_HELPERS
>
> --
> 2.17.1
>
>
Apart from that, the change looks good.
~Michal
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [XEN v2 03/12] xen/Arm: vreg: Support vreg_reg64_* helpers on Aarch32
2022-10-31 15:13 ` [XEN v2 03/12] xen/Arm: vreg: Support vreg_reg64_* helpers on Aarch32 Ayan Kumar Halder
2022-11-02 8:52 ` Michal Orzel
@ 2022-11-02 9:02 ` Julien Grall
1 sibling, 0 replies; 59+ messages in thread
From: Julien Grall @ 2022-11-02 9:02 UTC (permalink / raw)
To: Ayan Kumar Halder, xen-devel
Cc: sstabellini, stefanos, Volodymyr_Babchuk, bertrand.marquis, burzalodowa
Hi,
On 31/10/2022 15:13, Ayan Kumar Halder wrote:
> In some situations (eg GICR_TYPER), the hypervior may need to emulate
Typo: s/eg/e.g./
> 64bit registers in aarch32 mode. In such situations, the hypervisor may
> need to read/modify the lower or upper 32 bits of the 64 bit register.
>
> In aarch32, 'unsigned long' is 32 bits. Thus, we cannot use it for 64 bit
> registers.
>
> The correct approach is to typecast 'mask' based on the size of register access
> (ie uint32_t or uint64_t) instead of using 'unsigned long' as it will not
> generate the correct mask for the upper 32 bits of a 64 bit register.
> Also, 'val' needs to be typecasted so that it can correctly update the upper/
'val' doesn't exist everywhere. But rather than explaining variable by
variable what needs to be done, I would suggest something like the
following:
"While we could replace 'unsigned long' by 'uint64_t', it is not
entirely clear whether a 32-bit compiler would not allocate register for
the upper 32-bit. Therefore fold vreg_reg_* helper in the size specific
one and use the appropriate type based on the size requested."
This would also explain why we didn't do a straight replacement of
"unsigned long" to "uint64_t".
[...]
> /* N-bit register helpers */
> #define VREG_REG_HELPERS(sz, offmask) \
> static inline register_t vreg_reg##sz##_extract(uint##sz##_t reg, \
> const mmio_info_t *info)\
> { \
> - return vreg_reg_extract(reg, info->gpa & (offmask), \
> - info->dabt.size); \
> + unsigned int offset = info->gpa & (offmask); \
> + \
> + reg >>= 8 * offset; \
> + reg &= VREG_REG_MASK(info->dabt.size); \
> + \
> + return reg; \
> } \
> \
> static inline void vreg_reg##sz##_update(uint##sz##_t *reg, \
> register_t val, \
> const mmio_info_t *info) \
> { \
> - unsigned long tmp = *reg; \
> - \
> - vreg_reg_update(&tmp, val, info->gpa & (offmask), \
> - info->dabt.size); \
> + unsigned int offset = info->gpa & (offmask); \
> + uint##sz##_t mask = VREG_REG_MASK(info->dabt.size); \
> + int shift = offset * 8; \
As you fold it, please switch to "unsigned int".
> \
> - *reg = tmp; \
> + *reg &= ~(mask << shift); \
> + *reg |= ((uint##sz##_t)val & mask) << shift; \
> } \
> \
> static inline void vreg_reg##sz##_setbits(uint##sz##_t *reg, \
> register_t bits, \
> const mmio_info_t *info) \
> { \
> - unsigned long tmp = *reg; \
> - \
> - vreg_reg_setbits(&tmp, bits, info->gpa & (offmask), \
> - info->dabt.size); \
> + unsigned int offset = info->gpa & (offmask); \
> + uint##sz##_t mask = VREG_REG_MASK(info->dabt.size); \
> + int shift = offset * 8; \
Same here.
> \
> - *reg = tmp; \
> + *reg |= ((uint##sz##_t)bits & mask) << shift; \
> } \
> \
> static inline void vreg_reg##sz##_clearbits(uint##sz##_t *reg, \
> register_t bits, \
> const mmio_info_t *info) \
> { \
> - unsigned long tmp = *reg; \
> + unsigned int offset = info->gpa & (offmask); \
> + uint##sz##_t mask = VREG_REG_MASK(info->dabt.size); \
> + int shift = offset * 8; \
Same here.
> \
> - vreg_reg_clearbits(&tmp, bits, info->gpa & (offmask), \
> - info->dabt.size); \
> - \
> - *reg = tmp; \
> + *reg &= ~(((uint##sz##_t)bits & mask) << shift); \
> }
>
> -/*
> - * 64 bits registers are only supported on platform with 64-bit long.
> - * This is also allow us to optimize the 32 bit case by using
> - * unsigned long rather than uint64_t
> - */
> -#if BITS_PER_LONG == 64
> -VREG_REG_HELPERS(64, 0x7);
> -#endif
> VREG_REG_HELPERS(32, 0x3);
> +VREG_REG_HELPERS(64, 0x7);
>
> #undef VREG_REG_HELPERS
>
Cheers,
--
Julien Grall
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [XEN v2 03/12] xen/Arm: vreg: Support vreg_reg64_* helpers on Aarch32
2022-11-02 8:52 ` Michal Orzel
@ 2022-11-02 9:08 ` Julien Grall
0 siblings, 0 replies; 59+ messages in thread
From: Julien Grall @ 2022-11-02 9:08 UTC (permalink / raw)
To: Michal Orzel, Ayan Kumar Halder, xen-devel
Cc: sstabellini, stefanos, Volodymyr_Babchuk, bertrand.marquis, burzalodowa
On 02/11/2022 08:52, Michal Orzel wrote:
>> /* N-bit register helpers */
>> #define VREG_REG_HELPERS(sz, offmask) \
>> static inline register_t vreg_reg##sz##_extract(uint##sz##_t reg, \
>> const mmio_info_t *info)\
>> { \
>> - return vreg_reg_extract(reg, info->gpa & (offmask), \
>> - info->dabt.size); \
>> + unsigned int offset = info->gpa & (offmask); \
> In all the other helpers you are also defining the variables to store shift and mask,
> no matter the number of uses. I know that this is a left over from the removed helpers,
> but since you are modifying the file you could improve consistency and define them
> here as well.
Nack. We don't define extra local variable just for consistency. They
are added in some places below to reduce the number of operation in one
line.
This is not necessary here.
Cheers,
--
Julien Grall
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [XEN v2 02/12] xen/Arm: GICv3: Move the macros to compute the affnity level to arm64/arm32
2022-11-02 8:46 ` Julien Grall
@ 2022-11-02 9:57 ` Xenia Ragiadakou
2022-11-02 10:10 ` Julien Grall
0 siblings, 1 reply; 59+ messages in thread
From: Xenia Ragiadakou @ 2022-11-02 9:57 UTC (permalink / raw)
To: Julien Grall, Ayan Kumar Halder, xen-devel
Cc: sstabellini, stefanos, Volodymyr_Babchuk, bertrand.marquis
On 11/2/22 10:46, Julien Grall wrote:
> Hi,
>
> Title: The macros you are moving are not GICv3 specific.
>
> On 31/10/2022 15:13, Ayan Kumar Halder wrote:
>> Refer https://elixir.bootlin.com/linux/v6.1-rc1/source/arch/arm64/ \
>> include/asm/cputype.h#L14 , for the macros specific for arm64.
>>
>> Refer
>> https://elixir.bootlin.com/linux/v6.1-rc1/source/arch/arm/include/ \
>> asm/cputype.h#L54 , for the macros specific for arm32.
>>
>> MPIDR_LEVEL_SHIFT() differs between 64 and 32 bit. > For 64 bit :-
>>
>> aff_lev3 aff_lev2 aff_lev1 aff_lev0
>> |________|________|________|________|________|
>> 40 32 24 16 8 0
>>
>> For 32 bit :-
>>
>> aff_lev3 aff_lev2 aff_lev1 aff_lev0
>> |________|________|________|________|
>> 32 24 16 8 0
>
> As discussed with Michal, AFF3 doesn't exist for 32-bit. So it is not
> clear to me what we are gaining by moving the macros.
>
I cannot understand what do you mean by "what we are gaining by moving
the macros".
IIUC, when identifying the cpu topology, a mask is applied to the value
of MPIDR_EL1
#ifdef CONFIG_ARM_64
#define MPIDR_HWID_MASK _AC(0xff00ffffff,UL)
#else
#define MPIDR_HWID_MASK _AC(0xffffff,U)
#endif
So, for arm32, the affinity at level 3 is considered to be 0.
Do you mean, what we are gaining by defining the MPIDR_LEVEL_SHIFT in a
different way for arm32 and for arm64?
IMO, we need to do so, because the shift, used to retrieve the affinity
at each level, cannot be calculated using the same logic i.e
(((1 << (level)) >> 1) << MPIDR_LEVEL_BITS_SHIFT)
For arm32 the affinity at each level is calculated as follows
((level) << MPIDR_LEVEL_BITS_SHIFT)
Also, IMO, since MPIDR_HWID_MASK is defined in the common header, maybe
the same needs to be done for MPIDR_LEVEL_SHIFT, to make easier for
someone reading the code to understand the difference.
I hope I'm not out of context.
> Cheers,
>
--
Xenia
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [XEN v2 02/12] xen/Arm: GICv3: Move the macros to compute the affnity level to arm64/arm32
2022-11-02 9:57 ` Xenia Ragiadakou
@ 2022-11-02 10:10 ` Julien Grall
2022-11-02 10:36 ` Xenia Ragiadakou
0 siblings, 1 reply; 59+ messages in thread
From: Julien Grall @ 2022-11-02 10:10 UTC (permalink / raw)
To: Xenia Ragiadakou, Ayan Kumar Halder, xen-devel
Cc: sstabellini, stefanos, Volodymyr_Babchuk, bertrand.marquis
Hi Xenia,
On 02/11/2022 09:57, Xenia Ragiadakou wrote:
>
> On 11/2/22 10:46, Julien Grall wrote:
>> Hi,
>>
>> Title: The macros you are moving are not GICv3 specific.
>>
>> On 31/10/2022 15:13, Ayan Kumar Halder wrote:
>>> Refer https://elixir.bootlin.com/linux/v6.1-rc1/source/arch/arm64/ \
>>> include/asm/cputype.h#L14 , for the macros specific for arm64.
>>>
>>> Refer
>>> https://elixir.bootlin.com/linux/v6.1-rc1/source/arch/arm/include/ \
>>> asm/cputype.h#L54 , for the macros specific for arm32.
>>>
>>> MPIDR_LEVEL_SHIFT() differs between 64 and 32 bit. > For 64 bit :-
>>>
>>> aff_lev3 aff_lev2 aff_lev1 aff_lev0
>>> |________|________|________|________|________|
>>> 40 32 24 16 8 0
>>>
>>> For 32 bit :-
>>>
>>> aff_lev3 aff_lev2 aff_lev1 aff_lev0
>>> |________|________|________|________|
>>> 32 24 16 8 0
>>
>> As discussed with Michal, AFF3 doesn't exist for 32-bit. So it is not
>> clear to me what we are gaining by moving the macros.
>>
>
> I cannot understand what do you mean by "what we are gaining by moving
> the macros".
>
> IIUC, when identifying the cpu topology, a mask is applied to the value
> of MPIDR_EL1
> #ifdef CONFIG_ARM_64
> #define MPIDR_HWID_MASK _AC(0xff00ffffff,UL)
> #else
> #define MPIDR_HWID_MASK _AC(0xffffff,U)
> #endif
> So, for arm32, the affinity at level 3 is considered to be 0.
>
> Do you mean, what we are gaining by defining the MPIDR_LEVEL_SHIFT in a
> different way for arm32 and for arm64?
Yes. There are nothing justifying the move so far.
>
> IMO, we need to do so, because the shift, used to retrieve the affinity
> at each level, cannot be calculated using the same logic i.e
> (((1 << (level)) >> 1) << MPIDR_LEVEL_BITS_SHIFT)
>
> For arm32 the affinity at each level is calculated as follows
> ((level) << MPIDR_LEVEL_BITS_SHIFT)
I understand they are written differently. But if you look at the
layout, AFF0, AFF1, AFF2 are in the same position. AFF3 doesn't exist
for arm32 and, AFAICT, the shift will not matter because the bits 40:32
will be zeroed in any case.
So I don't see the problem of using the arm64 version.
Cheers,
--
Julien Grall
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [XEN v2 05/12] xen/Arm: GICv3: Fix GICR_{PENDBASER, PROPBASER} emulation on 32-bit host
2022-10-31 15:13 ` [XEN v2 05/12] xen/Arm: GICv3: Fix GICR_{PENDBASER, PROPBASER} emulation on 32-bit host Ayan Kumar Halder
@ 2022-11-02 10:26 ` Michal Orzel
2022-11-06 18:05 ` Julien Grall
1 sibling, 0 replies; 59+ messages in thread
From: Michal Orzel @ 2022-11-02 10:26 UTC (permalink / raw)
To: Ayan Kumar Halder, xen-devel
Cc: sstabellini, stefanos, julien, Volodymyr_Babchuk,
bertrand.marquis, burzalodowa
Hi Ayan,
On 31/10/2022 16:13, Ayan Kumar Halder wrote:
>
>
> 'unsigned long long' is defined as 64 bit across both aarch32 and aarch64.
> So, use 'ULL' for 64 bit word instead of UL which is 32 bits for aarch32.
> GICR_PENDBASER and GICR_PROPBASER both are 64 bit registers.
>
> Signed-off-by: Ayan Kumar Halder <ayankuma@amd.com>
> ---
>
> Changes from -
> v1 - 1. Extract the bug fix for incorrect bit clearing (GICR_PENDBASER_PTZ)
> into a separate patch fix.
> https://patchwork.kernel.org/project/xen-devel/patch/20221027185555.46125-1-ayankuma@amd.com/
>
> xen/arch/arm/include/asm/gic_v3_defs.h | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/xen/arch/arm/include/asm/gic_v3_defs.h b/xen/arch/arm/include/asm/gic_v3_defs.h
> index 728e28d5e5..48a1bc401e 100644
> --- a/xen/arch/arm/include/asm/gic_v3_defs.h
> +++ b/xen/arch/arm/include/asm/gic_v3_defs.h
> @@ -134,15 +134,15 @@
>
> #define GICR_PROPBASER_OUTER_CACHEABILITY_SHIFT 56
> #define GICR_PROPBASER_OUTER_CACHEABILITY_MASK \
> - (7UL << GICR_PROPBASER_OUTER_CACHEABILITY_SHIFT)
> + (7ULL << GICR_PROPBASER_OUTER_CACHEABILITY_SHIFT)
> #define GICR_PROPBASER_SHAREABILITY_SHIFT 10
> #define GICR_PROPBASER_SHAREABILITY_MASK \
> - (3UL << GICR_PROPBASER_SHAREABILITY_SHIFT)
> + (3ULL << GICR_PROPBASER_SHAREABILITY_SHIFT)
> #define GICR_PROPBASER_INNER_CACHEABILITY_SHIFT 7
> #define GICR_PROPBASER_INNER_CACHEABILITY_MASK \
> - (7UL << GICR_PROPBASER_INNER_CACHEABILITY_SHIFT)
> + (7ULL << GICR_PROPBASER_INNER_CACHEABILITY_SHIFT)
> #define GICR_PROPBASER_RES0_MASK \
> - (GENMASK(63, 59) | GENMASK(55, 52) | GENMASK(6, 5))
> + (GENMASK_ULL(63, 59) | GENMASK_ULL(55, 52) | GENMASK_ULL(6, 5))
>
> #define GICR_PENDBASER_SHAREABILITY_SHIFT 10
> #define GICR_PENDBASER_INNER_CACHEABILITY_SHIFT 7
> @@ -152,11 +152,11 @@
> #define GICR_PENDBASER_INNER_CACHEABILITY_MASK \
> (7UL << GICR_PENDBASER_INNER_CACHEABILITY_SHIFT)
> #define GICR_PENDBASER_OUTER_CACHEABILITY_MASK \
> - (7UL << GICR_PENDBASER_OUTER_CACHEABILITY_SHIFT)
> -#define GICR_PENDBASER_PTZ BIT(62, UL)
> + (7ULL << GICR_PENDBASER_OUTER_CACHEABILITY_SHIFT)
> +#define GICR_PENDBASER_PTZ BIT(62, ULL)
> #define GICR_PENDBASER_RES0_MASK \
> - (BIT(63, UL) | GENMASK(61, 59) | GENMASK(55, 52) | \
> - GENMASK(15, 12) | GENMASK(6, 0))
> + (BIT(63, ULL) | GENMASK_ULL(61, 59) | GENMASK_ULL(55, 52) | \
It would be good to align \ but at the same time I can understand that it was not
aligned before your change and you may not want to do this, so:
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
~Michal
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [XEN v2 02/12] xen/Arm: GICv3: Move the macros to compute the affnity level to arm64/arm32
2022-11-02 10:10 ` Julien Grall
@ 2022-11-02 10:36 ` Xenia Ragiadakou
2022-11-06 17:59 ` Julien Grall
0 siblings, 1 reply; 59+ messages in thread
From: Xenia Ragiadakou @ 2022-11-02 10:36 UTC (permalink / raw)
To: Julien Grall, Ayan Kumar Halder, xen-devel
Cc: sstabellini, stefanos, Volodymyr_Babchuk, bertrand.marquis
Hi Julien,
On 11/2/22 12:10, Julien Grall wrote:
> Hi Xenia,
>
> On 02/11/2022 09:57, Xenia Ragiadakou wrote:
>>
>> On 11/2/22 10:46, Julien Grall wrote:
>>> Hi,
>>>
>>> Title: The macros you are moving are not GICv3 specific.
>>>
>>> On 31/10/2022 15:13, Ayan Kumar Halder wrote:
>>>> Refer https://elixir.bootlin.com/linux/v6.1-rc1/source/arch/arm64/ \
>>>> include/asm/cputype.h#L14 , for the macros specific for arm64.
>>>>
>>>> Refer
>>>> https://elixir.bootlin.com/linux/v6.1-rc1/source/arch/arm/include/ \
>>>> asm/cputype.h#L54 , for the macros specific for arm32.
>>>>
>>>> MPIDR_LEVEL_SHIFT() differs between 64 and 32 bit. > For 64 bit :-
>>>>
>>>> aff_lev3 aff_lev2 aff_lev1 aff_lev0
>>>> |________|________|________|________|________|
>>>> 40 32 24 16 8 0
>>>>
>>>> For 32 bit :-
>>>>
>>>> aff_lev3 aff_lev2 aff_lev1 aff_lev0
>>>> |________|________|________|________|
>>>> 32 24 16 8 0
>>>
>>> As discussed with Michal, AFF3 doesn't exist for 32-bit. So it is not
>>> clear to me what we are gaining by moving the macros.
>>>
>>
>> I cannot understand what do you mean by "what we are gaining by moving
>> the macros".
> >
>> IIUC, when identifying the cpu topology, a mask is applied to the
>> value of MPIDR_EL1
>> #ifdef CONFIG_ARM_64
>> #define MPIDR_HWID_MASK _AC(0xff00ffffff,UL)
>> #else
>> #define MPIDR_HWID_MASK _AC(0xffffff,U)
>> #endif
>> So, for arm32, the affinity at level 3 is considered to be 0.
>>
>> Do you mean, what we are gaining by defining the MPIDR_LEVEL_SHIFT in
>> a different way for arm32 and for arm64?
>
> Yes. There are nothing justifying the move so far.
>
>>
>> IMO, we need to do so, because the shift, used to retrieve the
>> affinity at each level, cannot be calculated using the same logic i.e
>> (((1 << (level)) >> 1) << MPIDR_LEVEL_BITS_SHIFT)
>>
>> For arm32 the affinity at each level is calculated as follows
>> ((level) << MPIDR_LEVEL_BITS_SHIFT)
>
> I understand they are written differently. But if you look at the
> layout, AFF0, AFF1, AFF2 are in the same position. AFF3 doesn't exist
> for arm32 and, AFAICT, the shift will not matter because the bits 40:32
> will be zeroed in any case.
>
> So I don't see the problem of using the arm64 version.
Now I see :) ... IIUC you are proposing to just cast the mpidr in
MPIDR_AFFINITY_LEVEL(mpidr, level) to uint64_t?
In this case, I think, UL, below, needs to also to become ULL
#define AFFINITY_MASK(level) ~((_AC(0x1,UL) <<
MPIDR_LEVEL_SHIFT(level)) - 1)
>
> Cheers,
>
--
Xenia
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [XEN v2 06/12] xen/Arm: vGICv3: Fix emulation of ICC_SGI1R on AArch32
2022-10-31 15:13 ` [XEN v2 06/12] xen/Arm: vGICv3: Fix emulation of ICC_SGI1R on AArch32 Ayan Kumar Halder
@ 2022-11-02 10:41 ` Michal Orzel
2022-11-06 18:06 ` Julien Grall
0 siblings, 1 reply; 59+ messages in thread
From: Michal Orzel @ 2022-11-02 10:41 UTC (permalink / raw)
To: Ayan Kumar Halder, xen-devel
Cc: sstabellini, stefanos, julien, Volodymyr_Babchuk,
bertrand.marquis, burzalodowa
Hi Ayan,
On 31/10/2022 16:13, Ayan Kumar Halder wrote:
>
>
> Refer Arm IHI 0069H ID020922, 12.5.23, ICC_SGI1R is a 64 bit register on
> Aarch32 systems. Thus, the prototype needs to change to reflect this.
NIT: prototype means function declaration.
vgic_v3_to_sgi is a function that has no prototype.
Apart from that:
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
~Michal
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [XEN v2 07/12] xen/Arm: GICv3: Define ICH_LR<n>_EL2 on AArch32
2022-10-31 15:13 ` [XEN v2 07/12] xen/Arm: GICv3: Define ICH_LR<n>_EL2 " Ayan Kumar Halder
@ 2022-11-03 12:13 ` Michal Orzel
2022-11-06 18:14 ` Julien Grall
2022-11-06 18:19 ` Julien Grall
1 sibling, 1 reply; 59+ messages in thread
From: Michal Orzel @ 2022-11-03 12:13 UTC (permalink / raw)
To: Ayan Kumar Halder, xen-devel
Cc: sstabellini, stefanos, julien, Volodymyr_Babchuk,
bertrand.marquis, burzalodowa
Hi Ayan,
On 31/10/2022 16:13, Ayan Kumar Halder wrote:
>
>
> Refer "Arm IHI 0069H ID020922", 12.4.6, Interrupt Controller List Registers
>
> AArch64 System register ICH_LR<n>_EL2 bits [31:0] are architecturally
> mapped to AArch32 System register ICH_LR<n>[31:0].
> AArch64 System register ICH_LR<n>_EL2 bits [63:32] are architecturally
> mapped to AArch32 System register ICH_LRC<n>[31:0].
>
> Defined ICH_LR<0...15>_EL2 and ICH_LRC<0...15>_EL2 for Aarch32.
> For AArch32, the link register is stored as :-
> (((uint64_t) ICH_LRC<0...15>_EL2) << 32) | ICH_LR<0...15>_EL2
>
> Also, ICR_LR macros need to be modified as ULL is 64 bits for AArch32 and
> AArch64.
>
> Signed-off-by: Ayan Kumar Halder <ayankuma@amd.com>
> ---
>
> Changes from :-
> v1 - 1. Moved the coproc register definitions to asm/cpregs.h.
> 2. Use GENMASK(31, 0) to represent 0xFFFFFFFF
> 3. Use READ_CP32()/WRITE_CP32() instead of READ_SYSREG()/WRITE_SYSREG().
> 4. Multi-line macro definitions should be enclosed within ({ }).
>
> xen/arch/arm/gic-v3.c | 132 +++++++++++------------
> xen/arch/arm/include/asm/arm32/sysregs.h | 17 +++
> xen/arch/arm/include/asm/arm64/sysregs.h | 3 +
> xen/arch/arm/include/asm/cpregs.h | 42 ++++++++
> xen/arch/arm/include/asm/gic_v3_defs.h | 6 +-
> 5 files changed, 131 insertions(+), 69 deletions(-)
>
> diff --git a/xen/arch/arm/include/asm/arm32/sysregs.h b/xen/arch/arm/include/asm/arm32/sysregs.h
> index 6841d5de43..8a9a014bef 100644
> --- a/xen/arch/arm/include/asm/arm32/sysregs.h
> +++ b/xen/arch/arm/include/asm/arm32/sysregs.h
> @@ -62,6 +62,23 @@
> #define READ_SYSREG(R...) READ_SYSREG32(R)
> #define WRITE_SYSREG(V, R...) WRITE_SYSREG32(V, R)
>
> +#define ICH_LR_REG(INDEX) ICH_LR ## INDEX ## _EL2
> +#define ICH_LRC_REG(INDEX) ICH_LRC ## INDEX ## _EL2
You could align to WRITE_SYSREG32(V, R).
Apart from that it would be good to add some comment before the code you added (ICH_LR_REG)
to separate from the code above and its comment about registers coming in 3 types.
Something like:
/* Wrappers for accessing interrupt controller list registers. */
> +
> +#define READ_SYSREG_LR(INDEX) ({ \
Opening ({ should be placed one space after READ_SYSREG_LR(INDEX). It does not need to be aligned.
> + uint64_t _val; \
val is not really necessary. You could directly return the ((uint64_t) _lrc << 32) | _lr;
Just something to consider, no need to replace.
> + uint32_t _lrc = READ_CP32(ICH_LRC_REG(INDEX)); \
> + uint32_t _lr = READ_CP32(ICH_LR_REG(INDEX)); \
> + \
> + _val = ((uint64_t) _lrc << 32) | _lr; \
> + _val; })
Here, you did put }) at the same line...
> +
> +#define WRITE_SYSREG_LR(INDEX, V) ({ \
> + uint64_t _val = (V); \
> + WRITE_CP32(_val & GENMASK(31, 0), ICH_LR_REG(INDEX)); \
> + WRITE_CP32(_val >> 32, ICH_LRC_REG(INDEX)); \
Please, align \
> +});
... and here you did not.
> +
> /* MVFR2 is not defined on ARMv7 */
> #define MVFR2_MAYBE_UNDEFINED
>
> diff --git a/xen/arch/arm/include/asm/arm64/sysregs.h b/xen/arch/arm/include/asm/arm64/sysregs.h
> index 54670084c3..353f0eea29 100644
> --- a/xen/arch/arm/include/asm/arm64/sysregs.h
> +++ b/xen/arch/arm/include/asm/arm64/sysregs.h
> @@ -471,6 +471,9 @@
>
> #define READ_SYSREG(name) READ_SYSREG64(name)
> #define WRITE_SYSREG(v, name) WRITE_SYSREG64(v, name)
Here, I would separate the below macros by adding the comment similar to the one I showed above.
Or at least add a blank line.
> +#define ICH_LR_REG(index) ICH_LR ## index ## _EL2
> +#define WRITE_SYSREG_LR(index, v) WRITE_SYSREG(v, ICH_LR_REG(index))
> +#define READ_SYSREG_LR(index) READ_SYSREG(ICH_LR_REG(index))
I find it a bit odd that the macro param 'index' is written in lower case and for arm32 in upper case.
>
> #endif /* _ASM_ARM_ARM64_SYSREGS_H */
>
> diff --git a/xen/arch/arm/include/asm/cpregs.h b/xen/arch/arm/include/asm/cpregs.h
> index 6daf2b1a30..4421dd49ac 100644
> --- a/xen/arch/arm/include/asm/cpregs.h
> +++ b/xen/arch/arm/include/asm/cpregs.h
> @@ -362,6 +362,48 @@
> #define MVFR0_EL1 MVFR0
> #define MVFR1_EL1 MVFR1
> #define MVFR2_EL1 MVFR2
> +
You could align everything below to MVFR2.
Also maybe you could add some comment stating that the below relates to GIC system registers?
> +#define ___CP32(a,b,c,d,e) a,b,c,d,e
> +#define __LR0_EL2(x) ___CP32(p15,4,c12,c12,x)
> +#define __LR8_EL2(x) ___CP32(p15,4,c12,c13,x)
> +
> +#define __LRC0_EL2(x) ___CP32(p15,4,c12,c14,x)
> +#define __LRC8_EL2(x) ___CP32(p15,4,c12,c15,x)
> +
> +#define ICH_LR0_EL2 __LR0_EL2(0)
> +#define ICH_LR1_EL2 __LR0_EL2(1)
> +#define ICH_LR2_EL2 __LR0_EL2(2)
> +#define ICH_LR3_EL2 __LR0_EL2(3)
> +#define ICH_LR4_EL2 __LR0_EL2(4)
> +#define ICH_LR5_EL2 __LR0_EL2(5)
> +#define ICH_LR6_EL2 __LR0_EL2(6)
> +#define ICH_LR7_EL2 __LR0_EL2(7)
> +#define ICH_LR8_EL2 __LR8_EL2(0)
> +#define ICH_LR9_EL2 __LR8_EL2(1)
> +#define ICH_LR10_EL2 __LR8_EL2(2)
> +#define ICH_LR11_EL2 __LR8_EL2(3)
> +#define ICH_LR12_EL2 __LR8_EL2(4)
> +#define ICH_LR13_EL2 __LR8_EL2(5)
> +#define ICH_LR14_EL2 __LR8_EL2(6)
> +#define ICH_LR15_EL2 __LR8_EL2(7)
> +
> +#define ICH_LRC0_EL2 __LRC0_EL2(0)
> +#define ICH_LRC1_EL2 __LRC0_EL2(1)
> +#define ICH_LRC2_EL2 __LRC0_EL2(2)
> +#define ICH_LRC3_EL2 __LRC0_EL2(3)
> +#define ICH_LRC4_EL2 __LRC0_EL2(4)
> +#define ICH_LRC5_EL2 __LRC0_EL2(5)
> +#define ICH_LRC6_EL2 __LRC0_EL2(6)
> +#define ICH_LRC7_EL2 __LRC0_EL2(7)
> +#define ICH_LRC8_EL2 __LRC8_EL2(0)
> +#define ICH_LRC9_EL2 __LRC8_EL2(1)
> +#define ICH_LRC10_EL2 __LRC8_EL2(2)
> +#define ICH_LRC11_EL2 __LRC8_EL2(3)
> +#define ICH_LRC12_EL2 __LRC8_EL2(4)
> +#define ICH_LRC13_EL2 __LRC8_EL2(5)
> +#define ICH_LRC14_EL2 __LRC8_EL2(6)
> +#define ICH_LRC15_EL2 __LRC8_EL2(7)
> +
> #endif
>
> #endif
> diff --git a/xen/arch/arm/include/asm/gic_v3_defs.h b/xen/arch/arm/include/asm/gic_v3_defs.h
> index 48a1bc401e..87115f8b25 100644
> --- a/xen/arch/arm/include/asm/gic_v3_defs.h
> +++ b/xen/arch/arm/include/asm/gic_v3_defs.h
> @@ -185,9 +185,9 @@
> #define ICH_LR_HW_SHIFT 61
> #define ICH_LR_GRP_MASK 0x1
> #define ICH_LR_GRP_SHIFT 60
> -#define ICH_LR_MAINTENANCE_IRQ (1UL<<41)
> -#define ICH_LR_GRP1 (1UL<<60)
> -#define ICH_LR_HW (1UL<<61)
> +#define ICH_LR_MAINTENANCE_IRQ (1ULL<<41)
> +#define ICH_LR_GRP1 (1ULL<<60)
> +#define ICH_LR_HW (1ULL<<61)
You could take the opportunity to add spaces between << to adhere to similar uses in this file.
>
> #define ICH_VTR_NRLRGS 0x3f
> #define ICH_VTR_PRIBITS_MASK 0x7
> --
> 2.17.1
>
>
~Michal
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [XEN v2 08/12] xen/Arm: GICv3: Define ICH_AP0R<n> and ICH_AP1R<n> for AArch32
2022-10-31 15:13 ` [XEN v2 08/12] xen/Arm: GICv3: Define ICH_AP0R<n> and ICH_AP1R<n> for AArch32 Ayan Kumar Halder
@ 2022-11-03 12:35 ` Michal Orzel
2022-11-06 18:20 ` Julien Grall
0 siblings, 1 reply; 59+ messages in thread
From: Michal Orzel @ 2022-11-03 12:35 UTC (permalink / raw)
To: Ayan Kumar Halder, xen-devel
Cc: sstabellini, stefanos, julien, Volodymyr_Babchuk,
bertrand.marquis, burzalodowa
Hi Ayan,
On 31/10/2022 16:13, Ayan Kumar Halder wrote:
>
>
> Refer "Arm IHI 0069H ID020922",
> 12.7.1 - Interrupt Controller Hyp Active Priorities Group0 Registers 0-3
> 12.7.2 - Interrupt Controller Hyp Active Priorities Group1 Registers 0-3
>
Commit msg like this is not really beneficial as it requires someone to have
this spec and only tells that such registers exist on AArch32. It is missing some
information e.g. what is the purpose of defining them.
> Signed-off-by: Ayan Kumar Halder <ayankuma@amd.com>
> ---
>
> Changes from :-
> v1 - 1. Moved coproc register definition to asm/cpregs.h.
>
> xen/arch/arm/include/asm/arm32/sysregs.h | 1 -
> xen/arch/arm/include/asm/cpregs.h | 11 +++++++++++
> 2 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/arm/include/asm/arm32/sysregs.h b/xen/arch/arm/include/asm/arm32/sysregs.h
> index 8a9a014bef..1b2915a526 100644
> --- a/xen/arch/arm/include/asm/arm32/sysregs.h
> +++ b/xen/arch/arm/include/asm/arm32/sysregs.h
> @@ -81,7 +81,6 @@
>
> /* MVFR2 is not defined on ARMv7 */
> #define MVFR2_MAYBE_UNDEFINED
> -
> #endif /* __ASSEMBLY__ */
>
> #endif /* __ASM_ARM_ARM32_SYSREGS_H */
> diff --git a/xen/arch/arm/include/asm/cpregs.h b/xen/arch/arm/include/asm/cpregs.h
> index 4421dd49ac..bfabee0bc3 100644
> --- a/xen/arch/arm/include/asm/cpregs.h
> +++ b/xen/arch/arm/include/asm/cpregs.h
> @@ -404,6 +404,17 @@
> #define ICH_LRC14_EL2 __LRC8_EL2(6)
> #define ICH_LRC15_EL2 __LRC8_EL2(7)
>
> +#define __AP0Rx_EL2(x) ___CP32(p15,4,c12,c8,x)
> +#define ICH_AP0R0_EL2 __AP0Rx_EL2(0)
> +#define ICH_AP0R1_EL2 __AP0Rx_EL2(1)
> +#define ICH_AP0R2_EL2 __AP0Rx_EL2(2)
> +#define ICH_AP0R3_EL2 __AP0Rx_EL2(3)
> +
> +#define __AP1Rx_EL2(x) ___CP32(p15,4,c12,c9,x)
> +#define ICH_AP1R0_EL2 __AP1Rx_EL2(0)
> +#define ICH_AP1R1_EL2 __AP1Rx_EL2(1)
> +#define ICH_AP1R2_EL2 __AP1Rx_EL2(2)
> +#define ICH_AP1R3_EL2 __AP1Rx_EL2(3)
This might need to be re-aligned after you fix patch no. 7.
Then, you can add:
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
~Michal
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [XEN v2 09/12] xen/Arm: GICv3: Define GIC registers for AArch32
2022-10-31 15:13 ` [XEN v2 09/12] xen/Arm: GICv3: Define GIC registers " Ayan Kumar Halder
@ 2022-11-03 15:08 ` Michal Orzel
2022-11-03 20:14 ` Ayan Kumar Halder
2022-11-06 18:26 ` Julien Grall
0 siblings, 2 replies; 59+ messages in thread
From: Michal Orzel @ 2022-11-03 15:08 UTC (permalink / raw)
To: Ayan Kumar Halder, xen-devel
Cc: sstabellini, stefanos, julien, Volodymyr_Babchuk,
bertrand.marquis, burzalodowa
Hi Ayan,
On 31/10/2022 16:13, Ayan Kumar Halder wrote:
>
The title is a bit ambiguous given that the previous patches were also defining GIC registers.
Maybe adding "remaining" would result in a better commit title.
>
> Refer "Arm IHI 0069H ID020922"
> 12.5.23 ICC_SGI1R, Interrupt Controller Software Generated Interrupt
> Group 1 Register
> 12.5.12 ICC_HSRE, Interrupt Controller Hyp System Register Enable register
> 12.7.10 ICH_VTR, Interrupt Controller VGIC Type Register
> 12.7.5 ICH_HCR, Interrupt Controller Hyp Control Register
> 12.5.20 ICC_PMR, Interrupt Controller Interrupt Priority Mask Register
> 12.5.24 ICC_SRE, Interrupt Controller System Register Enable register
> 12.5.7 ICC_DIR, Interrupt Controller Deactivate Interrupt Register
> 12.5.9 ICC_EOIR1, Interrupt Controller End Of Interrupt Register 1
> 12.5.14 ICC_IAR1, Interrupt Controller Interrupt Acknowledge Register 1
> 12.5.5 ICC_BPR1, Interrupt Controller Binary Point Register 1
> 12.5.6 ICC_CTLR, Interrupt Controller Control Register
> 12.5.16 ICC_IGRPEN1, Interrupt Controller Interrupt Group 1 Enable register
> 12.7.9 ICH_VMCR, Interrupt Controller Virtual Machine Control Register
>
As said in the previous patches: this may be my personal opinion but sth like this would be easier to read:
"
Define missing assembly aliases for GIC registers on arm32, taking the ones
defined already for arm64 as a base. Aliases are defined according to the
GIC Architecture Specification ARM IHI 0069H.
"
> Signed-off-by: Ayan Kumar Halder <ayankuma@amd.com>
> ---
>
> Changes from :-
> v1 - 1. Moved coproc regs definition to asm/cpregs.h
>
> xen/arch/arm/include/asm/cpregs.h | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/xen/arch/arm/include/asm/cpregs.h b/xen/arch/arm/include/asm/cpregs.h
> index bfabee0bc3..62b63f4cef 100644
> --- a/xen/arch/arm/include/asm/cpregs.h
> +++ b/xen/arch/arm/include/asm/cpregs.h
> @@ -415,6 +415,22 @@
> #define ICH_AP1R1_EL2 __AP1Rx_EL2(1)
> #define ICH_AP1R2_EL2 __AP1Rx_EL2(2)
> #define ICH_AP1R3_EL2 __AP1Rx_EL2(3)
> +
> +#define ICC_SGI1R_EL1 p15,0,c12
> +
> +#define ICC_SRE_EL2 p15,4,c12,c9,5
> +#define ICH_VTR_EL2 p15,4,c12,c11,1
> +#define ICH_HCR_EL2 p15,4,c12,c11,0
> +
> +#define ICC_PMR_EL1 p15,0,c4,c6,0
> +#define ICC_SRE_EL1 p15,0,c12,c12,5
> +#define ICC_DIR_EL1 p15,0,c12,c11,1
> +#define ICC_EOIR1_EL1 p15,0,c12,c12,1
> +#define ICC_IAR1_EL1 p15,0,c12,c12,0
> +#define ICC_BPR1_EL1 p15,0,c12,c12,3
> +#define ICC_CTLR_EL1 p15,0,c12,c12,4
> +#define ICC_IGRPEN1_EL1 p15,0,c12,c12,7
> +#define ICH_VMCR_EL2 p15,4,c12,c11,7
I did not check this in previous patches but in which order are you defining these registers?
I took a look at arm64/sysregs.h and these regs are placed in assembly aliases name order.
So for instance ICC_PMR_EL1 would be defined before ICC_SRE_EL2, etc.
Also, I cannot see some regs like MISR, EISR that are defined for arm64. Did you decide not to define them
for arm32 because they are not used by Xen?
~Michal
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [XEN v2 09/12] xen/Arm: GICv3: Define GIC registers for AArch32
2022-11-03 15:08 ` Michal Orzel
@ 2022-11-03 20:14 ` Ayan Kumar Halder
2022-11-04 9:27 ` Michal Orzel
2022-11-06 18:26 ` Julien Grall
1 sibling, 1 reply; 59+ messages in thread
From: Ayan Kumar Halder @ 2022-11-03 20:14 UTC (permalink / raw)
To: Michal Orzel, xen-devel
Cc: sstabellini, stefanos, julien, Volodymyr_Babchuk,
bertrand.marquis, burzalodowa
On 03/11/2022 15:08, Michal Orzel wrote:
> Hi Ayan,
Hi Michal,
>
> On 31/10/2022 16:13, Ayan Kumar Halder wrote:
> The title is a bit ambiguous given that the previous patches were also defining GIC registers.
> Maybe adding "remaining" would result in a better commit title.
>
>> Refer "Arm IHI 0069H ID020922"
>> 12.5.23 ICC_SGI1R, Interrupt Controller Software Generated Interrupt
>> Group 1 Register
>> 12.5.12 ICC_HSRE, Interrupt Controller Hyp System Register Enable register
>> 12.7.10 ICH_VTR, Interrupt Controller VGIC Type Register
>> 12.7.5 ICH_HCR, Interrupt Controller Hyp Control Register
>> 12.5.20 ICC_PMR, Interrupt Controller Interrupt Priority Mask Register
>> 12.5.24 ICC_SRE, Interrupt Controller System Register Enable register
>> 12.5.7 ICC_DIR, Interrupt Controller Deactivate Interrupt Register
>> 12.5.9 ICC_EOIR1, Interrupt Controller End Of Interrupt Register 1
>> 12.5.14 ICC_IAR1, Interrupt Controller Interrupt Acknowledge Register 1
>> 12.5.5 ICC_BPR1, Interrupt Controller Binary Point Register 1
>> 12.5.6 ICC_CTLR, Interrupt Controller Control Register
>> 12.5.16 ICC_IGRPEN1, Interrupt Controller Interrupt Group 1 Enable register
>> 12.7.9 ICH_VMCR, Interrupt Controller Virtual Machine Control Register
>>
> As said in the previous patches: this may be my personal opinion but sth like this would be easier to read:
> "
> Define missing assembly aliases for GIC registers on arm32, taking the ones
> defined already for arm64 as a base. Aliases are defined according to the
> GIC Architecture Specification ARM IHI 0069H.
> "
>> Signed-off-by: Ayan Kumar Halder <ayankuma@amd.com>
>> ---
>>
>> Changes from :-
>> v1 - 1. Moved coproc regs definition to asm/cpregs.h
>>
>> xen/arch/arm/include/asm/cpregs.h | 16 ++++++++++++++++
>> 1 file changed, 16 insertions(+)
>>
>> diff --git a/xen/arch/arm/include/asm/cpregs.h b/xen/arch/arm/include/asm/cpregs.h
>> index bfabee0bc3..62b63f4cef 100644
>> --- a/xen/arch/arm/include/asm/cpregs.h
>> +++ b/xen/arch/arm/include/asm/cpregs.h
>> @@ -415,6 +415,22 @@
>> #define ICH_AP1R1_EL2 __AP1Rx_EL2(1)
>> #define ICH_AP1R2_EL2 __AP1Rx_EL2(2)
>> #define ICH_AP1R3_EL2 __AP1Rx_EL2(3)
>> +
>> +#define ICC_SGI1R_EL1 p15,0,c12
>> +
>> +#define ICC_SRE_EL2 p15,4,c12,c9,5
>> +#define ICH_VTR_EL2 p15,4,c12,c11,1
>> +#define ICH_HCR_EL2 p15,4,c12,c11,0
>> +
>> +#define ICC_PMR_EL1 p15,0,c4,c6,0
>> +#define ICC_SRE_EL1 p15,0,c12,c12,5
>> +#define ICC_DIR_EL1 p15,0,c12,c11,1
>> +#define ICC_EOIR1_EL1 p15,0,c12,c12,1
>> +#define ICC_IAR1_EL1 p15,0,c12,c12,0
>> +#define ICC_BPR1_EL1 p15,0,c12,c12,3
>> +#define ICC_CTLR_EL1 p15,0,c12,c12,4
>> +#define ICC_IGRPEN1_EL1 p15,0,c12,c12,7
>> +#define ICH_VMCR_EL2 p15,4,c12,c11,7
> I did not check this in previous patches but in which order are you defining these registers?
My bad, I did not follow any particular order.
> I took a look at arm64/sysregs.h and these regs are placed in assembly aliases name order.
> So for instance ICC_PMR_EL1 would be defined before ICC_SRE_EL2, etc.
This makes sense. I will fix this in v3.
>
> Also, I cannot see some regs like MISR, EISR that are defined for arm64. Did you decide not to define them
> for arm32 because they are not used by Xen?
Actually these registers are not being used by arm64 as well. A grep for
"ICH_MISR" or "ICH_EISR" did not return any usage of these registers
ayankuma@xcbayankuma41x:/scratch/ayankuma/upstream_xen/xen$ grep -ri
ICH_MISR *
xen/arch/arm/include/asm/gic.h:#define GICH_MISR (0x10)
xen/arch/arm/include/asm/gic.h:#define GICH_MISR_EOI (1 << 0)
xen/arch/arm/include/asm/gic.h:#define GICH_MISR_U (1 << 1)
xen/arch/arm/include/asm/gic.h:#define GICH_MISR_LRENP (1 << 2)
xen/arch/arm/include/asm/gic.h:#define GICH_MISR_NP (1 << 3)
xen/arch/arm/include/asm/gic.h:#define GICH_MISR_VGRP0E (1 << 4)
xen/arch/arm/include/asm/gic.h:#define GICH_MISR_VGRP0D (1 << 5)
xen/arch/arm/include/asm/gic.h:#define GICH_MISR_VGRP1E (1 << 6)
xen/arch/arm/include/asm/gic.h:#define GICH_MISR_VGRP1D (1 << 7)
xen/arch/arm/include/asm/arm64/sysregs.h:#define
ICH_MISR_EL2 S3_4_C12_C11_2
ayankuma@xcbayankuma41x:/scratch/ayankuma/upstream_xen/xen$ grep -ri
ICH_EISR *
xen/arch/arm/include/asm/gic.h:#define GICH_EISR0 (0x20)
xen/arch/arm/include/asm/gic.h:#define GICH_EISR1 (0x24)
xen/arch/arm/include/asm/arm64/sysregs.h:#define
ICH_EISR_EL2 S3_4_C12_C11_3
As I see, they seem deadcode for me.
Do you suggest that we should remove them ? If so, I can send a patch
for this.
- Ayan
>
> ~Michal
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [XEN v2 09/12] xen/Arm: GICv3: Define GIC registers for AArch32
2022-11-03 20:14 ` Ayan Kumar Halder
@ 2022-11-04 9:27 ` Michal Orzel
2022-11-04 10:04 ` Ayan Kumar Halder
0 siblings, 1 reply; 59+ messages in thread
From: Michal Orzel @ 2022-11-04 9:27 UTC (permalink / raw)
To: Ayan Kumar Halder, xen-devel
Cc: sstabellini, stefanos, julien, Volodymyr_Babchuk,
bertrand.marquis, burzalodowa
Hi Ayan,
On 03/11/2022 21:14, Ayan Kumar Halder wrote:
>
> On 03/11/2022 15:08, Michal Orzel wrote:
>> Hi Ayan,
> Hi Michal,
>>
>> On 31/10/2022 16:13, Ayan Kumar Halder wrote:
>> The title is a bit ambiguous given that the previous patches were also defining GIC registers.
>> Maybe adding "remaining" would result in a better commit title.
>>
>>> Refer "Arm IHI 0069H ID020922"
>>> 12.5.23 ICC_SGI1R, Interrupt Controller Software Generated Interrupt
>>> Group 1 Register
>>> 12.5.12 ICC_HSRE, Interrupt Controller Hyp System Register Enable register
>>> 12.7.10 ICH_VTR, Interrupt Controller VGIC Type Register
>>> 12.7.5 ICH_HCR, Interrupt Controller Hyp Control Register
>>> 12.5.20 ICC_PMR, Interrupt Controller Interrupt Priority Mask Register
>>> 12.5.24 ICC_SRE, Interrupt Controller System Register Enable register
>>> 12.5.7 ICC_DIR, Interrupt Controller Deactivate Interrupt Register
>>> 12.5.9 ICC_EOIR1, Interrupt Controller End Of Interrupt Register 1
>>> 12.5.14 ICC_IAR1, Interrupt Controller Interrupt Acknowledge Register 1
>>> 12.5.5 ICC_BPR1, Interrupt Controller Binary Point Register 1
>>> 12.5.6 ICC_CTLR, Interrupt Controller Control Register
>>> 12.5.16 ICC_IGRPEN1, Interrupt Controller Interrupt Group 1 Enable register
>>> 12.7.9 ICH_VMCR, Interrupt Controller Virtual Machine Control Register
>>>
>> As said in the previous patches: this may be my personal opinion but sth like this would be easier to read:
>> "
>> Define missing assembly aliases for GIC registers on arm32, taking the ones
>> defined already for arm64 as a base. Aliases are defined according to the
>> GIC Architecture Specification ARM IHI 0069H.
>> "
>>> Signed-off-by: Ayan Kumar Halder <ayankuma@amd.com>
>>> ---
>>>
>>> Changes from :-
>>> v1 - 1. Moved coproc regs definition to asm/cpregs.h
>>>
>>> xen/arch/arm/include/asm/cpregs.h | 16 ++++++++++++++++
>>> 1 file changed, 16 insertions(+)
>>>
>>> diff --git a/xen/arch/arm/include/asm/cpregs.h b/xen/arch/arm/include/asm/cpregs.h
>>> index bfabee0bc3..62b63f4cef 100644
>>> --- a/xen/arch/arm/include/asm/cpregs.h
>>> +++ b/xen/arch/arm/include/asm/cpregs.h
>>> @@ -415,6 +415,22 @@
>>> #define ICH_AP1R1_EL2 __AP1Rx_EL2(1)
>>> #define ICH_AP1R2_EL2 __AP1Rx_EL2(2)
>>> #define ICH_AP1R3_EL2 __AP1Rx_EL2(3)
>>> +
>>> +#define ICC_SGI1R_EL1 p15,0,c12
>>> +
>>> +#define ICC_SRE_EL2 p15,4,c12,c9,5
>>> +#define ICH_VTR_EL2 p15,4,c12,c11,1
>>> +#define ICH_HCR_EL2 p15,4,c12,c11,0
>>> +
>>> +#define ICC_PMR_EL1 p15,0,c4,c6,0
>>> +#define ICC_SRE_EL1 p15,0,c12,c12,5
>>> +#define ICC_DIR_EL1 p15,0,c12,c11,1
>>> +#define ICC_EOIR1_EL1 p15,0,c12,c12,1
>>> +#define ICC_IAR1_EL1 p15,0,c12,c12,0
>>> +#define ICC_BPR1_EL1 p15,0,c12,c12,3
>>> +#define ICC_CTLR_EL1 p15,0,c12,c12,4
>>> +#define ICC_IGRPEN1_EL1 p15,0,c12,c12,7
>>> +#define ICH_VMCR_EL2 p15,4,c12,c11,7
>> I did not check this in previous patches but in which order are you defining these registers?
> My bad, I did not follow any particular order.
>> I took a look at arm64/sysregs.h and these regs are placed in assembly aliases name order.
>> So for instance ICC_PMR_EL1 would be defined before ICC_SRE_EL2, etc.
> This makes sense. I will fix this in v3.
>>
>> Also, I cannot see some regs like MISR, EISR that are defined for arm64. Did you decide not to define them
>> for arm32 because they are not used by Xen?
>
> Actually these registers are not being used by arm64 as well. A grep for
> "ICH_MISR" or "ICH_EISR" did not return any usage of these registers
>
> ayankuma@xcbayankuma41x:/scratch/ayankuma/upstream_xen/xen$ grep -ri
> ICH_MISR *
> xen/arch/arm/include/asm/gic.h:#define GICH_MISR (0x10)
> xen/arch/arm/include/asm/gic.h:#define GICH_MISR_EOI (1 << 0)
> xen/arch/arm/include/asm/gic.h:#define GICH_MISR_U (1 << 1)
> xen/arch/arm/include/asm/gic.h:#define GICH_MISR_LRENP (1 << 2)
> xen/arch/arm/include/asm/gic.h:#define GICH_MISR_NP (1 << 3)
> xen/arch/arm/include/asm/gic.h:#define GICH_MISR_VGRP0E (1 << 4)
> xen/arch/arm/include/asm/gic.h:#define GICH_MISR_VGRP0D (1 << 5)
> xen/arch/arm/include/asm/gic.h:#define GICH_MISR_VGRP1E (1 << 6)
> xen/arch/arm/include/asm/gic.h:#define GICH_MISR_VGRP1D (1 << 7)
> xen/arch/arm/include/asm/arm64/sysregs.h:#define
> ICH_MISR_EL2 S3_4_C12_C11_2
>
> ayankuma@xcbayankuma41x:/scratch/ayankuma/upstream_xen/xen$ grep -ri
> ICH_EISR *
> xen/arch/arm/include/asm/gic.h:#define GICH_EISR0 (0x20)
> xen/arch/arm/include/asm/gic.h:#define GICH_EISR1 (0x24)
> xen/arch/arm/include/asm/arm64/sysregs.h:#define
> ICH_EISR_EL2 S3_4_C12_C11_3
>
> As I see, they seem deadcode for me.
Macros are preprocessor constructs whose content is replaced whenever the name is used.
I would not call this a deadcode as this is not something that can be executed.
If a macro is not used, its content will not appear in the actual code.
>
> Do you suggest that we should remove them ? If so, I can send a patch
> for this.
This is a question to maintainers.
Bare in mind that we really have a lot of unused macros in Xen codebase.
IMO, if we decide to remove them, this should be done in a single series,
so no need to add another additional patch in your series, especially if you
are not modifying this code directly.
>
> - Ayan
>
>>
>> ~Michal
~Michal
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [XEN v2 12/12] xen/Arm: GICv3: Enable GICv3 for AArch32
2022-10-31 15:13 ` [XEN v2 12/12] xen/Arm: GICv3: Enable GICv3 for AArch32 Ayan Kumar Halder
@ 2022-11-04 9:55 ` Michal Orzel
2022-11-04 11:09 ` Ayan Kumar Halder
2022-11-06 18:39 ` Julien Grall
1 sibling, 1 reply; 59+ messages in thread
From: Michal Orzel @ 2022-11-04 9:55 UTC (permalink / raw)
To: Ayan Kumar Halder, xen-devel
Cc: sstabellini, stefanos, julien, Volodymyr_Babchuk,
bertrand.marquis, burzalodowa
Hi Ayan,
On 31/10/2022 16:13, Ayan Kumar Halder wrote:
>
>
> Refer ARM DDI 0487G.b ID072021,
> D13.2.86 -
> ID_PFR1_EL1, AArch32 Processor Feature Register 1
>
> GIC, bits[31:28] == 0b0001 for GIC3.0 on Aarch32
>
> One can now enable GICv3 on AArch32 systems. However, ITS is not supported.
> The reason being currently we are trying to validate GICv3 on an AArch32_v8R
> system. Refer ARM DDI 0568A.c ID110520, B1.3.1,
> "A Generic Interrupt Controller (GIC) implemented with an Armv8-R PE must not
> implement LPI support."
>
> Updated SUPPORT.md.
>
> Signed-off-by: Ayan Kumar Halder <ayankuma@amd.com>
> ---
>
> Changed from :-
> v1 - 1. Remove "ARM_64 || ARM_32" as it is always true.
> 2. Updated SUPPORT.md.
>
> SUPPORT.md | 6 ++++++
> xen/arch/arm/Kconfig | 4 ++--
> xen/arch/arm/include/asm/cpufeature.h | 1 +
> 3 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/SUPPORT.md b/SUPPORT.md
> index cf2ddfacaf..0137855c66 100644
> --- a/SUPPORT.md
> +++ b/SUPPORT.md
> @@ -82,6 +82,12 @@ Extension to the GICv3 interrupt controller to support MSI.
>
> Status: Experimental
>
> +### ARM/GICv3 + AArch32 ARM v8
> +
> +GICv3 is supported on AArch32 ARMv8 (besides AArch64)
Looking at the CONFIG_GICV3, it can be enabled on arm32, which at the moment
supports only ARMv7 (see __lookup_processor_type -> proc-v7.S).
What will prevent the user from enabling GICv3 for ARMv7 based CPU?
> +
> + Status: Supported, not security supported
> +
> ## Guest Type
>
> ### x86/PV
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index 1fe5faf847..7c3c6eb3bd 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -41,7 +41,7 @@ config ARM_EFI
>
> config GICV3
> bool "GICv3 driver"
> - depends on ARM_64 && !NEW_VGIC
> + depends on !NEW_VGIC
> default y
> ---help---
>
> @@ -50,7 +50,7 @@ config GICV3
>
> config HAS_ITS
> bool "GICv3 ITS MSI controller support (UNSUPPORTED)" if UNSUPPORTED
> - depends on GICV3 && !NEW_VGIC
> + depends on GICV3 && !NEW_VGIC && !ARM_32
>
> config HVM
> def_bool y
> diff --git a/xen/arch/arm/include/asm/cpufeature.h b/xen/arch/arm/include/asm/cpufeature.h
> index c86a2e7f29..c62cf6293f 100644
> --- a/xen/arch/arm/include/asm/cpufeature.h
> +++ b/xen/arch/arm/include/asm/cpufeature.h
> @@ -33,6 +33,7 @@
> #define cpu_has_aarch32 (cpu_has_arm || cpu_has_thumb)
>
> #ifdef CONFIG_ARM_32
> +#define cpu_has_gicv3 (boot_cpu_feature32(gic) >= 1)
What is the purpose of defining this macro if it is not used?
> #define cpu_has_gentimer (boot_cpu_feature32(gentimer) == 1)
> /*
> * On Armv7, the value 0 is used to indicate that PMUv2 is not
> --
> 2.17.1
>
>
~Michal
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [XEN v2 09/12] xen/Arm: GICv3: Define GIC registers for AArch32
2022-11-04 9:27 ` Michal Orzel
@ 2022-11-04 10:04 ` Ayan Kumar Halder
2022-11-06 18:31 ` Julien Grall
0 siblings, 1 reply; 59+ messages in thread
From: Ayan Kumar Halder @ 2022-11-04 10:04 UTC (permalink / raw)
To: Michal Orzel, xen-devel
Cc: sstabellini, stefanos, julien, Volodymyr_Babchuk,
bertrand.marquis, burzalodowa
On 04/11/2022 09:27, Michal Orzel wrote:
> Hi Ayan,
Hi Michal,
>
> On 03/11/2022 21:14, Ayan Kumar Halder wrote:
>> On 03/11/2022 15:08, Michal Orzel wrote:
>>> Hi Ayan,
>> Hi Michal,
>>> On 31/10/2022 16:13, Ayan Kumar Halder wrote:
>>> The title is a bit ambiguous given that the previous patches were also defining GIC registers.
>>> Maybe adding "remaining" would result in a better commit title.
>>>
>>>> Refer "Arm IHI 0069H ID020922"
>>>> 12.5.23 ICC_SGI1R, Interrupt Controller Software Generated Interrupt
>>>> Group 1 Register
>>>> 12.5.12 ICC_HSRE, Interrupt Controller Hyp System Register Enable register
>>>> 12.7.10 ICH_VTR, Interrupt Controller VGIC Type Register
>>>> 12.7.5 ICH_HCR, Interrupt Controller Hyp Control Register
>>>> 12.5.20 ICC_PMR, Interrupt Controller Interrupt Priority Mask Register
>>>> 12.5.24 ICC_SRE, Interrupt Controller System Register Enable register
>>>> 12.5.7 ICC_DIR, Interrupt Controller Deactivate Interrupt Register
>>>> 12.5.9 ICC_EOIR1, Interrupt Controller End Of Interrupt Register 1
>>>> 12.5.14 ICC_IAR1, Interrupt Controller Interrupt Acknowledge Register 1
>>>> 12.5.5 ICC_BPR1, Interrupt Controller Binary Point Register 1
>>>> 12.5.6 ICC_CTLR, Interrupt Controller Control Register
>>>> 12.5.16 ICC_IGRPEN1, Interrupt Controller Interrupt Group 1 Enable register
>>>> 12.7.9 ICH_VMCR, Interrupt Controller Virtual Machine Control Register
>>>>
>>> As said in the previous patches: this may be my personal opinion but sth like this would be easier to read:
>>> "
>>> Define missing assembly aliases for GIC registers on arm32, taking the ones
>>> defined already for arm64 as a base. Aliases are defined according to the
>>> GIC Architecture Specification ARM IHI 0069H.
>>> "
>>>> Signed-off-by: Ayan Kumar Halder <ayankuma@amd.com>
>>>> ---
>>>>
>>>> Changes from :-
>>>> v1 - 1. Moved coproc regs definition to asm/cpregs.h
>>>>
>>>> xen/arch/arm/include/asm/cpregs.h | 16 ++++++++++++++++
>>>> 1 file changed, 16 insertions(+)
>>>>
>>>> diff --git a/xen/arch/arm/include/asm/cpregs.h b/xen/arch/arm/include/asm/cpregs.h
>>>> index bfabee0bc3..62b63f4cef 100644
>>>> --- a/xen/arch/arm/include/asm/cpregs.h
>>>> +++ b/xen/arch/arm/include/asm/cpregs.h
>>>> @@ -415,6 +415,22 @@
>>>> #define ICH_AP1R1_EL2 __AP1Rx_EL2(1)
>>>> #define ICH_AP1R2_EL2 __AP1Rx_EL2(2)
>>>> #define ICH_AP1R3_EL2 __AP1Rx_EL2(3)
>>>> +
>>>> +#define ICC_SGI1R_EL1 p15,0,c12
>>>> +
>>>> +#define ICC_SRE_EL2 p15,4,c12,c9,5
>>>> +#define ICH_VTR_EL2 p15,4,c12,c11,1
>>>> +#define ICH_HCR_EL2 p15,4,c12,c11,0
>>>> +
>>>> +#define ICC_PMR_EL1 p15,0,c4,c6,0
>>>> +#define ICC_SRE_EL1 p15,0,c12,c12,5
>>>> +#define ICC_DIR_EL1 p15,0,c12,c11,1
>>>> +#define ICC_EOIR1_EL1 p15,0,c12,c12,1
>>>> +#define ICC_IAR1_EL1 p15,0,c12,c12,0
>>>> +#define ICC_BPR1_EL1 p15,0,c12,c12,3
>>>> +#define ICC_CTLR_EL1 p15,0,c12,c12,4
>>>> +#define ICC_IGRPEN1_EL1 p15,0,c12,c12,7
>>>> +#define ICH_VMCR_EL2 p15,4,c12,c11,7
>>> I did not check this in previous patches but in which order are you defining these registers?
>> My bad, I did not follow any particular order.
>>> I took a look at arm64/sysregs.h and these regs are placed in assembly aliases name order.
>>> So for instance ICC_PMR_EL1 would be defined before ICC_SRE_EL2, etc.
>> This makes sense. I will fix this in v3.
>>> Also, I cannot see some regs like MISR, EISR that are defined for arm64. Did you decide not to define them
>>> for arm32 because they are not used by Xen?
>> Actually these registers are not being used by arm64 as well. A grep for
>> "ICH_MISR" or "ICH_EISR" did not return any usage of these registers
>>
>> ayankuma@xcbayankuma41x:/scratch/ayankuma/upstream_xen/xen$ grep -ri
>> ICH_MISR *
>> xen/arch/arm/include/asm/gic.h:#define GICH_MISR (0x10)
>> xen/arch/arm/include/asm/gic.h:#define GICH_MISR_EOI (1 << 0)
>> xen/arch/arm/include/asm/gic.h:#define GICH_MISR_U (1 << 1)
>> xen/arch/arm/include/asm/gic.h:#define GICH_MISR_LRENP (1 << 2)
>> xen/arch/arm/include/asm/gic.h:#define GICH_MISR_NP (1 << 3)
>> xen/arch/arm/include/asm/gic.h:#define GICH_MISR_VGRP0E (1 << 4)
>> xen/arch/arm/include/asm/gic.h:#define GICH_MISR_VGRP0D (1 << 5)
>> xen/arch/arm/include/asm/gic.h:#define GICH_MISR_VGRP1E (1 << 6)
>> xen/arch/arm/include/asm/gic.h:#define GICH_MISR_VGRP1D (1 << 7)
>> xen/arch/arm/include/asm/arm64/sysregs.h:#define
>> ICH_MISR_EL2 S3_4_C12_C11_2
>>
>> ayankuma@xcbayankuma41x:/scratch/ayankuma/upstream_xen/xen$ grep -ri
>> ICH_EISR *
>> xen/arch/arm/include/asm/gic.h:#define GICH_EISR0 (0x20)
>> xen/arch/arm/include/asm/gic.h:#define GICH_EISR1 (0x24)
>> xen/arch/arm/include/asm/arm64/sysregs.h:#define
>> ICH_EISR_EL2 S3_4_C12_C11_3
>>
>> As I see, they seem deadcode for me.
> Macros are preprocessor constructs whose content is replaced whenever the name is used.
> I would not call this a deadcode as this is not something that can be executed.
> If a macro is not used, its content will not appear in the actual code.
This makes sense.
>
>> Do you suggest that we should remove them ? If so, I can send a patch
>> for this.
> This is a question to maintainers.
> Bare in mind that we really have a lot of unused macros in Xen codebase.
> IMO, if we decide to remove them, this should be done in a single series,
> so no need to add another additional patch in your series, especially if you
> are not modifying this code directly.
Yes, I will keep these macros intact (as it exists).
WRT your question "Also, I cannot see some regs like MISR, EISR that are
defined for arm64. Did you decide not to define them
for arm32 because they are not used by Xen?"
These registers are not used by Xen.
Should I define these registers for the sake of completeness (to be in parity with AArch64) ?
- Ayan
>
>> - Ayan
>>
>>> ~Michal
> ~Michal
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [XEN v2 12/12] xen/Arm: GICv3: Enable GICv3 for AArch32
2022-11-04 9:55 ` Michal Orzel
@ 2022-11-04 11:09 ` Ayan Kumar Halder
2022-11-04 11:30 ` Julien Grall
0 siblings, 1 reply; 59+ messages in thread
From: Ayan Kumar Halder @ 2022-11-04 11:09 UTC (permalink / raw)
To: Michal Orzel, xen-devel
Cc: sstabellini, stefanos, julien, Volodymyr_Babchuk,
bertrand.marquis, burzalodowa
On 04/11/2022 09:55, Michal Orzel wrote:
> Hi Ayan,
Hi Michal,
>
> On 31/10/2022 16:13, Ayan Kumar Halder wrote:
>>
>> Refer ARM DDI 0487G.b ID072021,
>> D13.2.86 -
>> ID_PFR1_EL1, AArch32 Processor Feature Register 1
>>
>> GIC, bits[31:28] == 0b0001 for GIC3.0 on Aarch32
>>
>> One can now enable GICv3 on AArch32 systems. However, ITS is not supported.
>> The reason being currently we are trying to validate GICv3 on an AArch32_v8R
>> system. Refer ARM DDI 0568A.c ID110520, B1.3.1,
>> "A Generic Interrupt Controller (GIC) implemented with an Armv8-R PE must not
>> implement LPI support."
>>
>> Updated SUPPORT.md.
>>
>> Signed-off-by: Ayan Kumar Halder <ayankuma@amd.com>
>> ---
>>
>> Changed from :-
>> v1 - 1. Remove "ARM_64 || ARM_32" as it is always true.
>> 2. Updated SUPPORT.md.
>>
>> SUPPORT.md | 6 ++++++
>> xen/arch/arm/Kconfig | 4 ++--
>> xen/arch/arm/include/asm/cpufeature.h | 1 +
>> 3 files changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/SUPPORT.md b/SUPPORT.md
>> index cf2ddfacaf..0137855c66 100644
>> --- a/SUPPORT.md
>> +++ b/SUPPORT.md
>> @@ -82,6 +82,12 @@ Extension to the GICv3 interrupt controller to support MSI.
>>
>> Status: Experimental
>>
>> +### ARM/GICv3 + AArch32 ARM v8
>> +
>> +GICv3 is supported on AArch32 ARMv8 (besides AArch64)
> Looking at the CONFIG_GICV3, it can be enabled on arm32, which at the moment
> supports only ARMv7 (see __lookup_processor_type -> proc-v7.S).
> What will prevent the user from enabling GICv3 for ARMv7 based CPU?
Yes, this is my mistake.
ARMv7 does not support GICv3.
I should have introduced a new macro AArch32_v8R so that GICV3 is
defined for it.
config GICV3
bool "GICv3 driver"
- depends on ARM_64 && !NEW_VGIC
+ depends on ARM_64 || AArch32_v8R !NEW_VGIC
default y
---help---
>
>> +
>> + Status: Supported, not security supported
>> +
>> ## Guest Type
>>
>> ### x86/PV
>> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
>> index 1fe5faf847..7c3c6eb3bd 100644
>> --- a/xen/arch/arm/Kconfig
>> +++ b/xen/arch/arm/Kconfig
>> @@ -41,7 +41,7 @@ config ARM_EFI
>>
>> config GICV3
>> bool "GICv3 driver"
>> - depends on ARM_64 && !NEW_VGIC
>> + depends on !NEW_VGIC
>> default y
>> ---help---
>>
>> @@ -50,7 +50,7 @@ config GICV3
>>
>> config HAS_ITS
>> bool "GICv3 ITS MSI controller support (UNSUPPORTED)" if UNSUPPORTED
>> - depends on GICV3 && !NEW_VGIC
>> + depends on GICV3 && !NEW_VGIC && !ARM_32
>>
>> config HVM
>> def_bool y
>> diff --git a/xen/arch/arm/include/asm/cpufeature.h b/xen/arch/arm/include/asm/cpufeature.h
>> index c86a2e7f29..c62cf6293f 100644
>> --- a/xen/arch/arm/include/asm/cpufeature.h
>> +++ b/xen/arch/arm/include/asm/cpufeature.h
>> @@ -33,6 +33,7 @@
>> #define cpu_has_aarch32 (cpu_has_arm || cpu_has_thumb)
>>
>> #ifdef CONFIG_ARM_32
>> +#define cpu_has_gicv3 (boot_cpu_feature32(gic) >= 1)
> What is the purpose of defining this macro if it is not used?
It is used in xen/arch/arm/gic-v3.c, gicv3_init().
- Ayan
>
>> #define cpu_has_gentimer (boot_cpu_feature32(gentimer) == 1)
>> /*
>> * On Armv7, the value 0 is used to indicate that PMUv2 is not
>> --
>> 2.17.1
>>
>>
> ~Michal
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [XEN v2 12/12] xen/Arm: GICv3: Enable GICv3 for AArch32
2022-11-04 11:09 ` Ayan Kumar Halder
@ 2022-11-04 11:30 ` Julien Grall
2022-11-04 11:52 ` Michal Orzel
0 siblings, 1 reply; 59+ messages in thread
From: Julien Grall @ 2022-11-04 11:30 UTC (permalink / raw)
To: Ayan Kumar Halder
Cc: Bertrand.Marquis, Michal Orzel, Volodymyr_Babchuk, burzalodowa,
sstabellini, stefanos, xen-devel
[-- Attachment #1: Type: text/plain, Size: 4002 bytes --]
On Fri, 4 Nov 2022 at 12:09, Ayan Kumar Halder <ayankuma@amd.com> wrote:
>
> On 04/11/2022 09:55, Michal Orzel wrote:
> > Hi Ayan,
> Hi Michal,
> >
> > On 31/10/2022 16:13, Ayan Kumar Halder wrote:
> >>
> >> Refer ARM DDI 0487G.b ID072021,
> >> D13.2.86 -
> >> ID_PFR1_EL1, AArch32 Processor Feature Register 1
> >>
> >> GIC, bits[31:28] == 0b0001 for GIC3.0 on Aarch32
> >>
> >> One can now enable GICv3 on AArch32 systems. However, ITS is not
> supported.
> >> The reason being currently we are trying to validate GICv3 on an
> AArch32_v8R
> >> system. Refer ARM DDI 0568A.c ID110520, B1.3.1,
> >> "A Generic Interrupt Controller (GIC) implemented with an Armv8-R PE
> must not
> >> implement LPI support."
> >>
> >> Updated SUPPORT.md.
> >>
> >> Signed-off-by: Ayan Kumar Halder <ayankuma@amd.com>
> >> ---
> >>
> >> Changed from :-
> >> v1 - 1. Remove "ARM_64 || ARM_32" as it is always true.
> >> 2. Updated SUPPORT.md.
> >>
> >> SUPPORT.md | 6 ++++++
> >> xen/arch/arm/Kconfig | 4 ++--
> >> xen/arch/arm/include/asm/cpufeature.h | 1 +
> >> 3 files changed, 9 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/SUPPORT.md b/SUPPORT.md
> >> index cf2ddfacaf..0137855c66 100644
> >> --- a/SUPPORT.md
> >> +++ b/SUPPORT.md
> >> @@ -82,6 +82,12 @@ Extension to the GICv3 interrupt controller to
> support MSI.
> >>
> >> Status: Experimental
> >>
> >> +### ARM/GICv3 + AArch32 ARM v8
> >> +
> >> +GICv3 is supported on AArch32 ARMv8 (besides AArch64)
> > Looking at the CONFIG_GICV3, it can be enabled on arm32, which at the
> moment
> > supports only ARMv7 (see __lookup_processor_type -> proc-v7.S).
> > What will prevent the user from enabling GICv3 for ARMv7 based CPU?
> Yes, this is my mistake.
>
> ARMv7 does not support GICv3.
The same could be said for Xen on Aarch32 Armv8. This is not officially
supported but works with some tweak in the lookup function.
>
> I should have introduced a new macro AArch32_v8R so that GICV3 is
> defined for it.
I would rather not have such config. There are no issue to allow someone to
build it for 32-bit because Xen is perfectly capable to detect which GIC
version is in use.
Instead we could simply disable GICv3 by default for arm32.
>
> config GICV3
> bool "GICv3 driver"
> - depends on ARM_64 && !NEW_VGIC
> + depends on ARM_64 || AArch32_v8R !NEW_VGIC
> default y
> ---help---
>
> >
> >> +
> >> + Status: Supported, not security supported
> >> +
> >> ## Guest Type
> >>
> >> ### x86/PV
> >> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> >> index 1fe5faf847..7c3c6eb3bd 100644
> >> --- a/xen/arch/arm/Kconfig
> >> +++ b/xen/arch/arm/Kconfig
> >> @@ -41,7 +41,7 @@ config ARM_EFI
> >>
> >> config GICV3
> >> bool "GICv3 driver"
> >> - depends on ARM_64 && !NEW_VGIC
> >> + depends on !NEW_VGIC
> >> default y
> >> ---help---
> >>
> >> @@ -50,7 +50,7 @@ config GICV3
> >>
> >> config HAS_ITS
> >> bool "GICv3 ITS MSI controller support (UNSUPPORTED)" if
> UNSUPPORTED
> >> - depends on GICV3 && !NEW_VGIC
> >> + depends on GICV3 && !NEW_VGIC && !ARM_32
> >>
> >> config HVM
> >> def_bool y
> >> diff --git a/xen/arch/arm/include/asm/cpufeature.h
> b/xen/arch/arm/include/asm/cpufeature.h
> >> index c86a2e7f29..c62cf6293f 100644
> >> --- a/xen/arch/arm/include/asm/cpufeature.h
> >> +++ b/xen/arch/arm/include/asm/cpufeature.h
> >> @@ -33,6 +33,7 @@
> >> #define cpu_has_aarch32 (cpu_has_arm || cpu_has_thumb)
> >>
> >> #ifdef CONFIG_ARM_32
> >> +#define cpu_has_gicv3 (boot_cpu_feature32(gic) >= 1)
> > What is the purpose of defining this macro if it is not used?
>
> It is used in xen/arch/arm/gic-v3.c, gicv3_init().
>
> - Ayan
>
> >
> >> #define cpu_has_gentimer (boot_cpu_feature32(gentimer) == 1)
> >> /*
> >> * On Armv7, the value 0 is used to indicate that PMUv2 is not
> >> --
> >> 2.17.1
> >>
> >>
> > ~Michal
>
[-- Attachment #2: Type: text/html, Size: 6425 bytes --]
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [XEN v2 12/12] xen/Arm: GICv3: Enable GICv3 for AArch32
2022-11-04 11:30 ` Julien Grall
@ 2022-11-04 11:52 ` Michal Orzel
0 siblings, 0 replies; 59+ messages in thread
From: Michal Orzel @ 2022-11-04 11:52 UTC (permalink / raw)
To: Julien Grall, Ayan Kumar Halder
Cc: Bertrand.Marquis, Volodymyr_Babchuk, burzalodowa, sstabellini,
stefanos, xen-devel
On 04/11/2022 12:30, Julien Grall wrote:
>
>
>
>
>
> On Fri, 4 Nov 2022 at 12:09, Ayan Kumar Halder <ayankuma@amd.com <mailto:ayankuma@amd.com>> wrote:
>
>
> On 04/11/2022 09:55, Michal Orzel wrote:
> > Hi Ayan,
> Hi Michal,
> >
> > On 31/10/2022 16:13, Ayan Kumar Halder wrote:
> >>
> >> Refer ARM DDI 0487G.b ID072021,
> >> D13.2.86 -
> >> ID_PFR1_EL1, AArch32 Processor Feature Register 1
> >>
> >> GIC, bits[31:28] == 0b0001 for GIC3.0 on Aarch32
> >>
> >> One can now enable GICv3 on AArch32 systems. However, ITS is not supported.
> >> The reason being currently we are trying to validate GICv3 on an AArch32_v8R
> >> system. Refer ARM DDI 0568A.c ID110520, B1.3.1,
> >> "A Generic Interrupt Controller (GIC) implemented with an Armv8-R PE must not
> >> implement LPI support."
> >>
> >> Updated SUPPORT.md.
> >>
> >> Signed-off-by: Ayan Kumar Halder <ayankuma@amd.com <mailto:ayankuma@amd.com>>
> >> ---
> >>
> >> Changed from :-
> >> v1 - 1. Remove "ARM_64 || ARM_32" as it is always true.
> >> 2. Updated SUPPORT.md.
> >>
> >> SUPPORT.md | 6 ++++++
> >> xen/arch/arm/Kconfig | 4 ++--
> >> xen/arch/arm/include/asm/cpufeature.h | 1 +
> >> 3 files changed, 9 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/SUPPORT.md b/SUPPORT.md
> >> index cf2ddfacaf..0137855c66 100644
> >> --- a/SUPPORT.md
> >> +++ b/SUPPORT.md
> >> @@ -82,6 +82,12 @@ Extension to the GICv3 interrupt controller to support MSI.
> >>
> >> Status: Experimental
> >>
> >> +### ARM/GICv3 + AArch32 ARM v8
> >> +
> >> +GICv3 is supported on AArch32 ARMv8 (besides AArch64)
> > Looking at the CONFIG_GICV3, it can be enabled on arm32, which at the moment
> > supports only ARMv7 (see __lookup_processor_type -> proc-v7.S).
> > What will prevent the user from enabling GICv3 for ARMv7 based CPU?
>
>
> Yes, this is my mistake.
>
> ARMv7 does not support GICv3.
>
>
> The same could be said for Xen on Aarch32 Armv8. This is not officially supported but works with some tweak in the lookup function.
>
>
>
> I should have introduced a new macro AArch32_v8R so that GICV3 is
> defined for it.
>
>
> I would rather not have such config. There are no issue to allow someone to build it for 32-bit because Xen is perfectly capable to detect which GIC version is in use.
>
> Instead we could simply disable GICv3 by default for arm32.
+1
~Michal
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [XEN v2 02/12] xen/Arm: GICv3: Move the macros to compute the affnity level to arm64/arm32
2022-11-02 10:36 ` Xenia Ragiadakou
@ 2022-11-06 17:59 ` Julien Grall
0 siblings, 0 replies; 59+ messages in thread
From: Julien Grall @ 2022-11-06 17:59 UTC (permalink / raw)
To: Xenia Ragiadakou, Ayan Kumar Halder, xen-devel
Cc: sstabellini, stefanos, Volodymyr_Babchuk, bertrand.marquis
Hi Xenia,
On 02/11/2022 10:36, Xenia Ragiadakou wrote:
> Hi Julien,
>
> On 11/2/22 12:10, Julien Grall wrote:
>> Hi Xenia,
>>
>> On 02/11/2022 09:57, Xenia Ragiadakou wrote:
>>>
>>> On 11/2/22 10:46, Julien Grall wrote:
>>>> Hi,
>>>>
>>>> Title: The macros you are moving are not GICv3 specific.
>>>>
>>>> On 31/10/2022 15:13, Ayan Kumar Halder wrote:
>>>>> Refer https://elixir.bootlin.com/linux/v6.1-rc1/source/arch/arm64/ \
>>>>> include/asm/cputype.h#L14 , for the macros specific for arm64.
>>>>>
>>>>> Refer
>>>>> https://elixir.bootlin.com/linux/v6.1-rc1/source/arch/arm/include/ \
>>>>> asm/cputype.h#L54 , for the macros specific for arm32.
>>>>>
>>>>> MPIDR_LEVEL_SHIFT() differs between 64 and 32 bit. > For 64 bit :-
>>>>>
>>>>> aff_lev3 aff_lev2 aff_lev1 aff_lev0
>>>>> |________|________|________|________|________|
>>>>> 40 32 24 16 8 0
>>>>>
>>>>> For 32 bit :-
>>>>>
>>>>> aff_lev3 aff_lev2 aff_lev1 aff_lev0
>>>>> |________|________|________|________|
>>>>> 32 24 16 8 0
>>>>
>>>> As discussed with Michal, AFF3 doesn't exist for 32-bit. So it is
>>>> not clear to me what we are gaining by moving the macros.
>>>>
>>>
>>> I cannot understand what do you mean by "what we are gaining by
>>> moving the macros".
>> >
>>> IIUC, when identifying the cpu topology, a mask is applied to the
>>> value of MPIDR_EL1
>>> #ifdef CONFIG_ARM_64
>>> #define MPIDR_HWID_MASK _AC(0xff00ffffff,UL)
>>> #else
>>> #define MPIDR_HWID_MASK _AC(0xffffff,U)
>>> #endif
>>> So, for arm32, the affinity at level 3 is considered to be 0.
>>>
>>> Do you mean, what we are gaining by defining the MPIDR_LEVEL_SHIFT in
>>> a different way for arm32 and for arm64?
>>
>> Yes. There are nothing justifying the move so far.
>>
>>>
>>> IMO, we need to do so, because the shift, used to retrieve the
>>> affinity at each level, cannot be calculated using the same logic i.e
>>> (((1 << (level)) >> 1) << MPIDR_LEVEL_BITS_SHIFT)
>>>
>>> For arm32 the affinity at each level is calculated as follows
>>> ((level) << MPIDR_LEVEL_BITS_SHIFT)
>>
>> I understand they are written differently. But if you look at the
>> layout, AFF0, AFF1, AFF2 are in the same position. AFF3 doesn't exist
>> for arm32 and, AFAICT, the shift will not matter because the bits
>> 40:32 will be zeroed in any case.
>>
>> So I don't see the problem of using the arm64 version.
>
> Now I see :) ... IIUC you are proposing to just cast the mpidr in
> MPIDR_AFFINITY_LEVEL(mpidr, level) to uint64_t?
Not necessarilly. The other approach is to make sure that no arm32 code
is calling AFFINITY_MASK() with a level >= 3 (see vpsci.c for instance).
Cheers,
--
Julien Grall
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [XEN v2 04/12] xen/Arm: vGICv3: Adapt emulation of GICR_TYPER for AArch32
2022-10-31 15:13 ` [XEN v2 04/12] xen/Arm: vGICv3: Adapt emulation of GICR_TYPER for AArch32 Ayan Kumar Halder
@ 2022-11-06 18:04 ` Julien Grall
2022-11-07 11:33 ` Ayan Kumar Halder
0 siblings, 1 reply; 59+ messages in thread
From: Julien Grall @ 2022-11-06 18:04 UTC (permalink / raw)
To: Ayan Kumar Halder, xen-devel
Cc: sstabellini, stefanos, Volodymyr_Babchuk, bertrand.marquis, burzalodowa
Hi Ayan,
In the title you are using AArch32 but below you are using...
On 31/10/2022 15:13, Ayan Kumar Halder wrote:
> v->arch.vmpidr is assigned to uint64_t variable. This is to enable left shifts
> for Aarch32 so that one can extract affinity bits.
... Aarch32. The naming also seem to be inconsistent across your series.
AFAIU, it should be AArch32. So please look at all your commits and make
sure you use the same everywhere.
> This is then assigned to 'typer' so that the affinity bits form the upper 32 bits.
>
> Refer Arm IHI 0069H ID020922,
> The upper 32 bits of GICR_TYPER represent the affinity
> whereas the lower 32 bits represent the other bits (eg processor
> number, etc).
>
> Signed-off-by: Ayan Kumar Halder <ayankuma@amd.com>
> ---
>
> Changes from :-
> 1. v1 - Assigned v->arch.vmpidr to "uint64_t vmpdir". Then, we can use
> MPIDR_AFFINITY_LEVEL macros to extract the affinity value.
>
> xen/arch/arm/vgic-v3.c | 10 ++++++----
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
> index 3f4509dcd3..e5e6f2c573 100644
> --- a/xen/arch/arm/vgic-v3.c
> +++ b/xen/arch/arm/vgic-v3.c
> @@ -191,13 +191,15 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu *v, mmio_info_t *info,
> case VREG64(GICR_TYPER):
> {
> uint64_t typer, aff;
> + uint64_t vmpidr = v->arch.vmpidr;
>
> if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
> - aff = (MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 3) << 56 |
> - MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 2) << 48 |
> - MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 1) << 40 |
> - MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 0) << 32);
> + aff = (MPIDR_AFFINITY_LEVEL(vmpidr, 3) << 56 |
Shouldn't we #ifdef this level for 32-bit? Or maybe check if the domain
is 64-bit so we are using consistently regardless of the hypervisor bitness.
> + MPIDR_AFFINITY_LEVEL(vmpidr, 2) << 48 |
> + MPIDR_AFFINITY_LEVEL(vmpidr, 1) << 40 |
> + MPIDR_AFFINITY_LEVEL(vmpidr, 0) << 32);
> typer = aff;
> +
Spurious change?
> /* We use the VCPU ID as the redistributor ID in bits[23:8] */
> typer |= v->vcpu_id << GICR_TYPER_PROC_NUM_SHIFT;
>
Cheers,
--
Julien Grall
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [XEN v2 05/12] xen/Arm: GICv3: Fix GICR_{PENDBASER, PROPBASER} emulation on 32-bit host
2022-10-31 15:13 ` [XEN v2 05/12] xen/Arm: GICv3: Fix GICR_{PENDBASER, PROPBASER} emulation on 32-bit host Ayan Kumar Halder
2022-11-02 10:26 ` Michal Orzel
@ 2022-11-06 18:05 ` Julien Grall
1 sibling, 0 replies; 59+ messages in thread
From: Julien Grall @ 2022-11-06 18:05 UTC (permalink / raw)
To: Ayan Kumar Halder, xen-devel
Cc: sstabellini, stefanos, Volodymyr_Babchuk, bertrand.marquis, burzalodowa
Hi Ayan,
On 31/10/2022 15:13, Ayan Kumar Halder wrote:
> 'unsigned long long' is defined as 64 bit across both aarch32 and aarch64.
> So, use 'ULL' for 64 bit word instead of UL which is 32 bits for aarch32.
> GICR_PENDBASER and GICR_PROPBASER both are 64 bit registers.
>
> Signed-off-by: Ayan Kumar Halder <ayankuma@amd.com>
With or without Michal's comment addressed:
Acked-by: Julien Grall <jgrall@amazon.com>
Cheers,
--
Julien Grall
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [XEN v2 06/12] xen/Arm: vGICv3: Fix emulation of ICC_SGI1R on AArch32
2022-11-02 10:41 ` Michal Orzel
@ 2022-11-06 18:06 ` Julien Grall
0 siblings, 0 replies; 59+ messages in thread
From: Julien Grall @ 2022-11-06 18:06 UTC (permalink / raw)
To: Michal Orzel, Ayan Kumar Halder, xen-devel
Cc: sstabellini, stefanos, Volodymyr_Babchuk, bertrand.marquis, burzalodowa
On 02/11/2022 10:41, Michal Orzel wrote:
> Hi Ayan,
>
> On 31/10/2022 16:13, Ayan Kumar Halder wrote:
>>
>>
>> Refer Arm IHI 0069H ID020922, 12.5.23, ICC_SGI1R is a 64 bit register on
>> Aarch32 systems. Thus, the prototype needs to change to reflect this.
> NIT: prototype means function declaration.
> vgic_v3_to_sgi is a function that has no prototype.
>
> Apart from that:
> Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Cheers,
--
Julien Grall
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [XEN v2 07/12] xen/Arm: GICv3: Define ICH_LR<n>_EL2 on AArch32
2022-11-03 12:13 ` Michal Orzel
@ 2022-11-06 18:14 ` Julien Grall
0 siblings, 0 replies; 59+ messages in thread
From: Julien Grall @ 2022-11-06 18:14 UTC (permalink / raw)
To: Michal Orzel, Ayan Kumar Halder, xen-devel
Cc: sstabellini, stefanos, Volodymyr_Babchuk, bertrand.marquis, burzalodowa
Hi,
On 03/11/2022 12:13, Michal Orzel wrote:
> Hi Ayan,
>
> On 31/10/2022 16:13, Ayan Kumar Halder wrote:
>>
>>
>> Refer "Arm IHI 0069H ID020922", 12.4.6, Interrupt Controller List Registers
>>
>> AArch64 System register ICH_LR<n>_EL2 bits [31:0] are architecturally
>> mapped to AArch32 System register ICH_LR<n>[31:0].
>> AArch64 System register ICH_LR<n>_EL2 bits [63:32] are architecturally
>> mapped to AArch32 System register ICH_LRC<n>[31:0].
>>
>> Defined ICH_LR<0...15>_EL2 and ICH_LRC<0...15>_EL2 for Aarch32.
>> For AArch32, the link register is stored as :-
>> (((uint64_t) ICH_LRC<0...15>_EL2) << 32) | ICH_LR<0...15>_EL2
>>
>> Also, ICR_LR macros need to be modified as ULL is 64 bits for AArch32 and
>> AArch64.
>>
>> Signed-off-by: Ayan Kumar Halder <ayankuma@amd.com>
>> ---
>>
>> Changes from :-
>> v1 - 1. Moved the coproc register definitions to asm/cpregs.h.
>> 2. Use GENMASK(31, 0) to represent 0xFFFFFFFF
>> 3. Use READ_CP32()/WRITE_CP32() instead of READ_SYSREG()/WRITE_SYSREG().
>> 4. Multi-line macro definitions should be enclosed within ({ }).
>>
>> xen/arch/arm/gic-v3.c | 132 +++++++++++------------
>> xen/arch/arm/include/asm/arm32/sysregs.h | 17 +++
>> xen/arch/arm/include/asm/arm64/sysregs.h | 3 +
>> xen/arch/arm/include/asm/cpregs.h | 42 ++++++++
>> xen/arch/arm/include/asm/gic_v3_defs.h | 6 +-
>> 5 files changed, 131 insertions(+), 69 deletions(-)
>>
>> diff --git a/xen/arch/arm/include/asm/arm32/sysregs.h b/xen/arch/arm/include/asm/arm32/sysregs.h
>> index 6841d5de43..8a9a014bef 100644
>> --- a/xen/arch/arm/include/asm/arm32/sysregs.h
>> +++ b/xen/arch/arm/include/asm/arm32/sysregs.h
>> @@ -62,6 +62,23 @@
>> #define READ_SYSREG(R...) READ_SYSREG32(R)
>> #define WRITE_SYSREG(V, R...) WRITE_SYSREG32(V, R)
>>
>> +#define ICH_LR_REG(INDEX) ICH_LR ## INDEX ## _EL2
>> +#define ICH_LRC_REG(INDEX) ICH_LRC ## INDEX ## _EL2
> You could align to WRITE_SYSREG32(V, R).
>
> Apart from that it would be good to add some comment before the code you added (ICH_LR_REG)
> to separate from the code above and its comment about registers coming in 3 types.
> Something like:
> /* Wrappers for accessing interrupt controller list registers. */
>
>> +
>> +#define READ_SYSREG_LR(INDEX) ({ \
> Opening ({ should be placed one space after READ_SYSREG_LR(INDEX). It does not need to be aligned.
>
>> + uint64_t _val; \
> val is not really necessary. You could directly return the ((uint64_t) _lrc << 32) | _lr;
> Just something to consider, no need to replace.
>
>> + uint32_t _lrc = READ_CP32(ICH_LRC_REG(INDEX)); \
>> + uint32_t _lr = READ_CP32(ICH_LR_REG(INDEX)); \
>> + \
>> + _val = ((uint64_t) _lrc << 32) | _lr; \
>> + _val; })
> Here, you did put }) at the same line...
>
>> +
>> +#define WRITE_SYSREG_LR(INDEX, V) ({ \
>> + uint64_t _val = (V); \
>> + WRITE_CP32(_val & GENMASK(31, 0), ICH_LR_REG(INDEX)); \
>> + WRITE_CP32(_val >> 32, ICH_LRC_REG(INDEX)); \
> Please, align \
+1
>
>> +});
> ... and here you did not.
FAOD, this is the correct approach. That said, the ';' should not be added.
>
>> +
>> /* MVFR2 is not defined on ARMv7 */
>> #define MVFR2_MAYBE_UNDEFINED
>>
>> diff --git a/xen/arch/arm/include/asm/arm64/sysregs.h b/xen/arch/arm/include/asm/arm64/sysregs.h
>> index 54670084c3..353f0eea29 100644
>> --- a/xen/arch/arm/include/asm/arm64/sysregs.h
>> +++ b/xen/arch/arm/include/asm/arm64/sysregs.h
>> @@ -471,6 +471,9 @@
>>
>> #define READ_SYSREG(name) READ_SYSREG64(name)
>> #define WRITE_SYSREG(v, name) WRITE_SYSREG64(v, name)
> Here, I would separate the below macros by adding the comment similar to the one I showed above.
> Or at least add a blank line.
>
>> +#define ICH_LR_REG(index) ICH_LR ## index ## _EL2
>> +#define WRITE_SYSREG_LR(index, v) WRITE_SYSREG(v, ICH_LR_REG(index))
>> +#define READ_SYSREG_LR(index) READ_SYSREG(ICH_LR_REG(index))
> I find it a bit odd that the macro param 'index' is written in lower case and for arm32 in upper cas
FWIW, I would prefer the lower case version. That said, the arm32 code
match with the rest of the file.
Cheers,
--
Julien Grall
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [XEN v2 07/12] xen/Arm: GICv3: Define ICH_LR<n>_EL2 on AArch32
2022-10-31 15:13 ` [XEN v2 07/12] xen/Arm: GICv3: Define ICH_LR<n>_EL2 " Ayan Kumar Halder
2022-11-03 12:13 ` Michal Orzel
@ 2022-11-06 18:19 ` Julien Grall
1 sibling, 0 replies; 59+ messages in thread
From: Julien Grall @ 2022-11-06 18:19 UTC (permalink / raw)
To: Ayan Kumar Halder, xen-devel
Cc: sstabellini, stefanos, Volodymyr_Babchuk, bertrand.marquis, burzalodowa
Hi Ayan,
On 31/10/2022 15:13, Ayan Kumar Halder wrote:
> diff --git a/xen/arch/arm/include/asm/arm32/sysregs.h b/xen/arch/arm/include/asm/arm32/sysregs.h
> index 6841d5de43..8a9a014bef 100644
> --- a/xen/arch/arm/include/asm/arm32/sysregs.h
> +++ b/xen/arch/arm/include/asm/arm32/sysregs.h
> @@ -62,6 +62,23 @@
> #define READ_SYSREG(R...) READ_SYSREG32(R)
> #define WRITE_SYSREG(V, R...) WRITE_SYSREG32(V, R)
>
> +#define ICH_LR_REG(INDEX) ICH_LR ## INDEX ## _EL2
> +#define ICH_LRC_REG(INDEX) ICH_LRC ## INDEX ## _EL2
> +
> +#define READ_SYSREG_LR(INDEX) ({ \
> + uint64_t _val; \
> + uint32_t _lrc = READ_CP32(ICH_LRC_REG(INDEX)); \
> + uint32_t _lr = READ_CP32(ICH_LR_REG(INDEX)); \
> + \
> + _val = ((uint64_t) _lrc << 32) | _lr; \
> + _val; })
> +
> +#define WRITE_SYSREG_LR(INDEX, V) ({ \
I would prefer if the prototype stays consistent with the other write
helpers. I.e. the value is first and the name second.
> + uint64_t _val = (V); \
> + WRITE_CP32(_val & GENMASK(31, 0), ICH_LR_REG(INDEX)); \
> + WRITE_CP32(_val >> 32, ICH_LRC_REG(INDEX)); \
> +});
> +
> /* MVFR2 is not defined on ARMv7 */
> #define MVFR2_MAYBE_UNDEFINED
>
> diff --git a/xen/arch/arm/include/asm/arm64/sysregs.h b/xen/arch/arm/include/asm/arm64/sysregs.h
> index 54670084c3..353f0eea29 100644
> --- a/xen/arch/arm/include/asm/arm64/sysregs.h
> +++ b/xen/arch/arm/include/asm/arm64/sysregs.h
> @@ -471,6 +471,9 @@
>
> #define READ_SYSREG(name) READ_SYSREG64(name)
> #define WRITE_SYSREG(v, name) WRITE_SYSREG64(v, name)
> +#define ICH_LR_REG(index) ICH_LR ## index ## _EL2
> +#define WRITE_SYSREG_LR(index, v) WRITE_SYSREG(v, ICH_LR_REG(index))
> +#define READ_SYSREG_LR(index) READ_SYSREG(ICH_LR_REG(index))
>
> #endif /* _ASM_ARM_ARM64_SYSREGS_H */
>
> diff --git a/xen/arch/arm/include/asm/cpregs.h b/xen/arch/arm/include/asm/cpregs.h
> index 6daf2b1a30..4421dd49ac 100644
> --- a/xen/arch/arm/include/asm/cpregs.h
> +++ b/xen/arch/arm/include/asm/cpregs.h
> @@ -362,6 +362,48 @@
> #define MVFR0_EL1 MVFR0
> #define MVFR1_EL1 MVFR1
> #define MVFR2_EL1 MVFR2
> +
> +#define ___CP32(a,b,c,d,e) a,b,c,d,e
Unless there are a reason to do, please use space after each comma. The
same goes for the rest of the patch.
Cheers,
--
Julien Grall
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [XEN v2 08/12] xen/Arm: GICv3: Define ICH_AP0R<n> and ICH_AP1R<n> for AArch32
2022-11-03 12:35 ` Michal Orzel
@ 2022-11-06 18:20 ` Julien Grall
0 siblings, 0 replies; 59+ messages in thread
From: Julien Grall @ 2022-11-06 18:20 UTC (permalink / raw)
To: Michal Orzel, Ayan Kumar Halder, xen-devel
Cc: sstabellini, stefanos, Volodymyr_Babchuk, bertrand.marquis, burzalodowa
On 03/11/2022 12:35, Michal Orzel wrote:
> Hi Ayan,
>
> On 31/10/2022 16:13, Ayan Kumar Halder wrote:
>>
>>
>> Refer "Arm IHI 0069H ID020922",
>> 12.7.1 - Interrupt Controller Hyp Active Priorities Group0 Registers 0-3
>> 12.7.2 - Interrupt Controller Hyp Active Priorities Group1 Registers 0-3
>>
> Commit msg like this is not really beneficial as it requires someone to have
> this spec and only tells that such registers exist on AArch32. It is missing some
> information e.g. what is the purpose of defining them.
+1
>
>> Signed-off-by: Ayan Kumar Halder <ayankuma@amd.com>
>> ---
>>
>> Changes from :-
>> v1 - 1. Moved coproc register definition to asm/cpregs.h.
>>
>> xen/arch/arm/include/asm/arm32/sysregs.h | 1 -
>> xen/arch/arm/include/asm/cpregs.h | 11 +++++++++++
>> 2 files changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/arm/include/asm/arm32/sysregs.h b/xen/arch/arm/include/asm/arm32/sysregs.h
>> index 8a9a014bef..1b2915a526 100644
>> --- a/xen/arch/arm/include/asm/arm32/sysregs.h
>> +++ b/xen/arch/arm/include/asm/arm32/sysregs.h
>> @@ -81,7 +81,6 @@
>>
>> /* MVFR2 is not defined on ARMv7 */
>> #define MVFR2_MAYBE_UNDEFINED
>> -
Spurious change.
>> #endif /* __ASSEMBLY__ */
>>
>> #endif /* __ASM_ARM_ARM32_SYSREGS_H */
>> diff --git a/xen/arch/arm/include/asm/cpregs.h b/xen/arch/arm/include/asm/cpregs.h
>> index 4421dd49ac..bfabee0bc3 100644
>> --- a/xen/arch/arm/include/asm/cpregs.h
>> +++ b/xen/arch/arm/include/asm/cpregs.h
>> @@ -404,6 +404,17 @@
>> #define ICH_LRC14_EL2 __LRC8_EL2(6)
>> #define ICH_LRC15_EL2 __LRC8_EL2(7)
>>
>> +#define __AP0Rx_EL2(x) ___CP32(p15,4,c12,c8,x)
>> +#define ICH_AP0R0_EL2 __AP0Rx_EL2(0)
>> +#define ICH_AP0R1_EL2 __AP0Rx_EL2(1)
>> +#define ICH_AP0R2_EL2 __AP0Rx_EL2(2)
>> +#define ICH_AP0R3_EL2 __AP0Rx_EL2(3)
>> +
>> +#define __AP1Rx_EL2(x) ___CP32(p15,4,c12,c9,x)
>> +#define ICH_AP1R0_EL2 __AP1Rx_EL2(0)
>> +#define ICH_AP1R1_EL2 __AP1Rx_EL2(1)
>> +#define ICH_AP1R2_EL2 __AP1Rx_EL2(2)
>> +#define ICH_AP1R3_EL2 __AP1Rx_EL2(3)
> This might need to be re-aligned after you fix patch no. 7.
> Then, you can add:
> Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Cheers,
--
Julien Grall
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [XEN v2 09/12] xen/Arm: GICv3: Define GIC registers for AArch32
2022-11-03 15:08 ` Michal Orzel
2022-11-03 20:14 ` Ayan Kumar Halder
@ 2022-11-06 18:26 ` Julien Grall
1 sibling, 0 replies; 59+ messages in thread
From: Julien Grall @ 2022-11-06 18:26 UTC (permalink / raw)
To: Michal Orzel, Ayan Kumar Halder, xen-devel
Cc: sstabellini, stefanos, Volodymyr_Babchuk, bertrand.marquis, burzalodowa
On 03/11/2022 15:08, Michal Orzel wrote:
> Hi Ayan,
>
> On 31/10/2022 16:13, Ayan Kumar Halder wrote:
>>
> The title is a bit ambiguous given that the previous patches were also defining GIC registers.
> Maybe adding "remaining" would result in a better commit title.
>
>>
>> Refer "Arm IHI 0069H ID020922"
>> 12.5.23 ICC_SGI1R, Interrupt Controller Software Generated Interrupt
>> Group 1 Register
>> 12.5.12 ICC_HSRE, Interrupt Controller Hyp System Register Enable register
>> 12.7.10 ICH_VTR, Interrupt Controller VGIC Type Register
>> 12.7.5 ICH_HCR, Interrupt Controller Hyp Control Register
>> 12.5.20 ICC_PMR, Interrupt Controller Interrupt Priority Mask Register
>> 12.5.24 ICC_SRE, Interrupt Controller System Register Enable register
>> 12.5.7 ICC_DIR, Interrupt Controller Deactivate Interrupt Register
>> 12.5.9 ICC_EOIR1, Interrupt Controller End Of Interrupt Register 1
>> 12.5.14 ICC_IAR1, Interrupt Controller Interrupt Acknowledge Register 1
>> 12.5.5 ICC_BPR1, Interrupt Controller Binary Point Register 1
>> 12.5.6 ICC_CTLR, Interrupt Controller Control Register
>> 12.5.16 ICC_IGRPEN1, Interrupt Controller Interrupt Group 1 Enable register
>> 12.7.9 ICH_VMCR, Interrupt Controller Virtual Machine Control Register
>>
> As said in the previous patches: this may be my personal opinion but sth like this would be easier to read:
> "
> Define missing assembly aliases for GIC registers on arm32, taking the ones
> defined already for arm64 as a base. Aliases are defined according to the
> GIC Architecture Specification ARM IHI 0069H.
> "
+1 with one remark. I think listing the registers added in the commit
message (no need for the section) is fine.
>> Signed-off-by: Ayan Kumar Halder <ayankuma@amd.com>
>> ---
>>
>> Changes from :-
>> v1 - 1. Moved coproc regs definition to asm/cpregs.h
>>
>> xen/arch/arm/include/asm/cpregs.h | 16 ++++++++++++++++
>> 1 file changed, 16 insertions(+)
>>
>> diff --git a/xen/arch/arm/include/asm/cpregs.h b/xen/arch/arm/include/asm/cpregs.h
>> index bfabee0bc3..62b63f4cef 100644
>> --- a/xen/arch/arm/include/asm/cpregs.h
>> +++ b/xen/arch/arm/include/asm/cpregs.h
>> @@ -415,6 +415,22 @@
>> #define ICH_AP1R1_EL2 __AP1Rx_EL2(1)
>> #define ICH_AP1R2_EL2 __AP1Rx_EL2(2)
>> #define ICH_AP1R3_EL2 __AP1Rx_EL2(3)
>> +
>> +#define ICC_SGI1R_EL1 p15,0,c12
>> +
>> +#define ICC_SRE_EL2 p15,4,c12,c9,5
>> +#define ICH_VTR_EL2 p15,4,c12,c11,1
>> +#define ICH_HCR_EL2 p15,4,c12,c11,0
>> +
>> +#define ICC_PMR_EL1 p15,0,c4,c6,0
>> +#define ICC_SRE_EL1 p15,0,c12,c12,5
>> +#define ICC_DIR_EL1 p15,0,c12,c11,1
>> +#define ICC_EOIR1_EL1 p15,0,c12,c12,1
>> +#define ICC_IAR1_EL1 p15,0,c12,c12,0
>> +#define ICC_BPR1_EL1 p15,0,c12,c12,3
>> +#define ICC_CTLR_EL1 p15,0,c12,c12,4
>> +#define ICC_IGRPEN1_EL1 p15,0,c12,c12,7
>> +#define ICH_VMCR_EL2 p15,4,c12,c11,7
> I did not check this in previous patches but in which order are you defining these registers?
> I took a look at arm64/sysregs.h and these regs are placed in assembly aliases name order.
> So for instance ICC_PMR_EL1 would be defined before ICC_SRE_EL2, etc.
Per the comment in the header, they should be ordered as followed:
Coprocessor-> CRn-> Opcode 1-> CRm-> Opcode 2
Also, we first define the arm32 name and *then* define an alias for
common code.
These remarks applies for the full series.
Cheers,
--
Julien Grall
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [XEN v2 09/12] xen/Arm: GICv3: Define GIC registers for AArch32
2022-11-04 10:04 ` Ayan Kumar Halder
@ 2022-11-06 18:31 ` Julien Grall
0 siblings, 0 replies; 59+ messages in thread
From: Julien Grall @ 2022-11-06 18:31 UTC (permalink / raw)
To: Ayan Kumar Halder, Michal Orzel, xen-devel
Cc: sstabellini, stefanos, Volodymyr_Babchuk, bertrand.marquis, burzalodowa
Hi Ayan,
On 04/11/2022 10:04, Ayan Kumar Halder wrote:
> These registers are not used by Xen.
> Should I define these registers for the sake of completeness (to be in
> parity with AArch64) ?
Yes. I would at least expect the MISR might end up to be used if we were
supporting some interrupts controlled (e.g. the Apple Interrupt Controller).
Cheers,
--
Julien Grall
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [XEN v2 12/12] xen/Arm: GICv3: Enable GICv3 for AArch32
2022-10-31 15:13 ` [XEN v2 12/12] xen/Arm: GICv3: Enable GICv3 for AArch32 Ayan Kumar Halder
2022-11-04 9:55 ` Michal Orzel
@ 2022-11-06 18:39 ` Julien Grall
1 sibling, 0 replies; 59+ messages in thread
From: Julien Grall @ 2022-11-06 18:39 UTC (permalink / raw)
To: Ayan Kumar Halder, xen-devel
Cc: sstabellini, stefanos, Volodymyr_Babchuk, bertrand.marquis, burzalodowa
Hi Ayan,
On 31/10/2022 15:13, Ayan Kumar Halder wrote:
> Refer ARM DDI 0487G.b ID072021,
> D13.2.86 -
> ID_PFR1_EL1, AArch32 Processor Feature Register 1
>
> GIC, bits[31:28] == 0b0001 for GIC3.0 on Aarch32
>
> One can now enable GICv3 on AArch32 systems. However, ITS is not supported.
s/enable/use/
> The reason being currently we are trying to validate GICv3 on an AArch32_v8R
> system. Refer ARM DDI 0568A.c ID110520, B1.3.1,
> "A Generic Interrupt Controller (GIC) implemented with an Armv8-R PE must not
> implement LPI support."
>
> Updated SUPPORT.md.
>
> Signed-off-by: Ayan Kumar Halder <ayankuma@amd.com>
> ---
>
> Changed from :-
> v1 - 1. Remove "ARM_64 || ARM_32" as it is always true.
> 2. Updated SUPPORT.md.
>
> SUPPORT.md | 6 ++++++
> xen/arch/arm/Kconfig | 4 ++--
> xen/arch/arm/include/asm/cpufeature.h | 1 +
> 3 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/SUPPORT.md b/SUPPORT.md
> index cf2ddfacaf..0137855c66 100644
> --- a/SUPPORT.md
> +++ b/SUPPORT.md
> @@ -82,6 +82,12 @@ Extension to the GICv3 interrupt controller to support MSI.
>
> Status: Experimental
>
> +### ARM/GICv3 + AArch32 ARM v8
The general apprpoach in SUPPORT.MD is to name the feature and then
describe per arch the exact support. For this case it would be:
## ARM/GICv3
GICv3 is an interrupt controller specification designed by Arm.
Status, Arm64: Security supported
Status, Arm32: Supported, not security supported
Cheers,
--
Julien Grall
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [XEN v2 04/12] xen/Arm: vGICv3: Adapt emulation of GICR_TYPER for AArch32
2022-11-06 18:04 ` Julien Grall
@ 2022-11-07 11:33 ` Ayan Kumar Halder
2022-11-07 11:54 ` Julien Grall
0 siblings, 1 reply; 59+ messages in thread
From: Ayan Kumar Halder @ 2022-11-07 11:33 UTC (permalink / raw)
To: Julien Grall, xen-devel
Cc: sstabellini, stefanos, Volodymyr_Babchuk, bertrand.marquis, burzalodowa
On 06/11/2022 18:04, Julien Grall wrote:
> Hi Ayan,
Hi Julien,
I need a clarification.
>
> In the title you are using AArch32 but below you are using...
>
> On 31/10/2022 15:13, Ayan Kumar Halder wrote:
>> v->arch.vmpidr is assigned to uint64_t variable. This is to enable
>> left shifts
>> for Aarch32 so that one can extract affinity bits.
>
> ... Aarch32. The naming also seem to be inconsistent across your
> series. AFAIU, it should be AArch32. So please look at all your
> commits and make sure you use the same everywhere.
Ack
>
>> This is then assigned to 'typer' so that the affinity bits form the
>> upper 32 bits.
>>
>> Refer Arm IHI 0069H ID020922,
>> The upper 32 bits of GICR_TYPER represent the affinity
>> whereas the lower 32 bits represent the other bits (eg processor
>> number, etc).
>>
>> Signed-off-by: Ayan Kumar Halder <ayankuma@amd.com>
>> ---
>>
>> Changes from :-
>> 1. v1 - Assigned v->arch.vmpidr to "uint64_t vmpdir". Then, we can use
>> MPIDR_AFFINITY_LEVEL macros to extract the affinity value.
>>
>> xen/arch/arm/vgic-v3.c | 10 ++++++----
>> 1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
>> index 3f4509dcd3..e5e6f2c573 100644
>> --- a/xen/arch/arm/vgic-v3.c
>> +++ b/xen/arch/arm/vgic-v3.c
>> @@ -191,13 +191,15 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct
>> vcpu *v, mmio_info_t *info,
>> case VREG64(GICR_TYPER):
>> {
>> uint64_t typer, aff;
>> + uint64_t vmpidr = v->arch.vmpidr;
>> if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
>> - aff = (MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 3) << 56 |
>> - MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 2) << 48 |
>> - MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 1) << 40 |
>> - MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 0) << 32);
>> + aff = (MPIDR_AFFINITY_LEVEL(vmpidr, 3) << 56 |
>
> Shouldn't we #ifdef this level for 32-bit? Or maybe check if the
> domain is 64-bit so we are using consistently regardless of the
> hypervisor bitness.
We have typecasted "v->arch.vmpidr" (which is 32bit for AArch32 and
64bit for AArch64) to vmpidr (uint64_t).
So, we don't need to have any #ifdef for AArch32 or AArch64.
Please let me know if I am missing something.
Also, GICR_TYPER is 64 bit for AArch32 and AArch64.
- Ayan
>
>> + MPIDR_AFFINITY_LEVEL(vmpidr, 2) << 48 |
>> + MPIDR_AFFINITY_LEVEL(vmpidr, 1) << 40 |
>> + MPIDR_AFFINITY_LEVEL(vmpidr, 0) << 32);
>> typer = aff;
>> +
>
> Spurious change?
>
>> /* We use the VCPU ID as the redistributor ID in bits[23:8] */
>> typer |= v->vcpu_id << GICR_TYPER_PROC_NUM_SHIFT;
>
> Cheers,
>
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [XEN v2 04/12] xen/Arm: vGICv3: Adapt emulation of GICR_TYPER for AArch32
2022-11-07 11:33 ` Ayan Kumar Halder
@ 2022-11-07 11:54 ` Julien Grall
2022-11-07 14:00 ` Ayan Kumar Halder
0 siblings, 1 reply; 59+ messages in thread
From: Julien Grall @ 2022-11-07 11:54 UTC (permalink / raw)
To: Ayan Kumar Halder, xen-devel
Cc: sstabellini, stefanos, Volodymyr_Babchuk, bertrand.marquis, burzalodowa
Hi Ayan,
On 07/11/2022 11:33, Ayan Kumar Halder wrote:
>
> On 06/11/2022 18:04, Julien Grall wrote:
>> Hi Ayan,
>
> Hi Julien,
>
> I need a clarification.
>
>>
>> In the title you are using AArch32 but below you are using...
>>
>> On 31/10/2022 15:13, Ayan Kumar Halder wrote:
>>> v->arch.vmpidr is assigned to uint64_t variable. This is to enable
>>> left shifts
>>> for Aarch32 so that one can extract affinity bits.
>>
>> ... Aarch32. The naming also seem to be inconsistent across your
>> series. AFAIU, it should be AArch32. So please look at all your
>> commits and make sure you use the same everywhere.
> Ack
>>
>>> This is then assigned to 'typer' so that the affinity bits form the
>>> upper 32 bits.
>>>
>>> Refer Arm IHI 0069H ID020922,
>>> The upper 32 bits of GICR_TYPER represent the affinity
>>> whereas the lower 32 bits represent the other bits (eg processor
>>> number, etc).
>>>
>>> Signed-off-by: Ayan Kumar Halder <ayankuma@amd.com>
>>> ---
>>>
>>> Changes from :-
>>> 1. v1 - Assigned v->arch.vmpidr to "uint64_t vmpdir". Then, we can use
>>> MPIDR_AFFINITY_LEVEL macros to extract the affinity value.
>>>
>>> xen/arch/arm/vgic-v3.c | 10 ++++++----
>>> 1 file changed, 6 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
>>> index 3f4509dcd3..e5e6f2c573 100644
>>> --- a/xen/arch/arm/vgic-v3.c
>>> +++ b/xen/arch/arm/vgic-v3.c
>>> @@ -191,13 +191,15 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct
>>> vcpu *v, mmio_info_t *info,
>>> case VREG64(GICR_TYPER):
>>> {
>>> uint64_t typer, aff;
>>> + uint64_t vmpidr = v->arch.vmpidr;
>>> if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
>>> - aff = (MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 3) << 56 |
>>> - MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 2) << 48 |
>>> - MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 1) << 40 |
>>> - MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 0) << 32);
>>> + aff = (MPIDR_AFFINITY_LEVEL(vmpidr, 3) << 56 |
>>
>> Shouldn't we #ifdef this level for 32-bit? Or maybe check if the
>> domain is 64-bit so we are using consistently regardless of the
>> hypervisor bitness.
>
> We have typecasted "v->arch.vmpidr" (which is 32bit for AArch32 and
> 64bit for AArch64) to vmpidr (uint64_t).
>
> So, we don't need to have any #ifdef for AArch32 or AArch64.
This is not related to the typecast. This is more that fact that
affinity level 3 doesn't exist for 32-bit guest. For instance vpsci.c
will protect level 3 with an #ifdef.
Cheers,
--
Julien Grall
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [XEN v2 04/12] xen/Arm: vGICv3: Adapt emulation of GICR_TYPER for AArch32
2022-11-07 11:54 ` Julien Grall
@ 2022-11-07 14:00 ` Ayan Kumar Halder
2022-11-07 17:37 ` Julien Grall
0 siblings, 1 reply; 59+ messages in thread
From: Ayan Kumar Halder @ 2022-11-07 14:00 UTC (permalink / raw)
To: Julien Grall, xen-devel
Cc: sstabellini, stefanos, Volodymyr_Babchuk, bertrand.marquis, burzalodowa
On 07/11/2022 11:54, Julien Grall wrote:
> Hi Ayan,
Hi Julien,
I need one clarification.
>
> On 07/11/2022 11:33, Ayan Kumar Halder wrote:
>>
>> On 06/11/2022 18:04, Julien Grall wrote:
>>> Hi Ayan,
>>
>> Hi Julien,
>>
>> I need a clarification.
>>
>>>
>>> In the title you are using AArch32 but below you are using...
>>>
>>> On 31/10/2022 15:13, Ayan Kumar Halder wrote:
>>>> v->arch.vmpidr is assigned to uint64_t variable. This is to enable
>>>> left shifts
>>>> for Aarch32 so that one can extract affinity bits.
>>>
>>> ... Aarch32. The naming also seem to be inconsistent across your
>>> series. AFAIU, it should be AArch32. So please look at all your
>>> commits and make sure you use the same everywhere.
>> Ack
>>>
>>>> This is then assigned to 'typer' so that the affinity bits form the
>>>> upper 32 bits.
>>>>
>>>> Refer Arm IHI 0069H ID020922,
>>>> The upper 32 bits of GICR_TYPER represent the affinity
>>>> whereas the lower 32 bits represent the other bits (eg processor
>>>> number, etc).
>>>>
>>>> Signed-off-by: Ayan Kumar Halder <ayankuma@amd.com>
>>>> ---
>>>>
>>>> Changes from :-
>>>> 1. v1 - Assigned v->arch.vmpidr to "uint64_t vmpdir". Then, we can use
>>>> MPIDR_AFFINITY_LEVEL macros to extract the affinity value.
>>>>
>>>> xen/arch/arm/vgic-v3.c | 10 ++++++----
>>>> 1 file changed, 6 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
>>>> index 3f4509dcd3..e5e6f2c573 100644
>>>> --- a/xen/arch/arm/vgic-v3.c
>>>> +++ b/xen/arch/arm/vgic-v3.c
>>>> @@ -191,13 +191,15 @@ static int
>>>> __vgic_v3_rdistr_rd_mmio_read(struct vcpu *v, mmio_info_t *info,
>>>> case VREG64(GICR_TYPER):
>>>> {
>>>> uint64_t typer, aff;
>>>> + uint64_t vmpidr = v->arch.vmpidr;
>>>> if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
>>>> - aff = (MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 3) << 56 |
>>>> - MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 2) << 48 |
>>>> - MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 1) << 40 |
>>>> - MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 0) << 32);
>>>> + aff = (MPIDR_AFFINITY_LEVEL(vmpidr, 3) << 56 |
>>>
>>> Shouldn't we #ifdef this level for 32-bit? Or maybe check if the
>>> domain is 64-bit so we are using consistently regardless of the
>>> hypervisor bitness.
>>
>> We have typecasted "v->arch.vmpidr" (which is 32bit for AArch32 and
>> 64bit for AArch64) to vmpidr (uint64_t).
>>
>> So, we don't need to have any #ifdef for AArch32 or AArch64.
>
> This is not related to the typecast. This is more that fact that
> affinity level 3 doesn't exist for 32-bit guest. For instance vpsci.c
> will protect level 3 with an #ifdef.
Just to make sure, I understand you. You are suggesting this ?
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -191,13 +191,15 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu *v, mmio_info_t *info,
case VREG64(GICR_TYPER):
{
uint64_t typer, aff;
+ uint64_t vmpidr = v->arch.vmpidr;
if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
- aff = (MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 3) << 56 |
- MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 2) << 48 |
- MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 1) << 40 |
- MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 0) << 32);
+ aff = (
+#ifdef CONFIG_ARM_64
+ MPIDR_AFFINITY_LEVEL(vmpidr, 3) << 56 |
+#endif
+ MPIDR_AFFINITY_LEVEL(vmpidr, 2) << 48 |
+ MPIDR_AFFINITY_LEVEL(vmpidr, 1) << 40 |
+ MPIDR_AFFINITY_LEVEL(vmpidr, 0) << 32);
typer = aff;
+
/* We use the VCPU ID as the redistributor ID in bits[23:8] */
typer |= v->vcpu_id << GICR_TYPER_PROC_NUM_SHIFT;
If so, then we can drop the patch "[XEN v2 02/12] xen/Arm: GICv3: Move
the macros to compute the affnity level to arm64/arm32"
Also, we should do the following change :-
ayankuma@xcbayankuma41x:/scratch/ayankuma/r52_xen/xen-pristine$ git diff
xen/arch/arm/gic-v3.c
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index d8ce0f46c6..e7d5338152 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -527,7 +527,10 @@ static void gicv3_set_pending_state(struct irq_desc
*irqd, bool pending)
static inline uint64_t gicv3_mpidr_to_affinity(int cpu)
{
uint64_t mpidr = cpu_logical_map(cpu);
- return (MPIDR_AFFINITY_LEVEL(mpidr, 3) << 32 |
+ return (
+#ifdef CONFIG_ARM_64
+ MPIDR_AFFINITY_LEVEL(mpidr, 3) << 32 |
+#endif
MPIDR_AFFINITY_LEVEL(mpidr, 2) << 16 |
MPIDR_AFFINITY_LEVEL(mpidr, 1) << 8 |
MPIDR_AFFINITY_LEVEL(mpidr, 0));
@@ -720,7 +723,10 @@ static int __init gicv3_populate_rdist(void)
* Convert affinity to a 32bit value that can be matched to GICR_TYPER
* bits [63:32]
*/
- aff = (MPIDR_AFFINITY_LEVEL(mpidr, 3) << 24 |
+ aff = (
+#ifdef CONFIG_ARM_64
+ MPIDR_AFFINITY_LEVEL(mpidr, 3) << 24 |
+#endif
MPIDR_AFFINITY_LEVEL(mpidr, 2) << 16 |
MPIDR_AFFINITY_LEVEL(mpidr, 1) << 8 |
MPIDR_AFFINITY_LEVEL(mpidr, 0));
@@ -972,7 +978,10 @@ static void gicv3_send_sgi_list(enum gic_sgi sgi,
const cpumask_t *cpumask)
* Prepare affinity path of the cluster for which SGI is generated
* along with SGI number
*/
- val = (MPIDR_AFFINITY_LEVEL(cluster_id, 3) << 48 |
+ val = (
+#ifdef CONFIG_ARM_64
+ MPIDR_AFFINITY_LEVEL(cluster_id, 3) << 48 |
+#endif
MPIDR_AFFINITY_LEVEL(cluster_id, 2) << 32 |
sgi << 24 |
MPIDR_AFFINITY_LEVEL(cluster_id, 1) << 16 |
- Ayan
>
> Cheers,
>
^ permalink raw reply related [flat|nested] 59+ messages in thread
* Re: [XEN v2 04/12] xen/Arm: vGICv3: Adapt emulation of GICR_TYPER for AArch32
2022-11-07 14:00 ` Ayan Kumar Halder
@ 2022-11-07 17:37 ` Julien Grall
0 siblings, 0 replies; 59+ messages in thread
From: Julien Grall @ 2022-11-07 17:37 UTC (permalink / raw)
To: Ayan Kumar Halder, xen-devel
Cc: sstabellini, stefanos, Volodymyr_Babchuk, bertrand.marquis, burzalodowa
Hi Ayan,
On 07/11/2022 14:00, Ayan Kumar Halder wrote:
>
> On 07/11/2022 11:54, Julien Grall wrote:
>> Hi Ayan,
>
> Hi Julien,
>
> I need one clarification.
>
>>
>> On 07/11/2022 11:33, Ayan Kumar Halder wrote:
>>>
>>> On 06/11/2022 18:04, Julien Grall wrote:
>>>> Hi Ayan,
>>>
>>> Hi Julien,
>>>
>>> I need a clarification.
>>>
>>>>
>>>> In the title you are using AArch32 but below you are using...
>>>>
>>>> On 31/10/2022 15:13, Ayan Kumar Halder wrote:
>>>>> v->arch.vmpidr is assigned to uint64_t variable. This is to enable
>>>>> left shifts
>>>>> for Aarch32 so that one can extract affinity bits.
>>>>
>>>> ... Aarch32. The naming also seem to be inconsistent across your
>>>> series. AFAIU, it should be AArch32. So please look at all your
>>>> commits and make sure you use the same everywhere.
>>> Ack
>>>>
>>>>> This is then assigned to 'typer' so that the affinity bits form the
>>>>> upper 32 bits.
>>>>>
>>>>> Refer Arm IHI 0069H ID020922,
>>>>> The upper 32 bits of GICR_TYPER represent the affinity
>>>>> whereas the lower 32 bits represent the other bits (eg processor
>>>>> number, etc).
>>>>>
>>>>> Signed-off-by: Ayan Kumar Halder <ayankuma@amd.com>
>>>>> ---
>>>>>
>>>>> Changes from :-
>>>>> 1. v1 - Assigned v->arch.vmpidr to "uint64_t vmpdir". Then, we can use
>>>>> MPIDR_AFFINITY_LEVEL macros to extract the affinity value.
>>>>>
>>>>> xen/arch/arm/vgic-v3.c | 10 ++++++----
>>>>> 1 file changed, 6 insertions(+), 4 deletions(-)
>>>>>
>>>>> diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
>>>>> index 3f4509dcd3..e5e6f2c573 100644
>>>>> --- a/xen/arch/arm/vgic-v3.c
>>>>> +++ b/xen/arch/arm/vgic-v3.c
>>>>> @@ -191,13 +191,15 @@ static int
>>>>> __vgic_v3_rdistr_rd_mmio_read(struct vcpu *v, mmio_info_t *info,
>>>>> case VREG64(GICR_TYPER):
>>>>> {
>>>>> uint64_t typer, aff;
>>>>> + uint64_t vmpidr = v->arch.vmpidr;
>>>>> if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
>>>>> - aff = (MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 3) << 56 |
>>>>> - MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 2) << 48 |
>>>>> - MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 1) << 40 |
>>>>> - MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 0) << 32);
>>>>> + aff = (MPIDR_AFFINITY_LEVEL(vmpidr, 3) << 56 |
>>>>
>>>> Shouldn't we #ifdef this level for 32-bit? Or maybe check if the
>>>> domain is 64-bit so we are using consistently regardless of the
>>>> hypervisor bitness.
>>>
>>> We have typecasted "v->arch.vmpidr" (which is 32bit for AArch32 and
>>> 64bit for AArch64) to vmpidr (uint64_t).
>>>
>>> So, we don't need to have any #ifdef for AArch32 or AArch64.
>>
>> This is not related to the typecast. This is more that fact that
>> affinity level 3 doesn't exist for 32-bit guest. For instance vpsci.c
>> will protect level 3 with an #ifdef.
>
> Just to make sure, I understand you. You are suggesting this ?
Yes with...
>
> --- a/xen/arch/arm/vgic-v3.c
> +++ b/xen/arch/arm/vgic-v3.c
> @@ -191,13 +191,15 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct
> vcpu *v, mmio_info_t *info,
> case VREG64(GICR_TYPER):
> {
> uint64_t typer, aff;
> + uint64_t vmpidr = v->arch.vmpidr;
>
> if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
> - aff = (MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 3) << 56 |
> - MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 2) << 48 |
> - MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 1) << 40 |
> - MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 0) << 32);
> + aff = (
> +#ifdef CONFIG_ARM_64
> + MPIDR_AFFINITY_LEVEL(vmpidr, 3) << 56 |
> +#endif
> + MPIDR_AFFINITY_LEVEL(vmpidr, 2) << 48 |
> + MPIDR_AFFINITY_LEVEL(vmpidr, 1) << 40 |
> + MPIDR_AFFINITY_LEVEL(vmpidr, 0) << 32);
> typer = aff;
> +
... this spurious change dropped.
> /* We use the VCPU ID as the redistributor ID in bits[23:8] */
> typer |= v->vcpu_id << GICR_TYPER_PROC_NUM_SHIFT;
>
> If so, then we can drop the patch "[XEN v2 02/12] xen/Arm: GICv3: Move
> the macros to compute the affnity level to arm64/arm32"
>
> Also, we should do the following change :-
Yes but in a separate patch (we should keep vGIC and GIC changes separate).
>
> ayankuma@xcbayankuma41x:/scratch/ayankuma/r52_xen/xen-pristine$ git diff
> xen/arch/arm/gic-v3.c
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index d8ce0f46c6..e7d5338152 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -527,7 +527,10 @@ static void gicv3_set_pending_state(struct irq_desc
> *irqd, bool pending)
> static inline uint64_t gicv3_mpidr_to_affinity(int cpu)
> {
> uint64_t mpidr = cpu_logical_map(cpu);
> - return (MPIDR_AFFINITY_LEVEL(mpidr, 3) << 32 |
> + return (
> +#ifdef CONFIG_ARM_64
> + MPIDR_AFFINITY_LEVEL(mpidr, 3) << 32 |
> +#endif
> MPIDR_AFFINITY_LEVEL(mpidr, 2) << 16 |
> MPIDR_AFFINITY_LEVEL(mpidr, 1) << 8 |
> MPIDR_AFFINITY_LEVEL(mpidr, 0));
> @@ -720,7 +723,10 @@ static int __init gicv3_populate_rdist(void)
> * Convert affinity to a 32bit value that can be matched to
> GICR_TYPER
> * bits [63:32]
> */
> - aff = (MPIDR_AFFINITY_LEVEL(mpidr, 3) << 24 |
> + aff = (
> +#ifdef CONFIG_ARM_64
> + MPIDR_AFFINITY_LEVEL(mpidr, 3) << 24 |
> +#endif
> MPIDR_AFFINITY_LEVEL(mpidr, 2) << 16 |
> MPIDR_AFFINITY_LEVEL(mpidr, 1) << 8 |
> MPIDR_AFFINITY_LEVEL(mpidr, 0));
> @@ -972,7 +978,10 @@ static void gicv3_send_sgi_list(enum gic_sgi sgi,
> const cpumask_t *cpumask)
> * Prepare affinity path of the cluster for which SGI is
> generated
> * along with SGI number
> */
> - val = (MPIDR_AFFINITY_LEVEL(cluster_id, 3) << 48 |
> + val = (
> +#ifdef CONFIG_ARM_64
> + MPIDR_AFFINITY_LEVEL(cluster_id, 3) << 48 |
> +#endif
> MPIDR_AFFINITY_LEVEL(cluster_id, 2) << 32 |
> sgi << 24 |
> MPIDR_AFFINITY_LEVEL(cluster_id, 1) << 16 |
>
> - Ayan
>
>>
>> Cheers,
>>
--
Julien Grall
^ permalink raw reply [flat|nested] 59+ messages in thread
end of thread, other threads:[~2022-11-07 17:37 UTC | newest]
Thread overview: 59+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-10-31 15:13 [XEN v2 00/12] Arm: Enable GICv3 for AArch32 (v8R) Ayan Kumar Halder
2022-10-31 15:13 ` [XEN v2 01/12] xen/Arm: vGICv3: Sysreg emulation is applicable for Aarch64 only Ayan Kumar Halder
2022-10-31 17:43 ` Michal Orzel
2022-11-02 8:51 ` Julien Grall
2022-10-31 15:13 ` [XEN v2 02/12] xen/Arm: GICv3: Move the macros to compute the affnity level to arm64/arm32 Ayan Kumar Halder
2022-10-31 17:53 ` Michal Orzel
2022-11-01 8:58 ` Michal Orzel
2022-11-01 11:32 ` Ayan Kumar Halder
2022-11-02 8:46 ` Julien Grall
2022-11-02 9:57 ` Xenia Ragiadakou
2022-11-02 10:10 ` Julien Grall
2022-11-02 10:36 ` Xenia Ragiadakou
2022-11-06 17:59 ` Julien Grall
2022-10-31 15:13 ` [XEN v2 03/12] xen/Arm: vreg: Support vreg_reg64_* helpers on Aarch32 Ayan Kumar Halder
2022-11-02 8:52 ` Michal Orzel
2022-11-02 9:08 ` Julien Grall
2022-11-02 9:02 ` Julien Grall
2022-10-31 15:13 ` [XEN v2 04/12] xen/Arm: vGICv3: Adapt emulation of GICR_TYPER for AArch32 Ayan Kumar Halder
2022-11-06 18:04 ` Julien Grall
2022-11-07 11:33 ` Ayan Kumar Halder
2022-11-07 11:54 ` Julien Grall
2022-11-07 14:00 ` Ayan Kumar Halder
2022-11-07 17:37 ` Julien Grall
2022-10-31 15:13 ` [XEN v2 05/12] xen/Arm: GICv3: Fix GICR_{PENDBASER, PROPBASER} emulation on 32-bit host Ayan Kumar Halder
2022-11-02 10:26 ` Michal Orzel
2022-11-06 18:05 ` Julien Grall
2022-10-31 15:13 ` [XEN v2 06/12] xen/Arm: vGICv3: Fix emulation of ICC_SGI1R on AArch32 Ayan Kumar Halder
2022-11-02 10:41 ` Michal Orzel
2022-11-06 18:06 ` Julien Grall
2022-10-31 15:13 ` [XEN v2 07/12] xen/Arm: GICv3: Define ICH_LR<n>_EL2 " Ayan Kumar Halder
2022-11-03 12:13 ` Michal Orzel
2022-11-06 18:14 ` Julien Grall
2022-11-06 18:19 ` Julien Grall
2022-10-31 15:13 ` [XEN v2 08/12] xen/Arm: GICv3: Define ICH_AP0R<n> and ICH_AP1R<n> for AArch32 Ayan Kumar Halder
2022-11-03 12:35 ` Michal Orzel
2022-11-06 18:20 ` Julien Grall
2022-10-31 15:13 ` [XEN v2 09/12] xen/Arm: GICv3: Define GIC registers " Ayan Kumar Halder
2022-11-03 15:08 ` Michal Orzel
2022-11-03 20:14 ` Ayan Kumar Halder
2022-11-04 9:27 ` Michal Orzel
2022-11-04 10:04 ` Ayan Kumar Halder
2022-11-06 18:31 ` Julien Grall
2022-11-06 18:26 ` Julien Grall
2022-10-31 15:13 ` [XEN v2 10/12] xen/Arm: GICv3: Use ULL instead of UL for 64bits Ayan Kumar Halder
2022-11-01 10:03 ` Xenia Ragiadakou
2022-11-01 14:43 ` Ayan Kumar Halder
2022-11-02 8:10 ` Xenia Ragiadakou
2022-10-31 15:13 ` [XEN v2 11/12] xen/Arm: GICv3: Define macros to read/write 64 bit Ayan Kumar Halder
2022-11-01 7:08 ` Xenia Ragiadakou
2022-11-01 9:50 ` Julien Grall
2022-11-01 10:59 ` Ayan Kumar Halder
2022-11-01 11:57 ` Julien Grall
2022-11-01 14:23 ` Xenia Ragiadakou
2022-10-31 15:13 ` [XEN v2 12/12] xen/Arm: GICv3: Enable GICv3 for AArch32 Ayan Kumar Halder
2022-11-04 9:55 ` Michal Orzel
2022-11-04 11:09 ` Ayan Kumar Halder
2022-11-04 11:30 ` Julien Grall
2022-11-04 11:52 ` Michal Orzel
2022-11-06 18:39 ` Julien Grall
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.