Re: [PATCH v2 2/2] x86/dom0: improve paging memory usage calculations

From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	andrei.semenov@bertin.fr, Wei Liu <wei.liu2@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v2 2/2] x86/dom0: improve paging memory usage calculations
Date: Wed, 12 Dec 2018 11:16:48 +0100	[thread overview]
Message-ID: <20181212101648.fqww462x7jiwsjpp@mac> (raw)
In-Reply-To: <5C10DC0E020000780020561B@prv1-mh.provo.novell.com>

On Wed, Dec 12, 2018 at 02:59:42AM -0700, Jan Beulich wrote:
> >>> On 12.12.18 at 10:37, <roger.pau@citrix.com> wrote:
> > OK, I will iterate over all the devices in order to size the BARs, and
> > then add the sum of BARs MMIO regions to the amount of guest memory,
> > so that each 1MB of BAR MMIO will require 1 page for the p2m.
> 
> Don't you construct a rangeset for all of the BARs already
> anyway? For ones which have an address assigned and are
> enabled, also taking the address into account would seem
> desirable, as then you could do with less than double over-
> estimating (in the common case) the amount of space needed.

That's a chicken and egg problem, the current accounting of BAR sizes
is done in init_bars, which will also setup the identity p2m
mappings, so the call to paging_set_allocation (and thus the amount of
memory required by the p2m) needs to happen before mapping any BARs.

> > Note that ATM I will not account for VF BARs.
> 
> Hmm, yes, this is perhaps indeed too much to ask for at this
> point. But ultimately we need a clean approach there too.

Well, since there's no support for SR-IOV for PVH Dom0 ATM I guess I
could add this once it's supported. It's not overly complicated, at
the end is just BAR sizings at a different position in the config
space.

> > OK, so for shadow we also need to account for the IOMMU page table
> > size, which is not done now AFAICT.
> 
> As said (or perhaps implied) in the other reply, the calculation
> there may imply half of the space for the IOMMU, but it may
> also mean the other half to be for higher level tables on the
> CPU side. It's all guesswork without suitable comments.

My guess was that the other half of the space was supposed to be used
by higher level tables, and that the accounting for IOMMU page tables
is completely missing. Note that on PV there's no accounting for IOMMU
page tables either AFAICT.

There are also further issues that I wanted to discuss in a separate
thread, what about foreign mappings? Dom0 will likely map a non
trivial amount of grants and foreign mappings, which will also require
p2m/IOMMU page table entries.

Should we maybe size Dom0 p2m/iommu internal paging structures to be
able to map up to max_page at least?

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel