From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4D46AC4332F for ; Thu, 10 Nov 2022 10:28:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229541AbiKJK2t (ORCPT ); Thu, 10 Nov 2022 05:28:49 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56446 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229463AbiKJK2s (ORCPT ); Thu, 10 Nov 2022 05:28:48 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C7E2E17597 for ; Thu, 10 Nov 2022 02:28:47 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 7F8CCB82164 for ; Thu, 10 Nov 2022 10:28:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2698BC433C1; Thu, 10 Nov 2022 10:28:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1668076125; bh=xXzZzs5/fLCfogb13unEvFd90Zp8K6Hd5OUAlRpv9fM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Pjk7wWdQedbJEOMbhGjbTOxS6rpJFsew3Q8W/0QQgV0USCNbRLtt1QwSP2Hh//abw ps6pfE4HuGSbOBI0rGl1l1w1CsJ9ysdXLcw3T0mybccPyn21r/OTp7uXd1HE8jImHl BGaxxrrzZZaXytbZz2VQ12ENuMLgZnTNz+UxfkgzRU7zXam5B0nVMcCdB2UfRczQrb WAVA+yU1rPpo+Wi7HUlkX3lxrM2j2j7BuZ3AECkn3LcfaGVEy7xKHhQki9s1JpACaM QkaS1AjHvlf5BmR6wOuxOfJVszD09uIDQbEV57hEWR+8vreHyqsbrpXslH/ehZodQj VWSLyPNoVHqrA== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1ot4na-0057df-Qg; Thu, 10 Nov 2022 10:28:43 +0000 Date: Thu, 10 Nov 2022 10:28:42 +0000 Message-ID: <86r0ybp0h1.wl-maz@kernel.org> From: Marc Zyngier To: "chenxiang (M)" Cc: , , , Subject: Re: [PATCH] KVM: Add system call KVM_VERIFY_MSI to verify MSI vector In-Reply-To: References: <1667894937-175291-1-git-send-email-chenxiang66@hisilicon.com> <86wn85pq8f.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: chenxiang66@hisilicon.com, alex.williamson@redhat.com, kvm@vger.kernel.org, qemu-devel@nongnu.org, linuxarm@huawei.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Wed, 09 Nov 2022 06:21:18 +0000, "chenxiang (M)" wrote: >=20 > Hi Marc, >=20 >=20 > =E5=9C=A8 2022/11/8 20:47, Marc Zyngier =E5=86=99=E9=81=93: > > On Tue, 08 Nov 2022 08:08:57 +0000, > > chenxiang wrote: > >> From: Xiang Chen > >>=20 > >> Currently the numbers of MSI vectors come from register PCI_MSI_FLAGS > >> which should be power-of-2, but in some scenaries it is not the same as > >> the number that driver requires in guest, for example, a PCI driver wa= nts > >> to allocate 6 MSI vecotrs in guest, but as the limitation, it will all= ocate > >> 8 MSI vectors. So it requires 8 MSI vectors in qemu while the driver in > >> guest only wants to allocate 6 MSI vectors. > >>=20 > >> When GICv4.1 is enabled, we can see some exception print as following = for > >> above scenaro: > >> vfio-pci 0000:3a:00.1: irq bypass producer (token 000000008f08224d) re= gistration fails:66311 > >>=20 > >> In order to verify whether a MSI vector is valid, add KVM_VERIFY_MSI t= o do > >> that. If there is a mapping, return 0, otherwise return negative value. > >>=20 > >> This is the kernel part of adding system call KVM_VERIFY_MSI. > > Exposing something that is an internal implementation detail to > > userspace feels like the absolute wrong way to solve this issue. > >=20 > > Can you please characterise the issue you're having? Is it that vfio > > tries to enable an interrupt for which there is no virtual ITS > > mapping? Shouldn't we instead try and manage this in the kernel? >=20 > Before i reported the issue to community, you gave a suggestion about > the issue, but not sure whether i misundertood your meaning. > You can refer to the link for more details about the issue. > https://lkml.kernel.org/lkml/87cze9lcut.wl-maz@kernel.org/T/ Right. It would have been helpful to mention this earlier. Anyway, I would really like this to be done without involving userspace at all. But first, can you please confirm that the VM works as expected despite the message? If that's the case, we only need to handle the case where this is a multi-MSI setup, and I think this can be done in VFIO, without involving userspace. Thanks, M. --=20 Without deviation from the norm, progress is not possible.