From patchwork Thu Jun 27 05:02:31 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexey Kardashevskiy X-Patchwork-Id: 254953 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id A18ED2C052B for ; Thu, 27 Jun 2013 15:05:28 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752340Ab3F0FDV (ORCPT ); Thu, 27 Jun 2013 01:03:21 -0400 Received: from mail-pd0-f171.google.com ([209.85.192.171]:34242 "EHLO mail-pd0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752306Ab3F0FDP (ORCPT ); Thu, 27 Jun 2013 01:03:15 -0400 Received: by mail-pd0-f171.google.com with SMTP id y14so163412pdi.16 for ; Wed, 26 Jun 2013 22:03:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references :x-gm-message-state; bh=CnGUzszYJio7RM4M0kfrW2QE5mxscKQT8X7KZi78rbo=; b=E5ONggNrttcWSs0yaHY9mfN6CRge+HBZS/l8kx0GeXK3GRO3iPCOVgRFI6bruq10pS 2/zHC6YpR8DepVWJQN6KO5zFu0s23aqsk7OQ+W5mt6813bxjo0firy0nsLn+j4ipukMJ JFyjXcRDA56R3CWCvXNJpg2pgJBF+XQIejThfCyvzBIL5gyrFNOWv0PgoE9Dlp/kw49i c5DNN8/GhIG/c4Y6ePunuiSbjZORXMjt5vmAo/blAzcrWympT11sGcPLEKM85YRi4pyB XwxxwMqCE89HOrmGYCZ3XHLskCM9zOHnLNsdsdH8SXpOe20DahVUeVW0TlCfNbdDg97m qBdg== X-Received: by 10.68.184.100 with SMTP id et4mr4159130pbc.48.1372309394918; Wed, 26 Jun 2013 22:03:14 -0700 (PDT) Received: from ka1.ozlabs.ibm.com (ibmaus65.lnk.telstra.net. [165.228.126.9]) by mx.google.com with ESMTPSA id ve3sm1377120pbc.14.2013.06.26.22.03.07 for (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Jun 2013 22:03:13 -0700 (PDT) From: Alexey Kardashevskiy To: linuxppc-dev@lists.ozlabs.org Cc: Alexey Kardashevskiy , David Gibson , Benjamin Herrenschmidt , Alexander Graf , Paul Mackerras , Alex Williamson , "Paul E . McKenney" , kvm@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, kvm-ppc@vger.kernel.org Subject: [PATCH 3/8] vfio: add external user support Date: Thu, 27 Jun 2013 15:02:31 +1000 Message-Id: <1372309356-28320-4-git-send-email-aik@ozlabs.ru> X-Mailer: git-send-email 1.7.10.4 In-Reply-To: <1372309356-28320-1-git-send-email-aik@ozlabs.ru> References: <1372309356-28320-1-git-send-email-aik@ozlabs.ru> X-Gm-Message-State: ALoCoQlg8Uertwjtjp8hSlDx7wY4UD2j/70fzhiDYff9/BMnP1Ao7vXzp7fHItNwjrTFvIo6HMoP Sender: kvm-ppc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm-ppc@vger.kernel.org VFIO is designed to be used via ioctls on file descriptors returned by VFIO. However in some situations support for an external user is required. The first user is KVM on PPC64 (SPAPR TCE protocol) which is going to use the existing VFIO groups for exclusive access in real/virtual mode in the host kernel to avoid passing map/unmap requests to the user space which would made things pretty slow. The proposed protocol includes: 1. do normal VFIO init stuff such as opening a new container, attaching group(s) to it, setting an IOMMU driver for a container. When IOMMU is set for a container, all groups in it are considered ready to use by an external user. 2. pass a fd of the group we want to accelerate to KVM. KVM calls vfio_group_iommu_id_from_file() to verify if the group is initialized and IOMMU is set for it. The current TCE IOMMU driver marks the whole IOMMU table as busy when IOMMU is set for a container what this prevents other DMA users from allocating from it so it is safe to pass the group to the user space. 3. KVM increases the container users counter via vfio_group_add_external_user(). This prevents the VFIO group from being disposed prior to exiting KVM. 4. When KVM is finished and doing cleanup, it releases the group file and decrements the container users counter. Everything gets released. 5. KVM also keeps the group file as otherwise its fd might have been closed at the moment of KVM finish so vfio_group_del_external_user() call will not be possible. The "vfio: Limit group opens" patch is also required for the consistency. Signed-off-by: Alexey Kardashevskiy --- drivers/vfio/vfio.c | 53 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 53 insertions(+) diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c index c488da5..54192b2 100644 --- a/drivers/vfio/vfio.c +++ b/drivers/vfio/vfio.c @@ -1370,6 +1370,59 @@ static const struct file_operations vfio_device_fops = { }; /** + * External user API, exported by symbols to be linked dynamically. + */ + +/* Allows an external user (for example, KVM) to lock an IOMMU group */ +static int vfio_group_add_external_user(struct file *filep) +{ + struct vfio_group *group = filep->private_data; + + if (filep->f_op != &vfio_group_fops) + return -EINVAL; + + if (!atomic_inc_not_zero(&group->container_users)) + return -EINVAL; + + return 0; +} +EXPORT_SYMBOL_GPL(vfio_group_add_external_user); + +/* Allows an external user (for example, KVM) to unlock an IOMMU group */ +static void vfio_group_del_external_user(struct file *filep) +{ + struct vfio_group *group = filep->private_data; + + BUG_ON(filep->f_op != &vfio_group_fops); + + vfio_group_try_dissolve_container(group); +} +EXPORT_SYMBOL_GPL(vfio_group_del_external_user); + +/* + * Checks if a group for the specified file can be used by + * an external user and returns the IOMMU ID if external use is possible. + */ +static int vfio_group_iommu_id_from_file(struct file *filep) +{ + int ret; + struct vfio_group *group = filep->private_data; + + if (WARN_ON(filep->f_op != &vfio_group_fops)) + return -EINVAL; + + if (0 == atomic_read(&group->container_users) || + !group->container->iommu_driver || + !vfio_group_viable(group)) + return -EINVAL; + + ret = iommu_group_id(group->iommu_group); + + return ret; +} +EXPORT_SYMBOL_GPL(vfio_group_iommu_id_from_file); + +/** * Module/class support */ static char *vfio_devnode(struct device *dev, umode_t *mode)