From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A9E58318131 for ; Wed, 25 Feb 2026 23:41:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.169 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772062871; cv=none; b=kryPWA/Q1Od6FCOxk/OcJ0j8oMCEsnJb0+JOlAGZBb1xvn2IIMxRjOP04pqA/+x2Vd96v/CeoyNI3T/nNsgbrChuuIjJ4Up1KMUsAOvidbGIcEGt2psu5uDT+CU5d9PEtcyKSAZ5KrE5HAMsb3mkmTC/mz4Y7ttNKCXZqHplfJU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772062871; c=relaxed/simple; bh=bKI2pGpfY+ZCgdQUPM1XvD0dVj7imv1jMLjUvrJ34gY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Rn/owKxLCjSV1R5SDXL0aF/N+Rwpj0MhvRYrkHlw8zNjX6cGFOFjWIC5RheSeeBqEolxbwnZ4BLuPTZZRtBnqPKDI4qHfmxqf6RApLjFgQ1w7tYpI6cjssB8lz28UU4HFjgaQgLOxyZsMIffwsdFYA+5EygCKPIHWEN1CxlJU2I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=Ic4P6Fkf; arc=none smtp.client-ip=209.85.214.169 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Ic4P6Fkf" Received: by mail-pl1-f169.google.com with SMTP id d9443c01a7336-2adcede372cso754815ad.0 for ; Wed, 25 Feb 2026 15:41:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1772062870; x=1772667670; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=/CK8Xw2Z8/jwhJKdKy0esOogFCKRH5zkiTBeIKoVGlM=; b=Ic4P6Fkf/OXgNQ7BDlUnM2oIkuJMigxtpE353Q9PHMHUy8KOdfb/1AhXq8PqsRxaSa m6syzRvsuaI1TgkDNs2grnAoEIj7bWPlrj4VWShTXl7iDrARPiMPoSqkpGqHNQED7SJq sjDbCi10DOaC+SHAoHd9Q4nCSS8RWBjp9qw6oz5NoO6dSD4QNeh2TJHWLpYw0ODvYnTn v+8wV7PBBRjogrV24GXaeu7V/xKAw+w/ubVwn7sNdvaxR1vkIGn3FaUkv9a/jCqto8SF Gpe4rhG8F06u8QkjdUIFYrSI6mk1aDROt2IVSF511yCdy54NqgTXDMOVGZ7X+hVAhKvE Tf1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772062870; x=1772667670; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=/CK8Xw2Z8/jwhJKdKy0esOogFCKRH5zkiTBeIKoVGlM=; b=ctAXxRKuKxj56Q2mUezrydV7EiBnnYC3Vt0RUVQCvxbg7CkrGTn2OqOdXp1Nr3doCZ si1X3jBZEDGOZUpDMfZw6+5xUYC+gYe/AWNKT5gOWTPYF76GNSE1P1P1QlZu+jHqcRpy J9C94keAcOPfADsSyK+Bst+WZd4zx/fsajvPpMCa9bDWgddVYnWhKhddVD+FF6d9Hjef 0c3TzOceWr/o5L4fTCAOTLt+d28v/tI7ZVzBFGbUO/QBR5fp2LBpK5IcWr0AUz3sDXQ+ nT2BCyd/uzwpKNmAEUVhXfDRAS5kRwz7vraJaa8rRm5lUsCIRNPF6Flim29qgM94pDRr 4xhQ== X-Forwarded-Encrypted: i=1; AJvYcCUAF02nPUsSFGqJL/wUzTYRlwfnM7yf5iSQR4UIht4HtIHciWaAjU2i46jLSq93K6HrF7GqLEWc3Ao=@vger.kernel.org X-Gm-Message-State: AOJu0YyBRu145z3YKY/54kLnklmKRJRDqV3YtdNfsX3/JjpStsgG0aZo myT964Z4/VRmPolA8Oql0oJHzLIUISaopiQaRhgYxGkexHZA7xtgB97y2JgziHlCDw== X-Gm-Gg: ATEYQzy+km428rQ3p36FMTSpmzgjjFqD+Cu5duWFGdXPEV/XZtBQ63+sBQrjrSH1EYB Myeoxuu7Bxa69rlBxxoK+YHEh6jn+UozT0jXMoWCD/5eiOeupxSeKEGXwaZItNCFpnBOEm5A2wr sNpSShvMyDI5Qn4pQ8AClRyMuQE1B0lI6tuRO7VQLhYjL3NtT/t2ZD6CestpfwtSWramFOELN9T tYVV8EoAxDzROKbrLfGWSBoRzKK4JT5Si5VhscCVQ57coRP9O5Te42VtT/qRQ1Oc9taEquNmJQ/ xmholI4psKSXlIfBKDzndU7QrB/JYnVCOmlpK0w91zdK9SPyuof5Kw0+6QBXAijoKX8s6nShOnK 2/Ol5394PA6t7wnc53RU1ZdgencaWLclV9gH2kdAdK7gPgb4dTfvkTKElZV0gpDfL1v8NtBaDXq n9iQgDwsMiRkSS+6GLv7wY8yudrqesVmIkwg6FQHkXAjhLDoynnluGTe7U6m3MTg== X-Received: by 2002:a17:902:cccf:b0:2a1:e19:ff0 with SMTP id d9443c01a7336-2ae035d235dmr1928845ad.39.1772062869584; Wed, 25 Feb 2026 15:41:09 -0800 (PST) Received: from google.com (239.23.105.34.bc.googleusercontent.com. [34.105.23.239]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2adfb6b5813sm3778175ad.63.2026.02.25.15.41.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Feb 2026 15:41:08 -0800 (PST) Date: Wed, 25 Feb 2026 23:41:04 +0000 From: David Matlack To: Alex Williamson Cc: Adithya Jayachandran , Alexander Graf , Alex Mastro , Alistair Popple , Andrew Morton , Ankit Agrawal , Bjorn Helgaas , Chris Li , David Rientjes , Jacob Pan , Jason Gunthorpe , Jason Gunthorpe , Jonathan Corbet , Josh Hilke , Kevin Tian , kexec@lists.infradead.org, kvm@vger.kernel.org, Leon Romanovsky , Leon Romanovsky , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, linux-pci@vger.kernel.org, Lukas Wunner , =?utf-8?Q?Micha=C5=82?= Winiarski , Mike Rapoport , Parav Pandit , Pasha Tatashin , Pranjal Shrivastava , Pratyush Yadav , Raghavendra Rao Ananta , Rodrigo Vivi , Saeed Mahameed , Samiullah Khawaja , Shuah Khan , Thomas =?iso-8859-1?Q?Hellstr=F6m?= , Tomita Moeko , Vipin Sharma , Vivek Kasireddy , William Tu , Yi Liu , Zhu Yanjun Subject: Re: [PATCH v2 05/22] vfio/pci: Preserve vfio-pci device files across Live Update Message-ID: References: <20260129212510.967611-1-dmatlack@google.com> <20260129212510.967611-6-dmatlack@google.com> <20260225154124.78e18fa4@shazbot.org> Precedence: bulk X-Mailing-List: linux-pci@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260225154124.78e18fa4@shazbot.org> On 2026-02-25 03:41 PM, Alex Williamson wrote: > On Thu, 29 Jan 2026 21:24:52 +0000 David Matlack wrote: > > static bool vfio_pci_liveupdate_can_preserve(struct liveupdate_file_handler *handler, > > struct file *file) > > { > > - return false; > > + struct vfio_device_file *df = to_vfio_device_file(file); > > + > > + if (!df) > > + return false; > > + > > + /* Live Update support is limited to cdev files. */ > > + if (df->group) > > + return false; > > + > > + return df->device->ops == &vfio_pci_ops; > > } > > Why can't we use vfio_device_cdev_opened() here and avoid all the new > exposure in public headers? I thought I explored using vfio_device_cdev_opened() but I can't remember now why I went with df->group. Maybe there wasn't a good reason. I'll switch to vfio_device_cdev_opened() in the next version. > > > > static int vfio_pci_liveupdate_preserve(struct liveupdate_file_op_args *args) > > { > > - return -EOPNOTSUPP; > > + struct vfio_device *device = vfio_device_from_file(args->file); > > + struct vfio_pci_core_device_ser *ser; > > + struct vfio_pci_core_device *vdev; > > + struct pci_dev *pdev; > > + > > + vdev = container_of(device, struct vfio_pci_core_device, vdev); > > + pdev = vdev->pdev; > > + > > + if (IS_ENABLED(CONFIG_VFIO_PCI_ZDEV_KVM)) > > + return -EINVAL; > > + > > + if (vfio_pci_is_intel_display(pdev)) > > + return -EINVAL; > > Some comments describing what's missing, if these are TODO or DONTCARE > would be useful. Will do. > > +static int vfio_pci_liveupdate_freeze(struct liveupdate_file_op_args *args) > > +{ > > + struct vfio_device *device = vfio_device_from_file(args->file); > > + struct vfio_pci_core_device *vdev; > > + struct pci_dev *pdev; > > + int ret; > > + > > + vdev = container_of(device, struct vfio_pci_core_device, vdev); > > + pdev = vdev->pdev; > > + > > + guard(mutex)(&device->dev_set->lock); > > + > > + /* > > + * Userspace must disable interrupts on the device prior to freeze so > > + * that the device does not send any interrupts until new interrupt > > + * handlers have been established by the next kernel. > > + */ > > + if (vdev->irq_type != VFIO_PCI_NUM_IRQS) { > > + pci_err(pdev, "Freeze failed! Interrupts are still enabled.\n"); > > + return -EINVAL; > > + } > > + > > + pci_dev_lock(pdev); > > device_lock() is a dangerous source of deadlocks, for instance how can > we know the freeze isn't occurring with an outstanding driver unbind? I can change this to a try-lock and return an error if taking the lock fails. The freeze() callbacks are triggered by liveupdate_reboot() which is called from kernel_kexec(). So returning an error to userspace is possible. My only concern is whether using try-lock would make kexec flaky, or if it would only fail if userspace is misbehavior (e.g. unbinding drivers while kexecing). > > -static struct vfio_device *vfio_device_from_file(struct file *file) > > -{ > > - struct vfio_device_file *df = file->private_data; > > - > > - if (file->f_op != &vfio_device_fops) > > - return NULL; > > - return df->device; > > -} > > +EXPORT_SYMBOL_GPL(vfio_device_fops); > > Seems we just need to export vfio_device_from_file(). Thanks, Will do.