virtualization.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: Halil Pasic <pasic@linux.ibm.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>,
	linux-s390@vger.kernel.org, Eric Farman <farman@linux.ibm.com>,
	Claudio Imbrenda <imbrenda@linux.ibm.com>,
	kvm@vger.kernel.org, Sebastian Ott <sebott@linux.ibm.com>,
	Farhan Ali <alifm@linux.ibm.com>,
	virtualization@lists.linux-foundation.org,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Viktor Mihajlovski <mihajlov@linux.ibm.com>,
	Janosch Frank <frankja@linux.ibm.com>
Subject: Re: [RFC PATCH 02/12] virtio/s390: DMA support for virtio-ccw
Date: Tue, 9 Apr 2019 11:57:43 +0200	[thread overview]
Message-ID: <20190409115743.26e51b81.cohuck@redhat.com> (raw)
In-Reply-To: <20190404231622.52531-3-pasic@linux.ibm.com>

On Fri,  5 Apr 2019 01:16:12 +0200
Halil Pasic <pasic@linux.ibm.com> wrote:

> Currently we have a problem if a virtio-ccw device has
> VIRTIO_F_IOMMU_PLATFORM. 

Can you please describe what the actual problem is?

> In future we do want to support DMA API with
> virtio-ccw.
> 
> Let us do the plumbing, so the feature VIRTIO_F_IOMMU_PLATFORM works
> with virtio-ccw.
> 
> Let us also switch from legacy avail/used accessors to the DMA aware
> ones (even if it isn't strictly necessary).

I think with this change we can remove the legacy accessors, if I
didn't mis-grep.

> 
> Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
> ---
>  drivers/s390/virtio/virtio_ccw.c | 23 +++++++++++++++++------
>  1 file changed, 17 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/s390/virtio/virtio_ccw.c b/drivers/s390/virtio/virtio_ccw.c
> index edf4afe2d688..5956c9e820bb 100644
> --- a/drivers/s390/virtio/virtio_ccw.c
> +++ b/drivers/s390/virtio/virtio_ccw.c
> @@ -66,6 +66,7 @@ struct virtio_ccw_device {
>  	bool device_lost;
>  	unsigned int config_ready;
>  	void *airq_info;
> +	__u64 dma_mask;

u64?

>  };
>  
>  struct vq_info_block_legacy {
> @@ -536,8 +537,8 @@ static struct virtqueue *virtio_ccw_setup_vq(struct virtio_device *vdev,
>  		info->info_block->s.desc = queue;
>  		info->info_block->s.index = i;
>  		info->info_block->s.num = info->num;
> -		info->info_block->s.avail = (__u64)virtqueue_get_avail(vq);
> -		info->info_block->s.used = (__u64)virtqueue_get_used(vq);
> +		info->info_block->s.avail = (__u64)virtqueue_get_avail_addr(vq);
> +		info->info_block->s.used = (__u64)virtqueue_get_used_addr(vq);
>  		ccw->count = sizeof(info->info_block->s);
>  	}
>  	ccw->cmd_code = CCW_CMD_SET_VQ;
> @@ -769,10 +770,8 @@ static u64 virtio_ccw_get_features(struct virtio_device *vdev)
>  static void ccw_transport_features(struct virtio_device *vdev)
>  {
>  	/*
> -	 * Packed ring isn't enabled on virtio_ccw for now,
> -	 * because virtio_ccw uses some legacy accessors,
> -	 * e.g. virtqueue_get_avail() and virtqueue_get_used()
> -	 * which aren't available in packed ring currently.
> +	 * There shouldn't be anything that precludes supporting paced.

s/paced/packed/

> +	 * TODO: Remove the limitation after having another look into this.
>  	 */
>  	__virtio_clear_bit(vdev, VIRTIO_F_RING_PACKED);
>  }
> @@ -1255,6 +1254,18 @@ static int virtio_ccw_online(struct ccw_device *cdev)
>  		ret = -ENOMEM;
>  		goto out_free;
>  	}
> +	vcdev->vdev.dev.parent = &cdev->dev;

That one makes sense, pci and mmio are doing that as well.

> +	cdev->dev.dma_mask = &vcdev->dma_mask;

That one feels a bit weird. Will this change in one of the follow-on
patches? (Have not yet looked at the whole series.)

> +
> +	ret = dma_set_mask_and_coherent(&cdev->dev, DMA_BIT_MASK(64));
> +	if (ret)
> +		ret = dma_set_mask_and_coherent(&cdev->dev,
> +						DMA_BIT_MASK(32));
> +	if (ret) {
> +		dev_warn(&cdev->dev, "Failed to enable 64-bit or 32-bit DMA.  Trying to continue, but this might not work.\n");

This does not look like you'd try to continue?

> +		goto out_free;
> +	}
> +
>  	vcdev->config_block = kzalloc(sizeof(*vcdev->config_block),
>  				   GFP_DMA | GFP_KERNEL);
>  	if (!vcdev->config_block) {

  parent reply	other threads:[~2019-04-09  9:57 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20190404231622.52531-1-pasic@linux.ibm.com>
     [not found] ` <20190404231622.52531-2-pasic@linux.ibm.com>
2019-04-08 11:01   ` [RFC PATCH 01/12] virtio/s390: use vring_create_virtqueue Cornelia Huck
2019-04-08 12:37     ` Michael S. Tsirkin
     [not found] ` <20190404231622.52531-3-pasic@linux.ibm.com>
2019-04-09  9:57   ` Cornelia Huck [this message]
     [not found]     ` <20190409132927.5df3bc50@oc2783563651>
2019-04-09 13:01       ` [RFC PATCH 02/12] virtio/s390: DMA support for virtio-ccw Cornelia Huck
     [not found]         ` <20190409152313.0296e8f1@oc2783563651>
2019-04-09 15:47           ` Cornelia Huck
     [not found] ` <20190404231622.52531-4-pasic@linux.ibm.com>
2019-04-09 10:16   ` [RFC PATCH 03/12] s390/mm: force swiotlb for protected virtualization Cornelia Huck
     [not found]     ` <20190409125416.73713f23@oc2783563651>
2019-04-09 17:18       ` Cornelia Huck
2019-04-09 12:22   ` Christoph Hellwig
     [not found] ` <20190404231622.52531-5-pasic@linux.ibm.com>
2019-04-09 10:44   ` [RFC PATCH 04/12] s390/cio: introduce cio DMA pool Cornelia Huck
     [not found]     ` <20190409141114.7dcce94a@oc2783563651>
2019-04-09 17:14       ` Cornelia Huck
     [not found]         ` <20190410173148.067555dc@oc2783563651>
2019-04-10 16:07           ` Cornelia Huck
2019-04-11 18:25   ` Sebastian Ott
     [not found]     ` <20190412132010.3c74cb63@oc2783563651>
2019-04-12 12:12       ` Sebastian Ott
     [not found]         ` <20190412173017.04b768bb@oc2783563651>
2019-04-16 12:50           ` Sebastian Ott
     [not found] ` <20190404231622.52531-6-pasic@linux.ibm.com>
2019-04-09 17:55   ` [RFC PATCH 05/12] s390/cio: add protected virtualization support to cio Cornelia Huck
     [not found]     ` <20190410021044.4da3e847@oc2783563651>
2019-04-10  8:25       ` Cornelia Huck
     [not found]         ` <20190410150225.61b86cd9@oc2783563651>
2019-04-10 16:16           ` Cornelia Huck
2019-04-11 14:15   ` Sebastian Ott
     [not found] ` <20190404231622.52531-8-pasic@linux.ibm.com>
2019-04-10  8:42   ` [RFC PATCH 07/12] virtio/s390: use DMA memory for ccw I/O Cornelia Huck
     [not found]     ` <20190410164245.53f8b26d@oc2783563651>
2019-04-10 16:21       ` Cornelia Huck
     [not found] ` <20190404231622.52531-11-pasic@linux.ibm.com>
2019-04-10  8:46   ` [RFC PATCH 10/12] virtio/s390: consolidate DMA allocations Cornelia Huck
     [not found]     ` <20190410171254.71206015@oc2783563651>
2019-04-10 16:36       ` Cornelia Huck
     [not found]         ` <20190410194849.511ecc46@oc2783563651>
2019-04-11  9:24           ` Cornelia Huck
2019-04-10  9:20 ` [RFC PATCH 00/12] s390: virtio: support protected virtualization Cornelia Huck
     [not found]   ` <20190410175750.0ed0a454@oc2783563651>
2019-04-10 16:24     ` Cornelia Huck
2019-04-12 13:47 ` David Hildenbrand
     [not found]   ` <20190416131005.6f3e05eb@oc2783563651>
2019-04-16 11:50     ` David Hildenbrand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190409115743.26e51b81.cohuck@redhat.com \
    --to=cohuck@redhat.com \
    --cc=alifm@linux.ibm.com \
    --cc=farman@linux.ibm.com \
    --cc=frankja@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mihajlov@linux.ibm.com \
    --cc=pasic@linux.ibm.com \
    --cc=schwidefsky@de.ibm.com \
    --cc=sebott@linux.ibm.com \
    --cc=virtualization@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).