On Mon, Jun 13, 2022 at 09:30:06AM +0200, Jan Beulich wrote:
> On 10.06.2022 17:06, Roger Pau Monne wrote:
> > Prevent dropping console output from the hardware domain, since it's
> > likely important to have all the output if the boot fails without
> > having to resort to sync_console (which also affects the output from
> > other guests).
> >
> > Do so by pairing the console_serial_puts() with
> > serial_{start,end}_log_everything(), so that no output is dropped.
>
> While I can see the goal, why would Dom0 output be (effectively) more
> important than Xen's own one (which isn't "forced")? And with this
> aiming at boot output only, wouldn't you want to stop the overriding
> once boot has completed (of which, if I'm not mistaken, we don't
> really have any signal coming from Dom0)? And even during boot I'm
> not convinced we'd want to let through everything, but perhaps just
> Dom0's kernel messages?
I normally use sync_console on all the boxes I'm doing dev work, so
this request is something that come up internally.
Didn't realize Xen output wasn't forced, since we already have rate
limiting based on log levels I was assuming that non-ratelimited
messages wouldn't be dropped. But yes, I agree that Xen (non-guest
triggered) output shouldn't be rate limited either.
> I'm also a little puzzled by the sync_console argument: If boot
> fails, other guests aren't really involved yet, are they?
No, but it would useful to get all relevant info without having to ask
users to use sync_console.
> Finally, what about (if such configured) output from a Xenstore
> domain? That's kind of importantish as well, I'd say.
I would be less inclined to do so. Xenstore domains can use a regular
PV console, which shouldn't be affected by the rate limiting applied to
the serial. Also that would give the xenstore domain a way to trigger
DoS attacks.
Thanks, Roger.
