From mboxrd@z Thu Jan 1 00:00:00 1970
From: Pavel Fedin
Subject: RE: [PATCH v3 00/16] KVM: arm64: GICv3 ITS emulation
Date: Wed, 07 Oct 2015 19:05:38 +0300
Message-ID: <029601d1011a$026e1000$074a3000$@samsung.com>
References: <1444229726-31559-1-git-send-email-andre.przywara@arm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: eric.auger@linaro.org, kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org
To: 'Andre Przywara' , marc.zyngier@arm.com,
christoffer.dall@linaro.org
Return-path:
Received: from mailout4.w1.samsung.com ([210.118.77.14]:22007 "EHLO
mailout4.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
with ESMTP id S1754939AbbJGQFm (ORCPT );
Wed, 7 Oct 2015 12:05:42 -0400
Received: from eucpsbgm2.samsung.com (unknown [203.254.199.245])
by mailout4.w1.samsung.com
(Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014))
with ESMTP id <0NVU002E9Y1FD010@mailout4.w1.samsung.com> for
kvm@vger.kernel.org; Wed, 07 Oct 2015 17:05:39 +0100 (BST)
In-reply-to: <1444229726-31559-1-git-send-email-andre.przywara@arm.com>
Content-language: ru
Sender: kvm-owner@vger.kernel.org
List-ID:
Hello!
One more concern about the whole thing. I already replied to the previous series, but looks like my
reply was missed.
Your implementation does not care about live migration at all. And there's one fundamental issue
with it. In the redistributor LPIs can be only pending, but in the CPU interface they still can be
active. And they have priorities, therefore they can be preempted, so we can have even more than one
active LPI at once. How to migrate this state?
Here i am trying to prototype this by leaving active interrupts in LRs and allowing the userland to
read/write them. This looks a bit stupid, additionally this will create problems if we are e. g.
migrating from host with 8 LRs to host with 4 LRs, while having 6 active LPIs. Can anybody suggest
better solution?
Technically LPI pending table has unused bits from 0 to 8191, and we have 8192 LPIs, so we could
push active state there, just for migration. Would this be a big violation of specification? It says
nothing about these bits at all.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
From mboxrd@z Thu Jan 1 00:00:00 1970
From: p.fedin@samsung.com (Pavel Fedin)
Date: Wed, 07 Oct 2015 19:05:38 +0300
Subject: [PATCH v3 00/16] KVM: arm64: GICv3 ITS emulation
In-Reply-To: <1444229726-31559-1-git-send-email-andre.przywara@arm.com>
References: <1444229726-31559-1-git-send-email-andre.przywara@arm.com>
Message-ID: <029601d1011a$026e1000$074a3000$@samsung.com>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org
Hello!
One more concern about the whole thing. I already replied to the previous series, but looks like my
reply was missed.
Your implementation does not care about live migration at all. And there's one fundamental issue
with it. In the redistributor LPIs can be only pending, but in the CPU interface they still can be
active. And they have priorities, therefore they can be preempted, so we can have even more than one
active LPI at once. How to migrate this state?
Here i am trying to prototype this by leaving active interrupts in LRs and allowing the userland to
read/write them. This looks a bit stupid, additionally this will create problems if we are e. g.
migrating from host with 8 LRs to host with 4 LRs, while having 6 active LPIs. Can anybody suggest
better solution?
Technically LPI pending table has unused bits from 0 to 8191, and we have 8192 LPIs, so we could
push active state there, just for migration. Would this be a big violation of specification? It says
nothing about these bits at all.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia