netdev - RE: [PATCH V7 mlx5-next 08/15] vfio: Define device migration protocol v2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 17 Feb 2022 02:29:56 +0000
From:   "Tian, Kevin" <kevin.tian@...el.com>
To:     Jason Gunthorpe <jgg@...dia.com>
CC:     Alex Williamson <alex.williamson@...hat.com>,
        Yishai Hadas <yishaih@...dia.com>,
        "bhelgaas@...gle.com" <bhelgaas@...gle.com>,
        "saeedm@...dia.com" <saeedm@...dia.com>,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "leonro@...dia.com" <leonro@...dia.com>,
        "kwankhede@...dia.com" <kwankhede@...dia.com>,
        "mgurtovoy@...dia.com" <mgurtovoy@...dia.com>,
        "maorg@...dia.com" <maorg@...dia.com>,
        "Raj, Ashok" <ashok.raj@...el.com>,
        "shameerali.kolothum.thodi@...wei.com" 
        <shameerali.kolothum.thodi@...wei.com>
Subject: RE: [PATCH V7 mlx5-next 08/15] vfio: Define device migration protocol
 v2

> From: Jason Gunthorpe <jgg@...dia.com>
> Sent: Wednesday, February 16, 2022 8:14 PM
> 
> On Wed, Feb 16, 2022 at 03:17:36AM +0000, Tian, Kevin wrote:
> 
> > those requests don't rely on vCPUs but still take time to complete
> > (thus may break SLA) and are invisible to migration driver (directly
> > submitted by the guest thus cannot be estimated). So the only means
> > is for user to wait on a fd with a timeout (based on whatever SLA) and
> > if expires then aborts migration (may retry later).
> 
> I think I explained in my other email how this can be implemented
> today with v2 for STOP_COPY without an event fd.
> 

I suppose you meant this part:

"It allows RUNNING -> STOP_COPY to be made async because the driver can
return SET_STATE immediately, backround the state save and indicate
completion/progress/error via poll(readable) on the data_fd."

Yes it could work if the user directly request STOP_COPY as the end state
(with STOP as an implicit/immediate step). In that case polling on data_fd
with timeout can cover the requirement described for STOP here.

Thanks
Kevin