All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefano Stabellini <sstabellini@kernel.org>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Peng Fan <peng.fan@nxp.com>,
	sstabellini@kernel.org, boris.ostrovsky@oracle.com,
	jgross@suse.com, konrad.wilk@oracle.com, jasowang@redhat.com,
	x86@kernel.org, xen-devel@lists.xenproject.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
	virtualization@lists.linux-foundation.org, linux-imx@nxp.com
Subject: Re: [PATCH] xen: introduce xen_vring_use_dma
Date: Wed, 24 Jun 2020 10:59:47 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.21.2006241047010.8121@sstabellini-ThinkPad-T480s> (raw)
In-Reply-To: <20200624050355-mutt-send-email-mst@kernel.org>

On Wed, 24 Jun 2020, Michael S. Tsirkin wrote:
> On Wed, Jun 24, 2020 at 05:17:32PM +0800, Peng Fan wrote:
> > Export xen_swiotlb for all platforms using xen swiotlb
> > 
> > Use xen_swiotlb to determine when vring should use dma APIs to map the
> > ring: when xen_swiotlb is enabled the dma API is required. When it is
> > disabled, it is not required.
> > 
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> 
> Isn't there some way to use VIRTIO_F_IOMMU_PLATFORM for this?
> Xen was there first, but everyone else is using that now.

Unfortunately it is complicated and it is not related to
VIRTIO_F_IOMMU_PLATFORM :-(


The Xen subsystem in Linux uses dma_ops via swiotlb_xen to translate
foreign mappings (memory coming from other VMs) to physical addresses.
On x86, it also uses dma_ops to translate Linux's idea of a physical
address into a real physical address (this is unneeded on ARM.)


So regardless of VIRTIO_F_IOMMU_PLATFORM, dma_ops should be used on Xen/x86
always and on Xen/ARM if Linux is Dom0 (because it has foreign
mappings.) That is why we have the if (xen_domain) return true; in
vring_use_dma_api.

You might have noticed that I missed one possible case above: Xen/ARM
DomU :-)

Xen/ARM domUs don't need swiotlb_xen, it is not even initialized. So if
(xen_domain) return true; would give the wrong answer in that case.
Linux would end up calling the "normal" dma_ops, not swiotlb-xen, and
the "normal" dma_ops fail.


The solution I suggested was to make the check in vring_use_dma_api more
flexible by returning true if the swiotlb_xen is supposed to be used,
not in general for all Xen domains, because that is what the check was
really meant to do.


In this regards I have two more comments:

- the comment on top of the check in vring_use_dma_api is still valid
- the patch looks broken on x86: it should always return true, but it
  returns false instead

 
> > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> > index a2de775801af..768afd79f67a 100644
> > --- a/drivers/virtio/virtio_ring.c
> > +++ b/drivers/virtio/virtio_ring.c
> > @@ -252,7 +252,7 @@ static bool vring_use_dma_api(struct virtio_device *vdev)
> >  	 * the DMA API if we're a Xen guest, which at least allows
> >  	 * all of the sensible Xen configurations to work correctly.
> >  	 */
> > -	if (xen_domain())
> > +	if (xen_vring_use_dma())
> >  		return true;
> >  
> >  	return false;
> 
> 
> The comment above this should probably be fixed.

> 

WARNING: multiple messages have this Message-ID (diff)
From: Stefano Stabellini <sstabellini@kernel.org>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: jgross@suse.com, Peng Fan <peng.fan@nxp.com>,
	sstabellini@kernel.org, konrad.wilk@oracle.com,
	jasowang@redhat.com, x86@kernel.org,
	linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	iommu@lists.linux-foundation.org, linux-imx@nxp.com,
	xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] xen: introduce xen_vring_use_dma
Date: Wed, 24 Jun 2020 10:59:47 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.21.2006241047010.8121@sstabellini-ThinkPad-T480s> (raw)
In-Reply-To: <20200624050355-mutt-send-email-mst@kernel.org>

