From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: xen-vbd interface (segment size expansion) - FreeBSD host have it. Date: Tue, 25 Sep 2012 11:26:00 -0400 Message-ID: <20120925152600.GA967@phenom.dumpdata.com> References: <20120817172838.GA3515@phenom.dumpdata.com> <61DFA8800400A143A5A7C5E136A726DC5F867490@reactor.sldomain.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <61DFA8800400A143A5A7C5E136A726DC5F867490@reactor.sldomain.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Justin Gibbs , xen-devel@lists.xensource.com Cc: "Duan, Ronghui" List-Id: xen-devel@lists.xenproject.org On Mon, Aug 20, 2012 at 06:56:02PM +0000, Justin Gibbs wrote: > Ronghui, > > It has been a while since I've actively worked on the blkif stuff. ... > > That said, I'm happy to help in whatever ways I can to help get the blkif interface sorted out. I see several steps that should be taken: > > 1) Fix the Xen and QEMU builds so that QEMU keeps its own copy of the Xen interface version. This will allow interfaces to rev safely and in a coordinated fashion (i.e. update interface in Xen, then add support for the new interface in QEMU upstream). > > 2) Complete support in drivers for the existing blkif interface so that you get maximum performance against systems using the existing multi-page extensions. > > 3) Do something to allow for larger and more numerous requests. > > On point 3, my approach was to try to perturb the existing protocol as little as possible in the hopes that other implementations could quickly be enhanced to support the feature. However, there is a lot of ugliness in the existing blkif interface. I can certainly understand the desires of some to just replace blkif with a blkif2. > > What are your current plans in this area? How can I be of assistance? Hey Justin and Ronghui, Note: I've expanded the email thread to include xen-devel. I was wondering how the protocol you developed works when it comes to migration to a host that does not support the new features? Specifically how do deal with a guest which tries to replay in progress I/Os that do not fit within the old-segment size (11)?