regression from -unstable c/s 21812:e382656e4dcc (noticed in 4.0.1)

regression from -unstable c/s 21812:e382656e4dcc (noticed in 4.0.1)

[Jan Beulich]

Keir,

without the use of dom0_mem= reserving sufficiently much memory,
this change causes a regression as the calculation of the Dom0
allocation doesn't account for the memory consumed by
iommu_dom0_init(). With enough memory in the system, this may
run Xen out of memory altogether, in particular preventing Dom0
from setting up its swiotlb (and pointing out lack of error handling,
as it's very unlikely for hd->platform_ops->dom0_init() to have
succeeded when afterwards there's not a single page left available).

To me it's not immediately clear what the best fix for this problem
is: Either there needs to be another hook into iommu code to
pre-calculate the memory needs, or the !strict case needs to be
handled earlier again (under [questionable] the assumption that
someone forcing strict mode will know to also pass a suitable
dom0_mem=).

Thanks, Jan

Re: regression from -unstable c/s 21812:e382656e4dcc (noticed in 4.0.1)

[Keir Fraser]

Yeah, this is in my todo list. It's kind of hard to know how much memory
iommu mappings will take before the (scattered) dom0 memory is actually
allocated. I'll probably just reserve enough memory to map all of host
memory with 4kB mappings if iommu_enabled. Good enough I think, many people
run with dom0_mem= anyway, and if not you can run dom0 with mem= to expand
the p2m map and then balloon up some more in the init scripts if there is
still available memory at that point. All quite plausible for a packaged up
distro to do.

 -- Keir

On 13/12/2010 09:18, "Jan Beulich" <JBeulich@novell.com> wrote:

> Keir,
> 
> without the use of dom0_mem= reserving sufficiently much memory,
> this change causes a regression as the calculation of the Dom0
> allocation doesn't account for the memory consumed by
> iommu_dom0_init(). With enough memory in the system, this may
> run Xen out of memory altogether, in particular preventing Dom0
> from setting up its swiotlb (and pointing out lack of error handling,
> as it's very unlikely for hd->platform_ops->dom0_init() to have
> succeeded when afterwards there's not a single page left available).
> 
> To me it's not immediately clear what the best fix for this problem
> is: Either there needs to be another hook into iommu code to
> pre-calculate the memory needs, or the !strict case needs to be
> handled earlier again (under [questionable] the assumption that
> someone forcing strict mode will know to also pass a suitable
> dom0_mem=).
> 
> Thanks, Jan
>