On 2023/1/10 19:44, Daniel P. Berrangé wrote:
> On Tue, Jan 10, 2023 at 07:30:08PM +0800, Jiang Jiacheng wrote:
>>
>>
>> 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 <zhengch...@huawei.com>
>>>>
>>>> Firstly, we need to get migration pids, add
>>>> virDomainMigrateGetMigrationPids() for migration pin.
>>>>
>>>> Signed-off-by:zhengchuan<zhengch...@huawei.com>
>>>> ---
>>>>  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.
> 
> iothreadpin doesn't take thread PIDs, it takes integer
> identifiers associated with the threads.
> 
> Why does the mgmt app need to know the migration PIDs ? The
> API for setting pinning in the next patch doesn't accept a
> PID, and we don't need to set different pinning for each
> migration thread. Only libvirt QEMU driver code needs to
> know the PIDs, not the libvirt public API/mgmt app.
> 
>

I have got that the pids shouldn't show up in libvirt public API/mgmt
app, so I want to drop those changes related with PIDs in mgmt app and
try to get the migration pid using qmp command like the way getting
iothreads' pid in 'qemuProcessDetectIOThreadPIDs' in qemu_process.c.

Thanks
Jiang Jiacheng
> With regards,
> Daniel

Reply via email to