From patchwork Thu Mar 15 21:31:27 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alex Williamson X-Patchwork-Id: 886473 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=nongnu.org (client-ip=2001:4830:134:3::11; helo=lists.gnu.org; envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=redhat.com Received: from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 402MHm44P7z9sVX for ; Fri, 16 Mar 2018 08:32:19 +1100 (AEDT) Received: from localhost ([::1]:53458 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ewaTw-0007OI-4u for incoming@patchwork.ozlabs.org; Thu, 15 Mar 2018 17:32:16 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55334) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ewaTM-0007O4-K9 for qemu-devel@nongnu.org; Thu, 15 Mar 2018 17:31:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ewaTI-0001Ul-Ll for qemu-devel@nongnu.org; Thu, 15 Mar 2018 17:31:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38080) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ewaTI-0001Tr-Fa for qemu-devel@nongnu.org; Thu, 15 Mar 2018 17:31:36 -0400 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 718D5272AC; Thu, 15 Mar 2018 21:31:35 +0000 (UTC) Received: from gimli.home (ovpn-117-203.phx2.redhat.com [10.3.117.203]) by smtp.corp.redhat.com (Postfix) with ESMTP id C109560BE5; Thu, 15 Mar 2018 21:31:27 +0000 (UTC) From: Alex Williamson To: kvm@vger.kernel.org Date: Thu, 15 Mar 2018 15:31:27 -0600 Message-ID: <20180315212634.15150.88094.stgit@gimli.home> User-Agent: StGit/0.18-102-gdf9f MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Thu, 15 Mar 2018 21:31:35 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PATCH v2 0/3] vfio/pci: ioeventfd support X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: aik@ozlabs.ru, linux-kernel@vger.kernel.org, peterx@redhat.com, qemu-devel@nongnu.org, eric.auger@redhat.com, alex.williamson@redhat.com Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" A vfio ioeventfd will perform the pre-specified device write on triggering of an eventfd. When coupled with KVM ioeventfds, this feature allows a VM to trap a device page for virtualization, while also registering targeted ioeventfds to maintain performance of high frequency register writes within the trapped range. Much like the existing interrupt eventfd/irqfd coupling, such writes can be handled entirely in the host kernel. The new VFIO device ioctl may be supported by any vfio bus driver, including mdev drivers, but the implementation here only enables vfio-pci. This is intended as an acceleration path, bus drivers may choose which regions to support and userspace should always intend to fall back to non-accelerated handling when unavailable. v1->v2: * Peter & Eric Sign-offs on 1/3 * mutex_destroy() in 3/3 * Slight enhancement to uapi description * sparse clean - Sparse didn't like that we dropped the __iomem address space when calling iowriteXX, re-adding it via the opaque and data pointers of the virq was crude, and that was not a 32-bit friendly soluion anyway, so add the iomem address to our ioeventfd struct, pass that, and use a more simple, common handler. RFC->v1: * An arbitrary limit is added for the number of ioeventfds supported per device. The intention is to set this high enough to allow any reasonable use case, but limit malicious user behavior. * Split patches, including adding a patch for endian neutral io reads and writes. This should be a nop for little-endian and avoid redundant swap on big-endian, and hopefully resolves Alexey's comments regarding the endian nature of this interface. * Rebase to v4.16-rc3 Thanks, Alex Reviewed-by: Alexey Kardashevskiy --- Alex Williamson (3): vfio/pci: Pull BAR mapping setup from read-write path vfio/pci: Use endian neutral helpers vfio/pci: Add ioeventfd support drivers/vfio/pci/vfio_pci.c | 35 +++++++ drivers/vfio/pci/vfio_pci_private.h | 19 ++++ drivers/vfio/pci/vfio_pci_rdwr.c | 184 +++++++++++++++++++++++++++++++---- include/uapi/linux/vfio.h | 27 +++++ 4 files changed, 245 insertions(+), 20 deletions(-)