On Wed, 24 Jun 2020, Michael S. Tsirkin wrote:
> On Wed, Jun 24, 2020 at 05:17:32PM +0800, Peng Fan wrote:
> > Export xen_swiotlb for all platforms using xen swiotlb
> > 
> > Use xen_swiotlb to determine when vring should use dma APIs to map the
> > ring: when xen_swiotlb is enabled the dma API is required. When it is
> > disabled, it is not required.
> > 
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> 
> Isn't there some way to use VIRTIO_F_IOMMU_PLATFORM for this?
> Xen was there first, but everyone else is using that now.

Unfortunately it is complicated and it is not related to
VIRTIO_F_IOMMU_PLATFORM :-(


The Xen subsystem in Linux uses dma_ops via swiotlb_xen to translate
foreign mappings (memory coming from other VMs) to physical addresses.
On x86, it also uses dma_ops to translate Linux's idea of a physical
address into a real physical address (this is unneeded on ARM.)


So regardless of VIRTIO_F_IOMMU_PLATFORM, dma_ops should be used on Xen/x86
always and on Xen/ARM if Linux is Dom0 (because it has foreign
mappings.) That is why we have the if (xen_domain) return true; in
vring_use_dma_api.

You might have noticed that I missed one possible case above: Xen/ARM
DomU :-)

Xen/ARM domUs don't need swiotlb_xen, it is not even initialized. So if
(xen_domain) return true; would give the wrong answer in that case.
Linux would end up calling the "normal" dma_ops, not swiotlb-xen, and
the "normal" dma_ops fail.


The solution I suggested was to make the check in vring_use_dma_api more
flexible by returning true if the swiotlb_xen is supposed to be used,
not in general for all Xen domains, because that is what the check was
really meant to do.


In this regards I have two more comments:

- the comment on top of the check in vring_use_dma_api is still valid
- the patch looks broken on x86: it should always return true, but it
  returns false instead

 
> > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> > index a2de775801af..768afd79f67a 100644
> > --- a/drivers/virtio/virtio_ring.c
> > +++ b/drivers/virtio/virtio_ring.c
> > @@ -252,7 +252,7 @@ static bool vring_use_dma_api(struct virtio_device *vdev)
> >  	 * the DMA API if we're a Xen guest, which at least allows
> >  	 * all of the sensible Xen configurations to work correctly.
> >  	 */
> > -	if (xen_domain())
> > +	if (xen_vring_use_dma())
> >  		return true;
> >  
> >  	return false;
> 
> 
> The comment above this should probably be fixed.

> 
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
From: Stefano Stabellini <sstabellini@kernel.org>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: jgross@suse.com, Peng Fan <peng.fan@nxp.com>,
	sstabellini@kernel.org, konrad.wilk@oracle.com,
	jasowang@redhat.com, x86@kernel.org,
	linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	iommu@lists.linux-foundation.org, linux-imx@nxp.com,
	xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] xen: introduce xen_vring_use_dma
Date: Wed, 24 Jun 2020 10:59:47 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.21.2006241047010.8121@sstabellini-ThinkPad-T480s> (raw)
In-Reply-To: <20200624050355-mutt-send-email-mst@kernel.org>

On Wed, 24 Jun 2020, Michael S. Tsirkin wrote:
> On Wed, Jun 24, 2020 at 05:17:32PM +0800, Peng Fan wrote:
> > Export xen_swiotlb for all platforms using xen swiotlb
> > 
> > Use xen_swiotlb to determine when vring should use dma APIs to map the
> > ring: when xen_swiotlb is enabled the dma API is required. When it is
> > disabled, it is not required.
> > 
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> 
> Isn't there some way to use VIRTIO_F_IOMMU_PLATFORM for this?
> Xen was there first, but everyone else is using that now.

