On 18.09.2023 20:49, Julien Grall wrote: > On 18/09/2023 19:17, Chuck Zmudzinski wrote: >> On 9/18/2023 9:00 AM, Chuck Zmudzinski wrote: >>> I tested Xen 4.18~rc0 on Alma Linux 9 and my first tests indicate it works >>> fine for starting the guests I manage but I notice that immediately after >>> boot and with only dom0 running on the system, I get: >>> >>> [user@Malmalinux ~]$ sudo xl dmesg >>> 00bee72000-00000bee72fff type=7 attr=000000000000000f >>> (XEN) 00000bee73000-00000bef49fff type=4 attr=000000000000000f >>> (XEN) 00000bef4a000-00000bef4bfff type=7 attr=000000000000000f >>> (XEN) 00000bef4c000-00000befbafff type=4 attr=000000000000000f >>> (XEN) 00000befbb000-00000befbbfff type=7 attr=000000000000000f >>> ... >>> >>> I have noticed the buffer fills up quickly on earlier Xen versions, but >>> never have I seen it fill up during boot and with only dom0 running. >>> >>> Can increasing the buffer fix this? How would one do that? >>> >>> Thanks >>> >> >> I see the setting is the command line option conring_size: >> >> https://xenbits.xen.org/docs/unstable/misc/xen-command-line.html#conring_size >> >> The default is 16k, I tried 48k and that was big enough to capture all the >> messages at boot for 4.18 rc0. This is probably not an issue if the release >> candidate is being more verbose than the actual release will be. But if the >> release is still this verbose, maybe the default of 16k should be increased.
Just to mention it: Log-level defaults are different for debug and release builds, which means release builds are typically less verbose. Jan
