From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:55268)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <eric.auger@linaro.org>) id 1YvROs-0004oP-IM
	for qemu-devel@nongnu.org; Thu, 21 May 2015 10:24:46 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <eric.auger@linaro.org>) id 1YvROo-0003l2-8w
	for qemu-devel@nongnu.org; Thu, 21 May 2015 10:24:42 -0400
Received: from mail-wi0-f174.google.com ([209.85.212.174]:36002)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <eric.auger@linaro.org>) id 1YvROo-0003kr-3Q
	for qemu-devel@nongnu.org; Thu, 21 May 2015 10:24:38 -0400
Received: by wizk4 with SMTP id k4so16794854wiz.1
	for <qemu-devel@nongnu.org>; Thu, 21 May 2015 07:24:37 -0700 (PDT)
Message-ID: <555DEA9B.7070306@linaro.org>
Date: Thu, 21 May 2015 16:24:27 +0200
From: Eric Auger <eric.auger@linaro.org>
MIME-Version: 1.0
References: <1431624430-3996-1-git-send-email-ashoks@broadcom.com>
	<00c401d08eda$57394490$05abcdb0$@samsung.com>
	<555B31A4.9050708@linaro.org>
	<007101d09391$f20306d0$d6091470$@samsung.com>
	<555D9E71.5060703@linaro.org>
	<014801d093cf$da300d80$8e902880$@samsung.com>
In-Reply-To: <014801d093cf$da300d80$8e902880$@samsung.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [RFC PATCH] hw/arm/virt: Added preliminary GICv3
 support for kvm mode
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Pavel Fedin <p.fedin@samsung.com>, 'Ashok Kumar' <ashoks@broadcom.com>, qemu-devel@nongnu.org
Cc: 'Shlomo Pongratz' <shlomo.pongratz@huawei.com>

On 05/21/2015 04:10 PM, Pavel Fedin wrote:
>  Hello!
> 
>> So to me it is sensible to instantiate GICV2 through legacy
>> KVM_CREATE_IRQCHIP API if both KVM_CREATE_DEVICE(test mode=true) failed.
> 
>  I disagree because at this point we already know which GIC version the user wants. This
> is because kvm_irqchip_create() is called after machine instance is created (and
> virt_instance_init() has been called). At this point we already know all the options. At
> this point i think the scenario should be:
>  a) If we want GICv3 - test for KVM_CREATE_DEVICE(GICv3) and fail if we don't have one.
>  b) If we want GICv2 - test for KVM_CREATE_DEVICE(GICv2). If it fails, try
> KVM_CREATE_IRQCHIP.
>  IMHO there is little sense to fall back from v3 to v2 or vice versa because other
> important parameters (like number of CPUs) depend on it.
>  Implementing this behavior costs only one more integer in MachineState structure. Is it
> too large ? If you want, i can post my patches as RFC, i think now they are more or less
> OK.

Hi Pavel,

yes sure please post your RFC and let's wait for other reviewer
feedback. I just shared my understanding ;-)

Best Regards

Eric
> 
> Kind regards,
> Pavel Fedin
> Expert Engineer
> Samsung Electronics Research center Russia
> 
>