Anthony Liguori <anthony@xxxxxxxxxxxxx> 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. [...] -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list