From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53704) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VMkS7-0000jn-5N for qemu-devel@nongnu.org; Thu, 19 Sep 2013 16:03:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VMkS1-0006zF-BZ for qemu-devel@nongnu.org; Thu, 19 Sep 2013 16:03:51 -0400 Received: from mail-ve0-f177.google.com ([209.85.128.177]:60247) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VMkS1-0006z9-7d for qemu-devel@nongnu.org; Thu, 19 Sep 2013 16:03:45 -0400 Received: by mail-ve0-f177.google.com with SMTP id db12so7074544veb.8 for ; Thu, 19 Sep 2013 13:03:44 -0700 (PDT) Date: Thu, 19 Sep 2013 21:03:41 +0100 From: Christoffer Dall Message-ID: <20130919200341.GO7623@lvm> References: <1377288624-7418-1-git-send-email-christoffer.dall@linaro.org> <1377288624-7418-5-git-send-email-christoffer.dall@linaro.org> <20130914015227.GE30894@cbox> <20130919194835.GN7623@lvm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130919194835.GN7623@lvm> Subject: Re: [Qemu-devel] [PATCH 4/5] hw: arm_gic: Support setting/getting binary point reg List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Marc Zyngier , "linaro-kernel@lists.linaro.org" , QEMU Developers , Patch Tracking , "kvmarm@lists.cs.columbia.edu" On Thu, Sep 19, 2013 at 08:48:35PM +0100, Christoffer Dall wrote: > On Sat, Sep 14, 2013 at 10:46:37AM +0100, Peter Maydell wrote: > > On 14 September 2013 02:52, Christoffer Dall > > wrote: > > > On Fri, Sep 06, 2013 at 03:41:04PM +0100, Peter Maydell wrote: > > >> The TCG QEMU GIC model is currently adopting the > > >> "GIC without Security Extensions" model, which implies > > >> that we should be implementing GIC_ABPR too. What > > >> model does KVM's in-kernel vGIC use? (ie what state > > >> does it put into binary_point[0] and [1] on save/load)? > > >> > > > We put whatever the guest writes into the GICV_BPR and GICV_ABPR, but > > > the in-kernel distributor does not care about priorities at all and > > > considers all interrupts to be group 0 interrupts, which just happens to > > > work for Linux. > > > > > > So yes, we should implement the GIC_ABPR, but there's no need for it > > > yet. But, if I don't add these fields the guest will (by reading the > > > GICC_[A]BPR registers) be able to tell it was migrated, but it will not > > > influence anything on the distributor level. Therefore, by adding these > > > fields we support the kernel's limited model fully without adding a > > > bunch of code that we can't really test in real life anyhow, and it > > > doesn't prevent us from adding full grouping support later on. > > > > I agree we should have the fields for KVM's benefit. I think we > > should also add simple reads-as-written code in the TCG > > side so they're both accessible. State that the TCG implementation > > can't access is a bit weird. We should probably also call > > the fields bpr[NCPU] and abpr[NCPU] or something, so they're > > a little more self-documenting about what they represent. > > > I already added the accessors for the TCG side? oh, accessor for ABPR, got it. > > I will rename to bpr and abpr. > > -Christoffer -- Christoffer