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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 820E2C433FE for ; Thu, 30 Sep 2021 17:01:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6B0B5610A2 for ; Thu, 30 Sep 2021 17:01:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352457AbhI3RD3 (ORCPT ); Thu, 30 Sep 2021 13:03:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44230 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344773AbhI3RD3 (ORCPT ); Thu, 30 Sep 2021 13:03:29 -0400 Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 564AFC06176C for ; Thu, 30 Sep 2021 10:01:46 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id x9so6422719qtv.0 for ; Thu, 30 Sep 2021 10:01:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=4vHHMFNBH4hAm5F563BvE8+3o+7NJnRDr/RUjwsUT7o=; b=QGIRkmLfQXIeyUEAHPlvDndXmMMIAMxSXtZXhhRKYvklIE9s9V0mxKkMNZc361fu2+ /oV28Ti2mLOszUCQtAVFm+lO7hdx7RISinOyXEgG679jauOsPEZJsDn97BSKI/Y+XZGn nvKzE18TgoAr5yYwzqF0BLBR/d2XlDNYCnfE8BWTl7rPF2hP87rXsdSJGEEz4xNJo7IA XD/7Y7rdo0+4GJu9Kcd/XwUsO2juMuUKx3MqXsyQc6zYkSOTMavlqDYBTbIG5C39TIF8 RnCcanamumbSy2k6pKQ2iu96IWFTPNHP8Dtw3MHS8f+D1FklgeJFEug0i3XEm+5ai9kb OSaA== 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:references :mime-version:content-disposition:in-reply-to; bh=4vHHMFNBH4hAm5F563BvE8+3o+7NJnRDr/RUjwsUT7o=; b=nx98jmQvPoiwgI5Ua38NMsiZmkizFXj6ynvxWz1dIle2kWa9LsKfvv2q6prD0XtkBx hEJeHxavltZFS3iZ8RwXDnZpdh/4RkDAO+hrB+84tBgl+kbZx6Cb9yi6Hhj5UI69qX6V 3h1V4VTlQKq4zWaOvbBXUPibbmsPziRBTTIG6rgzweAX3uxXUj4DZMi+EsLbx2SOpH5V yP7aAoh8V967opxV7f+fZxbkP5NAQxdT4lntbqtIQCNf0M/iRqGFKeTrFqu102WiHNEJ rJVUWVFz0WSGwBamIrT2dLxbw4eHo9ieQUfnEmFkkOwcXt9oIRqVIlUvTkdgCqFfBbXj 6lOw== X-Gm-Message-State: AOAM533gW+WJMTaCPMQNYpcO5b/8TYdaLcco9YgkXiJota8K7bwiYAsV OPJ2OFAU2bs+Gaw1Oua7XJOSMw== X-Google-Smtp-Source: ABdhPJzF+pPtZvhaFL1R8QP7BIsE2HJOfVSnKQcQu0YBk68rNLfkGNJ3nrCGS43Vfn59rLAM1LD5RQ== X-Received: by 2002:ac8:4084:: with SMTP id p4mr7765655qtl.306.1633021305549; Thu, 30 Sep 2021 10:01:45 -0700 (PDT) Received: from ziepe.ca (hlfxns017vw-142-162-113-129.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.162.113.129]) by smtp.gmail.com with ESMTPSA id l7sm1852806qth.81.2021.09.30.10.01.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Sep 2021 10:01:44 -0700 (PDT) Received: from jgg by jggl with local (Exim 4.94) (envelope-from ) id 1mVzRH-000I2E-Ia; Thu, 30 Sep 2021 14:01:43 -0300 Date: Thu, 30 Sep 2021 14:01:43 -0300 From: Jason Gunthorpe To: Max Gurtovoy Cc: Alex Williamson , 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: <20210930170143.GB69218@ziepe.ca> References: <20210929091712.6390141c.alex.williamson@redhat.com> <20210929161433.GA1808627@ziepe.ca> <29835bf4-d094-ae6d-1a32-08e65847b52c@nvidia.com> <20210929232109.GC3544071@ziepe.ca> <20210930144752.GA67618@ziepe.ca> <20210930162442.GB67618@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org On Thu, Sep 30, 2021 at 07:51:22PM +0300, Max Gurtovoy wrote: > > On 9/30/2021 7:24 PM, Jason Gunthorpe wrote: > > On Thu, Sep 30, 2021 at 06:32:07PM +0300, Max Gurtovoy wrote: > > > > Just prior to open device the vfio pci layer will generate a FLR to > > > > the function so we expect that post open_device has a fresh from reset > > > > fully running device state. > > > running also mean that the device doesn't have a clue on its internal state > > > ? or running means unfreezed and unquiesced ? > > The device just got FLR'd and it should be in a clean state and > > operating. Think the VM is booting for the first time. > > During the resume phase in the dst, the VM is paused and not booting. > Migration SW is waiting to get memory and state from SRC. The device will > start from the exact point that was in the src. > > it's exactly "000b => Device Stopped, not saving or resuming" For this case qmeu should open the VFIO device and immediately issue a command to go to resuming. The kernel cannot know at open_device time which case userspace is trying to do. Due to backwards compat we assume userspace is going to boot a fresh VM. > Well, this is your design for the driver implementation. Nobody is > preventing other drivers to start deserializing device state into the device > during RESUMING bit on. It is a logical model. Devices can stream the migration data directly into the internal state if they like. It just creates more conditions where they have report an error state. > So if we moved from 100b to 010b somehow, one should deserialized its buffer > to the device, and then serialize it to migration region again ? Yes. > I guess its doable since the device is freeze and quiesced. But moving from > 100b to 011b is not possible, right ? Why not? 100b to 011b is no different than going indirectly 100b -> 001b -> 011b The time spent in 001b is just negligable. Jason