[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:Sorry, I could not follow how you inferred this. Can you paste the relevant snippet ?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 */ +#endifI 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. Use of concatenated second-level translation tablesA 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 be0. 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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |