From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:34390)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1SiiW3-0003ho-Gw
	for qemu-devel@nongnu.org; Sun, 24 Jun 2012 04:49:56 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1SiiW1-0001Yo-UJ
	for qemu-devel@nongnu.org; Sun, 24 Jun 2012 04:49:55 -0400
Received: from mx1.redhat.com ([209.132.183.28]:59926)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1SiiW1-0001Xi-Mn
	for qemu-devel@nongnu.org; Sun, 24 Jun 2012 04:49:53 -0400
Message-ID: <4FE6D4A6.9080708@redhat.com>
Date: Sun, 24 Jun 2012 11:49:42 +0300
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
References: <4FE4F56D.1020201@web.de> <4FE4F7F5.7030400@web.de>
	<20120623002259.GA13440@amt.cnet>
	<20120623090646.GA21908@amt.cnet> <4FE5AC75.1020504@web.de>
In-Reply-To: <4FE5AC75.1020504@web.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH] kvm: First step to push iothread lock out
 of inner run loop
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Jan Kiszka <jan.kiszka@web.de>
Cc: Liu Ping Fan <pingfank@linux.vnet.ibm.com>, kvm <kvm@vger.kernel.org>, Marcelo Tosatti <mtosatti@redhat.com>, qemu-devel <qemu-devel@nongnu.org>, Alexander Graf <agraf@suse.de>, Anthony Liguori <anthony@codemonkey.ws>

On 06/23/2012 02:45 PM, Jan Kiszka wrote:
> 
> Hmm, we may need the iothread lock around cpu_set_apic_tpr for
> !kvm_irqchip_in_kernel(). And as we are at it, apic_base manipulation
> can be but there as well.
> 
> With in-kernel irqchip, there is no such need. Also, no one accesses
> eflags outside of the vcpu thread, independent of the irqchip mode.

In fact !kvm_irqchip_in_kernel() is broken wrt the tpr.  Interrupt
injection needs to be done atomically, but currently we check the tpr
from the injecting thread, which means the cpu thread can race with it.
 We need to move the check to the vcpu thread so that the guest vcpu is
halted.


-- 
error compiling committee.c: too many arguments to function