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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 DB81AECE587 for ; Tue, 1 Oct 2019 15:38:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B285C20842 for ; Tue, 1 Oct 2019 15:38:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389651AbfJAPiy (ORCPT ); Tue, 1 Oct 2019 11:38:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39342 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727236AbfJAPix (ORCPT ); Tue, 1 Oct 2019 11:38:53 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6AB7C10C0944; Tue, 1 Oct 2019 15:38:53 +0000 (UTC) Received: from x1.home (ovpn-118-102.phx2.redhat.com [10.3.118.102]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0ACC95C226; Tue, 1 Oct 2019 15:38:52 +0000 (UTC) Date: Tue, 1 Oct 2019 09:38:52 -0600 From: Alex Williamson To: Shawn Anastasio Cc: kvm@vger.kernel.org, cohuck@redhat.com, linux-kernel@vger.kernel.org, Donald Dutile Subject: Re: [PATCH RFC 0/1] VFIO: Region-specific file descriptors Message-ID: <20191001093852.5c1d9c7c@x1.home> In-Reply-To: <20190930235533.2759-1-shawn@anastas.io> References: <20190930235533.2759-1-shawn@anastas.io> Organization: Red Hat MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.redhat.com [10.5.110.66]); Tue, 01 Oct 2019 15:38:53 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 30 Sep 2019 18:55:32 -0500 Shawn Anastasio wrote: > This patch adds region file descriptors to VFIO, a simple file descriptor type > that allows read/write/mmap operations on a single region of a VFIO device. > > This feature is particularly useful for privileged applications that use VFIO > and wish to share file descriptors with unprivileged applications without > handing over full control of the device. Such as? How do we defined "privileged"? VFIO already allows "unprivileged applications" to own a device, only file permissions are necessary for the VFIO group. Does region level granularity really allow us to claim that the consumer of this fd doesn't have full control of the device? Clearly device ioctls, including interrupts, and DMA mappings are not granted with only access to a region, but said unprivileged application may have absolute full control of the device itself via that region. > It also allows applications to use > regular offsets in read/write/mmap instead of the region index + offset that > must be used with device file descriptors. How is this actually an issue that needs a solution? > The current implementation is very raw (PCI only, no reference counting which > is probably wrong), but I wanted to get a sense to see if this feature is > desired. If it is, tips on how to implement this more correctly are > appreciated. Handling the ownership and life cycle of the region fds is the more complicated problem. If an unprivileged user has an mmap to a device owned by a privileged user, how does it get revoked by the privileged part of this equation? How do we decide which regions merit this support, for instance a device specific region could have just as viable a use case as a BAR. Why does this code limit support to regions supporting mmap but then support read/write as well? Technically, isn't the extent of functionality provided in this RFC already available via the PCI resource files in sysfs? Without a concrete use case, this looks like a solution in search of a problem. Thanks, Alex