Re: xl dmesg buffer too small for Xen 4.18?

[Julien Grall <julien@xxxxxxx>]

Hi Roger,

On 19/09/2023 17:10, Roger Pau Monné wrote:
> On Tue, Sep 19, 2023 at 06:00:32PM +0200, Jan Beulich wrote:
> > On 19.09.2023 17:56, Julien Grall wrote:
> > > On 19/09/2023 16:09, Chuck Zmudzinski wrote:
> > > > On 9/19/2023 8:10 AM, Julien Grall wrote:
> > > > > On 19/09/2023 08:02, Roger Pau Monné wrote:
> > > > > > On Mon, Sep 18, 2023 at 07:49:26PM +0100, Julien Grall wrote:
> > > > > > > (+Roger and moving to xen-devel)
> > > > > > > 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.
> > > > > > > Thanks for the report. This remind me the series [1] from Roger which tries
> > > > > > > to increase the default size to 32K. @Roger, I am wondering if we should
> > > > > > > revive it?
> > > > > > I think the relevant patch (2/2) will still apply as-is, it's just a
> > > > > > Kconfig one line change.  I'm however thinking it might be better to
> > > > > > bump it even further, to 128K.  From a system point of view it's still
> > > > > > a very small amount of memory.
> > > > > I don't have a strong opinion about 128K vs 32K.
> > > > I am sure 32k will be big enough on my system, and based on Jan's comment
> > > > about release builds being less verbose, the current default of 16k may
> > > > still work on my system once the release is out.
> > > I think it is quite (actually more) important to capture all the logs
> > > even in non-release build. So it would makes sense to increase the
> > > buffer to 32KB.
> > >
> > > An alternative option would be to have a different limit for debug and
> > > production build. Not sure what the others thinks.
> > I would certainly like a two-way default better than the uniform bumping
> > to 128k.
> It's not just the output from Xen that goes into such buffer, but also
> the output from dom0.  Hence making the decision based on Xen release
> vs debug builds doesn't seem reliable to me.
Fair point. It seems to me you want to have a size that cover pretty 
much everyone. Which is fine, but may have unintented impact on user 
that want to reduce the footprint of Xen.
> Again 128K is a trivial amount of memory on current systems
I am not sure I would call it trivial. For Arm, this is about 12% of the 
size of Xen (currently about 1MB). Right now, I am not aware of users 
that may try to have a very slim down Xen. But I wouldn't suprised if 
this will come up in the future and therefore reserving 128K for the 
console may not be desirable.
Admittly those users would likely try to tailor Xen. So a bigger default 
would not matter. But this is showing that there are conflicting 
requirements and we need to find a middle ground.
> , I'm quite
> sure 32K is already not enough on some of the systems I test with, but
> anyway.  Feel free to pick and adjust the patch to 32K if that's the
> only option, in any case it's better than the current default of 16K.
Jan seems to be more happy with 32K. So I will adjust the patch to 32K. 
We can refine it if we notice that this is not sufficient for most of 
the systems.
Cheers,

---
Julien Grall