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 X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 033F9C49EA6 for ; Thu, 24 Jun 2021 17:00:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CFBDE6100A for ; Thu, 24 Jun 2021 17:00:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230450AbhFXRC7 (ORCPT ); Thu, 24 Jun 2021 13:02:59 -0400 Received: from mga03.intel.com ([134.134.136.65]:41012 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229445AbhFXRC6 (ORCPT ); Thu, 24 Jun 2021 13:02:58 -0400 IronPort-SDR: 2qg1F7AqXMLaduBvZ9EDqAEMEP2Qgny62S8tBcP3pzyPF6zC27tytp69JNMYReZaUkgk/2hKZY T4bLPDkx2TbQ== X-IronPort-AV: E=McAfee;i="6200,9189,10025"; a="207552777" X-IronPort-AV: E=Sophos;i="5.83,296,1616482800"; d="scan'208";a="207552777" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Jun 2021 10:00:29 -0700 IronPort-SDR: vNQhrnzkoU+nttCQvWuDFgP9ciM245PNH7OvUhhQTYmvsowoak6ujOAO5lfoBE9tW8J0Oxyve5 yWYxPI3kP4zw== X-IronPort-AV: E=Sophos;i="5.83,296,1616482800"; d="scan'208";a="407097549" Received: from jacob-builder.jf.intel.com (HELO jacob-builder) ([10.7.199.155]) by orsmga003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Jun 2021 10:00:27 -0700 Date: Thu, 24 Jun 2021 10:03:16 -0700 From: Jacob Pan To: "Tian, Kevin" Cc: Thomas Gleixner , Alex Williamson , Jason Gunthorpe , "Dey, Megha" , "Raj, Ashok" , "Jiang, Dave" , "Liu, Yi L" , "Lu, Baolu" , "Williams, Dan J" , "Luck, Tony" , "Kumar, Sanjay K" , LKML , KVM , Kirti Wankhede , Peter Zijlstra , Marc Zyngier , Bjorn Helgaas , jacob.jun.pan@intel.com Subject: Re: Virtualizing MSI-X on IMS via VFIO Message-ID: <20210624100316.1c1c4c6f@jacob-builder> In-Reply-To: References: <20210622131217.76b28f6f.alex.williamson@redhat.com> <87o8bxcuxv.ffs@nanos.tec.linutronix.de> <87bl7wczkp.ffs@nanos.tec.linutronix.de> <87tuloawm0.ffs@nanos.tec.linutronix.de> Organization: OTC X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org Hi Kevin, On Wed, 23 Jun 2021 19:41:24 -0700, "Tian, Kevin" wrote: > > > 1) Fix the lost interrupt issue in existing MSI virtualization flow; > > > > > > > That _cannot_ be fixed without a hypercall. See my reply to Alex. > > The lost interrupt issue was caused due to resizing based on stale > impression of vector exhaustion. Is it possible to mitigate the lost interrupt by always injecting an IRQ after unmask? Either in VFIO layer, or let QEMU do that after the second VFIO_DEVICE_SET_IRQS in step 4.b of your original email. After all, spurious interrupts should be tolerated and unmasking MSI-x should be rare. I am not suggesting this as an alternative to the real fix, just a stop gap. Thanks, Jacob