Re: [Xen-devel] [PATCH v2 10/10] xen/arm: add reserved-memory regions to the dom0 memory node

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Tue, 7 May 2019, Julien Grall wrote:
> Hi Stefano,
> 
> On 4/30/19 10:02 PM, Stefano Stabellini wrote:
> > Reserved memory regions are automatically remapped to dom0. Their device
> > tree nodes are also added to dom0 device tree. However, the dom0 memory
> > node is not currently extended to cover the reserved memory regions
> > ranges as required by the spec.  This commit fixes it.
> 
> AFAICT, this does not cover the problem mention by Amit in [1].

What do you think is required to fix Amit's problem?


> But I am still not happy with the approach taken for the reserved-memory
> regions in this series. As I pointed out before, they are just normal memory
> that was reserved for other purpose (CMA, framebuffer...).
> 
> Treating them as "device" from Xen POV is a clear abuse of the meaning and I
> don't believe it is a viable solution long term.

If we don't consider "reusable" memory regions as part of the
discussion, the distinction becomes more philosophical than practical:

- Xen is not supposed to use them for anything
- only given them to the VM configured for it

I don't see much of a difference with MMIO regions, except for the
expected pagetable attributes: i.e. cacheable, not-cacheable. But even
in that case, there could be reasonable use cases for non-cacheable
mappings of reserved-memory regions, even if reserved-memory regions are
"normal" memory.

Could you please help me understand why you see them so differently, as
far as to say that "treating them as "device" from Xen POV is a clear
abuse of the meaning"?


> Indeed, some of the regions may have a property "reusable" allowing the the OS
> to use them until they are claimed by the device driver owning the region. I
> don't know how Linux (or any other OS) is using it today, but I don't see what
> would prevent it to use them as hypercall buffer. This would obviously not
> work because they are not actual RAM from Xen POV.

I haven't attempted at handling "reusable" reserved-memory regions
because I don't have a test environment and/or a use-case for them. In
other words, I don't have any "reusable" reserved-memory regions in any
of the boards (Xilinx and not Xilinx) I have access to. I could add a
warning if we find a "reusable" reserved-memory region at boot.

Nonetheless, if you have a concrete suggestion which doesn't require a
complete rework of this series, I can try to put extra effort to handle
this case even if it is not a benefit to my employer. I am also open to
the possibility of dropping patches 6-10 from the series.

There is also the option of going to devicetree.org to request a new
binding different from reserved-memory. If reserved-memory regions are
expected to be treated as normal memory for all intents and purposes
except for being reserved sometimes, then they might not be the right
bindings to describe Xilinx hardware, which requires fully dedicated
memory regions with both cacheable and non-cacheable mappings for the
purpose of communicating with foreign CPUs.

As a maintainer, even if the approach might considered not-ideal, my
opinion is that this series is still an improvement over what we have
today.


> On a similar topic, because they are normal memory, I don't think
> XEN_DOMCTL_memory_mapping should be able to map reserved-regions. So the iomem
> rangeset should not contain them.

What hypercall do you suggest should be used instead?


> Cheers,
> 
> [1] <CABHD4K-z-x=3joJWcOb_x9m7zsjzhskDQweNBr+paLS=PFEY9Q@xxxxxxxxxxxxxx>
> 
> -- 
> Julien Grall
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel