Re: [Xen-devel] [PATCH RFC 12/12] xen-block: implement indirect descriptors

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Tue, Mar 05, 2013 at 06:00:51PM +0100, Roger Pau Monné wrote:
> On 05/03/13 15:16, Konrad Rzeszutek Wilk wrote:
> > On Tue, Mar 05, 2013 at 08:11:19AM +0000, Jan Beulich wrote:
> >>>>> On 04.03.13 at 21:44, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> 
> >>>>> wrote:
> >>> <nods> 'op' sounds good. With a comment saying it can do all of the 
> >>> BLKIF_OPS_..
> >>> except the BLKIF_OP_INDIRECT one. Thought one could in theory chain
> >>> it that way for fun.
> >>
> >> In fact I'd like to exclude chaining as well as BLKIF_OP_DISCARD here.
> >> The former should - if useful for anything - be controlled by a
> >> separate feature flag, and the latter is plain pointless to indirect.
> >> And I reckon the same would apply to BLKIF_OP_FLUSH_DISKCACHE
> >> and BLKIF_OP_RESERVED_1 - i.e. it might be better to state that
> >> indirection is only permitted for normal I/O (read/write) ops.
> > 
> > <nods> That makes sense. And also of course the new BLKIF_OP should
> > be documented in the Xen tree as well.
> 
> The only ops that can be done indirectly are _READ, _WRITE and
> _BARRIER/_FLUSH. From the implementation in blkfront it seems like
> _FLUSH/_BARRIER requests can indeed contain segments, but I haven't been
> able to spot any _FLUSH op with segments on it. Can you confirm FLUSH
> requests never contain bios?

Not FLUSH per say. But the FUA should be able to provide data and the
flush semantics with it. Except we don't support FUA so this is irrelevant
 - unless in the future we want to intrduce FUA or WRITE with some extra
flags.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel