[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v5 3/4] Plumb the HAXM-based hardware accelerati
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [PATCH v5 3/4] Plumb the HAXM-based hardware acceleration support |
Date: |
Thu, 5 Jan 2017 15:01:45 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 |
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 ?
Try computing the latency between qemu_cpu_kick and the exit from HAXM.
That is, something like
int64_t kick_time = -1;
...
atomic_set(&kick_time, qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL));
before SuspendThread or respectively QueueUserAPC, and
extern volatile int64_t kick_time;
...
int64_t kicked = atomic_xchg(&kick_time, -1);
if (kicked != -1) {
printf("%lld\n",
qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) - kicked);
}
right after hax_vcpu_run. As long as the printed values remain
smallish, it's okay.
If you don't get any output, passing "info cpus" repeatedly to the QEMU
monitor will force a kick.
Paolo