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

Re: [PATCH v2 1/4] xen/arm: Alloc hypervisor reserved pages as magic pages for Dom0less DomUs


  • To: Julien Grall <julien@xxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Henry Wang <xin.wang2@xxxxxxx>
  • Date: Mon, 13 May 2024 11:42:01 +0800
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=xen.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=gpVhZr3pJ/2KnxJu5+W/8YpRxSFTY/qNwTc7kC3HGOs=; b=V68Ml4Rgdg99TL+hEgzoH5DjxbvYJ5bFSdw+VSiJfaL7x+Bm60Z1ijaMyeivU2SG+D0w+UK+3x2tc25WBmqu4KIsB5VtrS5Xjv0ggeME4EJg/jJZqLn8MjpS1ONURhnd0MXX8TW2Ao/+CXUFy5b92WoEn6+X/UPS20qAqHo4LbOrMvF/hw3e8oC8vN+9u9NJ2yvvZu59/OXto/Ns5HRbZCORtD8NAPgIXxSBHV4dAgqKtE9sHzt9GEJj8QulYw+z6ledn8cfSKxGgbF6sVjnmmi4fHST/mRLUlJldVU1VXtGd3cAApyqP6wM/0qPBhY6CtM7LIZ5E0pLHsFkFj7JYw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CMySr3I2YBydBi7ozd2MjjHNtOfQm4n81gJYRRfWHZF6KKacl+UvjrZVk+xY1X11e1DbHCOVxO4we+Vs/lg5mlnuv5/UzK+8bciInx7X+IZxzDLfHKkogdvwOEbIbra94/HcbnzHKpMRzUFsv8YswdzSLo9tsF1mPn/bwEu1Gz/VpWWjaDPiKLzhtP6vVadYzM5dcF2560dpHk86RnVKnj31pNgIJYIoKI19LUs76InpaO5Hgz08+FyzikO5Pz0bWimcFyi4vudEuFqro4ZijH3FLzHTyFZEcq8dYfybmw6ec6YaMph7QTslTysbQGPNscqqL/ZfOgUnWQN3jk5NZg==
  • Cc: Anthony PERARD <anthony@xxxxxxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, "Volodymyr Babchuk" <Volodymyr_Babchuk@xxxxxxxx>, Alec Kwapis <alec.kwapis@xxxxxxxxxxxxx>, "Daniel P . Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 13 May 2024 03:42:37 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

Hi Julien,

On 5/11/2024 7:03 PM, Julien Grall wrote:
Hi Henry,

On 11/05/2024 01:56, Henry Wang wrote:
  +static int __init alloc_magic_pages(struct domain *d)
+{
+    struct page_info *magic_pg;
+    mfn_t mfn;
+    gfn_t gfn;
+    int rc;
+
+    d->max_pages += NR_MAGIC_PAGES;
+    magic_pg = alloc_domheap_pages(d, get_order_from_pages(NR_MAGIC_PAGES), 0);
+    if ( magic_pg == NULL )
+        return -ENOMEM;
+
+    mfn = page_to_mfn(magic_pg);
+    if ( !is_domain_direct_mapped(d) )
+        gfn = gaddr_to_gfn(GUEST_MAGIC_BASE);
+    else
+        gfn = gaddr_to_gfn(mfn_to_maddr(mfn));

Summarizing the discussion we had on Matrix. Regions like the extend area and shared memory may not be direct mapped. So unfortunately, I think it is possible that the GFN could clash with one of those.

At least in the shared memory case, the user can provide the address. But as you use the domheap allocator, the address returned could easily change if you tweak your setup.

I am not entirely sure what's the best solution. We could ask the user to provide the information for reserved region. But it feels like we are exposing a bit too much to the user.

So possibly we would want to use the same approach as extended regions. Once we processed all the mappings, find some space for the hypervisor regions.

One thing that I noticed when I re-visit the extended region finding code from the hypervisor side is: When the domain is direct-mapped, when we find extended region for the domain, we either use find_unallocated_memory() or find_memory_holes(). It looks like the removal of shared memory regions in both functions uses the paddr parsed from the device tree to remove the regions, which indicates there is an assumption that when a domain is direct-mapped, the shared memory should also be direct-mapped. I might be wrong, but otherwise I don't think the extended region finding logic will carve out the correct shared memory region gpaddr range for guests.

So I think we are missing the documentation (and the corresponding checking when we parse the device tree) for above assumption for the static shared memory, i.e., when the domain is direct-mapped, the static shared memory should also be direct-mapped, and user should make sure this is satisfied in the device tree otherwise Xen should complain.

If we add this assumption and related checking code, I think your concern of clashing with static shared memory can be addressed. Do you agree?

Kind regards,
Henry


Any other suggestions?

Cheers,





 


Rackspace

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