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

Re: [PATCH] xen/common: Do not allocate magic pages 1:1 for direct mapped domains


  • To: Michal Orzel <michal.orzel@xxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Henry Wang <xin.wang2@xxxxxxx>
  • Date: Tue, 27 Feb 2024 21:27:27 +0800
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0)
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=7fG32DN/8O+e4OkIL0FSBLZGXZRyL1cyzCIz9t1QoEI=; b=cpqgITKuYRJKWCFU0MKAFUg4koIOkp7hU2Z1xfxG5GUyV+N51p20Hj24HNE8dtMXfvNufoHCzAURPQ884IThZ+3pP0gJAiWf0ND6ikg1Y2IffdqhU2P7PSy8PMMVZL2XkGUp8wNiJBo/hD2L7zClgFP2gD48/G+6MvKqYTy+xxpLowLf2+18wMNU0aN7g5a3O9T2GrNLfMsXkyPN/bzvwXD6+MzrKU9QVTKbgp7+M5DLpMQVET5yVDQIOdRnSR+VeesL0+5IZzJD9u6O5f9Fhj9/y8ZgNsIzDsfVPILZ9+DeLI7RfadPdzdVfjr8e409Rdwb5TbBwTSdjkczLHSfVg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ilBTWxFnGU2PV0RgxG/LfsGp3Gr7LHnLdMcXAI+abyI4Z/13deZjwvpmrrjSr7gGM6lEgi1kj53gjn9vgRnhqM6hnbycgVXJQEuOZVaXSlvYgfVALOM5Mo02s1iY+l2F2S1Zl+/mrIwEhwa8UAblFbMdAdMQINcDWWGGS1HRkjMYmYv5XtXQdVu40d7c7P4/YpNVfN1rSeoPa7MrZ0AMapwFCOpIZXRkc+UE58c+1Tte1oZjKvKLWnNCoyHSsP48wGEOyFPZZ8XVwpwuIYULn7i5ZRoXJKoXWzszeyMurFIZ+gASMLufPkR1V2NSN1NwQIuSWAfDS2cQbuplFFTPSg==
  • Cc: Anthony PERARD <anthony.perard@xxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, "Bertrand Marquis" <bertrand.marquis@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Alec Kwapis <alec.kwapis@xxxxxxxxxxxxx>
  • Delivery-date: Tue, 27 Feb 2024 13:27:39 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

Hi Michal,

On 2/26/2024 6:29 PM, Michal Orzel wrote:
Hi Henry,

On 26/02/2024 02:19, Henry Wang wrote:
An error message can seen from the init-dom0less application on
direct-mapped 1:1 domains:
```
Allocating magic pages
memory.c:238:d0v0 mfn 0x39000 doesn't belong to d1
Error on alloc magic pages
```

This is because populate_physmap() automatically assumes gfn == mfn
for direct mapped domains. This cannot be true for the magic pages
that are allocated later for Dom0less DomUs from the init-dom0less
helper application executed in Dom0.

Force populate_physmap to take the "normal" memory allocation route for
the magic pages even for 1:1 Dom0less DomUs. This should work as long
as the 1:1 Dom0less DomU doesn't have anything else mapped at the same
guest address as the magic pages:
- gfn 0x39000 address 0x39000000
- gfn 0x39001 address 0x39001000
- gfn 0x39002 address 0x39002000
- gfn 0x39003 address 0x39003000
Create helper is_magic_gpfn() for Arm to assist this and stub helpers
for non-Arm architectures to avoid #ifdef. Move the definition of the
magic pages on Arm to a more common place.

Note that the init-dom0less application of the diffenent Xen version
may allocate all or part of four magic pages for each DomU.

Reported-by: Alec Kwapis <alec.kwapis@xxxxxxxxxxxxx>
Signed-off-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>
Signed-off-by: Henry Wang <xin.wang2@xxxxxxx>
NIT: Generally, the first SOB is the same as author of the patch.

I will fix in the next version. Thanks.

[...]
diff --git a/xen/common/memory.c b/xen/common/memory.c
index b3b05c2ec0..ab4bad79e2 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -219,7 +219,7 @@ static void populate_physmap(struct memop_args *a)
          }
          else
          {
-            if ( is_domain_direct_mapped(d) )
+            if ( is_domain_direct_mapped(d) && !is_magic_gpfn(gpfn) )
I struggle to understand the goal of this patch and the proposed solution.
The problem with magic pages applies to static mem domUs in general.
A direct mapped domU is a static mem domU whose memory is 1:1 mapped.
Let's say we try to map a magic page for a direct mapped domU. That check will 
be false
and the execution will move to the next one i.e. is_domain_using_staticmem(d).
This check will be true and acquire_reserved_page() will fail instead (similar 
to the
static mem (no direct map) scenario). The only thing that has changed is the 
message.

Yes you are definitely correct, I missed the check for static mem domains. Will fix in v2 once the proposal in the other thread is agreed. Thanks for spotting this issue!

Kind regards,
Henry

~Michal




 


Rackspace

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