On Mon, 2022-05-02 at 07:17 -0700, Dave Hansen wrote: > On 5/1/22 22:59, Kai Huang wrote: > > On Fri, 2022-04-29 at 07:20 -0700, Dave Hansen wrote: > > How about adding below in the changelog: > > > > " > > However using alloc_contig_pages() to allocate large physically contiguous > > memory at runtime may fail. The larger the allocation, the more likely it is to > > fail. Due to the fragmentation, the kernel may need to move pages out of the > > to-be-allocated contiguous memory range but it may fail to move even the last > > stubborn page. A good way (although not foolproof) is to launch a TD VM early > > in boot to get PAMTs allocated before memory gets fragmented or consumed. > > " > > Better, although it's getting a bit off topic for this changelog. > > Just be short and sweet: > > 1. the allocation can fail > 2. Launch a VM early to (badly) mitigate this > 3. the only way to fix it is to add a boot option > OK. Thanks. > > > > > > > + /* > > > > > > + * One TDMR must cover at least one (or partial) RAM entry, > > > > > > + * otherwise it is kernel bug. WARN_ON() in this case. > > > > > > + */ > > > > > > + if (WARN_ON_ONCE((start >= end) || start >= TDMR_END(tdmr))) > > > > > > + return 0; > > > > > > This really means "no RAM found for this TDMR", right? Can we say that, > > > please. > > > > OK will add it. How about: > > > > /* > > * No RAM found for this TDMR. WARN() in this case, as it > > * cannot happen otherwise it is a kernel bug. > > */ > > The only useful information in that comment is the first sentence. The > jibberish about WARN() is patently obvious from the next two lines of code. > > *WHY* can't this happen? How might it have actually happened? When TDMRs are created, we already have made sure one TDMR must cover at least one or partial RAM entry. -- Thanks, -Kai
