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 >>>>> + /* >>>>> + * 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?
