[Qemu-devel] Re: RFC: blockdev_add & friends, brief rationale, QMP docs

[Markus Armbruster]

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.