Re: [Xen-devel] [PATCH v1 08/10] iommu: Split iommu_hwdom_init() into arch specific parts

[Oleksandr Tyshchenko <olekstysh@xxxxxxxxx>]

Hi, Jan.

On Mon, May 15, 2017 at 3:43 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> On 15.05.17 at 13:45, <julien.grall@xxxxxxx> wrote:
>> On 05/15/2017 09:19 AM, Jan Beulich wrote:
>>>>>> On 15.05.17 at 09:42, <julien.grall@xxxxxxx> wrote:
>>>> On 15/05/2017 08:20, Jan Beulich wrote:
>>>>> With this I think there's quite a bit of justification needed to keep
>>>>> going without M2P on ARM.
>>>>
>>>> As said in a previous thread, I made a quick calculation, ARM32 supports
>>>> up 40-bit PA and IPA (e.g guest address), which means 28-bits of
>>>> MFN/GFN. The GFN would have to be stored in a 32-bit for alignment, so
>>>> we would need 2^28 * 4 = 1GiB of virtual address space and potentially
>>>> physical memory. We don't have 1GB of VA space free on 32-bit right now.
>>>
>>> How come? You don't share address spaces with guests.
>>
>> Below the layout for ARM32:
>>
>>
>>   *   0  -  12M   <COMMON>
>>   *
>>   *  32M - 128M   Frametable: 24 bytes per page for 16GB of RAM
>>   * 256M -   1G   VMAP: ioremap and early_ioremap use this virtual address
>>   *                    space
>>   *
>>   *   1G -   2G   Xenheap: always-mapped memory
>>   *   2G -   4G   Domheap: on-demand-mapped
>
> Since Domheap hardly covers all memory, the obvious thing would
> seem to be to take part of that region, just like on x86 we also
> had to reduce the direct mapping area in order to support systems
> with more than 5Tb.
>
>>>> ARM64 currently supports up to 48-bit PA and 48-bit IPA, which means
>>>> 36-bits of MFN/GFN. The GFN would have to be stored in 64-bit for
>>>> alignment, so we would need 2^36 * 8 = 512GiB of virtual address space
>>>> and potentially physical memory. While virtual address space is not a
>>>> problem, the memory is a problem for embedded platform. We want Xen to
>>>> be as lean as possible.
>>>
>>> You don't need to allocate all 512Gb, the table can be as sparse as
>>> present memory permits.
>>
>> I am aware about that... The main point is reducing the footprint of
>> Xen. Assuming you have a 8GB board, you would have to use 16MB for the M2P.
>>
>> Likely this will increase the footprint of Xen ARM. For what benefits?
>> Avoiding to store few byte in a non-generic way when we need it...
>
> But that's the point: Generic code becomes more and more clumsy
> if non-generic mechanisms need to be introduced. Quite a few we've
> had the discussion of saving a few Mb here or there, and I've almost
> always been the one to ask for not wasting memory even if we have
> plenty, so I'm all with you on that aspect. Nevertheless there is a
> point where the trade-off between memory overhead and generic
> (i.e. easier to maintain) code crosses a boundary, and I'm simply
> wondering whether we aren't at that point.

Is the lack of M2P support on ARM a blocker for this patch to be accepted?
This patch I think is only prevents us from possible bugs in a future.
Please correct me if I am wrong.

>
> Jan
>



-- 
Regards,

Oleksandr Tyshchenko

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel