From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 10 Apr 2019 11:20:48 +0200 From: Cornelia Huck Subject: Re: [RFC PATCH 00/12] s390: virtio: support protected virtualization Message-ID: <20190410112048.154c96fc.cohuck@redhat.com> In-Reply-To: <20190404231622.52531-1-pasic@linux.ibm.com> References: <20190404231622.52531-1-pasic@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: kvm-owner@vger.kernel.org List-Archive: List-Post: To: Halil Pasic 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 Fri, 5 Apr 2019 01:16:10 +0200 Halil Pasic wrote: > Enhanced virtualization protection technology may require the use of > bounce buffers for I/O. While support for this was built into the virtio > core, virtio-ccw wasn't changed accordingly. > > Thus what needs to be done to bring virtio-ccw up to speed with respect > to this is: > * use some 'new' common virtio stuff > * make sure that virtio-ccw specific stuff uses shared memory when > talking to the hypervisor (except communication blocks like ORB, these > are handled by the hypervisor) > * make sure the DMA API does what is necessary to talk through shared > memory if we are a protected virtualization guest. > * make sure the common IO layer plays along as well (airqs, sense). It would be good to have a summary somewhere in the code (or Documentation/) as to what needs the dma treatment and what doesn't, for later reference. We don't want people to accidentally break things (especially if they cannot refer to architecture documentation - or will at least some of that be published?) > > The series is structured in incremental fashion: some of the changes are > overridden by following patches. The main reason why is that this is how I > developed. But I think it ain't bad for the didactic and we are a bit more > flexible with regards to throwing out some of the stuff in the end. FWIW, I think reshuffling the patches in the next iteration would ease review. > > Important notes: > > * This is an early (WIP) RFC that does not add any function to the > kernel at his stage, as the ultravisor interactions are left out. > The purpose is getting some early feedback ASAP. I would like some comments from people who have experience with the dma api. > > * In future these patches will depend on some code interacting with the > ultravisor (WIP by Vasily and Janosch). > > * The s390 names are by no means final, and are not properly explained. Should > not hamper understanding too much. If it does please ask. > > * The existing naming in the common infrastructure (kernel internal > interfaces) is pretty much based on the AMD SEV terminology. Thus the > names aren't always perfect. There might be merit to changing these > names to more abstract ones. I did not put much thought into that at > the current stage. If we can find some generic names that work well for everyone, converting seems like a good idea. But following SEV is not that bad, either (you'll probably find more people who have heard about SEV than folks familiar with s390 ;) > > > Testing: > > Please use iommu_platform=on for any virtio devices you are going > to test this code with (so virtio actually uses the DMA API). > > Looking forward to your review or any other type of input. I have now read through the whole series and commented in some places. But I'd really like to see comments from others as well. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Cornelia Huck Subject: Re: [RFC PATCH 00/12] s390: virtio: support protected virtualization Date: Wed, 10 Apr 2019 11:20:48 +0200 Message-ID: <20190410112048.154c96fc.cohuck@redhat.com> References: <20190404231622.52531-1-pasic@linux.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20190404231622.52531-1-pasic@linux.ibm.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org To: Halil Pasic Cc: Vasily Gorbik , linux-s390@vger.kernel.org, Eric Farman , Claudio Imbrenda , kvm@vger.kernel.org, Sebastian Ott , Farhan Ali , virtualization@lists.linux-foundation.org, Martin Schwidefsky , Viktor Mihajlovski , Janosch Frank List-Id: virtualization@lists.linuxfoundation.org On Fri, 5 Apr 2019 01:16:10 +0200 Halil Pasic wrote: > Enhanced virtualization protection technology may require the use of > bounce buffers for I/O. While support for this was built into the virtio > core, virtio-ccw wasn't changed accordingly. > > Thus what needs to be done to bring virtio-ccw up to speed with respect > to this is: > * use some 'new' common virtio stuff > * make sure that virtio-ccw specific stuff uses shared memory when > talking to the hypervisor (except communication blocks like ORB, these > are handled by the hypervisor) > * make sure the DMA API does what is necessary to talk through shared > memory if we are a protected virtualization guest. > * make sure the common IO layer plays along as well (airqs, sense). It would be good to have a summary somewhere in the code (or Documentation/) as to what needs the dma treatment and what doesn't, for later reference. We don't want people to accidentally break things (especially if they cannot refer to architecture documentation - or will at least some of that be published?) > > The series is structured in incremental fashion: some of the changes are > overridden by following patches. The main reason why is that this is how I > developed. But I think it ain't bad for the didactic and we are a bit more > flexible with regards to throwing out some of the stuff in the end. FWIW, I think reshuffling the patches in the next iteration would ease review. > > Important notes: > > * This is an early (WIP) RFC that does not add any function to the > kernel at his stage, as the ultravisor interactions are left out. > The purpose is getting some early feedback ASAP. I would like some comments from people who have experience with the dma api. > > * In future these patches will depend on some code interacting with the > ultravisor (WIP by Vasily and Janosch). > > * The s390 names are by no means final, and are not properly explained. Should > not hamper understanding too much. If it does please ask. > > * The existing naming in the common infrastructure (kernel internal > interfaces) is pretty much based on the AMD SEV terminology. Thus the > names aren't always perfect. There might be merit to changing these > names to more abstract ones. I did not put much thought into that at > the current stage. If we can find some generic names that work well for everyone, converting seems like a good idea. But following SEV is not that bad, either (you'll probably find more people who have heard about SEV than folks familiar with s390 ;) > > > Testing: > > Please use iommu_platform=on for any virtio devices you are going > to test this code with (so virtio actually uses the DMA API). > > Looking forward to your review or any other type of input. I have now read through the whole series and commented in some places. But I'd really like to see comments from others as well.