Avi Kivity <a...@redhat.com> writes:
> On 05/28/2010 09:21 PM, Markus Armbruster wrote:
>
> <snip, agreed>
>
>> Summary of the host / guest split:
>>
>> -drive options host or guest?
>> bus, unit, if, index, addr guest, already covered by qdev
>> cyls, heads, secs, trans guest, new qdev properties
>> (but defaults depend on image)
>> media guest
>> snapshot, file, cache, aio, format host, blockdev_add options
>>
>
> We expose some of the cache property to the guest. IMO we need the
> cache property to be both guest and host, with qemu bridging the
> impedance mismatch if needed.
Yes.
How should the device properties look like?
>> rerror, werror host, guest drivers will reject
>> values they don't support
>>
>
> Did you mean 'block format drivers will reject'?
No. Actual implementation is in the guest drivers,
e.g. ide_handle_rw_error().
I see this as the host outsourcing the actual work to guest drivers.
Guest drivers that can't do the work should complain. Right now, they
silently ignore the order.
>> serial guest, new qdev properties
>> readonly both host& guest, qdev will refuse
>> to connect readonly host to read/
>> write guest
>>
>> QMP command docs:
>>
>> blockdev_add
>> ------------
>>
>> Add host block device.
>>
>> Arguments:
>>
>> - "id": the host block device's ID, must be unique (json-string)
>>
>
> Unique in which namespace? A global ID namespace if fine.
The device ID namespace.
We have numerous ID namespaces already: each QemuOptsList, device IDs
(which happens to be a superset of QemuOptsList qemu_device_opts),
perhaps more.
>> - "file": the disk image file to use (json-string, optional)
>> - "format": disk format (json-string, optional)
>> - Possible values: "raw", "qcow2", ...
>>
>
> Need some way to list supported formats.
See below.
>> - "aio": host AIO (json-string, optional)
>> - Possible values: "threads" (default), "native"
>>
>
> Need some way to list supported options.
>
>> - "cache": host cache usage (json-string, optional)
>> - Possible values: "writethrough" (default), "writeback", "unsafe",
>> "none"
>>
>
> ...
>
>> - "readonly": open image read-only (json-bool, optional, default false)
>> - "rerror": what to do on read error (json-string, optional)
>> - Possible values: "report" (default), "ignore", "stop"
>>
>
> ...
>
>> - "werror": what to do on write error (json-string, optional)
>> - Possible values: "enospc" (default), "report", "ignore", "stop"
>>
>
> ...
>> - "snapshot": enable snapshot (json-bool, optional, default false)
>>
>>
>
> An alternative to the "Need some way to list *" is to provide another
> query capability, akin to KVM_CAP_..., but I think listing is
> superior.
>
>> Example:
>>
>> -> { "execute": "blockdev_add",
>> "arguments": { "format": "raw", "id": "blk1",
>> "file": "fedora.img" } }
>> <- { "return": {} }
>>
>> Notes:
>>
>> (1) If argument "file" is missing, all other optional arguments must be
>> missing as well. This defines a block device with no media
>> inserted.
>>
>> (2) It's possible to list supported disk formats by running QEMU with
>> arguments "-blockdev_add \?".
>>
>
> Ok, so there's a partial answer here.
For human users, we need accurate interactive help, both for fixed sets
of options like "cache", and for configurable sets like "format".
-blockdev_add \? simply follows existing usage there.
We need to make QMP "self-documenting": describe commands, arguments,
argument values and so forth with sufficient completeness. In
particular, for arguments that are enumerations, enumerate all possible
values.
>> blockdev_change
>> ---------------
>>
>> Change host block device media.
>>
>> Arguments are exactly like blockdev_add.
>>
>> Notes:
>>
>> (1) If argument "file" is missing, all other optional arguments must be
>> missing as well. This ejects the media without inserting a new one.
>>
>
> Maybe we want an explicit blockdev_eject instead, not sure.
Either blockdev_change (can eject, insert with auto-eject) or completely
orthogonal blockdev_eject (can only eject) + blockdev_insert (can only
insert, no auto-eject), I'd say.
Thanks for the review!
