qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Guest application reading from pl011 without device dri


From: Jiahuan Zhang
Subject: Re: [Qemu-devel] Guest application reading from pl011 without device driver
Date: Mon, 1 May 2017 14:06:32 +0200

Hi, can somebody help to check this host (Windows 7) to guest (Linux
4.10) Windows named pipe data transfer?
The method I implemented has while loops that makes qemu consume 100% CPU
time.
I cannot find any optimization to eliminate the loops. So sad!

Anyone has time, please help.

On 24 March 2017 at 11:00, Jiahuan Zhang <address@hidden> wrote:

> Hi, now it is working with the following char-pipe_new.c.
>
> See the patch. Doing the "if fifo has space" polling only when there are
> data on the pipe, and next reading from pipe.
> The sub_thread does these three things, and the main thread only does
> writing to UART fifo when the subthread signalled its handler.
>
> It is working in my case to transfer large data. Rational? Please check.
>
> On 24 March 2017 at 08:24, Jiahuan Zhang <address@hidden> wrote:
>
>> Hi, here are the patch files for char-pipe.c, char-win.c, char-win.h
>>
>>
>> On 23 March 2017 at 18:31, Paolo Bonzini <address@hidden> wrote:
>>
>>>
>>>
>>> On 23/03/2017 18:28, Jiahuan Zhang wrote:
>>> > Hi, the method doesn't work for pipe. It still causes the same issue.
>>> > The only difference is that the first byte in the UART fifo can be read
>>> > by the guest app.
>>> > So now my guest app can immediately read 17bytes when the host is
>>> > sending data continuously,
>>> > then guest app is unable to read.
>>> >
>>> > Now there is a solution-to-be. Set the qemu pipe chardev to wait for 1
>>> > millisecond before do a next ReadFile(),
>>> > then the pl011 can deliver the complete large data by the 16-byte fifo
>>> > continuously to the guest app.
>>> >
>>> > Is it rational? Or is this host -CPU-dependent?
>>>
>>> Post the patch, maybe you have a bug.
>>>
>>> Paolo
>>>
>>
>>
>


reply via email to

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