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

Re: [PATCH] xen/arm: Sanity test specified domain's memory for being a multiple of a page size


  • To: "Orzel, Michal" <michal.orzel@xxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: "Alejandro Vallejo" <alejandro.garciavallejo@xxxxxxx>
  • Date: Fri, 09 Oct 2026 10:27:12 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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=IBAr+FGmNVov5kwYsJG0nmjFF6lCChS+ZKjKTew6/ME=; b=CJ1wacDjI2XKO7AvkA5MkmUXeX+EjKl9zwZnAw1TjCj4dQYzC3c7iq3Z6Fe0lCbiEIl6NIcCn0dkNTj/HnVqO0CLr3DfPexdNKqrJ/9J499PTSNWMU+hk6RgmKmcqNecxXQ1raYxrfVIhYRWupNrJDDr3BHmgI1vhDPUrBkcgdtUzb86rHhUClHRHCjVf/Fz625uRym4/K0w+7hAFWfT1IoOwOHhunZtIAGDOvAK7pgGg99elnOPiYWY4ZW1MaVtJZE+yzw7+8Ckqq1SGwRiS1R8OBrZg2m+L5IRr5smtl8dMPjD6oN1+6g0NJSo6aMwwE4DH7Xie41Q2wu5T0rqmQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=qJoZASVnfHiuQTvmLP7MmEhtFMgRRCiixJAZPsEP/U+apg5A9yAH6WIZAH4t4oXYoLjrVJJlmM6vqfH0rectj0qsO1yBhpgfM+m7/6Ay1cAbXkoand3P6jhP9Okxlam7ON3o3dIlMcVSdsQoHpb5QUucMAjSPQ7GSSdBcrcFJt+ujszZoAFGuULq7C53nk8+j0qIyHeYjr2HhHg7M9e++eHi6BO74QYNVaztPSjY3TMhwSAqPTCjRIp0cG5f56goKgYLomLN1uzQw8/zVG3cj8VMIKZMqvUr3oezVOElXzbRftNx+epDfCAJq8BQijI95NkVaa+64+mLjNj2X+F5tQ==
  • Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-Id:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
  • Authentication-results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com;
  • Cc: "Stefano Stabellini" <sstabellini@xxxxxxxxxx>, "Julien Grall" <julien@xxxxxxx>, "Bertrand Marquis" <bertrand.marquis@xxxxxxx>, "Volodymyr Babchuk" <Volodymyr_Babchuk@xxxxxxxx>, "Andrew Cooper" <andrew.cooper3@xxxxxxxxxx>, "Anthony PERARD" <anthony.perard@xxxxxxxxxx>, "Jan Beulich" <jbeulich@xxxxxxxx>, Roger Pau Monné <roger@xxxxxxxxxxxxxx>
  • Delivery-date: Fri, 09 Oct 2026 08:27:27 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Wed Oct 7, 2026 at 4:31 PM CEST, Orzel, Michal wrote:
>
>
> On 07-Oct-26 16:21, Alejandro Vallejo wrote:
> > On Wed Oct 7, 2026 at 4:11 PM CEST, Orzel, Michal wrote:
> >>
> >>
> >> On 07-Oct-26 15:40, Alejandro Vallejo wrote:
> >>> On Wed Oct 7, 2026 at 2:48 PM CEST, Michal Orzel wrote:
> >>>> We require memory to allocate for a domain as RAM to be a multiple of a
> >>>> page size. However, we neither document this nor sanity test. Specifying
> >>>> memory size that does not conform to this requirement fails the domain
> >>>> memory allocation in the non-obvious way that is difficult to parse for
> >>>> the user (printing over-allocation messages followed by the panic that 
> >>>> Xen
> >>>> could not allocate the requested amount of memory).
> >>>>
> >>>> While there, fix indentation from tabs to spaces for "memory" parameter 
> >>>> in
> >>>> booting.txt.
> >>>>
> >>>> Signed-off-by: Michal Orzel <michal.orzel@xxxxxxx>
> >>>> ---
> >>>>  docs/misc/arm/device-tree/booting.txt   | 4 ++--
> >>>>  docs/misc/xen-command-line.pandoc       | 5 +++--
> >>>>  xen/arch/arm/domain_build.c             | 6 ++++++
> >>>>  xen/common/device-tree/dom0less-build.c | 7 +++++++
> >>>>  4 files changed, 18 insertions(+), 4 deletions(-)
> >>>>
> >>>> diff --git a/docs/misc/arm/device-tree/booting.txt 
> >>>> b/docs/misc/arm/device-tree/booting.txt
> >>>> index bcb06bc796bf..7dfac2062a37 100644
> >>>> --- a/docs/misc/arm/device-tree/booting.txt
> >>>> +++ b/docs/misc/arm/device-tree/booting.txt
> >>>> @@ -155,8 +155,8 @@ with the following properties:
> >>>>  
> >>>>  - memory
> >>>>  
> >>>> -        A 64-bit integer specifying the amount of kilobytes of RAM to
> >>>> -    allocate to the guest.
> >>>> +    A 64-bit integer specifying the amount of kilobytes of RAM to
> >>>> +    allocate to the guest. Must be a multiple of 4KB (the page size).
> >>>
> >>> nit: s/KB/KiB
> >> Is it? I don't think it matters at all seeing the number of occurrences in 
> >> the code.
> >>
> >>>
> >>> But page size isn't always 4KiB on all ports. PowerPC has 64KiB pages.
> >>> IMO, 4KB shouldn't be here or elsewhere in documentation.
> >> This is Arm doc and on Arm we only support 4KB at the moment. User should 
> >> not
> >> need to dig into the code to check what is the page size. It's better imo 
> >> to
> >> give this information right away and change in the future when we add 
> >> support
> >> for 16 and 64KB pages on Arm.
> > 
> > This is already the only reference the other ports have for dom0less.
> > The document shouldn't be here since the movement of dom0less to common
> > code, but the side effect of it is that this no longer an arm-only 
> > reference.
> > 
> > I won't be annoying about moving the doc on this patch because that's a
> > separate matter, but not adding more easily avoidable debt seems
> > warranted.
> I don't quite understand your reasoning. If you worry about dom0less != Arm,
> then on that basis HAS_DOM0LESS is selected only for Arm and RISCV where
> PAGE_SIZE is 4KB. I don't think I'm introducing any doubt here. I can remove 
> the
> 4KB mentioning from the docs if you really insist but at least for me it's
> clearer for the user to know right away what's the requirement for the size.

It's a small adjustment to make the documentation truly generic. And
prevents the pgsz == 4KiB assumption from spreading further. Many docs
are spawned from copying other docs.

If you're so strongly against, that's fine; it's not incorrect today.
I still think the 4K should be gone, but if don't want to block the
patch on such silly things.

  Reviewed-by: Alejandro Vallejo <alejandro.garciavallejo@xxxxxxx>

Cheers,
Alejandro

>
> ~Michal




 


Rackspace

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