[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 2/2] x86/dom0: improve paging memory usage calculations
On Wed, Dec 12, 2018 at 02:59:42AM -0700, Jan Beulich wrote: > >>> On 12.12.18 at 10:37, <roger.pau@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |