From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51699) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cQTHG-0005rK-Mc for qemu-devel@nongnu.org; Mon, 09 Jan 2017 01:17:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cQTHC-0005CA-Pa for qemu-devel@nongnu.org; Mon, 09 Jan 2017 01:17:54 -0500 Received: from mga05.intel.com ([192.55.52.43]:4487) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cQTHC-0005Bl-C4 for qemu-devel@nongnu.org; Mon, 09 Jan 2017 01:17:50 -0500 References: <85250fb0450b5b95232b39c82ab310a0632fd23f.1482164622.git.vpalatin@chromium.org> <61d18d9c-32f1-983f-c237-3c28d31e2f23@redhat.com> From: Yu Ning Message-ID: <7e2bab8d-fcb4-c861-c1b5-f85c5df674b6@linux.intel.com> Date: Mon, 9 Jan 2017 14:17:43 +0800 MIME-Version: 1.0 In-Reply-To: <61d18d9c-32f1-983f-c237-3c28d31e2f23@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v5 3/4] Plumb the HAXM-based hardware acceleration support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , Vincent Palatin Cc: Eduardo Habkost , "Michael S . Tsirkin" , Stefan Weil , Marcelo Tosatti , qemu-devel On 1/6/2017 5:38, Paolo Bonzini wrote: > > On 05/01/2017 15:01, Paolo Bonzini wrote: >> >> In fact there is a race anyway: >> >> 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). Unfortunately, user_event_pending was introduced in 2011 without proper documentation, so I guess even the original author might not have an answer now (even if I could find him). I need more time to analyze the HAXM driver code to understand what it's about. Please feel free to add a FIXME for now. But one thing I've noticed is that the Darwin driver does not test or reset this flag properly - it will remain 1 after the first hax_raise_event() call. So removing user_event_pending from the QEMU side should not affect Mac.