| Message ID | 20230816094205.37389-1-liulongfang@huawei.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | add debugfs to migration driver | expand |
On Wed, 16 Aug 2023 17:42:01 +0800 liulongfang <liulongfang@huawei.com> wrote: > Add a debugfs function to the migration driver in VFIO to provide > a step-by-step test function for the migration driver. > > When the execution of live migration fails, the user can view the > status and data during the migration process separately from the > source and the destination, which is convenient for users to analyze > and locate problems. > > Changes v12 -> v13 > Solve the problem of open and close competition to debugfs. Hi, I'm not sure if the new To: list is a mistake or if this is an appeal to a different set of maintainers for a more favorable response than previous postings[1], but kvm@vger.kernel.org remains the list for this driver, which is under the perview of vfio [adding the correct list and co-maintainer]. I believe there is still a concern whether this is a valid and worthwhile debugfs interface. It has been suggested that much of what this provides could be done through userspace drivers to exercise the migration interfaces and/or userspace debugging techniques to examine the device migration data. I haven't seen a satisfactory conclusion for these comments yet. I think we have general consensus that the first couple patches are ok and useful, exposing the migration state generically and supporting a minor cleanup within the hisi_acc driver. However, the new approach to try to lock the device with igate is certainly not the correct (igate is used for serializing interrupt configuration) and the proposed hisi_acc specific debugfs interfaces themselves are not settled. Thanks, Alex [1]https://lore.kernel.org/all/20230728072104.64834-1-liulongfang@huawei.com/
On 2023/8/18 6:48, Alex Williamson wrote: > On Wed, 16 Aug 2023 17:42:01 +0800 > liulongfang <liulongfang@huawei.com> wrote: > >> Add a debugfs function to the migration driver in VFIO to provide >> a step-by-step test function for the migration driver. >> >> When the execution of live migration fails, the user can view the >> status and data during the migration process separately from the >> source and the destination, which is convenient for users to analyze >> and locate problems. >> >> Changes v12 -> v13 >> Solve the problem of open and close competition to debugfs. > > Hi, > > I'm not sure if the new To: list is a mistake or if this is an appeal > to a different set of maintainers for a more favorable response than > previous postings[1], but kvm@vger.kernel.org remains the list for this > driver, which is under the perview of vfio [adding the correct list and > co-maintainer]. > You are right, the patchset was sent to the wrong email address. > I believe there is still a concern whether this is a valid and > worthwhile debugfs interface. It has been suggested that much of what > this provides could be done through userspace drivers to exercise the > migration interfaces and/or userspace debugging techniques to examine > the device migration data. I haven't seen a satisfactory conclusion > for these comments yet. > It is reasonable to test live migrations via userspace drivers. This user-space operation is an unsolicited test. However, the current operations in this patchset only retain the function of reading status data. There is no test function, and this part of the function is no different from the debugfs function of other IO device drivers. It should be possible to use debugfs here. In addition, the debugfs in the driver does not need to rely on the userspace driver tool. It will be more convenient to use. > I think we have general consensus that the first couple patches are ok> and useful, exposing the migration state generically and supporting a > minor cleanup within the hisi_acc driver. However, the new approach to > try to lock the device with igate is certainly not the correct (igate > is used for serializing interrupt configuration) and the proposed > hisi_acc specific debugfs interfaces themselves are not settled. > Thanks, > Then I will disassemble the patch and send out the front part first. Thanks, Longfang. > Alex > > [1]https://lore.kernel.org/all/20230728072104.64834-1-liulongfang@huawei.com/ > > . >