From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoffer Dall Subject: Re: [Android-virt] [PATCH v5 11/13] ARM: KVM: Support SMP hosts Date: Tue, 13 Dec 2011 09:36:06 -0500 Message-ID: <-7628822570833811736@unknownmsgid> References: <20111211102403.21693.6887.stgit@localhost> <20111211102529.21693.62306.stgit@localhost> <4EE61017.3090106@redhat.com> <4EE6405A.7050908@redhat.com> <4EE71CF1.5080705@redhat.com> <4EE75E6C.4080903@redhat.com> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=ISO-8859-1 Cc: Christoffer Dall , "Marc.Zyngier@arm.com" , "tech@virtualopensystems.com" , "kvm@vger.kernel.org" , "android-virt@lists.cs.columbia.edu" To: Avi Kivity Return-path: Received: from mail-vx0-f174.google.com ([209.85.220.174]:58069 "EHLO mail-vx0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754200Ab1LMOfA (ORCPT ); Tue, 13 Dec 2011 09:35:00 -0500 Received: by vcbfk14 with SMTP id fk14so4679474vcb.19 for ; Tue, 13 Dec 2011 06:34:59 -0800 (PST) In-Reply-To: <4EE75E6C.4080903@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Dec 13, 2011, at 9:17 AM, Avi Kivity wrote: > 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. > Actually I did (yes the memory barriers hurt my brain), but I kind of missed the most basic level of memory atomicity - there was a nice section about this in the ARM arm though. Thanks for helping out on all this!