On 31/10/2024 04.52, Alistair Francis wrote:
The current approach of using qemu_chr_fe_write() and ignoring the
return values results in dropped characters [1].
Let's update the SiFive UART to use a async sifive_uart_xmit() function
to transmit the characters and apply back pressure to the guest with
the SIFIVE_UART_TXFIFO_FULL status.
This should avoid dropped characters and more realisticly model the
hardware.
1: https://gitlab.com/qemu-project/qemu/-/issues/2114
Signed-off-by: Alistair Francis <alistair.fran...@wdc.com>
Reviewed-by: Daniel Henrique Barboza <dbarb...@ventanamicro.com>
Tested-by: Thomas Huth <th...@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <phi...@linaro.org>
Message-ID: <20240910045419.1252277-3-alistair.fran...@wdc.com>
Signed-off-by: Alistair Francis <alistair.fran...@wdc.com>
---
...
@@ -106,12 +174,10 @@ sifive_uart_write(void *opaque, hwaddr addr,
{
SiFiveUARTState *s = opaque;
uint32_t value = val64;
- unsigned char ch = value;
switch (addr) {
case SIFIVE_UART_TXFIFO:
- qemu_chr_fe_write(&s->chr, &ch, 1);
- sifive_uart_update_irq(s);
+ sifive_uart_write_tx_fifo(s, (uint8_t *) &value, 1);
This broke the sifive_u machine on big endian hosts. "value" is a 64-bit
variable, so you cannot assume that you get the 8-bit character with such a
pointer magic here. I think we have to re-introduce the detour via the 8-bit
"ch" variable...
Thomas