Re: [PATCH] x86/pv: limit GDT and LDT mappings areas to max number of vCPUs

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Thu, Nov 21, 2024 at 05:03:21PM +0100, Jan Beulich wrote:
> On 21.11.2024 16:56, Roger Pau Monné wrote:
> > On Thu, Nov 21, 2024 at 12:12:18PM +0100, Roger Pau Monne wrote:
> >> The allocation of the paging structures in the per-domain area for mapping 
> >> the
> >> guest GDT and LDT can be limited to the maximum number of vCPUs the guest 
> >> can
> >> have.  The maximum number of vCPUs is available at domain creation since 
> >> commit
> >> 4737fa52ce86.
> >>
> >> Limiting to the actual number of vCPUs avoids wasting memory for paging
> >> structures that will never be used.  Current logic unconditionally uses 513
> >> pages, one page for the L3, plus 512 L1 pages.
> > 
> > This is not true, I was confused with the logic in
> > create_perdomain_mapping().  When create_perdomain_mapping() is called
> > with pl1tab == NULL and ppg == NULL it just allocates the L2, but not
> > the L1 tables.
> > 
> > So the purpose of the create_perdomain_mapping(d, GDT_LDT_VIRT_START,
> > ...) in pv_domain_initialise() is even more dubious now - as it just
> > allocates a page to use as L2.  I'm tempted to just remove it if you
> > agree, since I don't consider this useful.  The allocation will
> > already be done at vCPU initialization.
> 
> If it's done implicitly there, removing is likely fine. It feels like it may
> have been necessary to do this explicitly earlier on.

Possibly before you introduced the create_perdomain_mapping() the
initialization and allocation of the L2 was needed in
pv_domain_initialise().

I have a patch to remove it, and as expected nothing seems to explode,
so I will send it.

Thanks, Roger.