Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp5222695pxb; Tue, 28 Sep 2021 13:20:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyc+p4oBn/JkG8dAuMUzeAkm1c8OhNCYE0S8tdOIriTtH4DZ5c4ZK7t8KJzxsoduNkB2XUy X-Received: by 2002:a17:90a:af92:: with SMTP id w18mr1977722pjq.98.1632860421510; Tue, 28 Sep 2021 13:20:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632860421; cv=none; d=google.com; s=arc-20160816; b=l4ppr9zLx3+hph6126bXDmpAo3vijMQibGedtYrsLU94+2TJPX5v59HC5T1je/+Ryx sjSeFLOmDOWByyuwHtr62KXXWPPf6X7QCf/fs3k7pjhxM82wbwtIdvnt9TaiPPXqBBiU lCVmxHEb09MWPeM9WYYxYmqHDlurXPP4zyZW91zf9oLBsQlL++B2qxLnKS8pDvAfTq3k Z6PmmA882opgH314SiTuWbIUlSDLxjUmYMm64OO3n46CjlhUFod36sMqNBvZJI161ewJ HEMRZrqqqrzrrlOkVki2F4jjPUJJ5yH0iZTxkDwecmonW8+7xRu/SOxD1AZjCCholT0j So8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=6ty+2QJnNc2ErgiU8OvTWlQKFe+mg73c0FaGXapyCUI=; b=C5jabu8wiqq/2fJU632t0yDXJvm36nKO2GUY0O91GYsKppXSXz5q0FCA/U6cvWQrAa BaUwh30Xcu5YuFEqXvrNprcjGg+R63lEwQE1/dmpkRrMMJMSXmoA4mvS2OGoa4IWSr2M edyHap7o2Z3PKwHgXpBGSznY5pQ6OO1wdyC4t0jqYTnYAspKpbu6RhZmJrSLqwM5KQIV XWqAQhIMnC04WH//8jmt4AC7lCcHXBrdcDP+w4bDvZR//5w6uD+LRb25ohMLeZQOXLfw OTMWudblcLtsqcgPAclYDtDqUAYVRhFJo7HRU0BrUObrTuI4/SJfjLt0qqGXweahb2n9 +f6w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=LvO954vo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v186si153638pgd.51.2021.09.28.13.20.08; Tue, 28 Sep 2021 13:20:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=LvO954vo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242668AbhI1UU3 (ORCPT + 99 others); Tue, 28 Sep 2021 16:20:29 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:57297 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233437AbhI1UU2 (ORCPT ); Tue, 28 Sep 2021 16:20:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1632860328; 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=6ty+2QJnNc2ErgiU8OvTWlQKFe+mg73c0FaGXapyCUI=; b=LvO954vo87napXaGvSpbesqcOibkIb+6cHx72+uulazBnROn7H5eO/l7YnhhXwOjgnvkbI 2lm3jPI+3cro4AU/kiE3nA3NkqZO3FTVrG5p5YvdiyXKYtXAJyWRSLqjpH0YdbbspJbwUV DSTxrbFwt7Aqf/JCyWhpSgxr0tYWmVQ= Received: from mail-oi1-f199.google.com (mail-oi1-f199.google.com [209.85.167.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-44-0i6CuBdkOmC9OcDTweE2aw-1; Tue, 28 Sep 2021 16:18:46 -0400 X-MC-Unique: 0i6CuBdkOmC9OcDTweE2aw-1 Received: by mail-oi1-f199.google.com with SMTP id j200-20020acaebd1000000b0027357b3466aso31394oih.1 for ; Tue, 28 Sep 2021 13:18:46 -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:mime-version:content-transfer-encoding; bh=6ty+2QJnNc2ErgiU8OvTWlQKFe+mg73c0FaGXapyCUI=; b=FpXfLasxRaUAzs9IAacMGrbF4ywTOCI3wXV3otvoQi/xe9TH79Rp0No+G/IPF66Ay2 2lJfeeyj2DkheaOAOXvobp+PZDMcLAYt45ttqHX9Ks8ZP/AkxNMhFgJAEqD1iCgnSA8P IvRb1nsFUo37eiOVLScEsRJN7wk3uXfly6+SbMfpHXfhq2XDhA+d+MrFTL/k6uAdbKLJ IGUN3OnrK1OsCfLuZpJxIZknc7eyc/TMVjmJgwoz6+czT+RjkhbuNzqlvnrFstDizQWB mr51k3lbNV9MmCzZYC0O4ApOw6OyGqRKGRcK/Blg6r0f3Qud14mkM5XPvVNxAOUXzcom XS2g== X-Gm-Message-State: AOAM533pWK8UyfPZ/OarftQjdMuCxzlLC524S3z+hQfTyrqtIlFBHk4n zItGSoCM5AP/FkOz9+tQp6LuxiivQ7/UcpupLy9goDXemqjD6PagDRUfJ+BkwuhAorlKbeJ7xsz VLjmX2XH82p6EEZsSoALCxLEu X-Received: by 2002:a05:6808:1911:: with SMTP id bf17mr4993799oib.91.1632860326165; Tue, 28 Sep 2021 13:18:46 -0700 (PDT) X-Received: by 2002:a05:6808:1911:: with SMTP id bf17mr4993786oib.91.1632860325974; Tue, 28 Sep 2021 13:18:45 -0700 (PDT) Received: from redhat.com ([198.99.80.109]) by smtp.gmail.com with ESMTPSA id p18sm28234otk.7.2021.09.28.13.18.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Sep 2021 13:18:45 -0700 (PDT) Date: Tue, 28 Sep 2021 14:18:44 -0600 From: Alex Williamson To: Jason Gunthorpe Cc: Leon Romanovsky , Doug Ledford , Yishai Hadas , Bjorn Helgaas , "David S. Miller" , Jakub Kicinski , Kirti Wankhede , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, linux-rdma@vger.kernel.org, netdev@vger.kernel.org, Saeed Mahameed , Cornelia Huck Subject: Re: [PATCH mlx5-next 2/7] vfio: Add an API to check migration state transition validity Message-ID: <20210928141844.15cea787.alex.williamson@redhat.com> In-Reply-To: <20210928193550.GR3544071@ziepe.ca> References: <20210927164648.1e2d49ac.alex.williamson@redhat.com> <20210927231239.GE3544071@ziepe.ca> <20210928131958.61b3abec.alex.williamson@redhat.com> <20210928193550.GR3544071@ziepe.ca> 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 Tue, 28 Sep 2021 16:35:50 -0300 Jason Gunthorpe wrote: > On Tue, Sep 28, 2021 at 01:19:58PM -0600, Alex Williamson wrote: > > > In defining the device state, we tried to steer away from defining it > > in terms of the QEMU migration API, but rather as a set of controls > > that could be used to support that API to leave us some degree of > > independence that QEMU implementation might evolve. > > That is certainly a different perspective, it would have been > better to not express this idea as a FSM in that case... > > So each state in mlx5vf_pci_set_device_state() should call the correct > combination of (un)freeze, (un)quiesce and so on so each state > reflects a defined operation of the device? I'd expect so, for instance the implementation of entering the _STOP state presumes a previous state that where the device is apparently already quiesced. That doesn't support a direct _RUNNING -> _STOP transition where I argued in the linked threads that those states should be reachable from any other state. Thanks, Alex