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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7DB22C77B72 for ; Mon, 17 Apr 2023 20:07:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230078AbjDQUHi (ORCPT ); Mon, 17 Apr 2023 16:07:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39778 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229738AbjDQUHh (ORCPT ); Mon, 17 Apr 2023 16:07:37 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A163C46BC for ; Mon, 17 Apr 2023 13:06:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1681762007; 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=uJkreuNWxZEE44fygt5zWJA+zq6jhPLH5gKQqPjNWJQ=; b=Xla5ZkPsZPKIc6iceJ5yI579cJ/vPfYTS7feRDTt2FNYgmE4F92GfPV67YucZXjE0ao60z YQWmSaq2o/1TLchHDaHrCtzESaygjqpQus7Q4aCnzWAfVklcdGrq6vHu6AqCkRmncK5/w5 muYxHPeYsrCiyXMKxzMFWqJ6EQ0Jbjk= Received: from mail-il1-f199.google.com (mail-il1-f199.google.com [209.85.166.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-173-wmY85bN9PDOfCAo8f5Trhw-1; Mon, 17 Apr 2023 16:06:46 -0400 X-MC-Unique: wmY85bN9PDOfCAo8f5Trhw-1 Received: by mail-il1-f199.google.com with SMTP id e9e14a558f8ab-32ab644612aso10425695ab.1 for ; Mon, 17 Apr 2023 13:06:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681762005; x=1684354005; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=uJkreuNWxZEE44fygt5zWJA+zq6jhPLH5gKQqPjNWJQ=; b=kMtB22GI30Lhdn/yTWBwFV4751AyIOU6jUUMIFDdrxfh5idPrZ4GUWPYtWXqySkm/1 HOZegJvhDyLI4Hgv94tCLm1XFuQxbN3WdE0Cq9H3nzM5+wJ+gQqKGTB1oSrR6kH/vxL2 z2nsCao/Clv4ZMYmeOcwluHUnHqSrhNxR/OHIcS3uo3WbO/dA33vLMp4aDHwUJxR8ose WuHucuCvPCVDnZTluw8RJ1O8+egvMfdSFM1R4nZksFHIHrXisliv6riOvUm3GptTHlt/ YxDo2STZ+LnJhFjWqYr53ihp1ztOfwBgrBaJMUPHe25XWIipg3LmtNeNbltnYERLp3Kf DcVg== X-Gm-Message-State: AAQBX9f4HzwYv91z6RIB/8iZp8iBPROeUCWeuEbFfHwaJ3Q058UZbFqK IWECRMH5uXW2l/PAo7eWE4drZcKzdlFSufoBurvFpNoxll4FfrcpW4gP32PQv+j/5GdqwNfd64g wsQSsoToQBxKYkqKtnt7oEQ== X-Received: by 2002:a92:c9c3:0:b0:32a:ea4e:97d1 with SMTP id k3-20020a92c9c3000000b0032aea4e97d1mr5286313ilq.10.1681762005480; Mon, 17 Apr 2023 13:06:45 -0700 (PDT) X-Google-Smtp-Source: AKy350YnqbcCParzLbuNdjYNdpgBYhVf9e7CqwAl3G3qqrikIx+WLx6VM5MZjUBX5I9Y6yBJY1EJeg== X-Received: by 2002:a92:c9c3:0:b0:32a:ea4e:97d1 with SMTP id k3-20020a92c9c3000000b0032aea4e97d1mr5286281ilq.10.1681762005206; Mon, 17 Apr 2023 13:06:45 -0700 (PDT) Received: from redhat.com ([38.15.36.239]) by smtp.gmail.com with ESMTPSA id k14-20020a056e02134e00b003291bea8c7fsm3361811ilr.81.2023.04.17.13.06.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Apr 2023 13:06:44 -0700 (PDT) Date: Mon, 17 Apr 2023 14:06:42 -0600 From: Alex Williamson To: Jason Gunthorpe Cc: "Liu, Yi L" , "Tian, Kevin" , "eric.auger@redhat.com" , "joro@8bytes.org" , "robin.murphy@arm.com" , "cohuck@redhat.com" , "nicolinc@nvidia.com" , "kvm@vger.kernel.org" , "mjrosato@linux.ibm.com" , "chao.p.peng@linux.intel.com" , "yi.y.sun@linux.intel.com" , "peterx@redhat.com" , "jasowang@redhat.com" , "shameerali.kolothum.thodi@huawei.com" , "lulu@redhat.com" , "suravee.suthikulpanit@amd.com" , "intel-gvt-dev@lists.freedesktop.org" , "intel-gfx@lists.freedesktop.org" , "linux-s390@vger.kernel.org" , "Hao, Xudong" , "Zhao, Yan Y" , "Xu, Terrence" , "Jiang, Yanting" , "Duan, Zhenzhong" Subject: Re: [PATCH v3 12/12] vfio/pci: Report dev_id in VFIO_DEVICE_GET_PCI_HOT_RESET_INFO Message-ID: <20230417140642.650fc165.alex.williamson@redhat.com> In-Reply-To: References: <20230412105045.79adc83d.alex.williamson@redhat.com> <20230413120712.3b9bf42d.alex.williamson@redhat.com> <20230414111043.40c15dde.alex.williamson@redhat.com> <20230417130140.1b68082e.alex.williamson@redhat.com> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.35; 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-s390@vger.kernel.org On Mon, 17 Apr 2023 16:31:56 -0300 Jason Gunthorpe wrote: > On Mon, Apr 17, 2023 at 01:01:40PM -0600, Alex Williamson wrote: > > Yes, it's not trivial, but Jason is now proposing that we consider > > mixing groups, cdevs, and multiple iommufd_ctxs as invalid. I think > > this means that regardless of which device calls INFO, there's only one > > answer (assuming same set of devices opened, all cdev, all within same > > iommufd_ctx). Based on what I explained about my understanding of INFO2 > > and Jason agreed to, I think the output would be: > > > > flags: NOT_RESETABLE | DEV_ID > > { > > { valid devA-id, devA-BDF }, > > { valid devC-id, devC-BDF }, > > { valid devD-id, devD-BDF }, > > { invalid dev-id, devE-BDF }, > > } > > > > Here devB gets dropped because the kernel understands that devB is > > unopened, affected, and owned. It's therefore not a blocker for > > hot-reset. > > I don't think we want to drop anything because it makes the API > ill suited for the debugging purpose. > > devb should be returned with an invalid dev_id if I understand your > example. Maybe it should return with -1 as the dev_id instead of 0, to > make the debugging a bit better. > > Userspace should look at only NOT_RESETTABLE to determine if it > proceeds or not, and it should use the valid dev_id list to iterate > over the devices it has open to do the config stuff. If an affected device is owned, not opened, and not interfering with the reset, what is it adding to the API to report it for debugging purposes? I'm afraid this leads into expanding "invalid dev-id" into an errno or bitmap of error conditions that the user needs to parse. > > OTOH, devE is unopened, affected, and un-owned, and we > > previously agreed against the opportunistic un-opened/un-owned loophole. > > NOT_RESETABLE should be returned in this case, yes. > > If we want to enable userspace to use the loophole it should be an > additional flag. RESETABLE_FOR_NOW or something Ugh, please no. It's always a volatile result, but a volatile result that relies on device state outside the scope or control of the user is not even worthwhile imo. Thanks, Alex