Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752664AbbGFPJv (ORCPT ); Mon, 6 Jul 2015 11:09:51 -0400 Received: from cam-admin0.cambridge.arm.com ([217.140.96.50]:51223 "EHLO cam-admin0.cambridge.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752148AbbGFPJs (ORCPT ); Mon, 6 Jul 2015 11:09:48 -0400 Subject: Re: [PATCH 1/7] KVM: api: add kvm_irq_routing_extended_msi To: Christoffer Dall References: <1435592237-17924-2-git-send-email-eric.auger@linaro.org> <011f01d0b498$6a17aeb0$3e470c10$@samsung.com> <5596503E.6040902@arm.com> <00fd01d0b7b6$f6cf3550$e46d9ff0$@samsung.com> <559A3C9C.6050302@arm.com> <20150706093026.GA11590@cbox> <559A52E6.5050402@arm.com> <20150706103755.GC11590@cbox> <559A6164.1000401@redhat.com> <559A6527.1040107@arm.com> <20150706120837.GA13530@cbox> Cc: Paolo Bonzini , Pavel Fedin , "'Eric Auger'" , "eric.auger@st.com" , "linux-arm-kernel@lists.infradead.org" , Marc Zyngier , "kvmarm@lists.cs.columbia.edu" , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" From: Andre Przywara X-Enigmail-Draft-Status: N1110 Organization: ARM Ltd. Message-ID: <559A9A18.806@arm.com> Date: Mon, 6 Jul 2015 16:09:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <20150706120837.GA13530@cbox> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2366 Lines: 55 On 06/07/15 13:08, Christoffer Dall wrote: > On Mon, Jul 06, 2015 at 12:23:19PM +0100, Andre Przywara wrote: >> Hi Paolo, >> >> thanks for looking at this! >> >> On 06/07/15 12:07, Paolo Bonzini wrote: >>> >>> >>> On 06/07/2015 12:37, Christoffer Dall wrote: >>>> I don't view it as 'the kernel requires this' but as 'the kernel will >>>> not complain with arbitrary error code if you set the devid flag' >>>> capability, and it's up to userspace (as usual) to provide the correct >>>> arguments for things to work, and up to the kernel to ensure we don't >>>> crash the system etc. >>>> >>>> Thus, if you want to advertise it as a capability, I would rather call >>>> it KVM_CAP_MSI_DEVID. >>> >>> I agree. Does userspace know that ITS guests always require devid? >> >> Well, as we are about to implement this: yes. But the issue is that MSI >> injection and GSI routing code is generic PCI code in userland (at least >> in kvmtool, guess in QEMU, too), so I don't want to pull in any kind of >> ARM specific code in there. The idea is to always provide the device ID >> from the PCI code (for PCI devices it's just the B/D/F triplet), but >> only send it to the kernel if needed. Querying a KVM capability is >> perfectly fine for this IMO. >> >>> I >>> guess it's okay to return -EINVAL if the userspace doesn't set the flag >>> but the virtual hardware requires it. >> >> Yes, that is what I do in the kernel implementation. And that is >> perfectly fine: the ITS emulation does not work without a device ID, the >> ITS driver in the guest assigns the very same payload (and address) to >> different devices, so there is no way to tell the MSIs apart without a >> unique device ID. >> > Just so I'm sure I understand: The way the kernel differentiates between > no-devid and devid==0, is whether or not the devid flag is set, correct? Yes, that is the idea. The plan for the implementation is like this: 1) If the kernel does not need the device ID (x86, GICv2M), it does not care about the flag or the value at all. 2) In case for ITS on ARM64, the kernel returns an error is the flag is not set. Cheers, Andre. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/