On Thu, Jan 5, 2017 at 10:38 PM, Paolo Bonzini <pbonz...@redhat.com> wrote:
>
>
> On 05/01/2017 15:01, Paolo Bonzini wrote:
>>
>>
>> On 05/01/2017 14:50, Vincent Palatin wrote:
>>> Sorry I missed it.
>>> I move it to qemu_cpu_kick() as asked in the Darwin patch.
>>>
>>>> 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 :(
>
> if (cpu->exit_request) {
> ret = 1;
> break;
> }
> cpu->exit_request
> SuspendThread
> ResumeThread
> hax_vcpu_interrupt(env);
> qemu_mutex_unlock_iothread();
> hax_ret = hax_vcpu_run(vcpu);
>
> and the same race is true for QueueUserAPC. It's rare enough that I
> guess we can accept the patches with just a FIXME comment, but... Yu
> Ning, can you tell us what user_event_pending is for? :) My hunch is
> that we should call hax_raise_event after setting cpu->exit_request, like
>
> hax_raise_event();
> /* write user_event_pending before exit_request */
> smp_wmb();
> cpu->exit_request = 1;
> SuspendThread/ResumeThread
> (or QueueUserAPC)
>
> and in the hax thread:
>
> if (cpu->exit_request) {
> cpu->hax_vcpu->tunnel->user_event_pending = 0;
> ret = 1;
> break;
> }
>
> hax_vcpu_interrupt(env);
> qemu_mutex_unlock_iothread();
>
> /* read exit_request before user_event_pending */
> smp_rmb();
> hax_ret = hax_vcpu_run(vcpu);
>
> but I would like some more official documentation than my own reverse
> engineering of the brain of whoever wrote the interface (I have not
> looked at the HAXM driver binary).
>
> Paolo
