[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [XEN v2 11/11] xen/arm: p2m: Enable support for 32bit IPA
On 10/02/2023 17:51, Ayan Kumar Halder wrote:
On 10/02/2023 16:19, Julien Grall wrote:
Hi,
On 10/02/2023 15:39, Ayan Kumar Halder wrote:
On 09/02/2023 11:45, Julien Grall wrote:
Hi,
Hi Julien,
On 07/02/2023 15:34, Ayan Kumar Halder wrote:
On 20/01/2023 11:06, Julien Grall wrote:
Hi Ayan,
Hi Julien,
On 17/01/2023 17:43, Ayan Kumar Halder wrote:
VTCR.T0SZ should be set as 0x20 to support 32bit IPA.
Refer ARM DDI 0487I.a ID081822, G8-9824, G8.2.171, VTCR,
"Virtualization Translation Control Register" for the bit
descriptions.
Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@xxxxxxx>
---
Changes from -
v1 - New patch.
xen/arch/arm/p2m.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 948f199d84..cfdea55e71 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -2266,13 +2266,17 @@ void __init setup_virt_paging(void)
register_t val =
VTCR_RES1|VTCR_SH0_IS|VTCR_ORGN0_WBWA|VTCR_IRGN0_WBWA;
#ifdef CONFIG_ARM_32
- if ( p2m_ipa_bits < 40 )
+ if ( p2m_ipa_bits < PADDR_BITS )
panic("P2M: Not able to support %u-bit IPA at the
moment\n",
p2m_ipa_bits);
- printk("P2M: 40-bit IPA\n");
- p2m_ipa_bits = 40;
+ printk("P2M: %u-bit IPA\n",PADDR_BITS);
+ p2m_ipa_bits = PADDR_BITS;
+#ifdef CONFIG_ARM_PA_32
+ val |= VTCR_T0SZ(0x20); /* 32 bit IPA */
+#else
val |= VTCR_T0SZ(0x18); /* 40 bit IPA */
+#endif
I am wondering whether this is right time to switch to an array
like the arm64 code? This would allow to use 32-bit IPA also when
Xen support 64-bit physical address.
In AArch64, we use ID_AA64MMFR0_EL1.PARange to determine the
physical address range supported at runtime. This is then used as
an index into pa_range_info[] to determine t0sz, root_order, etc.
It is using both the ID_AA64MMFR0_EL1 but also p2m_ipa_bits to
decide the size.
Ack.
However, for AArch32 I do not see an equivalent register (similar
to ID_AA64MMFR0_EL1) or any register to determine the physical
address range. Thus, I will prefer to keep the code as it is unless
you suggest any alternative.
I looked at the Arm Arm and indeed it doesn't look like there are
equivalent for ID_AA64MMFR0_EL1.PARange.
However, my point was less about reading the system register but
more about the fact we could have the code a bit more generic and
avoid the assumption that PADDR_BITS is only modified when
CONFIG_ARM_PA_32 is set.
I had a rework at the patch. Please let me know if the following
looks better.
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 948f199d84..bc3bdf5f3e 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -2266,14 +2266,35 @@ void __init setup_virt_paging(void)
register_t val =
VTCR_RES1|VTCR_SH0_IS|VTCR_ORGN0_WBWA|VTCR_IRGN0_WBWA;
#ifdef CONFIG_ARM_32
- if ( p2m_ipa_bits < 40 )
+ static const struct {
+ unsigned int pabits; /* Physical Address Size */
+ unsigned int t0sz; /* Desired T0SZ */
+ unsigned int sl0; /* Desired SL0 */
Hmmm... Why don't you include the root order? In fact...
+ } pa_range_info[] __initconst = {
+ [0] = { 32, 32, 1 },
+ [1] = { 40, 24, 1 },
... looking at the ARMv7 specification (see B3-1345 in ARM DDI
0406C.d), the root page-table is only concatenated for 40-bits.
Sorry, I could not follow how you inferred this. Can you paste the
relevant snippet ?
Use of concatenated second-level translation tables
A stage 2 translation with an input address range of 31-34 bits can
start the translation either:
• With a first-level lookup, accessing a first-level translation table
with 2-16 entries.
• With a second-level lookup, accessing a set of concatenated
second-level translation tables.
+ };
+ int i = 0;
+
+ if ( p2m_ipa_bits < PADDR_BITS )
+ panic("P2M: Not able to support %u-bit IPA at the moment\n",
+ p2m_ipa_bits);
This check seems unnecessary now.
We still need this check as arm_smmu_device_cfg_probe() invokes
p2m_restrict_ipa_bits(size).
And referARM IHI 0062D.cID070116 (SMMU arch version 2.0 Specification),
the IPA address size can be
0.
0b0000 32-bit.
1.
0b0001 36-bit.
10.
0b0010 40-bit.
11.
0b0011 42-bit.
100.
0b0100 44-bit.
101.
0b0101 48-bit.
So if p2m_ipa_bits = 36 bits and PADDR_BITS = 40, then we want to panic.
We can have the same situation on Arm64 (PADDR_BITS = 48), yet we don't
panic(). So I don't quite understand why we would need to differ...
Or are you saying that for 64-bit we also need such check? If so, then I
am still not sure why because p2m_ipa_bits represent the guest physical
address space and PADDR_BITS the Xen physical address space. It is valid
to have both of them differing.
Cheers,
--
Julien Grall
|
