From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52071) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZP3u1-00052o-Sp for qemu-devel@nongnu.org; Tue, 11 Aug 2015 03:23:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZP3ty-0003MA-Lo for qemu-devel@nongnu.org; Tue, 11 Aug 2015 03:23:17 -0400 Received: from mailout1.w1.samsung.com ([210.118.77.11]:31843) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZP3ty-0003Lw-Fn for qemu-devel@nongnu.org; Tue, 11 Aug 2015 03:23:14 -0400 Received: from eucpsbgm2.samsung.com (unknown [203.254.199.245]) by mailout1.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0NSW00C8FPUN1100@mailout1.w1.samsung.com> for qemu-devel@nongnu.org; Tue, 11 Aug 2015 08:23:11 +0100 (BST) From: Pavel Fedin References: <797c8468e6b1fff3af01178e495f7ea437c73747.1439207299.git.p.fedin@samsung.com> In-reply-to: Date: Tue, 11 Aug 2015 10:23:09 +0300 Message-id: <00a901d0d406$93d5a990$bb80fcb0$@samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: quoted-printable Content-language: ru Subject: Re: [Qemu-devel] [PATCH v8 2/5] Extract some reusable vGIC code List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: 'Peter Maydell' Cc: 'Shlomo Pongratz' , 'Shlomo Pongratz' , 'QEMU Developers' , 'Christoffer Dall' , 'Eric Auger' Hello! > The need to add num_irq to this prototype reveals the ugliness > of it as an interface. > I don't think we gain much by making these two functions common, > and we do get a lot of churn in the existing code below. You know, i was also thinking about it. And actually there is a way to = resolve this: make some common structure holding num_irqs, num_cpus and = dev_fd, and share it between GICv2 and GICv3 code. But wouldn't this be = ugly too? So, i decided to make some compromise and leave it this way, = at least for now. Regarding the latter two functions, i thought that they are useful for = future live migration, aren't they?=20 > It would be much nicer to convert the > GIC to using named GPIO arrays for its incoming interrupt > lines, so that you can handle the different cases of SPIs > and PPIs naturally rather than exposing the awkward mapping > from multiple different sets of interrupts into a single > integer space. No no, not now. I believe this would require lots if changes in all = machne models, i'm not ready for this... Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia