[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v4 25/25] xen/riscv: add initial dom0less infrastructure support
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>
- Date: Thu, 2 Jul 2026 11:48:08 +0200
- Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
- Cc: Romain Caritey <Romain.Caritey@xxxxxxxxxxxxx>, Baptiste Le Duc <baptiste.le-duc@xxxxxxxxxx>, Alistair Francis <alistair.francis@xxxxxxx>, Connor Davis <connojdavis@xxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Julien Grall <julien@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Thu, 02 Jul 2026 09:48:13 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 7/2/26 8:41 AM, Jan Beulich wrote:
On 01.07.2026 17:24, Oleksii Kurochko wrote:
On 6/30/26 9:28 AM, Jan Beulich wrote:
On 26.06.2026 17:46, Oleksii Kurochko wrote:
--- a/xen/arch/riscv/include/asm/guest-layout.h
+++ b/xen/arch/riscv/include/asm/guest-layout.h
@@ -32,4 +32,16 @@
#define GUEST_RAM_BANK_BASES { GUEST_RAM0_BASE, GUEST_RAM1_BASE }
#define GUEST_RAM_BANK_SIZES { GUEST_RAM0_SIZE, GUEST_RAM1_SIZE }
+/*
+ * The guest magic region holds Xen-reserved pages mapped into the guest's
+ * physical address space (shared info, grant table, etc.). The only real
+ * constraint is that the GUEST_MAGIC_SIZE-byte region must not overlap
+ * guest RAM (the GUEST_RAMx banks) or the emulated device regions defined
+ * above; the exact base is otherwise arbitrary. Here it is placed in the
+ * unused gap below GUEST_RAM0_BASE (0x80000000), but a hole after a RAM
+ * bank would work equally well.
+ */
+#define GUEST_MAGIC_BASE _UL(0x79000000)
+#define GUEST_MAGIC_SIZE _UL(0x01000000)
... while 16Mb may seem a lot, it feels pretty little for 64-bit guests.
Even in just Sv39 mode they have ample VA space to map a bigger region.
(As iirc indicated before, a static upper bound looks questionable to me
anyway.)
I think the comment should be updated as for grants will be separate region.
For all others, it looks like 16MB is more then enough. For example, Arm
has only 4 used pages (CONSOLE=0, XENSTORE=1, MEMACCESS=2, VUART=3).
Then the question goes the other way around: Why 16Mb? Won't e.g. 2Mb
suffice?
I don't see any technical reason to have 16 Mb on Arm, IMO it could be
shrunk to what you suggested (I will do that for RISC-V).
~ Oleksii
So will you be okay with reworking of the comment to:
/*
* The guest magic region holds the Xen-reserved pages mapped into the
* guest's physical address space. The only real constraint on
* GUEST_MAGIC_BASE/SIZE is that the region must not overlap guest RAM
* (the GUEST_RAMx banks) or the emulated device regions defined above;
* the exact base is otherwise arbitrary. Here it is placed in the
unused gap
* below GUEST_RAM0_BASE (0x80000000), but a hole after a RAM bank
would work
* equally well.
*/
And add to the commit message that:
```
A separate region for grant tables will be introduced at the same time
as the introduction of the grant table for RISC-V.
```
That's quite a bit better, yes.
Jan
|
