docs/misc/xen-command-line.pandoc | 5 ++++- xen/drivers/char/Kconfig | 12 ++++++++++++ xen/drivers/char/console.c | 6 +++--- 3 files changed, 19 insertions(+), 4 deletions(-)
Add new CONRING_SIZE Kconfig parameter to specify the boot console buffer size
in bytes. The value is rounded to the nearest power of 2 to match existing
conring_size= behavior.
The supported range is [16KiB..128MiB].
Bump default size to 32 KiB.
Link: https://gitlab.com/xen-project/xen/-/issues/185
Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
Link to the original change:
- https://lore.kernel.org/xen-devel/20250103-vuart-ns8250-v3-v1-15-c5d36b31d66c@ford.com/
---
docs/misc/xen-command-line.pandoc | 5 ++++-
xen/drivers/char/Kconfig | 12 ++++++++++++
xen/drivers/char/console.c | 6 +++---
3 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index 9bbd00baef..563cdbdd49 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -425,10 +425,13 @@ The following are examples of correct specifications:
### conring_size
> `= <size>`
-> Default: `conring_size=16k`
+> Default: `conring_size=32k`
Specify the size of the console ring buffer.
+The console ring buffer size can be selected at build time via
+CONFIG_CONRING_SIZE.
+
### console
> `= List of [ vga | com1[H,L] | com2[H,L] | pv | dbgp | ehci | xhci | none ]`
diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
index e6e12bb413..54a3a79da3 100644
--- a/xen/drivers/char/Kconfig
+++ b/xen/drivers/char/Kconfig
@@ -96,6 +96,18 @@ config SERIAL_TX_BUFSIZE
Default value is 32768 (32KiB).
+config CONRING_SIZE
+ int "Console buffer size"
+ default 32768
+ range 16384 134217728
+ help
+ Select the boot console buffer size (in bytes).
+ Note, the value provided will be rounded down to the nearest power of 2.
+ Run-time console buffer size is the same as the boot console size,
+ unless overridden via 'conring_size=' boot parameter.
+
+ Default value is 32768 (32KiB).
+
config XHCI
bool "XHCI DbC UART driver"
depends on X86
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index ee5f720de4..73d24a7821 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -101,12 +101,12 @@ static int cf_check parse_console_timestamps(const char *s);
custom_runtime_param("console_timestamps", parse_console_timestamps,
con_timestamp_mode_upd);
-/* conring_size: allows a large console ring than default (16kB). */
+/* conring_size: override build-time CONRING_SIZE setting. */
static uint32_t __initdata opt_conring_size;
size_param("conring_size", opt_conring_size);
-#define _CONRING_SIZE 16384
-#define CONRING_IDX_MASK(i) ((i)&(conring_size-1))
+#define _CONRING_SIZE (1UL << (31 - __builtin_clz(CONFIG_CONRING_SIZE)))
+#define CONRING_IDX_MASK(i) ((i) & (conring_size - 1))
static char __initdata _conring[_CONRING_SIZE];
static char *__read_mostly conring = _conring;
static uint32_t __read_mostly conring_size = _CONRING_SIZE;
--
2.34.1On 12.02.2025 23:31, dmkhn@proton.me wrote: > --- a/xen/drivers/char/Kconfig > +++ b/xen/drivers/char/Kconfig > @@ -96,6 +96,18 @@ config SERIAL_TX_BUFSIZE > > Default value is 32768 (32KiB). > > +config CONRING_SIZE > + int "Console buffer size" > + default 32768 > + range 16384 134217728 > + help > + Select the boot console buffer size (in bytes). Why in bytes when ... > + Note, the value provided will be rounded down to the nearest power of 2. ... this rounding is done anyway? Why have people type in complicated numbers? A granularity of 1k would already be an improvement; yet better would be if this was a power-of-two value altogether. Jan
On Tuesday, February 18th, 2025 at 8:05 AM, Jan Beulich <jbeulich@suse.com> wrote: > > > On 12.02.2025 23:31, dmkhn@proton.me wrote: > > > --- a/xen/drivers/char/Kconfig > > +++ b/xen/drivers/char/Kconfig > > @@ -96,6 +96,18 @@ config SERIAL_TX_BUFSIZE > > > > Default value is 32768 (32KiB). > > > > +config CONRING_SIZE > > + int "Console buffer size" > > + default 32768 > > + range 16384 134217728 > > + help > > + Select the boot console buffer size (in bytes). > > > Why in bytes when ... > > > + Note, the value provided will be rounded down to the nearest power of 2. > > > ... this rounding is done anyway? Why have people type in complicated numbers? > A granularity of 1k would already be an improvement; yet better would be if > this was a power-of-two value altogether. My understanding that the semantics of new CONFIG_CONRING_SIZE build-time setting should be consistent with existing boot-time conring_size= behavior (string value converted to number of bytes). I can update both to round up to 1k boundary. I also agree that having power of 2s for both (e.g. similar to Linux'es CONFIG_LOG_BUF_SHIFT) will be the simplest (implementation) and non-ambigous. I had it done earlier: https://lore.kernel.org/xen-devel/20241205-vuart-ns8250-v1-26-e9aa923127eb@ford.com/ Also, since there's a build-time configuration parameter along with the boot-time configuration, perhaps it makes sense to retire boot-time setting in favor of build-time setting? > > Jan
On 21.02.2025 21:52, Denis Mukhin wrote: > On Tuesday, February 18th, 2025 at 8:05 AM, Jan Beulich <jbeulich@suse.com> wrote: >> On 12.02.2025 23:31, dmkhn@proton.me wrote: >>> --- a/xen/drivers/char/Kconfig >>> +++ b/xen/drivers/char/Kconfig >>> @@ -96,6 +96,18 @@ config SERIAL_TX_BUFSIZE >>> >>> Default value is 32768 (32KiB). >>> >>> +config CONRING_SIZE >>> + int "Console buffer size" >>> + default 32768 >>> + range 16384 134217728 >>> + help >>> + Select the boot console buffer size (in bytes). >> >> >> Why in bytes when ... >> >>> + Note, the value provided will be rounded down to the nearest power of 2. >> >> >> ... this rounding is done anyway? Why have people type in complicated numbers? >> A granularity of 1k would already be an improvement; yet better would be if >> this was a power-of-two value altogether. > > My understanding that the semantics of new CONFIG_CONRING_SIZE build-time setting > should be consistent with existing boot-time conring_size= behavior (string value > converted to number of bytes). > > I can update both to round up to 1k boundary. > > I also agree that having power of 2s for both (e.g. similar to Linux'es CONFIG_LOG_BUF_SHIFT) > will be the simplest (implementation) and non-ambigous. > I had it done earlier: > https://lore.kernel.org/xen-devel/20241205-vuart-ns8250-v1-26-e9aa923127eb@ford.com/ I'd prefer the power-of-2 approach, yet I could live with the Kb-based one as was suggested by Roger. > Also, since there's a build-time configuration parameter along with the boot-time > configuration, perhaps it makes sense to retire boot-time setting in favor of > build-time setting? Why would that be? Build-time settings can only ever be defaults. We don't know what people need in their configurations. Jan
On Monday, February 24th, 2025 at 2:44 AM, Jan Beulich <jbeulich@suse.com> wrote: > > > On 21.02.2025 21:52, Denis Mukhin wrote: > > > On Tuesday, February 18th, 2025 at 8:05 AM, Jan Beulich jbeulich@suse.com wrote: > > > > > On 12.02.2025 23:31, dmkhn@proton.me wrote: > > > > > > > --- a/xen/drivers/char/Kconfig > > > > +++ b/xen/drivers/char/Kconfig > > > > @@ -96,6 +96,18 @@ config SERIAL_TX_BUFSIZE > > > > > > > > Default value is 32768 (32KiB). > > > > > > > > +config CONRING_SIZE > > > > + int "Console buffer size" > > > > + default 32768 > > > > + range 16384 134217728 > > > > + help > > > > + Select the boot console buffer size (in bytes). > > > > > > Why in bytes when ... > > > > > > > + Note, the value provided will be rounded down to the nearest power of 2. > > > > > > ... this rounding is done anyway? Why have people type in complicated numbers? > > > A granularity of 1k would already be an improvement; yet better would be if > > > this was a power-of-two value altogether. > > > > My understanding that the semantics of new CONFIG_CONRING_SIZE build-time setting > > should be consistent with existing boot-time conring_size= behavior (string value > > converted to number of bytes). > > > > I can update both to round up to 1k boundary. > > > > I also agree that having power of 2s for both (e.g. similar to Linux'es CONFIG_LOG_BUF_SHIFT) > > will be the simplest (implementation) and non-ambigous. > > I had it done earlier: > > https://lore.kernel.org/xen-devel/20241205-vuart-ns8250-v1-26-e9aa923127eb@ford.com/ > > > I'd prefer the power-of-2 approach, yet I could live with the Kb-based one as > was suggested by Roger. Reworked to power of 2. > > > Also, since there's a build-time configuration parameter along with the boot-time > > configuration, perhaps it makes sense to retire boot-time setting in favor of > > build-time setting? > > > Why would that be? Build-time settings can only ever be defaults. We don't > know what people need in their configurations. > > Jan
On Monday, February 24th, 2025 at 2:44 AM, Jan Beulich <jbeulich@suse.com> wrote: > > > On 21.02.2025 21:52, Denis Mukhin wrote: > > > On Tuesday, February 18th, 2025 at 8:05 AM, Jan Beulich jbeulich@suse.com wrote: > > > > > On 12.02.2025 23:31, dmkhn@proton.me wrote: > > > > > > > --- a/xen/drivers/char/Kconfig > > > > +++ b/xen/drivers/char/Kconfig > > > > @@ -96,6 +96,18 @@ config SERIAL_TX_BUFSIZE > > > > > > > > Default value is 32768 (32KiB). > > > > > > > > +config CONRING_SIZE > > > > + int "Console buffer size" > > > > + default 32768 > > > > + range 16384 134217728 > > > > + help > > > > + Select the boot console buffer size (in bytes). > > > > > > Why in bytes when ... > > > > > > > + Note, the value provided will be rounded down to the nearest power of 2. > > > > > > ... this rounding is done anyway? Why have people type in complicated numbers? > > > A granularity of 1k would already be an improvement; yet better would be if > > > this was a power-of-two value altogether. > > > > My understanding that the semantics of new CONFIG_CONRING_SIZE build-time setting > > should be consistent with existing boot-time conring_size= behavior (string value > > converted to number of bytes). > > > > I can update both to round up to 1k boundary. > > > > I also agree that having power of 2s for both (e.g. similar to Linux'es CONFIG_LOG_BUF_SHIFT) > > will be the simplest (implementation) and non-ambigous. > > I had it done earlier: > > https://lore.kernel.org/xen-devel/20241205-vuart-ns8250-v1-26-e9aa923127eb@ford.com/ > > > I'd prefer the power-of-2 approach, yet I could live with the Kb-based one as > was suggested by Roger. Just to double check: I think it makes sense to switch both build-time and run-time settings to use the same size calculation algorithm (e.g. Kb-based) to avoid confusion during building hypervisor configuration. Will that be OK to do such change? > > > Also, since there's a build-time configuration parameter along with the boot-time > > configuration, perhaps it makes sense to retire boot-time setting in favor of > > build-time setting? > > > Why would that be? Build-time settings can only ever be defaults. We don't > know what people need in their configurations. I was thinking about few reasons. In embedded setup run-time settings are unlikely to change, it is mostly built-time configuration. On a server setup, bumping the size of console buffer morelikely means some debugging, which to me means new xen binary can be re-generated and re-deployed. Also, having dynamically configured options will add some extra burden for the follow-on cert work. I will keep both, just want to make sure that both settings are preferred. > > Jan
On 25.02.2025 03:45, Denis Mukhin wrote:
> On Monday, February 24th, 2025 at 2:44 AM, Jan Beulich <jbeulich@suse.com> wrote:
>
>>
>>
>> On 21.02.2025 21:52, Denis Mukhin wrote:
>>
>>> On Tuesday, February 18th, 2025 at 8:05 AM, Jan Beulich jbeulich@suse.com wrote:
>>>
>>>> On 12.02.2025 23:31, dmkhn@proton.me wrote:
>>>>
>>>>> --- a/xen/drivers/char/Kconfig
>>>>> +++ b/xen/drivers/char/Kconfig
>>>>> @@ -96,6 +96,18 @@ config SERIAL_TX_BUFSIZE
>>>>>
>>>>> Default value is 32768 (32KiB).
>>>>>
>>>>> +config CONRING_SIZE
>>>>> + int "Console buffer size"
>>>>> + default 32768
>>>>> + range 16384 134217728
>>>>> + help
>>>>> + Select the boot console buffer size (in bytes).
>>>>
>>>> Why in bytes when ...
>>>>
>>>>> + Note, the value provided will be rounded down to the nearest power of 2.
>>>>
>>>> ... this rounding is done anyway? Why have people type in complicated numbers?
>>>> A granularity of 1k would already be an improvement; yet better would be if
>>>> this was a power-of-two value altogether.
>>>
>>> My understanding that the semantics of new CONFIG_CONRING_SIZE build-time setting
>>> should be consistent with existing boot-time conring_size= behavior (string value
>>> converted to number of bytes).
>>>
>>> I can update both to round up to 1k boundary.
>>>
>>> I also agree that having power of 2s for both (e.g. similar to Linux'es CONFIG_LOG_BUF_SHIFT)
>>> will be the simplest (implementation) and non-ambigous.
>>> I had it done earlier:
>>> https://lore.kernel.org/xen-devel/20241205-vuart-ns8250-v1-26-e9aa923127eb@ford.com/
>>
>>
>> I'd prefer the power-of-2 approach, yet I could live with the Kb-based one as
>> was suggested by Roger.
>
> Just to double check: I think it makes sense to switch both build-time and run-time
> settings to use the same size calculation algorithm (e.g. Kb-based) to avoid
> confusion during building hypervisor configuration.
>
> Will that be OK to do such change?
No, you can't change existing command line options like this, at least not
without a very good reason. You'd break existing uses. Plus there is
size_param("conring_size", opt_conring_size);
already anyway, so the command line option can be used with Kb and other
granularities without any adjustments to the code.
>>> Also, since there's a build-time configuration parameter along with the boot-time
>>> configuration, perhaps it makes sense to retire boot-time setting in favor of
>>> build-time setting?
>>
>>
>> Why would that be? Build-time settings can only ever be defaults. We don't
>> know what people need in their configurations.
>
> I was thinking about few reasons.
> In embedded setup run-time settings are unlikely to change, it is mostly
> built-time configuration.
> On a server setup, bumping the size of console buffer morelikely means some
> debugging, which to me means new xen binary can be re-generated and re-deployed.
That depends on who's doing the debugging and who's giving the instructions.
A developer telling a customer to increase the buffer size is certainly
easier when it simply means adding/changing a command line option, for
example.
Jan
On Monday, February 24th, 2025 at 11:23 PM, Jan Beulich <jbeulich@suse.com> wrote:
>
>
> On 25.02.2025 03:45, Denis Mukhin wrote:
>
> > On Monday, February 24th, 2025 at 2:44 AM, Jan Beulich jbeulich@suse.com wrote:
> >
> > > On 21.02.2025 21:52, Denis Mukhin wrote:
> > >
> > > > On Tuesday, February 18th, 2025 at 8:05 AM, Jan Beulich jbeulich@suse.com wrote:
> > > >
> > > > > On 12.02.2025 23:31, dmkhn@proton.me wrote:
> > > > >
> > > > > > --- a/xen/drivers/char/Kconfig
> > > > > > +++ b/xen/drivers/char/Kconfig
> > > > > > @@ -96,6 +96,18 @@ config SERIAL_TX_BUFSIZE
> > > > > >
> > > > > > Default value is 32768 (32KiB).
> > > > > >
> > > > > > +config CONRING_SIZE
> > > > > > + int "Console buffer size"
> > > > > > + default 32768
> > > > > > + range 16384 134217728
> > > > > > + help
> > > > > > + Select the boot console buffer size (in bytes).
> > > > >
> > > > > Why in bytes when ...
> > > > >
> > > > > > + Note, the value provided will be rounded down to the nearest power of 2.
> > > > >
> > > > > ... this rounding is done anyway? Why have people type in complicated numbers?
> > > > > A granularity of 1k would already be an improvement; yet better would be if
> > > > > this was a power-of-two value altogether.
> > > >
> > > > My understanding that the semantics of new CONFIG_CONRING_SIZE build-time setting
> > > > should be consistent with existing boot-time conring_size= behavior (string value
> > > > converted to number of bytes).
> > > >
> > > > I can update both to round up to 1k boundary.
> > > >
> > > > I also agree that having power of 2s for both (e.g. similar to Linux'es CONFIG_LOG_BUF_SHIFT)
> > > > will be the simplest (implementation) and non-ambigous.
> > > > I had it done earlier:
> > > > https://lore.kernel.org/xen-devel/20241205-vuart-ns8250-v1-26-e9aa923127eb@ford.com/
> > >
> > > I'd prefer the power-of-2 approach, yet I could live with the Kb-based one as
> > > was suggested by Roger.
> >
> > Just to double check: I think it makes sense to switch both build-time and run-time
> > settings to use the same size calculation algorithm (e.g. Kb-based) to avoid
> > confusion during building hypervisor configuration.
> >
> > Will that be OK to do such change?
>
>
> No, you can't change existing command line options like this, at least not
> without a very good reason. You'd break existing uses. Plus there is
>
> size_param("conring_size", opt_conring_size);
>
> already anyway, so the command line option can be used with Kb and other
> granularities without any adjustments to the code.
OK, thanks.
>
> > > > Also, since there's a build-time configuration parameter along with the boot-time
> > > > configuration, perhaps it makes sense to retire boot-time setting in favor of
> > > > build-time setting?
> > >
> > > Why would that be? Build-time settings can only ever be defaults. We don't
> > > know what people need in their configurations.
> >
> > I was thinking about few reasons.
> > In embedded setup run-time settings are unlikely to change, it is mostly
> > built-time configuration.
> > On a server setup, bumping the size of console buffer morelikely means some
> > debugging, which to me means new xen binary can be re-generated and re-deployed.
>
>
> That depends on who's doing the debugging and who's giving the instructions.
> A developer telling a customer to increase the buffer size is certainly
> easier when it simply means adding/changing a command line option, for
> example.
Ack.
>
> Jan
On Fri, Feb 21, 2025 at 08:52:47PM +0000, Denis Mukhin wrote: > Also, since there's a build-time configuration parameter along with the boot-time > configuration, perhaps it makes sense to retire boot-time setting in favor of > build-time setting? IMO boot time setting is still useful to have, to not require rebuilding just if you want bigger buffer in some specific case. -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab
On Friday, February 21st, 2025 at 2:13 PM, Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> wrote: > > > On Fri, Feb 21, 2025 at 08:52:47PM +0000, Denis Mukhin wrote: > > > Also, since there's a build-time configuration parameter along with the boot-time > > configuration, perhaps it makes sense to retire boot-time setting in favor of > > build-time setting? > > > IMO boot time setting is still useful to have, to not require rebuilding > just if you want bigger buffer in some specific case. Ack. > > -- > Best Regards, > Marek Marczykowski-Górecki > Invisible Things Lab
On Wed, 12 Feb 2025, dmkhn@proton.me wrote:
> Add new CONRING_SIZE Kconfig parameter to specify the boot console buffer size
> in bytes. The value is rounded to the nearest power of 2 to match existing
> conring_size= behavior.
>
> The supported range is [16KiB..128MiB].
>
> Bump default size to 32 KiB.
>
> Link: https://gitlab.com/xen-project/xen/-/issues/185
> Signed-off-by: Denis Mukhin <dmukhin@ford.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
> ---
> Link to the original change:
> - https://lore.kernel.org/xen-devel/20250103-vuart-ns8250-v3-v1-15-c5d36b31d66c@ford.com/
> ---
> docs/misc/xen-command-line.pandoc | 5 ++++-
> xen/drivers/char/Kconfig | 12 ++++++++++++
> xen/drivers/char/console.c | 6 +++---
> 3 files changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
> index 9bbd00baef..563cdbdd49 100644
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -425,10 +425,13 @@ The following are examples of correct specifications:
> ### conring_size
> > `= <size>`
>
> -> Default: `conring_size=16k`
> +> Default: `conring_size=32k`
>
> Specify the size of the console ring buffer.
>
> +The console ring buffer size can be selected at build time via
> +CONFIG_CONRING_SIZE.
> +
> ### console
> > `= List of [ vga | com1[H,L] | com2[H,L] | pv | dbgp | ehci | xhci | none ]`
>
> diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
> index e6e12bb413..54a3a79da3 100644
> --- a/xen/drivers/char/Kconfig
> +++ b/xen/drivers/char/Kconfig
> @@ -96,6 +96,18 @@ config SERIAL_TX_BUFSIZE
>
> Default value is 32768 (32KiB).
>
> +config CONRING_SIZE
> + int "Console buffer size"
> + default 32768
> + range 16384 134217728
> + help
> + Select the boot console buffer size (in bytes).
> + Note, the value provided will be rounded down to the nearest power of 2.
> + Run-time console buffer size is the same as the boot console size,
> + unless overridden via 'conring_size=' boot parameter.
> +
> + Default value is 32768 (32KiB).
> +
> config XHCI
> bool "XHCI DbC UART driver"
> depends on X86
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index ee5f720de4..73d24a7821 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -101,12 +101,12 @@ static int cf_check parse_console_timestamps(const char *s);
> custom_runtime_param("console_timestamps", parse_console_timestamps,
> con_timestamp_mode_upd);
>
> -/* conring_size: allows a large console ring than default (16kB). */
> +/* conring_size: override build-time CONRING_SIZE setting. */
> static uint32_t __initdata opt_conring_size;
> size_param("conring_size", opt_conring_size);
>
> -#define _CONRING_SIZE 16384
> -#define CONRING_IDX_MASK(i) ((i)&(conring_size-1))
> +#define _CONRING_SIZE (1UL << (31 - __builtin_clz(CONFIG_CONRING_SIZE)))
> +#define CONRING_IDX_MASK(i) ((i) & (conring_size - 1))
> static char __initdata _conring[_CONRING_SIZE];
> static char *__read_mostly conring = _conring;
> static uint32_t __read_mostly conring_size = _CONRING_SIZE;
> --
> 2.34.1
>
>
© 2016 - 2025 Red Hat, Inc.