Re: [PATCH V5 2/3] libxl/arm: Add handling of extended regions for DomU

[Oleksandr <olekstysh@gmail.com>]

On 07.10.21 13:57, Ian Jackson wrote:

Hi Ian.

> Stefano Stabellini writes ("Re: [PATCH V5 2/3] libxl/arm: Add handling of extended regions for DomU"):
>> On Wed, 6 Oct 2021, Oleksandr wrote:
>>> On 06.10.21 14:34, Ian Jackson wrote:
>>>> Oleksandr Tyshchenko writes ("[PATCH V5 2/3] libxl/arm: Add handling of
>>>> extended regions for DomU"):
>>>>> The extended region (safe range) is a region of guest physical
>>>>> address space which is unused and could be safely used to create
>>>>> grant/foreign mappings instead of wasting real RAM pages from
>>>>> the domain memory for establishing these mappings.
>>>> Please forgive me for asking this question now, but: why is this
>>>> ARM-specific ?
>>>
>>> Sorry, I can't say for sure which x86 mode also suffers from
>>> that. I might be wrong, but as I understand that x86 in PVH (and
>>> HVM?) mode uses unpopulated memory ranges (which are unused from
>>> Linux PoV, actually everything not yet allocated or reserved from
>>> "iomem_resource") to create foreign/grant mappings.  So the real
>>> RAM pages are not ballooned out to get an physical address space
>>> to create these mappings. The problem is that we cannot follow
>>> Linux advise which memory ranges are unused on Arm for several
>>> reasons, this is why this patch series makes the hypervisor to
>>> start allocating and exposing these ranges.
> So it sounds like you are saying this is an ARM-specific problem ?
> The key being the "several reasons" which you mention.  Are they
> ARM-specifc problems.

Yes, you could say that. Below are reasons why we need the hypervisor to 
provide these ranges on Arm from my understanding.

[leaving aside hotplug case]

1. [Related to Dom0]  Dom0 is mapped 1:1 on Arm, but there might be some 
guest mapping, mapped identically in P2M (GFN == MFN) for PV drivers to 
work. So Xen has everything in hand to be able to choose extended 
regions (which won't clash with other resources).
2. [Related to every domain]  Not all device I/O regions might be known 
(registered) by the time the guest starts creating grant/foreign 
mappings, so guest cannot guess by itself what is really unused, but the 
entity which creates the domain (Xen, toolstack) knows these details in 
advance to be able to choose extended regions (which won't clash with 
other resources).


>
>> Two more things about this being ARM-specific.
>>
>> Even if x86 was affected exactly by the same problem, the code to expose
>> the safe memory ranges to DomU is arch-specific (currently device tree.)
>>
>> Also the code to calculate the safe memory ranges is arch-specific as it
>> depends on the DomU memory layout which is arch-specific.
> This demonstrates that the implementation is arch-specific.  But one
> of libxl's functions is to abstract away implementation details and
> provide an interface that can be used to "do the right thing".
>
> Ian.

-- 
Regards,

Oleksandr Tyshchenko