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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Thu, 7 Oct 2021, Ian Jackson wrote:
> 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.
> 
> > 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".

That's fair enough, I understand your question a bit better now.

I am not certain whether x86 has the same issue. But if it does, I am
pretty sure both the strategy to address the problem and the code would
be very different. At the moment, I cannot imagine how we could share
anything in this patch with x86, especially given the difference in
firmware interfaces (ACPI vs DT).

But I could see a theoretical third architecture (RISC-V?) with device
tree support potentially making use of make_hypervisor_node. But then at
the libxl API I don't imagine the API would look different or would need
to change.