qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 2/2] Drop obsolete nographic timer


From: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH 2/2] Drop obsolete nographic timer
Date: Fri, 16 Mar 2012 09:17:17 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

On 2012-03-16 01:52, Marek Vasut wrote:
> Dear Jan Kiszka,
> 
>> On 2012-03-15 19:12, Marek Vasut wrote:
>>> Dear Marek Vasut,
>>>
>>>> Dear Jan Kiszka,
>>>>
>>>>> On 2012-03-10 07:19, Marek Vasut wrote:
>>>>>> Dear Jan Kiszka,
>>>>>>
>>>>>>> We flush coalesced MMIO in the device models now, and VNC - for which
>>>>>>> this was once introduced - is also fine without it as it has its own
>>>>>>> refresh timer.
>>>>>>>
>>>>>>> Signed-off-by: Jan Kiszka <address@hidden>
>>>>>>> ---
>>>>>>>
>>>>>>>  vl.c |   13 -------------
>>>>>>>  1 files changed, 0 insertions(+), 13 deletions(-)
>>>>>>
>>>>>> This patch seems to break QEMU/PXA emulation for me on the ZipitZ2
>>>>>> platform. The serial console became very slow, but only when I type
>>>>>> something in. The output from the device to the console is ok. After
>>>>>> reverting this particular one, the console behaves normally.
>>>>>
>>>>> Removing that timer removal likely just revealed some formerly hidden
>>>>> bug. Can you share the command line used for starting and some test
>>>>> image?
>>>>>
>>>>> Jan
>>>>
>>>> qemu-system-arm -M z2 -pflash flash.img -serial null -serial null
>>>> -serial stdio -display none
>>>>
>>>> flash.img attached (XZ-ed)
>>>
>>> Bump?
>>
>> I had a brief look: The guest is apparently polling the uart, IRQ
>> delivery is disabled.
> 
> Yes, it is.
> 
>> But it also receives no timer ticks. I haven't
>> checked how it progresses, maybe there is some loop counter used.
> 
> What do you mean? How does the timer implementation in pxa-uboot work? 
> udelay() 
> calls on the guest (pxa-uboot) simply poll the timer until it reaches certain 
> value. There's no paralelism going on at all.

I'm starting to understand the issue: The serial port can only accept a
single byte. Once this arrived, serial_can_receive1 returns 0, and the
backend fd is not longer polled by the io-thread. This should change
again as soon as the guest read that byte. But qemu_chr_accept_input,
which is properly called by the serial device, didn't kick the io-thread
in some way. I solved it this way now:

diff --git a/qemu-char.c b/qemu-char.c
index 9a5be75..a589a84 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -177,6 +177,7 @@ void qemu_chr_accept_input(CharDriverState *s)
 {
     if (s->chr_accept_input)
         s->chr_accept_input(s);
+    qemu_notify_event();
 }

 void qemu_chr_fe_printf(CharDriverState *s, const char *fmt, ...)


But I'm not yet sure if this is correct. Comments welcome!

Jan

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]