From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoffer Dall Subject: Re: [PATCH 3/3] KVM: arm64: Implement accessors for vGIC CPU interface registers Date: Mon, 31 Aug 2015 11:01:26 +0200 Message-ID: <20150831090126.GJ24113@cbox> References: <2857f7cad7c17109dfa3028f79af28893c0171ce.1440766141.git.p.fedin@samsung.com> <20150830165015.GE24113@cbox> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Pavel Fedin , Marc Zyngier , "kvmarm@lists.cs.columbia.edu" , kvm-devel To: Peter Maydell Return-path: Received: from mail-lb0-f180.google.com ([209.85.217.180]:36851 "EHLO mail-lb0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751903AbbHaJAG (ORCPT ); Mon, 31 Aug 2015 05:00:06 -0400 Received: by lbvd4 with SMTP id d4so20534976lbv.3 for ; Mon, 31 Aug 2015 02:00:03 -0700 (PDT) Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On Sun, Aug 30, 2015 at 07:39:05PM +0100, Peter Maydell wrote: > On 30 August 2015 at 17:50, Christoffer Dall > wrote: > > I had imagined we would encode the GICv3 register accesses through the > > device API and not through the system register API, since I'm not crazy > > about polluting the general system register handling logic with GIC > > registers solely for the purposes of migration. > > There's an interesting design question lurking under this > about the extent to which you expose the h/w design split > between the CPU interface and the GIC proper as part of the > KVM APIs. I'm inclined to agree that it's better to for our > purposes treat both bits as just part of an irqchip device, > but I haven't given it a great deal of thought. Me neither, and I intended to start a discussion around this with my e-mail. But as I stated above, I think it will be easier to manage if the state belongs to the device, in general, but I have fairly little insight into how this is going to be implemented in QEMU at this point. But for the GICv2 implementation, it certainly made a lot of sense to only deal with one device and file descriptor when getting/setting the state. > > (Similarly in the QEMU emulated-GICv3 case you could also > split the CPU i/f more formally, or not. The kernel's choice > would have implications for which way QEMU ends up going, > I think.) > Thanks, -Christoffer