Re: [Qemu-devel] [PATCH v2 0/4] blockdev: Add blockdev-change-medium with read-only option

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 7123 bytes --]

On 12/05/2014 06:47 AM, Max Reitz wrote:
>> I'd like to make sure that new commands to control removable media get
>> us closer to a sane set of such commands.  Let's consider states and
>> transitions.
>>
>> If we ignore the tray lock for a moment, we have:
>>
>>                                      load
>>                      tray open  --------------->  tray closed
>>                        empty    <---------------    empty
>>                        ^   |        eject
>>                        |   |
>>          remove medium |   | insert medium
>>                        |   |
>>                        |   v        load
>>                      tray open  --------------->  tray closed
>>                         full    <---------------    full
>>                                      eject

By name, this command feels like it is just the remove/insert medium
step, and unrelated to tray open/close steps.

>>
>> Both the operator and the guest OS can load / eject.
>>
>> Only the operator can remove / insert medium.

Where change is a special case of remove and insert done together.

>>
>> A tray lock complicates things a bit.  Each state above splits into a
>> locked and unlocked state, with the obvious lock / unlock state
>> transitions.  Only the guest OS can lock / unlock.
>>
>> When the tray is locked and closed, operator eject merely notifies the
>> guest OS (blk_dev_eject_request(blk, false)).
>>
>> In states tray closed / locked, there's an additional operation "eject
>> forcefully".  It notifies the guest OS (blk_dev_eject_request(blk,
>> true)), and opens the tray.  Whether unlocks it depends on the device.
>>
>> Like change, blockdev-change-medium conflates several basic operations.
>> Is that what we want, or should we create something that lets us do
>> basic operations?

change lacks a force parameter, which means that it feels like something
that can only be attempted when the tray is open.  The fact that we
(can) make it auto-open an (unlocked) tray under the hood may be okay
for HMP, but should not be part of the QMP command.

> 
> Good question. I don't think it will be bad in practice, though. If you
> split up blockdev-change-medium or really only change the medium without
> loading it, then the only advantage that you get is that you can
> exchange media without loading them; I can't really think of a use case
> for that, so in reality you'll always have blockdev-change-medium
> followed immediately by blockdev-load-medium or blockdev-close-tray or
> whatever.
> 
> You could split it up even more of course, then you'd have the following
> order for loading a medium:
> (1) 'blockdev-open-tray', if not yet open
> (2) 'blockdev-remove-medium', if not yet empty
> (3) 'blockdev-insert-medium'

I'm not sure if 2 and 3 need to be separate, or if they can be a single
change-medium command.

> (4) 'blockdev-close-tray

But yes, I think we need separate QMP commands for tray movement as
compared to medium changes, and that medium change should fail if the
tray is closed.  Higher level software can string together multiple QMP
commands to give the user a single 'change' experience, as desired, but
I don't think QMP should provide such a command, as it is harder to
determine what state things are left in if it fails halfway through.

> 
> I can't think of any time when you'd want to call insert-medium without
> close-tray or without having called remove-medium before (well, if it's
> empty, you don't have to, but well...).
> 
> And 'eject' does blockdev-open-tray plus blockdev-remove-medium, so...
> 
> Or better, let's collect use cases:

Use cases are the HMP (or libvirt) side of things.  If the use case can
be accomplished by stringing together multiple well-defined QMP
operations, instead of having an overloaded QMP command that does
multiple steps, that's still okay for the user's point of view .

> (1) Insert medium into empty drive and load it: Works with
> 'blockdev-change-medium'

Umm, I'm actually agreeing with Markus that we probably want to separate
changing the medium from closing the tray; while for floppies, there is
no tray, so changing a medium is all the more you need to do.

> (2) Open drive, remove medium: Works with 'eject'

What about 'open drive, but leave medium in place for next time drive is
closed'.  Does 'eject' do that (possibly via the addition of an optional
boolean that says whether to leave the medium intact)?  Also, floppy
drives can be locked, but have no tray; do we have the right semantics
for requesting an eject but waiting for the guest to comply by unlocking
the drive?

> (3) Open drive, remove medium, insert medium, close drive: Works with
> 'blockdev-change-medium'

Or rather, works with the high-level HMP 'change', and may be
implemented via multiple QMP commands under the hood.

> (4) Open drive, remove medium, close drive: Does not work with only
> 'eject' and 'blockdev-change-medium', but I can't see a difference
> between an open drive and a closed empty drive

For floppies, there isn't a difference (no tray, so no medium is all the
more distinction you get).  But for cdroms, the guest knows if the tray
is still open or closed (it doesn't know if the medium is present when
the tray is open; the fact that qemu still tracks medium for an open
tray is for convenience in closing the tray and still having the medium
ready to use if it wasn't changed while the tray was open).

> (5) Open drive, repeatedly change medium, close drive: Does not work
> with 'blockdev-change-medium' because the guest will see all the media
> you cycled through; but I don't consider this an important use case

May not be important, and may not be something we expose through HMP,
but I agree with Markus that it would be nice to let the QMP side allow
this.

> 
> So, of course it may be nice in principle to have broken it down to the
> fundamental operations, but I don't see the practical implication.
> 
> Hm, well, there is one. I remember someone complaining that 'eject'
> sometimes removes the medium and sometimes doesn't. It did remove the
> medium when qemu could immediately eject it; but it didn't if the drive
> was locked, the guest was notified and then the guest opened the tray.
> So that is a practical implication, because after calling
> blockdev-open-tray, you'd be sure that the medium is still inserted.
> 
> I personally don't have a strong opinion. Introducing more commands
> would be work, but I guess I would have time for that now.

Requiring multiple QMP commands to do a high-level HMP operation may
feel like overkill, but in the long run the finer granularity will be
worth it.  I think that limiting 'blockdev-change-medium' to work only
on unlocked floppy drives and only on open-tray cdrom drives, plus the
additional glue to open/close the cdrom tray as necessary, will be worth
the effort.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 539 bytes --]