From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35752) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zouf9-00088o-IZ for qemu-devel@nongnu.org; Wed, 21 Oct 2015 10:46:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zouf5-0004N1-07 for qemu-devel@nongnu.org; Wed, 21 Oct 2015 10:46:46 -0400 Received: from mail-vk0-f45.google.com ([209.85.213.45]:33032) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zouf4-0004Mu-Ru for qemu-devel@nongnu.org; Wed, 21 Oct 2015 10:46:42 -0400 Received: by vkgy127 with SMTP id y127so30255978vkg.0 for ; Wed, 21 Oct 2015 07:46:42 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <01ba01d10c0e$9ebbfa90$dc33efb0$@samsung.com> References: <1445361732-16257-1-git-send-email-shlomopongratz@gmail.com> <1445361732-16257-7-git-send-email-shlomopongratz@gmail.com> <014301d10bfe$20c00970$62401c50$@samsung.com> <015801d10c02$1c60d130$55227390$@samsung.com> <016c01d10c07$3b156fa0$b1404ee0$@samsung.com> <019c01d10c0c$83292e30$897b8a90$@samsung.com> <01ba01d10c0e$9ebbfa90$dc33efb0$@samsung.com> From: Peter Maydell Date: Wed, 21 Oct 2015 15:46:22 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH RFC V5 6/9] hw/intc: arm_gicv3_spi_its List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Pavel Fedin Cc: Eric Auger , Shlomo Pongratz , Shlomo Pongratz , QEMU Developers , Shannon Zhao , Ashok Kumar , Igor Mammedov On 21 October 2015 at 15:41, Pavel Fedin wrote: > Hello! > >> I just wanted to understand. I don't have any preferences. > > In other words, in short: spec says that ITS is optional, so > we can implement it as a separate component, which gets attached > to the GIC using some specified interface. It's not a problem > to design such an interface. Actually, i believe real HW does > the same thing. For hw it's a design choice: hardware can either have the ITS as an extra component on the side that only talks to the redistributors via (impdef) redistributor registers; or it can be an integrated part of the GIC that's just directly connected internally. For QEMU we could in theory do either; I was leaning towards direct connection just because on the KVM side the in-kernel GIC isn't going to separate them out as two distinct things. But even there we can as you say sensibly model the ITS as its own QOM object with a fairly well-defined interface to the rest of the GIC. thanks -- PMM