ors by
> replacing the kmem_cache with a dma_cache and kalloc() with
> cio_dma_zalloc().
>
> Signed-off-by: Halil Pasic
Reviewed-by: Sebastian Ott
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxf
t; +/**
> + * Allocate zeroed dma coherent 31 bit addressable memory using
> + * the subchannels dma pool. Maximal size of allocation supported
> + * is PAGE_SIZE.
> + */
drivers/s390/cio/device_ops.c:708: warning: Function parameter or member 'cdev'
not described in 'ccw_device_dma_za
.c:1121: warning: Function parameter or member 'size' not
described in 'cio_dma_zalloc'
Reviewed-by: Sebastian Ott
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
On Mon, 20 May 2019, Halil Pasic wrote:
> On Thu, 16 May 2019 15:59:22 +0200 (CEST)
> Sebastian Ott wrote:
> > We only have a couple of users for airq_iv:
> >
> > virtio_ccw.c: 2K bits
>
> You mean a single allocation is 2k bits (VIRTIO_IV_BITS = 256 * 8)? My
>
On Sun, 12 May 2019, Halil Pasic wrote:
> I've also got code that deals with AIRQ_IV_CACHELINE by turning the
> kmem_cache into a dma_pool.
>
> Cornelia, Sebastian which approach do you prefer:
> 1) get rid of cio_dma_pool and AIRQ_IV_CACHELINE, and waste a page per
> vector, or
> 2) go with the
On Wed, 8 May 2019, Halil Pasic wrote:
> On Wed, 8 May 2019 15:46:42 +0200 (CEST)
> Sebastian Ott wrote:
> > On Fri, 26 Apr 2019, Halil Pasic wrote:
> > > static struct ccw_device * io_subchannel_allocate_dev(struct subchannel
> > > *sch)
> > > {
&
On Wed, 8 May 2019, Halil Pasic wrote:
> On Wed, 8 May 2019 15:18:10 +0200 (CEST)
> Sebastian Ott wrote:
> > > @@ -1063,6 +1163,7 @@ static int __init css_bus_init(void)
> > > unregister_reboot_notifier(_reboot_notifier);
> > &
On Fri, 26 Apr 2019, Halil Pasic wrote:
> @@ -182,6 +190,8 @@ void airq_iv_release(struct airq_iv *iv)
> kfree(iv->ptr);
> kfree(iv->bitlock);
> kfree(iv->vector);
- kfree(iv->vector);
> + dma_free_coherent(cio_get_dma_css_dev(), iv_size(iv->bits),
> +
On Fri, 26 Apr 2019, Halil Pasic wrote:
> static struct ccw_device * io_subchannel_allocate_dev(struct subchannel *sch)
> {
[..]
> + cdev->private = kzalloc(sizeof(struct ccw_device_private),
> + GFP_KERNEL | GFP_DMA);
Do we still need GFP_DMA here (since we
On Fri, 26 Apr 2019, Halil Pasic wrote:
> @@ -224,6 +228,9 @@ struct subchannel *css_alloc_subchannel(struct
> subchannel_id schid,
> INIT_WORK(>todo_work, css_sch_todo);
> sch->dev.release = _subchannel_release;
> device_initialize(>dev);
> + sch->dma_mask =
On Fri, 12 Apr 2019, Halil Pasic wrote:
> On Fri, 12 Apr 2019 14:12:31 +0200 (CEST)
> Sebastian Ott wrote:
> > On Fri, 12 Apr 2019, Halil Pasic wrote:
> > > On Thu, 11 Apr 2019 20:25:01 +0200 (CEST)
> > > Sebastian Ott wrote:
> > > > I don't think we sho
On Fri, 12 Apr 2019, Halil Pasic wrote:
> On Thu, 11 Apr 2019 20:25:01 +0200 (CEST)
> Sebastian Ott wrote:
> > I don't think we should use this global DMA pool. I guess it's OK for
> > stuff like airq (where we don't have a struct device at hand) but for
> > CCW we shoul
On Fri, 5 Apr 2019, Halil Pasic wrote:
> To support protected virtualization cio will need to make sure the
> memory used for communication with the hypervisor is DMA memory.
>
> Let us introduce a DMA pool to cio that will help us in allocating
> deallocating those chunks of memory.
>
> We use
On Fri, 5 Apr 2019, Halil Pasic wrote:
> @@ -1593,20 +1609,29 @@ struct ccw_device * __init
> ccw_device_create_console(struct ccw_driver *drv)
> return ERR_CAST(sch);
>
> io_priv = kzalloc(sizeof(*io_priv), GFP_KERNEL | GFP_DMA);
> - if (!io_priv) {
> -
Hi,
On Fri, 30 Oct 2015, Christian Borntraeger wrote:
> here is the 2nd version of providing an DMA API for s390.
>
> There are some attempts to unify the dma ops (Christoph) as well
> as some attempts to make virtio use the dma API (Andy).
>
> At kernel summit we concluded that we want to use
the noop ops for everything that is not PCI. To compile without PCI
> support we also have to enable the DMA api with virtio.
>
> Signed-off-by: Christian Borntraeger <borntrae...@de.ibm.com>
Acked-by: Sebastian Ott <seb...@linux.vnet.ibm.com>
_
, and only clear out the mapping for a BAR
when this number reaches 0.
Cc: Bjorn Helgaas bhelg...@google.com
Cc: linux-...@vger.kernel.org
Tested-by: Sebastian Ott seb...@linux.vnet.ibm.com
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
Heiko, Martin, can you please ack merging
On Mon, 15 Dec 2014, Michael S. Tsirkin wrote:
From: Michael S Tsirkin m...@redhat.com
Virtio drivers should map the part of the range they need, not
necessarily all of it.
To this end, support mapping ranges within BAR on s390.
Since multiple ranges can now be mapped within a BAR, we keep
On Fri, 19 Dec 2014, Michael S. Tsirkin wrote:
On Fri, Dec 19, 2014 at 03:13:37PM +0100, Sebastian Ott wrote:
On Mon, 15 Dec 2014, Michael S. Tsirkin wrote:
From: Michael S Tsirkin m...@redhat.com
Virtio drivers should map the part of the range they need, not
necessarily all
On Mon, 20 Oct 2014, Michael S. Tsirkin wrote:
On Mon, Oct 20, 2014 at 12:48:18PM +0200, Sebastian Ott wrote:
Hi,
016c98c6f virtio: unify config_changed handling
introduced a warning in virtio_ccw which is fixed by the following patch.
Regards,
Sebastian
---
virtio_ccw
/virtio_ccw.c:891:24: warning: unused variable ‘drv’
[-Wunused-variable]
struct virtio_driver *drv;
Signed-off-by: Sebastian Ott seb...@linux.vnet.ibm.com
---
drivers/s390/kvm/virtio_ccw.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/s390/kvm/virtio_ccw.c b/drivers/s390/kvm
21 matches
Mail list logo
