[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: RFC: blockdev_add & friends, brief rationale, QMP docs
From: |
Markus Armbruster |
Subject: |
[Qemu-devel] Re: RFC: blockdev_add & friends, brief rationale, QMP docs |
Date: |
Mon, 31 May 2010 13:50:45 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) |
Avi Kivity <address@hidden> writes:
> On 05/31/2010 01:54 PM, Markus Armbruster wrote:
>>
>>> 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?
>>
>
> write_cache=enabled|disabled|none? (disabled can be enabled by the
> guest, but none cannot)
> barrier=supported|unsupported?
>
> Need to look at our supported interfaces and see what's the LCM.
I figure we Can flesh it out later.
>>>> 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().
>>
>
> That is not a guest driver. It is a device model. A guest driver is
> something you modprobe.
Sorry, sloppy QEMU terminology seeping into my writing :(
>> 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.
>>
>
> With the terminology change, it makes a bit of sense.
>
>>
>>> 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.
>>
>
> I prefer the latter, especially as eject has numerous variants
> (software locked eject button, force=true to unwrap paper clip and
> insert into pinhole, tray ejects violently knocking down hot beverage,
> etc).
Okay.
- [Qemu-devel] Re: RFC: blockdev_add & friends, brief rationale, QMP docs, (continued)
- [Qemu-devel] Re: RFC: blockdev_add & friends, brief rationale, QMP docs, Kevin Wolf, 2010/05/28
- Re: [Qemu-devel] Re: RFC: blockdev_add & friends, brief rationale, QMP docs, Anthony Liguori, 2010/05/28
- Re: [Qemu-devel] Re: RFC: blockdev_add & friends, brief rationale, QMP docs, Luiz Capitulino, 2010/05/28
- Re: [Qemu-devel] Re: RFC: blockdev_add & friends, brief rationale, QMP docs, Avi Kivity, 2010/05/30
- Re: [Qemu-devel] Re: RFC: blockdev_add & friends, brief rationale, QMP docs, Markus Armbruster, 2010/05/31
- Re: [Qemu-devel] Re: RFC: blockdev_add & friends, brief rationale, QMP docs, Luiz Capitulino, 2010/05/31
- Re: [Qemu-devel] Re: RFC: blockdev_add & friends, brief rationale, QMP docs, Kevin Wolf, 2010/05/31
[Qemu-devel] Re: RFC: blockdev_add & friends, brief rationale, QMP docs, Avi Kivity, 2010/05/30