On Tue, 11 Jun 2019 12:17:21 +0200
Cornelia Huck <cohuck@xxxxxxxxxx> wrote:
> On Thu, 6 Jun 2019 13:51:23 +0200
> Halil Pasic <pasic@xxxxxxxxxxxxx> wrote:
>
> > 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@xxxxxxxxxxxxx>
> > Reviewed-by: Sebastian Ott <sebott@xxxxxxxxxxxxx>
> > ---
> > 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(-)
> >
>
> (...)
>
> > @@ -295,12 +303,12 @@ unsigned long airq_iv_scan(struct airq_iv *iv, unsigned long start,
> > }
> > EXPORT_SYMBOL(airq_iv_scan);
> >
> > -static int __init airq_init(void)
> > +int __init airq_init(void)
> > {
> > - airq_iv_cache = ) "airq_iv_cache", cache_line_size(),
> > - cache_line_size(), 0, NULL);
> > + airq_iv_cache = dma_pool_create("airq_iv_cache", cio_get_dma_css_dev(),
> > + cache_line_size(),
> > + cache_line_size(), PAGE_SIZE);
> > if (!airq_iv_cache)
> > return -ENOMEM;
>
> Sorry about not noticing that in the last iteration; but you may return
> an error here if airq_iv_cache could not be allocated...
>
> > return 0;
> > }
> > -subsys_initcall(airq_init);
>
> (...)
>
> > diff --git a/drivers/s390/cio/css.c b/drivers/s390/cio/css.c
> > index 6fc91d534af1..7901c8ed3597 100644
> > --- a/drivers/s390/cio/css.c
> > +++ b/drivers/s390/cio/css.c
> > @@ -1182,6 +1182,7 @@ static int __init css_bus_init(void)
> > ret = cio_dma_pool_init();
> > if (ret)
> > goto out_unregister_pmn;
> > + airq_init();
>
> ...but don't check the return code here. Probably a pathological case,
> but shouldn't you handle that error as well?
>
Tricky business... The problem is that the airq stuff ain't 'private' to
the CIO subsystem (e.g. zPCI). I'm afraid failing to init css won't
really prevent all usages.
My first thought was, that this is more or less analogous to what we
had before. Namely kmem_cache_create() and dma_pool_create() should fail
under similar circumstances, and the return value of airq_init() was
ignored in do_initcall_level(). So I was like ignoring it seems to be
consistent with previous state.
But, ouch, there is a big difference! While kmem_cache_zalloc() seems
to tolerate the first argument (pointer to kmem_cache) being NULL the
dma_pool_zalloc() does not.
IMHO the cleanest thing to do at this stage is to check if the
airq_iv_cache is NULL and fail the allocation if it is (to preserve
previous behavior).
I would prefer having a separate discussion on eventually changing
the behavior (e.g. fail css initialization).
Connie, would that work with you? Thanks for spotting this!
Regards,
Halil
> > css_init_done = 1;
> >
> > /* Enable default isc for I/O subchannels. */
>
