[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Hi, all.

On Wed, May 17, 2017 at 7:01 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> On 17.05.17 at 17:45, <olekstysh@xxxxxxxxx> wrote:
>> 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?
> Well, if the ARM maintainers insist on baking their own thing every
> time we'd use the M2P if it was there, I think I can't reasonably
> block this patch. Otoh I'd prefer to not see the non-x86-specific
> code move to x86/, so perhaps the whole patch wants
> re-structuring using either a manifest definition in the ARM headers
> or e.g. CONFIG_M2P (which x86 would select, but ARM wouldn't).
Jan, I am afraid but I didn't get what you meant here:
"manifest definition in the ARM headers"

Julien, Stefano what do you think in general?

>> This patch I think is only prevents us from possible bugs in a future.
>> Please correct me if I am wrong.
> Avoiding possible bugs in the future I didn't connect to this patch so
> far.
> Jan


Oleksandr Tyshchenko

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.