Unfortunately it is complicated and it is not related to
VIRTIO_F_IOMMU_PLATFORM :-(


The Xen subsystem in Linux uses dma_ops via swiotlb_xen to translate
foreign mappings (memory coming from other VMs) to physical addresses.
On x86, it also uses dma_ops to translate Linux's idea of a physical
address into a real physical address (this is unneeded on ARM.)


So regardless of VIRTIO_F_IOMMU_PLATFORM, dma_ops should be used on Xen/x86
always and on Xen/ARM if Linux is Dom0 (because it has foreign
mappings.) That is why we have the if (xen_domain) return true; in
vring_use_dma_api.

You might have noticed that I missed one possible case above: Xen/ARM
DomU :-)

Xen/ARM domUs don't need swiotlb_xen, it is not even initialized. So if
(xen_domain) return true; would give the wrong answer in that case.
Linux would end up calling the "normal" dma_ops, not swiotlb-xen, and
the "normal" dma_ops fail.


The solution I suggested was to make the check in vring_use_dma_api more
flexible by returning true if the swiotlb_xen is supposed to be used,
not in general for all Xen domains, because that is what the check was
really meant to do.


In this regards I have two more comments:

- the comment on top of the check in vring_use_dma_api is still valid
- the patch looks broken on x86: it should always return true, but it
  returns false instead

 
> > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> > index a2de775801af..768afd79f67a 100644
> > --- a/drivers/virtio/virtio_ring.c
> > +++ b/drivers/virtio/virtio_ring.c
> > @@ -252,7 +252,7 @@ static bool vring_use_dma_api(struct virtio_device *vdev)
> >  	 * the DMA API if we're a Xen guest, which at least allows
> >  	 * all of the sensible Xen configurations to work correctly.
> >  	 */
> > -	if (xen_domain())
> > +	if (xen_vring_use_dma())
> >  		return true;
> >  
> >  	return false;
> 
> 
> The comment above this should probably be fixed.

> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Stefano Stabellini <sstabellini@kernel.org>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: jgross@suse.com, Peng Fan <peng.fan@nxp.com>,
	sstabellini@kernel.org, konrad.wilk@oracle.com,
	jasowang@redhat.com, x86@kernel.org,
	linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	iommu@lists.linux-foundation.org, linux-imx@nxp.com,
	xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] xen: introduce xen_vring_use_dma
Date: Wed, 24 Jun 2020 10:59:47 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.21.2006241047010.8121@sstabellini-ThinkPad-T480s> (raw)
In-Reply-To: <20200624050355-mutt-send-email-mst@kernel.org>

On Wed, 24 Jun 2020, Michael S. Tsirkin wrote:
> On Wed, Jun 24, 2020 at 05:17:32PM +0800, Peng Fan wrote:
> > Export xen_swiotlb for all platforms using xen swiotlb
> > 
> > Use xen_swiotlb to determine when vring should use dma APIs to map the
> > ring: when xen_swiotlb is enabled the dma API is required. When it is
> > disabled, it is not required.
> > 
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> 
> Isn't there some way to use VIRTIO_F_IOMMU_PLATFORM for this?
> Xen was there first, but everyone else is using that now.

Unfortunately it is complicated and it is not related to
VIRTIO_F_IOMMU_PLATFORM :-(


The Xen subsystem in Linux uses dma_ops via swiotlb_xen to translate
foreign mappings (memory coming from other VMs) to physical addresses.
On x86, it also uses dma_ops to translate Linux's idea of a physical
address into a real physical address (this is unneeded on ARM.)


So regardless of VIRTIO_F_IOMMU_PLATFORM, dma_ops should be used on Xen/x86
always and on Xen/ARM if Linux is Dom0 (because it has foreign
mappings.) That is why we have the if (xen_domain) return true; in
vring_use_dma_api.

You might have noticed that I missed one possible case above: Xen/ARM
DomU :-)

Xen/ARM domUs don't need swiotlb_xen, it is not even initialized. So if
(xen_domain) return true; would give the wrong answer in that case.
Linux would end up calling the "normal" dma_ops, not swiotlb-xen, and
the "normal" dma_ops fail.


The solution I suggested was to make the check in vring_use_dma_api more
flexible by returning true if the swiotlb_xen is supposed to be used,
not in general for all Xen domains, because that is what the check was
really meant to do.


