[libvirt] [PATCHv2 4/4] qemu: Implement shared memory device hot-unplug

lhuang lhuang at redhat.com
Mon Dec 21 02:52:46 UTC 2015



On 12/21/2015 10:24 AM, lhuang wrote:
>
>
> On 12/17/2015 08:26 PM, John Ferlan wrote:
>>
>> On 12/16/2015 09:43 PM, lhuang wrote:
>>>
>>> On 12/15/2015 08:39 PM, John Ferlan wrote:
>>>> [...]
>>>>
>>>>>>> +    if (rc < 0)
>>>>>>> +        return -1;
>>>>>>> +
>>>>>> I know this is a copy of the RemoveRNGDevice; however, this code
>>>>>> doesn't
>>>>>> remove an 'obj'. In fact, if !shmem->server.enabled, then we don't
>>>>>> enter
>>>>>> the monitor at all.
>>>>>>
>>>>>> Thus the following event probably won't happen...
>>>>> I am not sure what your mean is ... i guess your mean the device 
>>>>> remove
>>>>> event we get from qmp monitor won't happen ? we will get that 
>>>>> event if
>>>>> qemu remove shmem device success, it should always happen if qemu 
>>>>> really
>>>>> remove it and there is no bugs on qemu :)
>>>>>
>>>> While reviewing I got lazy and didn't check the non hotplug case to 
>>>> how
>>>> shmem is added to the vm, but the point I was trying to make is 
>>>> that "if
>>>> (shmem->server.enabled)" fails (e.g. is false), then there is no "rc =
>>>> qemuMonitorDelObject(priv->mon, objAlias);" call in this API 
>>>> (similar to
>>>> RNG code), thus how does the following event get triggered? Even if 
>>>> the
>>>> condition was true, does detaching the char dev cause the event to be
>>>> triggered?
>>>> I thought the event was related to the DelObject code, but I didn't go
>>>> follow that code
>>> Oh, i see, event is not related to the object delete, i guess you have
>>> checked the code and know how it works now ;-)
>> Maybe you misunderstood - maybe I misunderstood your response... I
>> didn't go searching through the code, but something just didn't seem
>> right when looking so I wanted to note it.
>
> Looks like i misunderstood :)
>
>> Since I figured your model was RNG my thought process was how does RNG
>> do it and what is different...
>>
>> AttachRNG has 3 steps AttachCharDev, AddObject, and AddDevice
>> DetachRNG has 1 step DelDevice
>> RemoveRNG has 2 steps DelObject and DetachCharDev
>>
>>
>> AttachShmem has 2 steps AttachCharDev and AddDevice
>> DetachShmem has 1 step DelDevice
>> RemoveShmem has 1 step DetachCharDev
>>
>> I think my concern was more related to the difference where an RNG has
>> an Object that gets removed, but Shmem doesn't.
>
> ivshmem device doesn't have a QOM object, so no need to add/del a QOM 
> object.
>
> and you can check this doc:
>
> http://wiki.qemu.org/TexiDemo
>
> and see "Inter-VM Shared Memory device" part
>

ivshmem device could have a object when it use x-memdev, so seems we 
will add DelObject in RemoveShmem in future :) (maybe when someone 
implement ivshmem with hugepage support)


Luyao

>> After closer inspection now it seems that this event generation needs to
>> stay. The RemoveShmem code is generating the event not waiting on it
>> which perhaps is where my thoughts were when I first went through the
>> changes.
>
> yes, virDomainEventDeviceRemovedNewFromObj() is generating a event and 
> it can trigger the callback functions which registered in qemu driver.
>
> Thanks for your help and reply
>
> Luayo
>
>> John
>>
>>> Thanks for your quick reply !
>>>
>>> Luyao
>>>
>>>> John
>>>>
>>>> [...]
>>>>
>
> -- 
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list




More information about the libvir-list mailing list