[Qemu-devel] [PATCH][RESEND] char: Flush read buffer in mux_chr_can_read

[Qemu-devel] [PATCH][RESEND] char: Flush read buffer in mux_chr_can_read

[Jan Kiszka]

Move the buffer flush from mux_chr_read to mux_chr_can_read. While the
latter is called periodically, the former will only be invoked when new
characters arrive at the back-end. This caused problems to front-end
drivers whenever they were unable to read data immediately, e.g.
virtio-console attached to stdio.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 qemu-char.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/qemu-char.c b/qemu-char.c
index 6d2dce7..f4c3876 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -398,6 +398,8 @@ static int mux_chr_can_read(void *opaque)
     MuxDriver *d = chr->opaque;
     int m = d->focus;
 
+    mux_chr_accept_input(opaque);
+
     if ((d->prod[m] - d->cons[m]) < MUX_BUFFER_SIZE)
         return 1;
     if (d->chr_can_read[m])
@@ -412,8 +414,6 @@ static void mux_chr_read(void *opaque, const uint8_t *buf, int size)
     int m = d->focus;
     int i;
 
-    mux_chr_accept_input (opaque);
-
     for(i = 0; i < size; i++)
         if (mux_proc_byte(chr, d, buf[i])) {
             if (d->prod[m] == d->cons[m] &&
-- 
1.7.1

[Qemu-devel] Re: [PATCH][RESEND] char: Flush read buffer in mux_chr_can_read

[Alexander Graf]

Am 19.10.2010 um 17:04 schrieb Jan Kiszka <jan.kiszka@siemens.com>:

> Move the buffer flush from mux_chr_read to mux_chr_can_read. While the
> latter is called periodically, the former will only be invoked when new
> characters arrive at the back-end. This caused problems to front-end
> drivers whenever they were unable to read data immediately, e.g.
> virtio-console attached to stdio.

This should help ny s390 virtio console issue, right? :) I'll try it out asap, worst case that might take until the weekend.

Alex

> 

[Qemu-devel] Re: [PATCH][RESEND] char: Flush read buffer in mux_chr_can_read

[Jan Kiszka]

Am 19.10.2010 17:22, Alexander Graf wrote:
> 
> Am 19.10.2010 um 17:04 schrieb Jan Kiszka <jan.kiszka@siemens.com>:
> 
>> Move the buffer flush from mux_chr_read to mux_chr_can_read. While the
>> latter is called periodically, the former will only be invoked when new
>> characters arrive at the back-end. This caused problems to front-end
>> drivers whenever they were unable to read data immediately, e.g.
>> virtio-console attached to stdio.
> 
> This should help ny s390 virtio console issue, right? :) I'll try it out asap, worst case that might take until the weekend.

I think you already tried and still found some scenarios broken (we
still need to understand them IIRC). However, this one fixes at least
those virtio-console scenarios I tested (with x86 guests).

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

[Qemu-devel] Re: [PATCH][RESEND] char: Flush read buffer in mux_chr_can_read

[Jan Kiszka]

Am 19.10.2010 17:04, Jan Kiszka wrote:
> Move the buffer flush from mux_chr_read to mux_chr_can_read. While the
> latter is called periodically, the former will only be invoked when new
> characters arrive at the back-end. This caused problems to front-end
> drivers whenever they were unable to read data immediately, e.g.
> virtio-console attached to stdio.
> 

Ping.

> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> ---
>  qemu-char.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/qemu-char.c b/qemu-char.c
> index 6d2dce7..f4c3876 100644
> --- a/qemu-char.c
> +++ b/qemu-char.c
> @@ -398,6 +398,8 @@ static int mux_chr_can_read(void *opaque)
>      MuxDriver *d = chr->opaque;
>      int m = d->focus;
>  
> +    mux_chr_accept_input(opaque);
> +
>      if ((d->prod[m] - d->cons[m]) < MUX_BUFFER_SIZE)
>          return 1;
>      if (d->chr_can_read[m])
> @@ -412,8 +414,6 @@ static void mux_chr_read(void *opaque, const uint8_t *buf, int size)
>      int m = d->focus;
>      int i;
>  
> -    mux_chr_accept_input (opaque);
> -
>      for(i = 0; i < size; i++)
>          if (mux_proc_byte(chr, d, buf[i])) {
>              if (d->prod[m] == d->cons[m] &&

[Qemu-devel] Re: [PATCH][RESEND] char: Flush read buffer in mux_chr_can_read

[Alexander Graf]

On 17.11.2010, at 11:18, Jan Kiszka wrote:

> Am 19.10.2010 17:04, Jan Kiszka wrote:
>> Move the buffer flush from mux_chr_read to mux_chr_can_read. While the
>> latter is called periodically, the former will only be invoked when new
>> characters arrive at the back-end. This caused problems to front-end
>> drivers whenever they were unable to read data immediately, e.g.
>> virtio-console attached to stdio.
>> 
> 
> Ping.

It's still broken, even with this patch applied.


Alex

[Qemu-devel] Re: [PATCH][RESEND] char: Flush read buffer in mux_chr_can_read

[Jan Kiszka]

Am 17.11.2010 12:55, Alexander Graf wrote:
> 
> On 17.11.2010, at 11:18, Jan Kiszka wrote:
> 
>> Am 19.10.2010 17:04, Jan Kiszka wrote:
>>> Move the buffer flush from mux_chr_read to mux_chr_can_read. While the
>>> latter is called periodically, the former will only be invoked when new
>>> characters arrive at the back-end. This caused problems to front-end
>>> drivers whenever they were unable to read data immediately, e.g.
>>> virtio-console attached to stdio.
>>>
>>
>> Ping.
> 
> It's still broken, even with this patch applied.
> 

No surprise. Still, the patch fixes other archs (namely x86).

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

[Qemu-devel] Re: [PATCH][RESEND] char: Flush read buffer in mux_chr_can_read

[Alexander Graf]

On 17.11.2010, at 12:58, Jan Kiszka wrote:

> Am 17.11.2010 12:55, Alexander Graf wrote:
>> 
>> On 17.11.2010, at 11:18, Jan Kiszka wrote:
>> 
>>> Am 19.10.2010 17:04, Jan Kiszka wrote:
>>>> Move the buffer flush from mux_chr_read to mux_chr_can_read. While the
>>>> latter is called periodically, the former will only be invoked when new
>>>> characters arrive at the back-end. This caused problems to front-end
>>>> drivers whenever they were unable to read data immediately, e.g.
>>>> virtio-console attached to stdio.
>>>> 
>>> 
>>> Ping.
>> 
>> It's still broken, even with this patch applied.
>> 
> 
> No surprise. Still, the patch fixes other archs (namely x86).

Sure, no complaints on the patch from my side. The framework is still broken though :).


Alex