On 24.07.2025 17:59, Aidan Allen wrote:
> On Thu, Jul 24, 2025 at 12:52 PM Jan Beulich <jbeul...@suse.com> wrote:
>> On 24.07.2025 13:40, Aidan Allen wrote:
>>> --- a/xen/arch/x86/domain.c
>>> +++ b/xen/arch/x86/domain.c
>>> @@ -253,6 +253,10 @@ void dump_pageframe_info(struct domain *d)
>>> page->count_info, page->u.inuse.type_info);
>>> }
>>>
>>> + printk(" Domain paging pool: total: %d, free: %d, p2m: %d\n",
>>> + d->arch.paging.total_pages, d->arch.paging.free_pages,
>>> + d->arch.paging.p2m_pages);
>>
>> Should this perhaps be gated, to avoid printing all zeroes for domains not
>> using an paging mode? Whether to use paging_mode_enabled() to do so I'm not
>> sure, as a domain with no paging mode enabled could still have a paging
>> pool configured.
>
> I can gate this on total_pages > 0 if that would address your concern
> with paging_mode_enabled().
>
> However, regarding the gating itself, I don't believe that the line
> saved by not printing this
> is worth the potential confusion of somebody looking for this
> information and not finding
> it, I would prefer to leave it printing all zeroes.
While I can see your point, I also have to state that already on earlier
additions to the (bulky) output I was concerned of the overall (and
long term) output size growth. Especially when transmitted over a slow
serial line, any shortening counts imo. Anyway, I'm not going to insist,
first and foremost because I expect I'm the only one with this concern.
Somewhat related: With HVM=n and SHADOW_PAGING=n, this output isn't
useful at all, even if non-zero values were logged. All non-zero values
would indicate then is that someone pointlessly set up a paging pool
for a domain.
Jan
