From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45805) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dwmwL-0004fi-2B for qemu-devel@nongnu.org; Tue, 26 Sep 2017 06:18:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dwmwH-000274-61 for qemu-devel@nongnu.org; Tue, 26 Sep 2017 06:18:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33022) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dwmwG-00026n-W8 for qemu-devel@nongnu.org; Tue, 26 Sep 2017 06:18:05 -0400 Date: Tue, 26 Sep 2017 12:18:00 +0200 From: Cornelia Huck Message-ID: <20170926121800.1e9e1ac1.cohuck@redhat.com> In-Reply-To: <20170921180841.24490-1-pasic@linux.vnet.ibm.com> References: <20170921180841.24490-1-pasic@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v4 0/5] add CCW indirect data access support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Halil Pasic Cc: Dong Jia Shi , Pierre Morel , qemu-devel@nongnu.org On Thu, 21 Sep 2017 20:08:36 +0200 Halil Pasic wrote: > Abstract > -------- > > The objective of this series is introducing CCW IDA (indirect data > access) support to our virtual channel subsystem implementation. Briefly > CCW IDA can be thought of as a kind of a scatter gather support for a > single CCW. If certain flags are set, the cda is to be interpreted as an > address to a list which in turn holds further addresses designating the > actual data. Thus the scheme which we are currently using for accessing > CCW payload does not work in general case. Currently there is no > immediate need for proper IDA handling (no use case), but since it IDA is > a non-optional part of the architecture, the only way towards AR > compliance is actually implementing IDA. > > The focus of this patch set is introducing IDA support. There seems to be > a potential for further improvements based on the introduced > infrastructure, but such improvements are intended to be discusses > separately and realized as patches on top of this series. Hm, do you have a list of what you want to do as follow-on patches? (Checking return codes, ...) It's easy to lose track of all this :)