[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [XEN v1] Xen: Enable compilation when PADDR_BITS == BITS_PER_LONG
On 01/12/2022 12:12, Ayan Kumar Halder wrote: On 01/12/2022 10:26, Julien Grall wrote:Hi Ayan,Hi Julien, I have a question.On 01/12/2022 10:03, Ayan Kumar Halder wrote:It is possible for a pointer to represent physical memory of the same size. In other words, a 32 bit pointer can represent 32 bit addressable physicalmemory.Thus, issue a compilation failure only when the count of physical address bitsis greater than BITS_PER_LONG (ie count of bits in void*).I am having difficult to understand how this description is related to the BUILD_BUG_ON(). AFAIU, it is used to check that xenheap_bits can be used in shift.If the unsigned long is 32-bit, then a shift of 32 could be undefined. Looking at the current use, the shift are used with "xenheap_bits - PAGE_SHIFT". So as long as PAGE_SHIFT is not 0, you would be fine.AckSigned-off-by: Ayan Kumar Halder <ayan.kumar.halder@xxxxxxx> ---Currently this change will not have any impact on the existing architectures. The following table illustrates PADDR_BITS vs BITS_PER_LONG of different archs------------------------------------------------ | Arch | PADDR_BITS | BITS_PER_LONG | ------------------------------------------------ | Arm_64 | 48 | 64 | | Arm_32 | 40 | 32 | | RISCV_64 | Don't know | 64 | | x86 | 52 | 64 | -------------------------------------------------The Arm_32 line is a bit confusing because one would wonder why we haven't seen this issue yet. So I think you want to clarify that the code path is not used by Arm32.Do you want this clarification and the above/below explanation to be a part of the commit message ? No I don't think this will be relevant in the final commit message. Cheers, -- Julien Grall
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |