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=-8.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_2 autolearn=unavailable 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 74614C433FE for ; Wed, 22 Sep 2021 22:45:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 53AC961100 for ; Wed, 22 Sep 2021 22:45:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238327AbhIVWqr (ORCPT ); Wed, 22 Sep 2021 18:46:47 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:55109 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229506AbhIVWqm (ORCPT ); Wed, 22 Sep 2021 18:46:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1632350711; 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=E6zD8kdwatd21Yh5voYOyt3V4ervr93MOQFFBWnGbwo=; b=SxxnBoXzMFI9V5PnNlcLYtA5kDEs1zWLDlo4O5hkOPlFLgceS+T35Nl3dd7LsLTvDNgovc YnlpS2Zsz52pIkevwCd1bZl4KXdAkrB18JiQwIRIb5pUoWMZZgmT8q9zhLAwRNjI2f2RxJ JidBhY+/c0I63xtOhHvPMGOfRUEEmpc= Received: from mail-oo1-f72.google.com (mail-oo1-f72.google.com [209.85.161.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-307-z5XUQKEvPTe-uI0iuOtRsA-1; Wed, 22 Sep 2021 18:45:10 -0400 X-MC-Unique: z5XUQKEvPTe-uI0iuOtRsA-1 Received: by mail-oo1-f72.google.com with SMTP id f16-20020a4a9210000000b002a84ff0cc9aso2571838ooh.23 for ; Wed, 22 Sep 2021 15:45:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:organization:mime-version:content-transfer-encoding; bh=E6zD8kdwatd21Yh5voYOyt3V4ervr93MOQFFBWnGbwo=; b=DeMwQlgQB6/LAcn2jH9H+SS8r3sVqFcV9R3FeGbYzHHNFits/wEr7ojzxilRZ1jESB s1k4Bcdi0pHdjw+5NvmtPV2FkF1JKPJ0LTYVhsXLJ4PGMfUb8hcgj+UhLNo7+XjkbYLX 1QcYh1qlI9KbruDB/H2WMU01pC/LQtXtB1R5t5uUXe/apWHFxP9eyx3umDvnufKuXNQx 9k1dWb2aRCGkPJ+abXG9KqVY7AY5DV9IgzBzVJHuT08McbFi/5oS3W6zyzyrJbd5TcVx NApvEGgjyn6+yqDtHt2st54EfWMwmhj8Kcuzp/uMvgKMkQQSKBYzovMUjOzMmRj6YKE8 DCxg== X-Gm-Message-State: AOAM533cpgXAFFvZCQjxYZtrH2mpoLGa3NdNdG9EspgYUvlDUGefe75Y 6sJi84WGl5tEaaQUEbB5dd/MFGUN66ySSP+jLawVC3yO9OFsPDHL2nUsDAv+l3ZRzEHitWCltXd 17fkKT8gD9+gDhdaZBRwiAqB9 X-Received: by 2002:a9d:705e:: with SMTP id x30mr1392980otj.221.1632350709669; Wed, 22 Sep 2021 15:45:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxauNjEloOgS43KwaOum7NgsKLZs/SbMjhtO3+rybjyroY+pJjDvh7BSn/x0DQg1xt7M+tqTw== X-Received: by 2002:a9d:705e:: with SMTP id x30mr1392942otj.221.1632350709347; Wed, 22 Sep 2021 15:45:09 -0700 (PDT) Received: from redhat.com ([198.99.80.109]) by smtp.gmail.com with ESMTPSA id u27sm899416otj.6.2021.09.22.15.45.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Sep 2021 15:45:08 -0700 (PDT) Date: Wed, 22 Sep 2021 16:45:06 -0600 From: Alex Williamson To: "Tian, Kevin" Cc: Jason Gunthorpe , "Liu, Yi L" , "hch@lst.de" , "jasowang@redhat.com" , "joro@8bytes.org" , "jean-philippe@linaro.org" , "parav@mellanox.com" , "lkml@metux.net" , "pbonzini@redhat.com" , "lushenming@huawei.com" , "eric.auger@redhat.com" , "corbet@lwn.net" , "Raj, Ashok" , "yi.l.liu@linux.intel.com" , "Tian, Jun J" , "Wu, Hao" , "Jiang, Dave" , "jacob.jun.pan@linux.intel.com" , "kwankhede@nvidia.com" , "robin.murphy@arm.com" , "kvm@vger.kernel.org" , "iommu@lists.linux-foundation.org" , "dwmw2@infradead.org" , "linux-kernel@vger.kernel.org" , "baolu.lu@linux.intel.com" , "david@gibson.dropbear.id.au" , "nicolinc@nvidia.com" Subject: Re: [RFC 03/20] vfio: Add vfio_[un]register_device() Message-ID: <20210922164506.66976218.alex.williamson@redhat.com> In-Reply-To: References: <20210919063848.1476776-1-yi.l.liu@intel.com> <20210919063848.1476776-4-yi.l.liu@intel.com> <20210921160108.GO327412@nvidia.com> <20210922005337.GC327412@nvidia.com> <20210922122252.GG327412@nvidia.com> <20210922141036.5cd46b2b.alex.williamson@redhat.com> Organization: Red Hat X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 22 Sep 2021 22:34:42 +0000 "Tian, Kevin" wrote: > > From: Alex Williamson > > Sent: Thursday, September 23, 2021 4:11 AM > > > > On Wed, 22 Sep 2021 09:22:52 -0300 > > Jason Gunthorpe wrote: > > > > > On Wed, Sep 22, 2021 at 09:23:34AM +0000, Tian, Kevin wrote: > > > > > > > > Providing an ioctl to bind to a normal VFIO container or group might > > > > > allow a reasonable fallback in userspace.. > > > > > > > > I didn't get this point though. An error in binding already allows the > > > > user to fall back to the group path. Why do we need introduce another > > > > ioctl to explicitly bind to container via the nongroup interface? > > > > > > New userspace still needs a fallback path if it hits the 'try and > > > fail'. Keeping the device FD open and just using a different ioctl to > > > bind to a container/group FD, which new userspace can then obtain as a > > > fallback, might be OK. > > > > > > Hard to see without going through the qemu parts, so maybe just keep > > > it in mind > > > > If we assume that the container/group/device interface is essentially > > deprecated once we have iommufd, it doesn't make a lot of sense to me > > to tack on a container/device interface just so userspace can avoid > > reverting to the fully legacy interface. > > > > But why would we create vfio device interface files at all if they > > can't work? I'm not really on board with creating a try-and-fail > > interface for a mechanism that cannot work for a given device. The > > existence of the device interface should indicate that it's supported. > > Thanks, > > > > Now it's a try-and-fail model even for devices which support iommufd. > Per Jason's suggestion, a device is always opened with a parked fops > which supports only bind. Binding serves as the contract for handling > exclusive ownership on a device and switching to normal fops if > succeed. So the user has to try-and-fail in case multiple threads attempt > to open a same device. Device which doesn't support iommufd is not > different, except binding request 100% fails (due to missing .bind_iommufd > in kernel driver). That's a rather important difference. I don't really see how that's comparable to the mutually exclusive nature of the legacy vs device interface. We're not going to present a vfio device interface for SW mdevs that can't participate in iommufd, right? Thanks, Alex