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

Re: [Xen-devel] [PATCH v8 8/8] xen/arm: map reserved-memory regions as normal memory in dom0

On 07/11/2018 12:18, Julien Grall wrote:
Hi Stefano,

On 07/11/2018 00:32, Stefano Stabellini wrote:
On Mon, 22 Oct 2018, Julien Grall wrote:

On 09/10/2018 00:37, Stefano Stabellini wrote:
reserved-memory regions should be mapped as normal memory.

This is already the case with p2m_mmio_direct_c. The hardware domain should
have full control on the resulting attributes via its stage-1 mappings. So
what's wrong with that p2m type?

Shared mappings are prevented for any types other than p2m_ram_rw, see
the p2m_is_ram checks in the implementation of XENMAPSPACE_gmfn_share.

This does not make any sense. This series is about mapping between any domain but dom0. So if you end-up to map the reserved-memory region in dom0, why are you using XENMAPSPACE_gmfn_share?

To clarify my question, what are you trying to achieve? Are you trying to share memory between Dom0 and a guest. Or are you trying to share memory between an external entity (i.e R* core/device) and the guest?

The alternative is to remove or extend the p2m_is_ram check at

p2m_ram_* means the page is managed by Xen and accounting will be done. Similarly XENMAPSPACE_gmfn_share will do accounting on the page mapped through that.

In the case of reserved-memory, we never handled them properly in Xen (see [1]).

There are 2 types of reserved-memory region: static and dynamic. The dynamic one are not a concerned as addressed are not specified in them.

In the case of static one, they are backed by a page in Xen because we didn't updated the code to carve them out from xenheap. This means that you are mapping those pages in Dom0, yet they may not be assigned to Dom0 and may get allocated for Xen internal use or to another domain.

As such, this patch is just a workaround to an already broken code. So the first step is fixing the brokenness of reserved-memory region. Then we can discuss whether this patch is relevant for any of your use case.


[1] https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg02674.html

  At the
moment, they get remapped as device memory because Xen doesn't know
better. Add an explicit check for it.

Signed-off-by: Stefano Stabellini <stefanos@xxxxxxxxxx>
   xen/arch/arm/domain_build.c | 7 +++++++
   1 file changed, 7 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index f552154..c7df4cf 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1307,6 +1307,13 @@ static int __init handle_node(struct domain *d,
struct kernel_info *kinfo,
                  "WARNING: Path %s is reserved, skip the node as we may
re-use the path.\n",
   +    /*
+     * reserved-memory ranges should be mapped as normal memory in the
+     * p2m.
+     */
+    if ( !strcmp(dt_node_name(node), "reserved-memory") )
+        p2mt = p2m_ram_rw;
       res = handle_device(d, node, p2mt);
       if ( res)
           return res;

Julien Grall

Julien Grall

Xen-devel mailing list



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