Messages in this thread | ![/](/images/icornerl.gif) | | Subject | Re: [PATCH v1 01/10] powerpc/pseries/iommu: Replace hard-coded page shift | From | Alexey Kardashevskiy <> | Date | Mon, 31 Aug 2020 13:48:46 +1000 |
| |
On 31/08/2020 11:41, Oliver O'Halloran wrote: > On Mon, Aug 31, 2020 at 10:08 AM Alexey Kardashevskiy <aik@ozlabs.ru> wrote: >> >> On 29/08/2020 05:55, Leonardo Bras wrote: >>> On Fri, 2020-08-28 at 12:27 +1000, Alexey Kardashevskiy wrote: >>>> >>>> On 28/08/2020 01:32, Leonardo Bras wrote: >>>>> Hello Alexey, thank you for this feedback! >>>>> >>>>> On Sat, 2020-08-22 at 19:33 +1000, Alexey Kardashevskiy wrote: >>>>>>> +#define TCE_RPN_BITS 52 /* Bits 0-51 represent RPN on TCE */ >>>>>> >>>>>> Ditch this one and use MAX_PHYSMEM_BITS instead? I am pretty sure this >>>>>> is the actual limit. >>>>> >>>>> I understand this MAX_PHYSMEM_BITS(51) comes from the maximum physical memory addressable in the machine. IIUC, it means we can access physical address up to (1ul << MAX_PHYSMEM_BITS). >>>>> >>>>> This 52 comes from PAPR "Table 9. TCE Definition" which defines bits >>>>> 0-51 as the RPN. By looking at code, I understand that it means we may input any address < (1ul << 52) to TCE. >>>>> >>>>> In practice, MAX_PHYSMEM_BITS should be enough as of today, because I suppose we can't ever pass a physical page address over >>>>> (1ul << 51), and TCE accepts up to (1ul << 52). >>>>> But if we ever increase MAX_PHYSMEM_BITS, it doesn't necessarily means that TCE_RPN_BITS will also be increased, so I think they are independent values. >>>>> >>>>> Does it make sense? Please let me know if I am missing something. >>>> >>>> The underlying hardware is PHB3/4 about which the IODA2 Version 2.4 >>>> 6Apr2012.pdf spec says: >>>> >>>> "The number of most significant RPN bits implemented in the TCE is >>>> dependent on the max size of System Memory to be supported by the platform". >>>> >>>> IODA3 is the same on this matter. >>>> >>>> This is MAX_PHYSMEM_BITS and PHB itself does not have any other limits >>>> on top of that. So the only real limit comes from MAX_PHYSMEM_BITS and >>>> where TCE_RPN_BITS comes from exactly - I have no idea. >>> >>> Well, I created this TCE_RPN_BITS = 52 because the previous mask was a >>> hardcoded 40-bit mask (0xfffffffffful), for hard-coded 12-bit (4k) >>> pagesize, and on PAPR+/LoPAR also defines TCE as having bits 0-51 >>> described as RPN, as described before. >>> >>> IODA3 Revision 3.0_prd1 (OpenPowerFoundation), Figure 3.4 and 3.5. >>> shows system memory mapping into a TCE, and the TCE also has bits 0-51 >>> for the RPN (52 bits). "Table 3.6. TCE Definition" also shows it. >>>> In fact, by the looks of those figures, the RPN_MASK should always be a >>> 52-bit mask, and RPN = (page >> tceshift) & RPN_MASK. >> >> I suspect the mask is there in the first place for extra protection >> against too big addresses going to the TCE table (or/and for virtial vs >> physical addresses). Using 52bit mask makes no sense for anything, you >> could just drop the mask and let c compiler deal with 64bit "uint" as it >> is basically a 4K page address anywhere in the 64bit space. Thanks, > > Assuming 4K pages you need 52 RPN bits to cover the whole 64bit > physical address space. The IODA3 spec does explicitly say the upper > bits are optional and the implementation only needs to support enough > to cover up to the physical address limit, which is 56bits of P9 / > PHB4. If you want to validate that the address will fit inside of > MAX_PHYSMEM_BITS then fine, but I think that should be done as a > WARN_ON or similar rather than just silently masking off the bits.
We can do this and probably should anyway but I am also pretty sure we can just ditch the mask and have the hypervisor return an error which will show up in dmesg.
-- Alexey
| ![\](/images/icornerr.gif) |