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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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

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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]