Avi Kivity <a...@redhat.com> 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.
