Re: [Qemu-devel] [PATCH v5 3/4] Plumb the HAXM-based hardware acceleration support

[Vincent Palatin]

On Mon, Jan 9, 2017 at 2:03 PM, Paolo Bonzini <address@hidden> wrote:
>
>
> On 06/01/2017 15:08, Vincent Palatin wrote:
>>>>>> Apart from the above change, can you check if there are some less
>>>>>> heavyeight methods to force an exit?  I can think of QueueUserAPC with
>>>>>> an empty pfnAPC here, and SleepEx(0, TRUE) in qemu_hax_cpu_thread_fn
>>>>>> before qemu_wait_io_event_common.
>>>>> Actually I don't know a good test case to verify such a change, any 
>>>>> advice ?
>>> In fact there is a race anyway:
>> Thanks for the detailed examples and thoughts.
>> The timing/benchmarking code might actually need some kind of per-vcpu
>> time storage, but that's a detail.
>> I have experimented with it and so far, I have mainly generated random
>> numbers ...
>> I have yet to find a use-case where the current code (with
>> SuspendThread/ResumeThread) yields a better latency than just nothing
>> instead :(
>
> :)  Does QueueUserAPC generate better latency?


The same kind of random numbers so far.

By the way I have added  the THREAD_SET_CONTEXT  flag to the
OpenThread call in qemu_thread_get_handle() function, as I was getting
ACCESS_DENIED on the QueueUserApc call. Probably not terribly harmful.
I will publish the v6 series with this and continue my benchmarking quest.

>
> Windows delivers the scheduler tick to the first physical CPU.  Try
> pinning QEMU away from the first CPU.

Ok interesting, I will give it a try.

-- 
Vincent