From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Fedin Subject: RE: IRQFD support with GICv3 ITS (WAS: RE: [PATCH 00/13] arm64: KVM: GICv3 ITS emulation) Date: Wed, 17 Jun 2015 12:21:16 +0300 Message-ID: <011601d0a8de$f75b8280$e6128780$@samsung.com> References: <042601d0a357$d3cec4d0$7b6c4e70$@samsung.com> <557842A0.9070503@linaro.org> <05da01d0a392$58bf5030$0a3df090$@samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: 'Eric Auger' , 'Marc Zyngier' , 'Andre Przywara' , christoffer.dall@linaro.org Return-path: Received: from mailout2.w1.samsung.com ([210.118.77.12]:44862 "EHLO mailout2.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750909AbbFQJVU (ORCPT ); Wed, 17 Jun 2015 05:21:20 -0400 Received: from eucpsbgm1.samsung.com (unknown [203.254.199.244]) by mailout2.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0NQ300J0B0NIUX00@mailout2.w1.samsung.com> for kvm@vger.kernel.org; Wed, 17 Jun 2015 10:21:18 +0100 (BST) In-reply-to: <05da01d0a392$58bf5030$0a3df090$@samsung.com> Content-language: ru Sender: kvm-owner@vger.kernel.org List-ID: PING! The discussion has suddenly stopped... What is our status? Is ITS v2 patch being developed, or what? And do we have some conclusion on irqfd ? Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia > -----Original Message----- > From: kvm-owner@vger.kernel.org [mailto:kvm-owner@vger.kernel.org] On Behalf Of Pavel > Fedin > Sent: Wednesday, June 10, 2015 6:30 PM > To: 'Eric Auger'; 'Marc Zyngier'; 'Andre Przywara'; christoffer.dall@linaro.org > Cc: kvmarm@lists.cs.columbia.edu; linux-arm-kernel@lists.infradead.org; kvm@vger.kernel.org > Subject: RE: IRQFD support with GICv3 ITS (WAS: RE: [PATCH 00/13] arm64: KVM: GICv3 ITS > emulation) > > Hi! > > > indeed in newly added qemu kvm-all.c kvm_arch_msi_data_to_gsi we could > > call a new ioctl that translates the data + deviceid? into an LPI and > > program irqfd with that LPI. This is done once when setting irqfd up. > > This also means extending irqfd support to lpi injection, gsi being the > > LPI index if gsi >= 8192. in that case we continue using > > kvm_gsi_direct_mapping and gsi still is an IRQ index. > > This is exactly what i have done in my kernel + qemu. I have added a new KVM capability > and then in qemu i do this: > --- cut --- > if (kvm_gsi_kernel_mapping()) { > struct kvm_msi msi; > > msi.address_lo = (uint32_t)msg.address; > msi.address_hi = msg.address >> 32; > msi.data = le32_to_cpu(msg.data); > memset(msi.pad, 0, sizeof(msi.pad)); > > if (dev) { > msi.devid = (pci_bus_num(dev->bus) << 8) | dev->devfn; > msi.flags = KVM_MSI_VALID_DEVID; > } else { > msi.devid = 0; > msi.flags = 0; > } > > return kvm_vm_ioctl(s, KVM_TRANSLATE_MSI, &msi); > } > --- cut --- > KVM_TRANSLATE_MSI returns an LPI number. This seemed to be the simplest and fastest thing > to do. > If someone is interested, i could prepare an RFC patch series for this, which would apply > on top of Andre's ITS implementation. > > Kind regards, > Pavel Fedin > Expert Engineer > Samsung Electronics Research center Russia > > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html