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