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=-7.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 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 93A98C43461 for ; Fri, 11 Sep 2020 16:38:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3CE4322204 for ; Fri, 11 Sep 2020 16:38:55 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="gxXCtIup" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726266AbgIKQir (ORCPT ); Fri, 11 Sep 2020 12:38:47 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:28926 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726274AbgIKPMQ (ORCPT ); Fri, 11 Sep 2020 11:12:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1599837121; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=aiWmHLDD0Ad0LUM9I3Re3J2jS/emquPxE/7QtuwNOPg=; b=gxXCtIupESgbz961KIg5tC4lEmLWzKToPJBqqrL5WIchgdrsdUGifvttRW07oWQtkxCInS rLNv/SsI/azVsJHj2mLVsZ+cGXkEW22ym9M2v4+SkyUAF6rFPdvA9mj758sYLqEx90AtZp Jm+d0g8OSvLNiLA0hOM2YRmH5+4zdE8= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-200-4NT_19gWN0K2miAueSjn9w-1; Fri, 11 Sep 2020 09:53:13 -0400 X-MC-Unique: 4NT_19gWN0K2miAueSjn9w-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 62D58CD046; Fri, 11 Sep 2020 13:53:12 +0000 (UTC) Received: from [10.36.112.212] (ovpn-112-212.ams2.redhat.com [10.36.112.212]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1B1135DA2A; Fri, 11 Sep 2020 13:53:00 +0000 (UTC) Subject: Re: MSI/MSIX for VFIO platform To: Alex Williamson , Vikas Gupta Cc: Cornelia Huck , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Vikram Prakash , Srinath Mannam References: <20200910105735.1e060b95@w520.home> From: Auger Eric Message-ID: Date: Fri, 11 Sep 2020 15:52:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <20200910105735.1e060b95@w520.home> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Vikas, On 9/10/20 6:57 PM, Alex Williamson wrote: > On Thu, 10 Sep 2020 16:15:27 +0530 > Vikas Gupta wrote: > >> Hi Alex/Cornelia, >> >> We are looking for MSI interrupts for platform devices in user-space >> applications via event/poll mechanism using VFIO. >> >> Since there is no support for MSI/MSIX handling in VFIO-platform in kernel, >> it may not possible to get this feature in user-space. >> >> Is there any other way we can get this feature in user-space OR can you >> please suggest if any patch or feature is in progress for same in VFIO >> platform? >> >> Any suggestions would be helpful. > > Eric (Cc'd) is the maintainer of vfio-platform. > > vfio-platform devices don't have IRQ indexes dedicated to MSI and MSI-X > like vfio-pci devices do (technically these are PCI concepts, but I > assume we're referring generically to message signaled interrupts), but > that's simply due to the lack of standardization in platform devices. > Logically these are simply collections of edge triggered interrupts, > which the vfio device API supports generically, it's simply a matter > that the vfio bus driver exposing a vfio-platform device create an IRQ > index exposing these vectors. Thanks, I have not worked on MSI support and I am not aware of any work happening in this area. First I would recommend to look at IRQ related uapis exposed by VFIO: VFIO_DEVICE_GET_IRQ_INFO VFIO_DEVICE_SET_IRQS and try to understand if they can be implemented for MSIs in a generic way in the vfio_platform driver using platform-msi helpers. For instance VFIO_DEVICE_GET_IRQ_INFO would need to return the number of requested vectors. On init I guess we should allocate vectors using platform_msi_domain_alloc_irqs/ devm_request_irq and in the handler trigger the eventfd provided through VFIO_DEVICE_SET_IRQS. On userspace where you have to trap the MSI setup to call the above functions and setup irqfd injection. This would be device specific as opposed to PCI. That's just rough ideas at the moment. Thanks Eric > > Alex >