From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Fedin Subject: RE: [PATCH 1/7] KVM: api: add kvm_irq_routing_extended_msi Date: Mon, 06 Jul 2015 09:42:43 +0300 Message-ID: <00fd01d0b7b6$f6cf3550$e46d9ff0$@samsung.com> References: <1435592237-17924-1-git-send-email-eric.auger@linaro.org> <1435592237-17924-2-git-send-email-eric.auger@linaro.org> <011f01d0b498$6a17aeb0$3e470c10$@samsung.com> <5596503E.6040902@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 17F8B57B24 for ; Mon, 6 Jul 2015 02:31:23 -0400 (EDT) Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fe9K82vNT5qL for ; Mon, 6 Jul 2015 02:31:21 -0400 (EDT) Received: from mailout4.w1.samsung.com (mailout4.w1.samsung.com [210.118.77.14]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 3421757B05 for ; Mon, 6 Jul 2015 02:31:20 -0400 (EDT) Received: from eucpsbgm1.samsung.com (unknown [203.254.199.244]) by mailout4.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0NR100KYCZZ8HR40@mailout4.w1.samsung.com> for kvmarm@lists.cs.columbia.edu; Mon, 06 Jul 2015 07:42:44 +0100 (BST) In-reply-to: <5596503E.6040902@arm.com> Content-language: ru List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu To: 'Andre Przywara' , 'Eric Auger' , eric.auger@st.com, linux-arm-kernel@lists.infradead.org, 'Marc Zyngier' , christoffer.dall@linaro.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org Cc: pbonzini@redhat.com, linux-kernel@vger.kernel.org List-Id: kvmarm@lists.cs.columbia.edu Hello! > I like this approach, but it runs into problems: > As you read above the current documentation says that the flags field > must be zero and the current KVM_SET_GSI_ROUTING handler bails out if it > isn't. So userland would need to know whether it's safe to set that > field. This problem does not exist because: a) Older platforms do not need this flag, so they expect to get zero. b) ARM64 + GICv3 platform cannot work without this flag. This is perfectly OK combination IMO. Userland just knows, whether it needs to supply device ID or not. For example, my modified qemu now has kvm_msi_flags global variable which defaults to 0. ITS code, then, if activated, changes it to KVM_MSI_VALID_DEVID, and qemu starts supplying device IDs to the related calls. 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: Mon, 06 Jul 2015 09:42:43 +0300 Subject: [PATCH 1/7] KVM: api: add kvm_irq_routing_extended_msi In-Reply-To: <5596503E.6040902@arm.com> References: <1435592237-17924-1-git-send-email-eric.auger@linaro.org> <1435592237-17924-2-git-send-email-eric.auger@linaro.org> <011f01d0b498$6a17aeb0$3e470c10$@samsung.com> <5596503E.6040902@arm.com> Message-ID: <00fd01d0b7b6$f6cf3550$e46d9ff0$@samsung.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hello! > I like this approach, but it runs into problems: > As you read above the current documentation says that the flags field > must be zero and the current KVM_SET_GSI_ROUTING handler bails out if it > isn't. So userland would need to know whether it's safe to set that > field. This problem does not exist because: a) Older platforms do not need this flag, so they expect to get zero. b) ARM64 + GICv3 platform cannot work without this flag. This is perfectly OK combination IMO. Userland just knows, whether it needs to supply device ID or not. For example, my modified qemu now has kvm_msi_flags global variable which defaults to 0. ITS code, then, if activated, changes it to KVM_MSI_VALID_DEVID, and qemu starts supplying device IDs to the related calls. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753450AbbGFGm5 (ORCPT ); Mon, 6 Jul 2015 02:42:57 -0400 Received: from mailout4.w1.samsung.com ([210.118.77.14]:56512 "EHLO mailout4.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751349AbbGFGmr (ORCPT ); Mon, 6 Jul 2015 02:42:47 -0400 X-AuditID: cbfec7f4-f79c56d0000012ee-ed-559a2364294f From: Pavel Fedin To: "'Andre Przywara'" , "'Eric Auger'" , eric.auger@st.com, linux-arm-kernel@lists.infradead.org, "'Marc Zyngier'" , christoffer.dall@linaro.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org Cc: linux-kernel@vger.kernel.org, pbonzini@redhat.com References: <1435592237-17924-1-git-send-email-eric.auger@linaro.org> <1435592237-17924-2-git-send-email-eric.auger@linaro.org> <011f01d0b498$6a17aeb0$3e470c10$@samsung.com> <5596503E.6040902@arm.com> In-reply-to: <5596503E.6040902@arm.com> Subject: RE: [PATCH 1/7] KVM: api: add kvm_irq_routing_extended_msi Date: Mon, 06 Jul 2015 09:42:43 +0300 Message-id: <00fd01d0b7b6$f6cf3550$e46d9ff0$@samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-index: AQIj+X5s5FdAGWwAOFAf7dE3NOV/zwG0/EgbAfNFYEkCdP68yJz2jyRg Content-language: ru X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOIsWRmVeSWpSXmKPExsVy+t/xK7opyrNCDeadNbZYMe8no8WL1/8Y LeZvOcNqcXXzWSaLOVMLLT6eOs5usenxNVaLy7vmsFn8vfOPzWL/tn+sDlwea+atYfS4c20P m8f5TWuYPTYvqfd4v+8qm8fTH3uZPT5vkgtgj+KySUnNySxLLdK3S+DKWLDrB2vBR7aKf4uX sDYwHmTtYuTkkBAwkTj45x8zhC0mceHeerYuRi4OIYGljBKn3q1kh3C+M0pc39zMCFLFJqAu cfrrBxaQhIhAJ5PE3rvHWEASzAKmEm8XrWaG6DjDKLFkcz9YBydQR+udO+wgtrCAs8Sq/wfA 9rEIqErM/dHO1MXIwcErYCkx96gKSJhXQFDix+R7UDO1JNbvPM4EYctLbF7zFupUBYkdZ18z grSKCLhJXH0QAFEiIjHt3z3mCYxCs5BMmoVk0iwkk2YhaVnAyLKKUTS1NLmgOCk911CvODG3 uDQvXS85P3cTIyS6vuxgXHzM6hCjAAejEg9vRM3MUCHWxLLiytxDjBIczEoivIu5ZoUK8aYk VlalFuXHF5XmpBYfYpTmYFES5527632IkEB6YklqdmpqQWoRTJaJg1OqgZFF5k6R7Ezly339 t/f4ic1JWhwpGq7cPbVp/iO9qJcr9BkOCHT/El3zV+JB0c9nCmF7pDZd5hb98TU7tzchPLZK 7sBa5a1RBi1VPGuPXnn4cuskmZWf03wv7534UJ7Pu8CWe6dAY2BHibzTi/fJDql/1EWK/Y7k XHVw5py8p+Ct24mZqie75iuxFGckGmoxFxUnAgCpYN1xqgIAAA== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello! > I like this approach, but it runs into problems: > As you read above the current documentation says that the flags field > must be zero and the current KVM_SET_GSI_ROUTING handler bails out if it > isn't. So userland would need to know whether it's safe to set that > field. This problem does not exist because: a) Older platforms do not need this flag, so they expect to get zero. b) ARM64 + GICv3 platform cannot work without this flag. This is perfectly OK combination IMO. Userland just knows, whether it needs to supply device ID or not. For example, my modified qemu now has kvm_msi_flags global variable which defaults to 0. ITS code, then, if activated, changes it to KVM_MSI_VALID_DEVID, and qemu starts supplying device IDs to the related calls. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia