On Fri, 27 Feb 2026 09:07:48 -0800 David Matlack <[email protected]> wrote:
> On Fri, Feb 27, 2026 at 7:47 AM Alex Williamson <[email protected]> wrote: > > > > On Fri, 27 Feb 2026 00:51:18 +0000 > > David Matlack <[email protected]> wrote: > > > > > On 2026-02-26 05:00 PM, Alex Williamson wrote: > > > > On Thu, 29 Jan 2026 21:24:57 +0000 > > > > David Matlack <[email protected]> wrote: > > > > > > > > > > - vdev->reset_works = !ret; > > > > > pci_save_state(pdev); > > > > > vdev->pci_saved_state = pci_store_saved_state(pdev); > > > > > > > > Isn't this a problem too? In the first kernel we store the initial, > > > > post reset state of the device, now we're storing some arbitrary state. > > > > This is the state we're restore when the device is closed. > > > > > > The previous kernel resets the device and restores it back to its > > > post reset state in vfio_pci_liveupdate_freeze() before handing off > > > control to the next kernel. So my intention here is that VFIO will > > > receive the device in that state, allowing it to call > > > pci_store_saved_state() here to capture the post reset state of the > > > device again. > > > > > > Eventually we want to drop the reset in vfio_pci_liveupdate_freeze() and > > > preserve vdev->pci_saved_state across the Live Update. But I was hoping > > > to add that in a follow up series to avoid this one getting too long. > > > > I appreciate reviewing this in smaller chunks, but how does userspace > > know whether the kernel contains a stub implementation of liveupdate or > > behaves according to the end goal? > > Would a new VFIO_DEVICE_INFO_CAP be a good way to communicate this > information to userspace? Sorry if I don't have the whole model in my head yet, but is exposing the restriction to the vfio user of the device sufficient to manage the liveupdate orchestration? For example, a VFIO_DEVICE_INFO_CAP pushes the knowledge to QEMU... what does QEMU do with that knowledge? Who imposes the policy decision to decide what support is sufficient? Thanks, Alex
