Virtualization - Jun 2019 - [PATCH v3 4/8] s390/airq: use DMA memory for adapter interrupts

On Wed, 29 May 2019 14:26:53 +0200
Michael Mueller <mimu at linux.ibm.com> wrote:
> From: Halil Pasic <pasic at linux.ibm.com>
> 
> Protected virtualization guests have to use shared pages for airq
> notifier bit vectors, because hypervisor needs to write these bits.
> 
> Let us make sure we allocate DMA memory for the notifier bit vectors by
> replacing the kmem_cache with a dma_cache and kalloc() with
> cio_dma_zalloc().
> 
> Signed-off-by: Halil Pasic <pasic at linux.ibm.com>
> Reviewed-by: Sebastian Ott <sebott at linux.ibm.com>
> Signed-off-by: Michael Mueller <mimu at linux.ibm.com>
> ---
>  arch/s390/include/asm/airq.h |  2 ++
>  drivers/s390/cio/airq.c      | 32 ++++++++++++++++++++------------
>  drivers/s390/cio/cio.h       |  2 ++
>  drivers/s390/cio/css.c       |  1 +
>  4 files changed, 25 insertions(+), 12 deletions(-)
Apologies if that already has been answered (and I missed it in my mail
pile...), but two things had come to my mind previously:

- CHSC... does anything need to be done there? Last time I asked:
  "Anyway, css_bus_init() uses some chscs
   early (before cio_dma_pool_init), so we could not use the pools
   there, even if we wanted to. Do chsc commands either work, or else
   fail benignly on a protected virt guest?"
- PCI indicators... does this interact with any dma configuration on
  the pci device? (I know pci is not supported yet, and I don't really
  expect any problems.)

On Mon, 3 Jun 2019 17:27:40 +0200
Cornelia Huck <cohuck at redhat.com> wrote:
> On Wed, 29 May 2019 14:26:53 +0200
> Michael Mueller <mimu at linux.ibm.com> wrote:
> 
> > From: Halil Pasic <pasic at linux.ibm.com>
> > 
> > Protected virtualization guests have to use shared pages for airq
> > notifier bit vectors, because hypervisor needs to write these bits.
> > 
> > Let us make sure we allocate DMA memory for the notifier bit vectors
by
> > replacing the kmem_cache with a dma_cache and kalloc() with
> > cio_dma_zalloc().
> > 
> > Signed-off-by: Halil Pasic <pasic at linux.ibm.com>
> > Reviewed-by: Sebastian Ott <sebott at linux.ibm.com>
> > Signed-off-by: Michael Mueller <mimu at linux.ibm.com>
> > ---
> >  arch/s390/include/asm/airq.h |  2 ++
> >  drivers/s390/cio/airq.c      | 32 ++++++++++++++++++++------------
> >  drivers/s390/cio/cio.h       |  2 ++
> >  drivers/s390/cio/css.c       |  1 +
> >  4 files changed, 25 insertions(+), 12 deletions(-)
> 
> Apologies if that already has been answered (and I missed it in my mail
> pile...), but two things had come to my mind previously:
> 
> - CHSC... does anything need to be done there? Last time I asked:
>   "Anyway, css_bus_init() uses some chscs
>    early (before cio_dma_pool_init), so we could not use the pools
>    there, even if we wanted to. Do chsc commands either work, or else
>    fail benignly on a protected virt guest?"
Protected virt won't support all CHSC. The supported ones won't requre
use of shared memory. So we are fine.
> - PCI indicators... does this interact with any dma configuration on
>   the pci device? (I know pci is not supported yet, and I don't really
>   expect any problems.)
> 
It does but, I'm pretty confident we don't have a problem with PCI. IMHO
Sebastian is the guy who needs to be paranoid about this, and he r-b-ed
the respective patches.

Regards,
Halil

On Tue, 4 Jun 2019 15:22:56 +0200
Halil Pasic <pasic at linux.ibm.com> wrote:
> On Mon, 3 Jun 2019 17:27:40 +0200
> Cornelia Huck <cohuck at redhat.com> wrote:
> > Apologies if that already has been answered (and I missed it in my
mail
> > pile...), but two things had come to my mind previously:
> > 
> > - CHSC... does anything need to be done there? Last time I asked:
> >   "Anyway, css_bus_init() uses some chscs
> >    early (before cio_dma_pool_init), so we could not use the pools
> >    there, even if we wanted to. Do chsc commands either work, or else
> >    fail benignly on a protected virt guest?"  
> 
> Protected virt won't support all CHSC. The supported ones won't
requre
> use of shared memory. So we are fine.
I suppose the supported ones are the sync chscs that use the chsc area
as a direct parameter (and therefore are handled similarly to the other
I/O instructions that supply a direct parameter)? I don't think we care
about async chscs in KVM/QEMU anyway, as we don't even emulate chsc
subchannels :) (And IIRC, you don't get chsc subchannels in z/VM
guests, either.)
> 
> > - PCI indicators... does this interact with any dma configuration on
> >   the pci device? (I know pci is not supported yet, and I don't
really
> >   expect any problems.)
> >   
> 
> It does but, I'm pretty confident we don't have a problem with PCI.
IMHO
> Sebastian is the guy who needs to be paranoid about this, and he r-b-ed
> the respective patches.
Just wanted to make sure that this was on the radar. You guys are
obviously in a better position than me to judge this :)

Anyway, I do not intend to annoy with those questions, it's just hard
to get a feel if there are areas that still need care if you don't have
access to the documentation for this... if you tell me that you are
aware of it and it should work, that's fine for me.