Anthony Liguori <anthony@codemonkey.ws> writes:
On 04/23/2010 07:48 AM, Avi Kivity wrote:
On 04/22/2010 09:49 PM, Anthony Liguori wrote:
real API. Say, adding a device libvirt doesn't know about or stopping the VM while libvirt thinks it's still running or anything like that. Another problem is issuing Monitor commands that could confuse libvirt's
We need to make libvirt and qemu smarter.
We already face this problem today with multiple libvirt users. This is why sophisticated management mechanisms (like LDAP) have mechanisms to do transactions or at least a series of atomic operations.
And people said qmp/json was overengineered...
But seriously, transactions won't help anything. qemu maintains state, and when you have two updaters touching a shared variable not excepting each other to, things break, no matter how much locking there is.
Let's consider some concrete examples. I'm using libvirt and QMP and in QMP, I want to hot unplug a device.
Today, I do this by listing the pci devices, and issuing a pci_del that takes a PCI address. This is intrinsically racy though because in the worst case scenario, in between when I enumerate pci devices and do the pci_del in QMP, in libvirt, I've done a pci_del and then a pci_add within libvirt of a completely different device.
There are a few ways to solve this, the simplest being that we give devices unique ids that are never reused and instead of pci_del taking a pci bus address, it takes a device id. That would address this race.
For what it's worth, that's how device_del works, except the ID is chosen by the user, who is free to reuse them. Really tangential to this thread, but it's worth repeating anyway: use device_add & friends, not pci_add & friends. [...]