In this regards I have two more comments:

- the comment on top of the check in vring_use_dma_api is still valid
- the patch looks broken on x86: it should always return true, but it
  returns false instead

 
> > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> > index a2de775801af..768afd79f67a 100644
> > --- a/drivers/virtio/virtio_ring.c
> > +++ b/drivers/virtio/virtio_ring.c
> > @@ -252,7 +252,7 @@ static bool vring_use_dma_api(struct virtio_device *vdev)
> >  	 * the DMA API if we're a Xen guest, which at least allows
> >  	 * all of the sensible Xen configurations to work correctly.
> >  	 */
> > -	if (xen_domain())
> > +	if (xen_vring_use_dma())
> >  		return true;
> >  
> >  	return false;
> 
> 
> The comment above this should probably be fixed.

> 


  reply	other threads:[~2020-06-24 17:59 UTC|newest]

Thread overview: 113+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-24  9:17 [PATCH] xen: introduce xen_vring_use_dma Peng Fan
2020-06-24  9:17 ` Peng Fan
2020-06-24  9:17 ` Peng Fan
2020-06-24  9:17 ` Peng Fan
2020-06-24  9:17 ` Peng Fan
2020-06-24  9:06 ` Michael S. Tsirkin
2020-06-24  9:06   ` Michael S. Tsirkin
2020-06-24  9:06   ` Michael S. Tsirkin
2020-06-24  9:06   ` Michael S. Tsirkin
2020-06-24 17:59   ` Stefano Stabellini [this message]
2020-06-24 17:59     ` Stefano Stabellini
2020-06-24 17:59     ` Stefano Stabellini
2020-06-24 17:59     ` Stefano Stabellini
2020-06-24 20:47     ` Michael S. Tsirkin
2020-06-24 20:47       ` Michael S. Tsirkin
2020-06-24 20:47       ` Michael S. Tsirkin
2020-06-24 20:47       ` Michael S. Tsirkin
2020-06-24 20:47       ` Michael S. Tsirkin
2020-06-24 21:53       ` Stefano Stabellini
2020-06-24 21:53         ` Stefano Stabellini
2020-06-24 21:53         ` Stefano Stabellini
2020-06-24 21:53         ` Stefano Stabellini
2020-06-24 22:16         ` Michael S. Tsirkin
2020-06-24 22:16           ` Michael S. Tsirkin
2020-06-24 22:16           ` Michael S. Tsirkin
2020-06-24 22:16           ` Michael S. Tsirkin
2020-06-24 22:16           ` Michael S. Tsirkin
2020-06-25 17:31           ` Stefano Stabellini
2020-06-25 17:31             ` Stefano Stabellini
2020-06-25 17:31             ` Stefano Stabellini
2020-06-25 17:31             ` Stefano Stabellini
2020-06-26 15:32             ` Michael S. Tsirkin
2020-06-26 15:32               ` Michael S. Tsirkin
2020-06-26 15:32               ` Michael S. Tsirkin
2020-06-26 15:32               ` Michael S. Tsirkin
2020-06-26 15:32               ` Michael S. Tsirkin
2020-06-29  3:05               ` Peng Fan
2020-06-29  3:05                 ` Peng Fan
2020-06-29  3:05                 ` Peng Fan
2020-06-29  3:05                 ` Peng Fan
2020-06-29  3:05                 ` Peng Fan
2020-06-29  6:21                 ` Michael S. Tsirkin
2020-06-29  6:21                   ` Michael S. Tsirkin
2020-06-29  6:21                   ` Michael S. Tsirkin
2020-06-29  6:21                   ` Michael S. Tsirkin
2020-06-29  6:21                   ` Michael S. Tsirkin
2020-06-29  6:25                   ` Peng Fan
2020-06-29  6:25                     ` Peng Fan
2020-06-29  6:25                     ` Peng Fan
2020-06-29  6:25                     ` Peng Fan
2020-06-29  6:25                     ` Peng Fan
2020-06-29  6:33                     ` Michael S. Tsirkin
2020-06-29  6:33                       ` Michael S. Tsirkin
2020-06-29  6:33                       ` Michael S. Tsirkin
2020-06-29  6:33                       ` Michael S. Tsirkin
2020-06-29  6:33                       ` Michael S. Tsirkin
2020-06-29  6:35                       ` Peng Fan
2020-06-29  6:35                         ` Peng Fan
2020-06-29  6:35                         ` Peng Fan
2020-06-29  6:35                         ` Peng Fan
2020-06-29  6:35                         ` Peng Fan
2020-06-29 23:49                 ` Stefano Stabellini
2020-06-29 23:49                   ` Stefano Stabellini
2020-06-29 23:49                   ` Stefano Stabellini
2020-06-29 23:49                   ` Stefano Stabellini
2020-06-29 23:49                   ` Stefano Stabellini
2020-06-30  1:40                   ` Peng Fan
2020-06-30  1:40                     ` Peng Fan
2020-06-30  1:40                     ` Peng Fan
2020-06-30  1:40                     ` Peng Fan
2020-06-30  1:40                     ` Peng Fan
2020-06-29 23:46               ` Stefano Stabellini
2020-06-29 23:46                 ` Stefano Stabellini
2020-06-29 23:46                 ` Stefano Stabellini
2020-06-29 23:46                 ` Stefano Stabellini
2020-07-01 13:34                 ` Christoph Hellwig
2020-07-01 13:34                   ` Christoph Hellwig
2020-07-01 13:34                   ` Christoph Hellwig
2020-07-01 13:34                   ` Christoph Hellwig
2020-07-01 17:34                   ` Stefano Stabellini
2020-07-01 17:34                     ` Stefano Stabellini
2020-07-01 17:34                     ` Stefano Stabellini
2020-07-01 17:34                     ` Stefano Stabellini
2020-07-01 20:47                     ` Michael S. Tsirkin
2020-07-01 20:47                       ` Michael S. Tsirkin
2020-07-01 20:47                       ` Michael S. Tsirkin
2020-07-01 20:47                       ` Michael S. Tsirkin
2020-07-01 20:47                       ` Michael S. Tsirkin
2020-07-01 21:23                     ` Michael S. Tsirkin
2020-07-01 21:23                       ` Michael S. Tsirkin
2020-07-01 21:23                       ` Michael S. Tsirkin
2020-07-01 21:23                       ` Michael S. Tsirkin
2020-07-10 17:23                       ` Stefano Stabellini
2020-07-10 17:23                         ` Stefano Stabellini
2020-07-10 17:23                         ` Stefano Stabellini
2020-07-10 17:23                         ` Stefano Stabellini
2020-07-11 18:44                         ` Michael S. Tsirkin
2020-07-11 18:44                           ` Michael S. Tsirkin
2020-07-11 18:44                           ` Michael S. Tsirkin
2020-07-11 18:44                           ` Michael S. Tsirkin
2020-07-15 17:06                           ` Stefano Stabellini
2020-07-15 17:06                             ` Stefano Stabellini
2020-07-15 17:06                             ` Stefano Stabellini
2020-07-15 17:06                             ` Stefano Stabellini
2020-07-13  1:53                         ` Peng Fan
2020-07-13  1:53                           ` Peng Fan
2020-07-13  1:53                           ` Peng Fan
2020-07-13  1:53                           ` Peng Fan
2020-06-29  3:00             ` Peng Fan
2020-06-29  3:00               ` Peng Fan
2020-06-29  3:00               ` Peng Fan
2020-06-29  3:00               ` Peng Fan
2020-06-29  3:00               ` Peng Fan

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=alpine.DEB.2.21.2006241047010.8121@sstabellini-ThinkPad-T480s \
    --to=sstabellini@kernel.org \
    --cc=boris.ostrovsky@oracle.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jasowang@redhat.com \
    --cc=jgross@suse.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-imx@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=peng.fan@nxp.com \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=x86@kernel.org \
    --cc=xen-devel@lists.xenproject.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.