On 06/02/2024 10:08 am, Petr Beneš wrote: > From: Petr Beneš <w1be...@gmail.com> > > This commit introduces the ability to configure the maximum number of altp2m > and nestedp2m tables through boot-time parameters. Previously, the limits > were > hardcoded to a maximum of 10 for both. This change allows for greater > flexibility in environments that require more or fewer tables, enhancing Xen's > adaptability to different workloads and scenarios. > > Adjustments include: > - Adding boot parameters `max_altp2m` and `max_nestedp2m` to allow setting > these limits at boot time. > - Modifying various parts of the code to use these configurable limits instead > of the previous hardcoded values. > - Ensuring that if the configured values exceed the maximum supported EPTP > entries, they are adjusted down with a warning logged. > - Adjusting the initial allocation of pages in `hap_enable` from 256 to 2048 > pages when `old_pages == 0`. > > This change anticipates scenarios where `max_altp2m` and `max_nestedp2m` > are set to their maximum supported values (i.e., 512), ensuring sufficient > memory is allocated upfront to accommodate all altp2m and nestedp2m tables > without initialization failure. > > This enhancement is particularly relevant for users leveraging Xen's features > for virtual machine introspection or nested virtualization support. > > Signed-off-by: Petr Beneš <w1be...@gmail.com>
Thankyou for the patch. These fields should definitely be configurable. I realise you're copying existing examples, but they happen to be bad examples that we're trying to remove. It is erroneous to believe that there's one system-wide configuration that applies to all domains, and this has been the source of too many bugs. Instead, they should be parameters to the domain create hypercall, so they can be chosen on a per-VM basis. e.g. for some introspection tasks you only want 1 view + 1 alt per vCPU, for usually only a single vCPU. On the other hand, for nested-virt, you really need a minimum of two per vCPU, and probably 4, and there's no architectural upper bound. See the series adding vmtrace= support, which is the last time I plumbed a number like this into the domain create hypercall. You will want to split the patch into a series. For each of option, you'll want one patch plumbing the new parameter into the hypercall (along with a suitable toolstack default, and sanity checking), and a separate patch to rearrange Xen to use the new dynamic size. ~Andrew
