Re: [Qemu-devel] Mount image file feature

[Programmingkid]

On Sep 3, 2015, at 12:26 PM, Markus Armbruster wrote:

> 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.

Ok. There is no problem removing drive_del. It does seem that using
device_del is good enough. An "info block" after a device_del command
proves this. 

Hopefully Peter Maydell will tell me his comments on the patch soon. Then I 
will 
make a version 2 of the patch without the drive_del command.

Thank you for input.