[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] xen/console: do not drop serial output from the hardware domain


  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 13 Jun 2022 11:18:49 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/MfOVtcYc6x/YwYDCZkS2LDzAnNUQsrVsmViqAcAxVc=; b=NjRo6x8gBGuKSWUnXYkPSsEqxHRvyb0iFA+Lh0f/YD4GigrKUb5187eUfSVjhSea3Wbef1ib4kLdumHGWhBa5rLS+KsFHzc/HeIjS0qMLYS/eCMXVkGRmv2Q6ubO5NkMebE44ztQu24OEFF4ryGaZMSXU1BW5+6qOr4daQ3B3Sx6hI6PZeMuIfuDMs7TvVmUONYJo/VeUJjsW1Y02Es2oeX+QS8bndVavgA+Xoyrr/px3UkIycdyCc3knutkTZMzd1URyM3SZO4B/eg2cgM429I3sduOKD2+kWDabtENqaNR+G/v7jWzo1OUt/E0yj2tY8X9QRnqQO9juj4UAwznUw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HpYuO+uMbPdYY0Bb86idYNgm7q/+0G8mFAG9o1+xMhPElOD4EwIOxKMSiCgRiUbXoAnxql2+BFT1DfFyOzGtvkt72T0TOc67gxaYDXHp3rI1cteDWE+mkQeGy+QmuPvGhGg90vA0YS/nf9tLXPdRAtqE5GKEZzdq+RITVlaerhlVovng/r8G00iZIM6J5nmcaMhPe1yqsRqfK7y8xR/2I5E0xR0uZTg4shzW7V5rBHZPcSrQRs5cZuEvXxbPlcJyJHpIT/OCstgIMnkVaE4OdkZ4IA66F1o1ivxS9SRwdlUJF5GP/IWiTb47cT8fDOCRBTnpUqJALOKR3mZbnBroZA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 13 Jun 2022 09:18:58 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 13.06.2022 11:04, Roger Pau Monné wrote:
> On Mon, Jun 13, 2022 at 10:29:43AM +0200, Jan Beulich wrote:
>> On 13.06.2022 10:21, Roger Pau Monné wrote:
>>> 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.
>>
>> Which would raise the question of why we have log levels for non-guest
>> messages.
> 
> Hm, maybe I'm confused, but I don't see a direct relation between log
> levels and rate limiting.  If I set log level to WARNING I would
> expect to not loose _any_ non-guest log messages with level WARNING or
> above.  It's still useful to have log levels for non-guest messages,
> since user might want to filter out DEBUG non-guest messages for
> example.

It was me who was confused, because of the two log-everything variants
we have (console and serial). You're right that your change is unrelated
to log levels. However, when there are e.g. many warnings or when an
admin has lowered the log level, what you (would) do is effectively
force sync_console mode transiently (for a subset of messages, but
that's secondary, especially because the "forced" output would still
be waiting for earlier output to make it out). We strongly advise against
use of sync_console in production environments, so I'm afraid I have
trouble seeing how using this mode transiently can be safe. This is quite
different from forcing all output to appear when e.g. we're about to
crash Xen.

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.