From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 10 Apr 2019 17:31:48 +0200 From: Halil Pasic Subject: Re: [RFC PATCH 04/12] s390/cio: introduce cio DMA pool In-Reply-To: <20190409191453.01444317.cohuck@redhat.com> References: <20190404231622.52531-1-pasic@linux.ibm.com> <20190404231622.52531-5-pasic@linux.ibm.com> <20190409124458.348d1ff5.cohuck@redhat.com> <20190409141114.7dcce94a@oc2783563651> <20190409191453.01444317.cohuck@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20190410173148.067555dc@oc2783563651> Sender: kvm-owner@vger.kernel.org List-Archive: List-Post: To: Cornelia Huck Cc: kvm@vger.kernel.org, linux-s390@vger.kernel.org, Martin Schwidefsky , Sebastian Ott , virtualization@lists.linux-foundation.org, Christian Borntraeger , Viktor Mihajlovski , Vasily Gorbik , Janosch Frank , Claudio Imbrenda , Farhan Ali , Eric Farman List-ID: On Tue, 9 Apr 2019 19:14:53 +0200 Cornelia Huck wrote: [..] > > > At this point, you're always going via the css0 device. I'm > > > wondering whether you should pass in the cssid here and use > > > css_by_id(cssid) to make this future proof. But then, I'm not > > > quite clear from which context this will be called. > > > > As said before I don't see MCSS-E coming. Regarding the client code, > > please check out the rest of the series. Especially patch 6. > > > > From my perspective it would be at this stage saner to make it more > > obvious that only one css is supported (at the moment), than to > > implement MCSS-E, or to make this (kind of) MCSS-E ready. > > I disagree. I think there's value in keeping the interfaces clean > (within reasonable bounds, of course.) Even if there is no > implementation of MCSS-E other than QEMU... it is probably a good idea > to spend some brain cycles to make this conceptually clean. AFAIU Linux currently does not support MCSS-E. I don't have the bandwidth to implement MCSS-E support in the kernel. I fully agree for external interfaces should be MCSS-E conform, so should we ever decide to implement we don't have to overcome self-made obstacles. Kernel internal stuff however, IMHO, should avoid carrying a ballast of an 20%-30% implemented MCSS-E support. I see no benefit. But I don't insist. If you have a good idea how to make this more MCSS-E conform, you are welcome. In think something like this is best done on top of a series that provides a basic working solution. Especially if the conceptually clean thing is conceptually or code-wise more complex than the basic solution. If you have something in mind that is simpler and more lightweight than what I did here, I would be more than happy to make that happen. Regards, Halil