[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: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Mon, 13 Jun 2022 14:32:13 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.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=Yl1hpugtFISblOFnrxcOsdjwspC8D6kL2znPeVQKb64=; b=NumEmYf68rV/eVtcPd/oW8PsBtdEThaaaj1yp32tMaKD24W0pl9gMJgDfDJeyLwYMfjlNLzOT5RMYNcvfvYTH4suCNVpQWrvl/L0WPHtRKWp7AdXLRZ77URFAjZ1J1JslemU8abOaCPJ1ZivuHofcsKQDni6b9gxQ0AjDlaQQbJwWNWI4v5+M93WkO1M3ahHpR/39wzvw41fGwC6k1ik2P8FrHYkjUYIKKRJlsDssDj9BhMlLTIExTpDmMmY+XDezUXPpyW/Sth+yevcuWiMUkH1rdy4q0JRtA8+ysuXvskWRQnZxiIklnHac2tLozLQ+RmxdSQdiguX0uTKBVGdTA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Uk1W3K3/wF+hcAGqRyT1LpPbtpfGa9fGZ6c02LcwAYKHO1KbAeU2p74N/KDEuf5h4FGwIz86u7W8UJ8057YfnLtnrf0gqLnMOLqb3AJ+96TZODnR/WYhj9wEcvruh1E7znL/CwaiDW2lkvoPaGHcPI0hJgcZf/KOLvrnG0IE+2V0s5NkvBe8Ce3I/7lQZSSC8bwgkoUn2Od2KScF2phxvVtSTr6dPiiQUNZ3ij86dplWz9hUq9E3sq0dsMcnpMvrsGzlUw/z+PsImOq25qI1U2N2+kiqX3zvzvy9vgUnScgi86NIvknahrV6qkjyaYyKrpxpM3XQ5zodjoXVTtQTDw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.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 12:32:35 +0000
  • Ironport-data: A9a23:nU+wD6t1bCPgsFupYJZrdshQZ+fnVEpfMUV32f8akzHdYApBsoF/q tZmKWiFParbZDCgL9h2aIuy8k1Q7J/QzoAySVE/rSAzQnwS+JbJXdiXEBz9bniYRiHhoOOLz Cm8hv3odp1coqr0/0/1WlTZhSAgk/nOHNIQMcacUsxLbVYMpBwJ1FQywobVvqYy2YLjW13U4 ouryyHiEATNNwBcYzp8B52r8HuDjNyq0N/PlgVjDRzjlAa2e0g9VPrzF4noR5fLatA88tqBb /TC1NmEElbxpH/BPD8HfoHTKSXmSpaKVeSHZ+E/t6KK2nCurQRquko32WZ1he66RFxlkvgoo Oihu6BcRi8yH4jBpOYYViMESShDNqdJ9+PgPz+w5Jn7I03uKxMAwt1IJWRuYcg9xbwyBmtDs /sFNDoKcxaPwfqsx662QfVtgcJlK9T3OIQYuTdryjSx4fQOGMifBfmVo4ADmm5v36iiHt6HD yYdQSBoYxnaJQVGJ38cCY4knffujX76G9FdgA3O9fRmuTKKpOB3+IKwboDfasSIf9hUs2Wdu lLrpWHyWThPYbRzzhLAqBpAnNTnnyn2RYYTH72Q7eNxjRuYwWl7IB8LUVq2p9Gph0j4XMhQQ 2QP4TYnp6U28E2tT/H+Uge+rXrCuQQTM/JPF8Uq5QfLzbDbiy6JC25BQjNfZdgOsM4tWSdsx lKPh8nuBzFkrPuSU331y1uPhTa7OCxQKHBYYyYBFVcB+4O6/9h1iQ/TRNF+FqLzlsfyBTz73 zGNqm45mqkXiskIka68+Dgrng6Rm3QAdSZtji2/Y45vxlkRiFKND2Bw1WXm0A==
  • Ironport-hdrordr: A9a23:tKmasKBgV1H5gGzlHej6sseALOsnbusQ8zAXPh9KJyC9I/b2qy nxppgmPEfP+UossHFJo6HlBEDyewKiyXcV2/heAV7GZmjbUQSTXflfBOfZsl/d8mjFh5NgPM RbAulD4b/LfCNHZK/BiWHSebtBsbq6GeKT9J3jJhxWPGZXgtRbnn5E43GgYytLrWd9dP8EPa vZwvACiyureHwRYMj+LGICRfL/q9rCk4+jSQIaBjY8gTP+zQ+A2frfKVy1zx0eWzRAzfMJ6m 7eiTH04a2lrrWS1gLc7WnO9J5b8eGRieerRfb8yPT9GA+czjpAV74RHIFqewpF5t1H3Wxa1e UkZS1QZvibpUmhJl1d6iGdpTUImAxemkMKj2Xo2kcL6PaJNA4SGo5Pg5lUfQDe7FdltNZg0L hT12bcrJZPCwjc9R6NreQg+Csa4nZcjEBS2dL7tUYvGrf2qYUh2rA37QdQCtMNDSj64IcoHK 1nC9zd/u9fdRefY2rCtmdizdSwVjBrdy32DnQqq4iQyXxbjXp5x0wXyIgWmWoB7os0T91B6/ 7fOqplmblSRotPBJgNS9spUI+yECjAUBjMOGWdLRDuE7wGIWvEr9ry7K8u7O+ndZQUxN85mY jHUllfqWkuEnieRPGmzdlO6FTAUW+9VTPixoVX4IV4oKT1QP7xPSiKWDkV4oKdSjUkc7vmst qISeBr6qXYXBjT8K5yrnjDZ6U=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Mon, Jun 13, 2022 at 11:18:49AM +0200, Jan Beulich wrote:
> 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).

Right, it would have to wait for any previous output on the buffer to
go out first.  In any case we can guarantee that no more output will
be added to the buffer while Xen waits for it to be flushed.

So for the hardware domain it might make sense to wait for the TX
buffers to be half empty (the current tx_quench logic) by preempting
the hypercall.  That however could cause issues if guests manage to
keep filling the buffer while the hardware domain is being preempted.

Alternatively we could always reserve half of the buffer for the
hardware domain, and allow it to be preempted while waiting for space
(since it's guaranteed non hardware domains won't be able to steal the
allocation from the hardware domain).

For Xen it's not trivial to prevent messages from being dropped. At
least during Xen boot (system_state < SYS_STATE_active) we could also
active the sync mode and make the spin wait in __serial_putc process
softirqs.

Thanks, Roger.



 


Rackspace

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