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 933C0C4332F for ; Sat, 26 Nov 2022 11:15:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229551AbiKZLP3 (ORCPT ); Sat, 26 Nov 2022 06:15:29 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51670 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229529AbiKZLP2 (ORCPT ); Sat, 26 Nov 2022 06:15:28 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 92B0019008 for ; Sat, 26 Nov 2022 03:15:27 -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 4EC6BB801BC for ; Sat, 26 Nov 2022 11:15:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1450BC433D6; Sat, 26 Nov 2022 11:15:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1669461325; bh=CJAmRDS9cd6CrI/gMmLKX+4f1bK7TbWQc+x0LimLB8s=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=dZGzK9iz5nZTsy2Wy3E6c/ZT/64S/VEEkMa2Ca7SdtqkNHNHcnkQlTk/ZRRAtMoXE PAw1lfJpRyVa7/qFdBCOJqwozMIQiiNAj2SXtT+yvdx3os3KLHRo0rBZ9aviSxvoaT 4IB5aBONrilTTGdQ8elQ1arAehG1UPMyS00Qmrh/tIwf3Fyn9IMWeLyIWr/TVSG3qS n9SAMIzksW2s21xXBpjcKJAg2gz2S3F0qbwcfDteJvNI45I61dev721560IaM0fR5H axCXc6PFkihRgyS3TMNcBTMTHOTPRk52ORxWVW1+kayo5hGbiqzbUWZhWLINtxct5P Jsblw5dPCEdiw== Received: from sofa.misterjones.org ([185.219.108.64] helo=wait-a-minute.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 1oyt9W-008hss-R0; Sat, 26 Nov 2022 11:15:22 +0000 Date: Sat, 26 Nov 2022 11:15:14 +0000 Message-ID: <871qpquful.wl-maz@kernel.org> From: Marc Zyngier To: Jason Gunthorpe Cc: chenxiang , alex.williamson@redhat.com, kvm@vger.kernel.org, qemu-devel@nongnu.org, linuxarm@huawei.com Subject: Re: [PATCH v2] vfio/pci: Verify each MSI vector to avoid invalid MSI vectors In-Reply-To: References: <1669167756-196788-1-git-send-email-chenxiang66@hisilicon.com> 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 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: jgg@ziepe.ca, 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 Thu, 24 Nov 2022 18:00:44 +0000, Jason Gunthorpe wrote: > > On Wed, Nov 23, 2022 at 09:42:36AM +0800, chenxiang via wrote: > > From: Xiang Chen > > > > Currently the number of MSI vectors comes from register PCI_MSI_FLAGS > > which should be power-of-2 in qemu, in some scenaries it is not the same as > > the number that driver requires in guest, for example, a PCI driver wants > > to allocate 6 MSI vecotrs in guest, but as the limitation, it will allocate > > 8 MSI vectors. So it requires 8 MSI vectors in qemu while the driver in > > guest only wants to allocate 6 MSI vectors. > > > > When GICv4.1 is enabled, it iterates over all possible MSIs and enable the > > forwarding while the guest has only created some of mappings in the virtual > > ITS, so some calls fail. The exception print is as following: > > vfio-pci 0000:3a:00.1: irq bypass producer (token 000000008f08224d) registration > > fails:66311 > > With Thomas's series to make MSI more dynamic this could spell future > problems, as future kernels might have different ordering. Enabling MSIs on the endpoint before they are programmed in the interrupt controller? I don't think that's a realistic outcome. > It is just architecturally wrong to tie the MSI programming at the PCI > level with the current state of the guest's virtual interrupt > controller. There is no architectural ties between the two at all. There is an optimisation that allows direct injection if you do it in a non braindead order. Nothing breaks if you don't, you just have wasted memory, performance, power and area. You're welcome. > Physical hardware doesn't do this, virtual emulation shouldn't either. If you want to fix VFIO, be my guest. My rambling about the sorry state of this has been in the kernel for 5 years (ed8703a506a8). > People are taking too many liberties with trapping the PCI MSI > registers through VFIO. :( Do you really want to leave access to the MSI BAR to userspace? The number of ways this can go wrong is mind-boggling. Starting with having to rebuild the interrupt translation tables on the host side to follow what the guest does, instead of keeping the two independent. M. -- Without deviation from the norm, progress is not possible.