This question is about VMSAv8-64's EL1&0 stage 2 translation regime. The use of concatenated translation tables for the initial lookup is presented, in the ARM ARM, as an optional alternative to the overhead of an additional level of translation. However, there are cases where that alternative is seemingly necessary.In the ARM ARM (ARM DDI 0487G.a), the table "PA size implications for the VTCR_EL2.T0SZ and VSTCR_EL2.T0SZ fields" (D5-6, on page 2669) shows how the supported physical address size constrains the IPA size and the translation starting level. Some starting levels are surprisingly invalid.For example, if the supported PA size is 40 bits (or even less than that when EL1 uses Aarch32) and the translation granule is 4 KiB, then, according to table D5-6, the IPA size can be chosen to be 40 bits (VTCR_EL2.T0SZ = 24), but translation may only start at level 1 or more. This is surprising, because level 1 can only resolve 39-bit IPAs without concatenated translation tables. Indeed, table "VTCR_EL2.T0SZ values and IA ranges, 4KB granule with possible concatenation of translation tables" (D5-14, on pages 2686-2687) confirms that 2 concatenated translation tables are necessary in this case (to resolve the additional bit [39]).Is my understanding correct that the PA size may force the use of concatenated translation tables in this way? Bonus question: if so, why does VMSAv8-64 not support more translation levels instead? Suggestion: make it clearer, in the ARM ARM's section on concatenated translation tables, that their use may not be optional.Thanks!