[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: |
Vincent Palatin |
Subject: |
Re: [Qemu-devel] [PATCH v5 3/4] Plumb the HAXM-based hardware acceleration support |
Date: |
Thu, 5 Jan 2017 14:50:11 +0100 |
On Thu, Dec 22, 2016 at 10:57 AM, Paolo Bonzini <address@hidden> wrote:
>
>
> On 19/12/2016 17:24, Vincent Palatin wrote:
>> #else /* _WIN32 */
>> - abort();
>> + if (!qemu_cpu_is_self(cpu)) {
>> + CONTEXT context;
>> + if (SuspendThread(cpu->hThread) == (DWORD)(-1)) {
>> + fprintf(stderr, "qemu:%s: GetLastError:%lu\n", __func__,
>> + GetLastError());
>> + exit(1);
>> + }
>> +
>> + /* On multi-core systems, we are not sure that the thread is
>> actually
>> + * suspended until we can get the context.
>> + */
>> + context.ContextFlags = CONTEXT_CONTROL;
>> + while (GetThreadContext(cpu->hThread, &context) != 0) {
>> + continue;
>> + }
>> +
>> + if (hax_enabled()) {
>> + cpu->exit_request = 1;
>> + }
>
> As mentioned in the reply to patch 4, please leave the cpu->exit_request
> = 1 assignment to the caller.
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 ?
>
>> + if (ResumeThread(cpu->hThread) == (DWORD)(-1)) {
>> + fprintf(stderr, "qemu:%s: GetLastError:%lu\n", __func__,
>> + GetLastError());
>> + exit(1);
>> + }
>> + }
>
> [...]
>
>>
>> + /*
>> + * In Hax, the qemu allocate the virtual address, and HAX kernel
>> + * populate the memory with physical memory. Currently we have
>> no
>> + * paging, so user should make sure enough free memory in
>> advance
>> + */
>> + if (hax_enabled()) {
>> + int ret;
>> + ret = hax_populate_ram((uint64_t)(uintptr_t)new_block->host,
>> + new_block->max_length);
>> + if (ret < 0) {
>> + error_setg(errp, "Hax failed to populate ram");
>> + return;
>> + }
>> + }
>> +
>
> Can you check if the interface at
> http://marc.info/?l=qemu-devel&m=148225154320642&q=raw would be good for
> your purposes, and if so include that patch in your v6?
Seems to work, updated for v6.
--
Vincent
- Re: [Qemu-devel] [PATCH v5 3/4] Plumb the HAXM-based hardware acceleration support,
Vincent Palatin <=