Andreas Färber <afaer...@suse.de> writes: > Am 05.03.2014 09:43, schrieb Markus Armbruster: >> Kevin Wolf <kw...@redhat.com> writes: >> >>> 'change' is a bit trickier because it involves several low-level actions >>> at once, and device_add is not one of them. >> >> The problem is that it can run while a device model is attached. > > What exactly is the problem here? 'change' is for floppy and CD, right? > The device stays realized/connected and guest-visible during that time, > and the guest should be able to live with no media while the new drive > is not yet decrypted. Are we just lacking a QMP command to enter the > password and complete the change while the guest is executing?
Here's how change works (both HMP and QMP): 1. bdrv_close(); now we have no medium. 2. If a device model is attached, tell it the medium has been ejected. A device model supporting notification (anything but floppy, I guess) in turn notifies the guest. 3. bdrv_open(); now we again have a medium, we're in state NOKEY if the image is unencrypted, and in state NEEDKEY if it's encrypted. 4. Only in state NOKEY: if a device model is attached, tell it a medium has been loaded. A device model supporting notification in turn notifies the guest. 5. Only in state NEEDKEY: If QMP, fail the command with error DeviceEncrypted. If HMP, prompt user for password. In QMP, the client needs to follow up with a block_passwd command. In HMP, the user neeeds to enter a password. In both cases, time passes, guest can run, and even other monitor commands can be executed, possibly in other monitors. When the password arrives: 7. Set the key, state is now GOTKEY. 8. If a device model is attached, tell it a medium has been loaded. A device model supporting notification in turn notifies the guest. Shit happens for encrypted images if anything reads or writes between 3. and 8.
