From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: [PATCH V2 1/3] xen-blkfront: add BLKIF_OP_TRIM and backend type flags Date: Fri, 19 Aug 2011 17:38:54 -0700 Message-ID: <4E4F021E.5060502@goop.org> References: <1313660071-25230-1-git-send-email-lidongyang@novell.com> <1313660071-25230-2-git-send-email-lidongyang@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1313660071-25230-2-git-send-email-lidongyang@novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Li Dongyang Cc: xen-devel@lists.xensource.com, owen.smith@citrix.com, JBeulich@novell.com List-Id: xen-devel@lists.xenproject.org On 08/18/2011 02:34 AM, Li Dongyang wrote: > This adds the BLKIF_OP_TRIM for blkfront and blkback, also 2 flags telling > us the type of the backend, used in blkback to determine what to do when we > see a trim request. > Part of the patch is just taken from Owen Smith, Thanks > > Signed-off-by: Owen Smith > Signed-off-by: Li Dongyang > --- > include/xen/interface/io/blkif.h | 21 +++++++++++++++++++++ > 1 files changed, 21 insertions(+), 0 deletions(-) > > diff --git a/include/xen/interface/io/blkif.h b/include/xen/interface/io/blkif.h > index 3d5d6db..b92cf23 100644 > --- a/include/xen/interface/io/blkif.h > +++ b/include/xen/interface/io/blkif.h > @@ -57,6 +57,19 @@ typedef uint64_t blkif_sector_t; > * "feature-flush-cache" node! > */ > #define BLKIF_OP_FLUSH_DISKCACHE 3 > + > +/* > + * Recognised only if "feature-trim" is present in backend xenbus info. > + * The "feature-trim" node contains a boolean indicating whether barrier > + * requests are likely to succeed or fail. Either way, a trim request Barrier requests? > + * may fail at any time with BLKIF_RSP_EOPNOTSUPP if it is unsupported by > + * the underlying block-device hardware. The boolean simply indicates whether > + * or not it is worthwhile for the frontend to attempt trim requests. > + * If a backend does not recognise BLKIF_OP_TRIM, it should *not* > + * create the "feature-trim" node! Is all this necessary? What happens if guests just send OP_TRIM requests, and if the host doesn't understand them then it will fails them with EOPNOTSUPP? Is a TRIM request ever anything more than a hint to the backend that certain blocks are no longer needed? > + */ > +#define BLKIF_OP_TRIM 5 > + > /* > * Maximum scatter/gather segments per request. > * This is carefully chosen so that sizeof(struct blkif_ring) <= PAGE_SIZE. > @@ -74,6 +87,11 @@ struct blkif_request_rw { > } seg[BLKIF_MAX_SEGMENTS_PER_REQUEST]; > }; > > +struct blkif_request_trim { > + blkif_sector_t sector_number; > + uint64_t nr_sectors; > +}; > + > struct blkif_request { > uint8_t operation; /* BLKIF_OP_??? */ > uint8_t nr_segments; /* number of segments */ > @@ -81,6 +99,7 @@ struct blkif_request { > uint64_t id; /* private guest value, echoed in resp */ > union { > struct blkif_request_rw rw; > + struct blkif_request_trim trim; > } u; > }; > > @@ -109,6 +128,8 @@ DEFINE_RING_TYPES(blkif, struct blkif_request, struct blkif_response); > #define VDISK_CDROM 0x1 > #define VDISK_REMOVABLE 0x2 > #define VDISK_READONLY 0x4 > +#define VDISK_FILE_BACKEND 0x8 > +#define VDISK_PHY_BACKEND 0x10 What are these for? Why does a frontend care about these? J