Re: [Qemu-devel] Mount image file feature

[Markus Armbruster]

Programmingkid <address@hidden> writes:

> On Sep 3, 2015, at 5:46 AM, Markus Armbruster wrote:
>
>> Programmingkid <address@hidden> writes:
>> 
>>> On Sep 2, 2015, at 10:31 AM, Max Reitz wrote:
>>> 
>>>> On 31.08.2015 22:33, Programmingkid wrote:
>>>>> 
>>>>> On Aug 31, 2015, at 4:26 PM, Max Reitz wrote:
>>>> 
>>>> [snip]
>>>> 
>>>>>> The following works for me:
>>>>>> 
>>>>>> $ echo foo > bar
>>>>>> $ x86_64-softmmu/qemu-system-x86_64 -qmp stdio -usb -cdrom
>>>>>> ~/tmp/archlinux-2015.07.01-dual.iso -enable-kvm -m 512
>>>>>> {"QMP": {"version": {"qemu": {"micro": 50, "minor": 4, "major": 2},
>>>>>> "package": ""}, "capabilities": []}}
>>>>>> {'execute': 'qmp_capabilities'}
>>>>>> {"return": {}}
>>>>>> {'execute': 'blockdev-add', 'arguments': {'options': {'id': 'usb-image',
>>>>>> 'driver': 'raw', 'file': {'driver': 'file', 'filename': 'bar'}}}}
>>>>>> 
>>>>>> {"return": {}}
>>>>>> {'execute': 'device_add', 'arguments': {'driver': 'usb-storage', 'id':
>>>>>> 'usb-disk', 'drive': 'usb-image'}}
>>>>>> {"return": {}}
>>>>>> 
>>>>>> In the VM, before device_add:
>>>>>> # cat /dev/sda
>>>>>> cat: /dev/sda: No such file or directory
>>>>>> 
>>>>>> After device_add:
>>>>>> # cat /dev/sda
>>>>>> foo
>>>>> 
>>>>> Is there a function that the GUI could call to send all of the JSON
>>>>> code as the
>>>>> argument to execute.
>>>> 
>>>> If you put the GUI outside of qemu, it's very simple, obviously, since
>>>> you then just need to send it to whichever interface you chose to be
>>>> used for QMP.
>>>> 
>>>> (Yes, I'm still strongly encouraging you to write a separate GUI. The
>>>> only part that I suppose to be more difficult than when putting
>>>> everything into qemu itself is integrating the guest output into your
>>>> GUI. Ideally you'd probably either use VNC or qxl/spice for that, but
>>>> for the start I personally would just use SDL (it does work on OS X,
>>>> too, doesn't it?)
>>> 
>>> Yes it does.
>>> 
>>>> so you get a bare window which is only the guest
>>>> output, and then put the VM controls into a separate window.)
>>>> 
>>>> The nice thing about a GUI outside of qemu, besides looking preferable
>>>> design-wise to me, is that you can configure the VM offline, too.
>>>> 
>>>> 
>>>> For the GUI inside of qemu: Well, there is handle_qmp_command(), but it
>>>> doesn't look like it's intended to be used directly. Judging from
>>>> monitor.c, you'd want to set up a JSON parser, call
>>>> json_message_parser_init(parser, handle_hmp_command); and then use
>>>> json_message_parser_feed() to send commands.
>>> 
>>> Wow, that is a bit overwhelming. I really like what my patch does. It
>>> just sends a
>>> command to the monitor as if the user typed it up. Very simple, easy,
>>> and effective.
>>> I will never have to look for some poorly documented function again!
>> 
>> On the flip side, you'll never get a patch abusing handle_hmp_command()
>> or handle_qmp_command() as internal interface committed.
>> 
>>>> So the GUI inside of qemu would probably want to continue to call qmp_*
>>>> directly, i.e. qmp_blockdev_add() and qmp_device_add().
>>>> 
>>>>>> Unplugging the device can be done with device_del; but there is no
>>>>>> blockdev-del yet, so the image file will remain lingering.
>>>>> 
>>>>> If the user decided to use the same image file again, would that
>>>>> be possible?
>>>> 
>>>> Yes, but you'd have to keep track of the ID you gave it. If you call
>>>> blockdev-add again, qemu will happily open it anew and then it'll be
>>>> open twice.
>>> 
>>> I just call drive_del then device_del. So far so good. I have mounted
>>> and unmounted the same image file several times without problem.
>> 
>> Wrong order, trap for the unwary.  Let me paste my standard advice:
>> 
>>    drive_del is nasty.  Its purpose is to revoke access to an image
>>    even when the guest refuses to cooperate.  To the guest, this looks
>>    like hardware failure. 
>
> Has the device been probably ejected from the guest first?

For a PCI device (such as virtio-blk-pci), device_del merely asks the
guest politely to relinquish the device.  As soon as it complies, the
device gets unplugged.

What if it doesn't?  Buggy, maliciously, or simply incapable of ACPI.
You sometimes still a surefire way to revoke its access to an image
anyway.  That way is the (badly named!) drive_del.

>>    If you drive_del before device_del, even a perfectly well-behaved
>>    guest guest is exposed to a terminally broken device between
>>    drive_del and completion of unplug.
>> 
>>    Always try a device_del first, and only if that does not complete
>>    within reasonable time, and you absolutely must revoke access to the
>>    image, then whack it over the head with drive_del.
>
> I guess I could use "device_del" only. I just thought it made sense to use
> "drive_del" when I used the "drive_add" command.

Did I mention "badly named"?

>> Copied from
>> http://lists.gnu.org/archive/html/qemu-devel/2014-04/msg00116.html
>> 
>> I hope we can eventually replace and deprecate drive_del with something
>> that where the obvious use is the correct one.
>
> I haven't noticed any problems so far. When I use "drive_del", the "info 
> block" 
> command says it is gone. That is good. Then I do a "device_del". "info
> usb" shows
> the device gone. Maybe any problems with "drive_del" you might have had in 
> the 
> past have been fixed. Have you tried it out lately? I did extensive
> testing of my patch
> using Debian Linux as a guest. Never heard it complain. 

Read again:

    If you drive_del before device_del, even a perfectly well-behaved
    guest guest is exposed to a terminally broken device between
    drive_del and completion of unplug.

This is a race condition.  If the guest doesn't look between drive_del
and device_del, nothing bad happens.  If it does, it sees a dead device.

Dijkstra's old adage "testing shows the presence, not the absence of
bugs" applies to race conditions most forcefully.