From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43364) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ys8AG-0004N2-FY for qemu-devel@nongnu.org; Tue, 12 May 2015 07:15:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ys8AB-0003R4-F6 for qemu-devel@nongnu.org; Tue, 12 May 2015 07:15:56 -0400 Received: from mailout3.w1.samsung.com ([210.118.77.13]:63909) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ys8AB-0003QW-98 for qemu-devel@nongnu.org; Tue, 12 May 2015 07:15:51 -0400 Received: from eucpsbgm1.samsung.com (unknown [203.254.199.244]) by mailout3.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0NO800H65HYB0Z40@mailout3.w1.samsung.com> for qemu-devel@nongnu.org; Tue, 12 May 2015 12:15:47 +0100 (BST) From: Pavel Fedin References: <00c901d08990$2763c410$762b4c30$@samsung.com> <20150512092015.GF18200@redhat.com> In-reply-to: Date: Tue, 12 May 2015 14:15:46 +0300 Message-id: <039401d08ca4$ff1cd830$fd568890$@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 v2] Add virt-v3 machine that uses GIC-500 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: 'Peter Maydell' , "'Daniel P. Berrange'" Cc: 'Shlomo Pongratz' , 'QEMU Developers' Hello! > We are not. Support for GICv2 vs v3 should be dealt with > by suitable machine properties I don't remember whether i clearly wrote about it... First i added a = property, like -machine virt,gicv3=3Don. But then i decided to stick = back to different machine name because libvirt does not have mechanism = for passing machine options. > (and by figuring out how > we handle probing for which of the two the host kernel > can provide us). This is tricky. I thought about it. Kernel offers us only KVM_CAP_IRQCHIP Boolean. But it does not tell us = which irqchip. Possible variants are: a) Host with GICv2 - this can only be v2. b) Host with GICv3 with backwards compatibility option - this can be = both b) Host with GICv3 without compatibility option - this can only be v3. Perhaps we could do a probe in kvm_arch_irqchip_create(), however i'm = not sure what happens in the kernel when this is called. This call = actually instantiates the device, but drops its fd. I suggest, the = device is still created, and next attempt to do it will just return the = same fd. And i don't know what happens if we create both GICs (i cannot = test because i don't have machine capable of doing it). OTOH, if we don't have in-kernel acceleration, perhaps the good idea is = stick to what the user wants, and use emulation. Yes, i know about = problems with generic timer in this case, but this if different issue = which can also be fixed. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia