From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [Android-virt] [PATCH v5 11/13] ARM: KVM: Support SMP hosts Date: Tue, 13 Dec 2011 16:17:16 +0200 Message-ID: <4EE75E6C.4080903@redhat.com> References: <20111211102403.21693.6887.stgit@localhost> <20111211102529.21693.62306.stgit@localhost> <4EE61017.3090106@redhat.com> <4EE6405A.7050908@redhat.com> <4EE71CF1.5080705@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Marc.Zyngier@arm.com, tech@virtualopensystems.com, android-virt@lists.cs.columbia.edu, kvm@vger.kernel.org To: Christoffer Dall Return-path: Received: from mx1.redhat.com ([209.132.183.28]:33716 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754425Ab1LMORc (ORCPT ); Tue, 13 Dec 2011 09:17:32 -0500 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 12/13/2011 03:36 PM, Christoffer Dall wrote: > > if (new_virt_intr == IRQ | FIQ && virt_intr == FIQ) { > > /* IRQ raised, FIQ already set */ > > return; > > } > > > > hmm, so what you want to avoid here is sending an IPI to the other CPU > in case we already have FIQ raised? But I think we have to do this > anyhow. If a guest is servicing a raised FIQ and have FIQs masked, but > the GIC hasn't lowered the FIQ line yet, and now comes an IRQ, if the > IRQ is unmasked we want to change the hypervisor virtual IRQ register > right away as to signal an IRQ immediately and if the guest masks IRQ > we still want to change the hypervisor virtual register so that the > moment the guest unmasks the IRQ, an exception is raised. The only way > to set the hypervisor register for another CPU would be to have it > take a world-switch round. Ah, if the register is virtualized, indeed you need to signal immediately. > >> But, if I am doing atomic bitops on an unsigned long field, how do I > >> read that (or test two bits at once) atomically? > > > > Reads (and writes) are always atomic. Its read-modify-write that needs > > special treatment. > > > embarrassing. I actually thought read/writes of a word could be > partial to the byte between SMP nodes, but it turns out, and as you > say, they cannot. Got it. Read Documentation/atomic_ops.txt and Documentation/memory-barriers.txt, it's a tricky subject. -- error compiling committee.c: too many arguments to function