qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: "Marc-André Lureau" <marcandre.lureau@gmail.com>
Cc: "Philippe Mathieu-Daudé" <philmd@linaro.org>,
	qemu-devel@nongnu.org, "Alex Bennée" <alex.bennee@linaro.org>,
	"Gavin Shan" <gshan@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Mark Cave-Ayland" <mark.cave-ayland@ilande.co.uk>,
	"Peter Maydell" <peter.maydell@linaro.org>,
	"Evgeny Iakovlev" <eiakovlev@linux.microsoft.com>,
	qemu-arm@nongnu.org, "Mikko Rapeli" <mikko.rapeli@linaro.org>
Subject: Re: [PATCH-for-8.2 v4 10/10] hw/char/pl011: Implement TX FIFO
Date: Wed, 22 Nov 2023 10:38:41 +0000	[thread overview]
Message-ID: <ZV3aMYohaUsg5gWx@redhat.com> (raw)
In-Reply-To: <CAJ+F1CKFFU_VEA4nhgWw9RLDgc_gD0h-FPfvSP4LaFC1j4pP6Q@mail.gmail.com>

On Wed, Nov 22, 2023 at 02:31:29PM +0400, Marc-André Lureau wrote:
> Hi
> 
> On Thu, Nov 9, 2023 at 11:30 PM Philippe Mathieu-Daudé
> <philmd@linaro.org> wrote:
> >
> > If the UART back-end chardev doesn't drain data as fast as stdout
> > does or blocks, buffer in the TX FIFO to try again later.
> >
> > This avoids having the IO-thread busy waiting on chardev back-ends,
> > reported recently when testing the Trusted Reference Stack and
> > using the socket backend:
> > https://linaro.atlassian.net/browse/TRS-149?focusedCommentId=149574
> >
> > Implement registering a front-end 'watch' callback on back-end
> > events, so we can resume transmitting when the back-end is writable
> > again, not blocking the main loop.
> 
> I do not have access to that Jira issue.
> 
> In general, chardev backends should have some buffering already
> (socket, files etc).
> 
> If we want more, or extra control over buffering, maybe this should be
> implemented at the chardev level, rather than each frontend implement
> its own extra buffering logic...
> 
> Regardless, I think frontends should have an option to "drop" data
> when the chardev/buffer is full, rather than hanging.

Does anyone really want data to be dropped by QEMU ? Every time I've seen
a scenario where data has been dropped or lost, it has been considered
a bug to be solved.

Sure, we don't want QEMU to block on chardev writes, but we want that
more than throwing away data.

What's the use case for capturing data from the serial port, but throwing
it away if the other end of a socket doesn't read quickly enough ?

If someone does want lossy serial ports, they could configure the UDP
charedev backend already.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



  reply	other threads:[~2023-11-22 10:39 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-09 19:28 [PATCH-for-8.2 v4 00/10] hw/char/pl011: Implement TX (async) FIFO to avoid blocking the main loop Philippe Mathieu-Daudé
2023-11-09 19:28 ` [PATCH-for-8.2 v4 01/10] util/fifo8: Allow fifo8_pop_buf() to not populate popped length Philippe Mathieu-Daudé
2023-11-09 23:12   ` Richard Henderson
2023-11-09 19:28 ` [PATCH-for-8.2 v4 02/10] util/fifo8: Introduce fifo8_peek_buf() Philippe Mathieu-Daudé
2023-11-09 23:15   ` Richard Henderson
2023-11-09 19:28 ` [PATCH-for-8.2 v4 03/10] hw/char/pl011: Split RX/TX path of pl011_reset_fifo() Philippe Mathieu-Daudé
2023-11-09 19:28 ` [PATCH-for-8.2 v4 04/10] hw/char/pl011: Extract pl011_write_txdata() from pl011_write() Philippe Mathieu-Daudé
2023-11-09 23:17   ` Richard Henderson
2023-12-13  9:13     ` Philippe Mathieu-Daudé
2023-11-09 19:28 ` [PATCH-for-8.2 v4 05/10] hw/char/pl011: Extract pl011_read_rxdata() from pl011_read() Philippe Mathieu-Daudé
2023-11-09 19:28 ` [PATCH-for-8.2 v4 06/10] hw/char/pl011: Warn when using disabled transmitter Philippe Mathieu-Daudé
2023-11-09 19:28 ` [PATCH-for-8.2 v4 07/10] hw/char/pl011: Check if receiver is enabled Philippe Mathieu-Daudé
2023-11-09 19:28 ` [PATCH-for-8.2 v4 08/10] hw/char/pl011: Rename RX FIFO methods Philippe Mathieu-Daudé
2023-11-09 19:28 ` [PATCH-for-8.2 v4 09/10] hw/char/pl011: Add transmit FIFO to PL011State Philippe Mathieu-Daudé
2023-11-09 23:24   ` Richard Henderson
2023-11-16 15:48     ` Juan Quintela
2024-07-17 13:34       ` Philippe Mathieu-Daudé
2023-11-09 19:28 ` [PATCH-for-8.2 v4 10/10] hw/char/pl011: Implement TX FIFO Philippe Mathieu-Daudé
2023-11-09 23:34   ` Richard Henderson
2023-11-22 10:31   ` Marc-André Lureau
2023-11-22 10:38     ` Daniel P. Berrangé [this message]
2023-11-24 12:47       ` Philippe Mathieu-Daudé
2023-11-09 19:29 ` [PATCH-for-8.2 v4 00/10] hw/char/pl011: Implement TX (async) FIFO to avoid blocking the main loop Peter Maydell
2023-11-09 20:59   ` Philippe Mathieu-Daudé
2023-11-13 13:11     ` Peter Maydell
2023-11-13 15:44       ` Philippe Mathieu-Daudé
2023-11-24 10:24       ` Alex Bennée
2024-01-05  7:50 ` Mark Cave-Ayland
2024-01-10  7:05   ` Mark Cave-Ayland

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZV3aMYohaUsg5gWx@redhat.com \
    --to=berrange@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=eiakovlev@linux.microsoft.com \
    --cc=gshan@redhat.com \
    --cc=marcandre.lureau@gmail.com \
    --cc=mark.cave-ayland@ilande.co.uk \
    --cc=mikko.rapeli@linaro.org \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=philmd@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).