On 2023/1/9 22:46, Daniel P. Berrangé wrote: > On Tue, Jan 03, 2023 at 09:08:20PM +0800, Jiang Jiacheng wrote: >> From: zhengchuan <zhengchuan@xxxxxxxxxx> >> >> Firstly, we need to get migration pids, add >> virDomainMigrateGetMigrationPids() for migration pin. >> >> Signed-off-by:zhengchuan<zhengchuan@xxxxxxxxxx> >> --- >> include/libvirt/libvirt-domain.h | 3 +++ >> src/driver-hypervisor.h | 5 ++++ >> src/libvirt-domain.c | 39 ++++++++++++++++++++++++++++++++ >> src/libvirt_public.syms | 5 ++++ >> src/qemu/qemu_domain.c | 2 ++ >> src/qemu/qemu_domain.h | 2 ++ >> src/qemu/qemu_driver.c | 31 +++++++++++++++++++++++++ >> src/remote/remote_driver.c | 1 + >> src/remote/remote_protocol.x | 17 +++++++++++++- >> src/remote_protocol-structs | 8 +++++++ >> 10 files changed, 112 insertions(+), 1 deletion(-) >> >> diff --git a/include/libvirt/libvirt-domain.h b/include/libvirt/libvirt-domain.h >> index 295fd30c93..e11f2795f1 100644 >> --- a/include/libvirt/libvirt-domain.h >> +++ b/include/libvirt/libvirt-domain.h >> @@ -6457,4 +6457,7 @@ int virDomainStartDirtyRateCalc(virDomainPtr domain, >> int seconds, >> unsigned int flags); >> >> +char *virDomainMigrateGetMigrationPids(virDomainPtr domain, >> + unsigned int flags); > > Exposing QEMU thread PIDs in the public libvirt API is not something > we should be doing. We've explicitly aimed to avoid exposing the notion > of PIDs in our API in general. > Thanks for your reply! As we should not exposing QEMU thread PIDs, is it a better way to proactively detect the PIDs of the qemu migration thread? For example, using QMP command during migration to detect the QEMU migration thread PIDs like iothreadpin does. Compared to QEMU event, detecting proactively may spend more time to complete migration pin, but i think its still makes sense for migration. Thanks, Jiang Jiacheng > > With regards, > Daniel
