qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

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