All of lore.kernel.org
 help / color / mirror / Atom feed
From: Halil Pasic <pasic@linux.ibm.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Will Deacon <will@kernel.org>,
	iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
	Guenter Roeck <linux@roeck-us.net>,
	Claire Chang <tientzu@chromium.org>,
	Christoph Hellwig <hch@lst.de>,
	Robin Murphy <robin.murphy@arm.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Nathan Chancellor <nathan@kernel.org>,
	Halil Pasic <pasic@linux.ibm.com>
Subject: Re: [PATCH v2 0/4] Fix restricted DMA vs swiotlb_exit()
Date: Fri, 23 Jul 2021 03:12:52 +0200	[thread overview]
Message-ID: <20210723031252.655d6a83.pasic@linux.ibm.com> (raw)
In-Reply-To: <57e37ef9-c055-d6a6-2244-2c7dd243b5c1@de.ibm.com>

On Thu, 22 Jul 2021 21:22:58 +0200
Christian Borntraeger <borntraeger@de.ibm.com> wrote:

> On 20.07.21 15:38, Will Deacon wrote:
> > Hi again, folks,
> > 
> > This is version two of the patch series I posted yesterday:
> > 
> >    https://lore.kernel.org/r/20210719123054.6844-1-will@kernel.org
> > 
> > The only changes since v1 are:
> > 
> >    * Squash patches 2 and 3, amending the commit message accordingly
> >    * Add Reviewed-by and Tested-by tags from Christoph and Claire (thanks!)
> > 
> > I'd usually leave it a bit longer between postings, but since this fixes
> > issues with patches in -next I thought I'd spin a new version immediately.
> > 
> > Cheers,  
> 
> FWIW, I just bisected virtio-errors with secure execution mode
> qemu-system-s390x: virtio-serial-bus: Unexpected port id 4205794771 for device virtio-serial0.0
> 
> to
> commit 903cd0f315fe426c6a64c54ed389de0becb663dc
> Author: Claire Chang <tientzu@chromium.org>
> Date:   Thu Jun 24 23:55:20 2021 +0800
> 
>       swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing
> 
> Unfortunately this patch series does NOT fix this issue, so it seems that even more
> things are broken.
> 
> Any idea what else might be broken?

I've done some debugging, and I think I know what is going on. Since
that commit we need to set force_swiotlb before the swiotlb itself is
initialized. So the patch below should fix the problem.

--------------------8<-------------------------------------

From: Halil Pasic <pasic@linux.ibm.com>
Date: Fri, 23 Jul 2021 02:57:06 +0200
Subject: [PATCH 1/1] s390/pv: fix the forcing of the swiotlb

Since commit 903cd0f315fe ("swiotlb: Use is_swiotlb_force_bounce for
swiotlb data bouncing") if code sets swiotlb_force it needs to do so
before the swiotlb is initialised. Otherwise
io_tlb_default_mem->force_bounce will not get set to true, and devices
that use (the default) swiotlb will not bounce  despite switolb_force
having the value of SWIOTLB_FORCE.

Let us restore swiotlb functionality for PV by fulfilling this new
requirement.

Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
---
 arch/s390/mm/init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/s390/mm/init.c b/arch/s390/mm/init.c
index 8ac710de1ab1..07bbee9b7320 100644
--- a/arch/s390/mm/init.c
+++ b/arch/s390/mm/init.c
@@ -186,9 +186,9 @@ static void pv_init(void)
 		return;
 
 	/* make sure bounce buffers are shared */
+	swiotlb_force = SWIOTLB_FORCE;
 	swiotlb_init(1);
 	swiotlb_update_mem_attributes();
-	swiotlb_force = SWIOTLB_FORCE;
 }
 
 void __init mem_init(void)
-- 
2.29.2

WARNING: multiple messages have this Message-ID (diff)
From: Halil Pasic <pasic@linux.ibm.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Halil Pasic <pasic@linux.ibm.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Robin Murphy <robin.murphy@arm.com>,
	linux-kernel@vger.kernel.org,
	Nathan Chancellor <nathan@kernel.org>,
	iommu@lists.linux-foundation.org,
	Claire Chang <tientzu@chromium.org>,
	Will Deacon <will@kernel.org>, Christoph Hellwig <hch@lst.de>,
	Guenter Roeck <linux@roeck-us.net>
Subject: Re: [PATCH v2 0/4] Fix restricted DMA vs swiotlb_exit()
Date: Fri, 23 Jul 2021 03:12:52 +0200	[thread overview]
Message-ID: <20210723031252.655d6a83.pasic@linux.ibm.com> (raw)
In-Reply-To: <57e37ef9-c055-d6a6-2244-2c7dd243b5c1@de.ibm.com>

On Thu, 22 Jul 2021 21:22:58 +0200
Christian Borntraeger <borntraeger@de.ibm.com> wrote:

> On 20.07.21 15:38, Will Deacon wrote:
> > Hi again, folks,
> > 
> > This is version two of the patch series I posted yesterday:
> > 
> >    https://lore.kernel.org/r/20210719123054.6844-1-will@kernel.org
> > 
> > The only changes since v1 are:
> > 
> >    * Squash patches 2 and 3, amending the commit message accordingly
> >    * Add Reviewed-by and Tested-by tags from Christoph and Claire (thanks!)
> > 
> > I'd usually leave it a bit longer between postings, but since this fixes
> > issues with patches in -next I thought I'd spin a new version immediately.
> > 
> > Cheers,  
> 
> FWIW, I just bisected virtio-errors with secure execution mode
> qemu-system-s390x: virtio-serial-bus: Unexpected port id 4205794771 for device virtio-serial0.0
> 
> to
> commit 903cd0f315fe426c6a64c54ed389de0becb663dc
> Author: Claire Chang <tientzu@chromium.org>
> Date:   Thu Jun 24 23:55:20 2021 +0800
> 
>       swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing
> 
> Unfortunately this patch series does NOT fix this issue, so it seems that even more
> things are broken.
> 
> Any idea what else might be broken?

I've done some debugging, and I think I know what is going on. Since
that commit we need to set force_swiotlb before the swiotlb itself is
initialized. So the patch below should fix the problem.

--------------------8<-------------------------------------

From: Halil Pasic <pasic@linux.ibm.com>
Date: Fri, 23 Jul 2021 02:57:06 +0200
Subject: [PATCH 1/1] s390/pv: fix the forcing of the swiotlb

Since commit 903cd0f315fe ("swiotlb: Use is_swiotlb_force_bounce for
swiotlb data bouncing") if code sets swiotlb_force it needs to do so
before the swiotlb is initialised. Otherwise
io_tlb_default_mem->force_bounce will not get set to true, and devices
that use (the default) swiotlb will not bounce  despite switolb_force
having the value of SWIOTLB_FORCE.

Let us restore swiotlb functionality for PV by fulfilling this new
requirement.

Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
---
 arch/s390/mm/init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/s390/mm/init.c b/arch/s390/mm/init.c
index 8ac710de1ab1..07bbee9b7320 100644
--- a/arch/s390/mm/init.c
+++ b/arch/s390/mm/init.c
@@ -186,9 +186,9 @@ static void pv_init(void)
 		return;
 
 	/* make sure bounce buffers are shared */
+	swiotlb_force = SWIOTLB_FORCE;
 	swiotlb_init(1);
 	swiotlb_update_mem_attributes();
-	swiotlb_force = SWIOTLB_FORCE;
 }
 
 void __init mem_init(void)
-- 
2.29.2
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  reply	other threads:[~2021-07-23  1:13 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-20 13:38 [PATCH v2 0/4] Fix restricted DMA vs swiotlb_exit() Will Deacon
2021-07-20 13:38 ` Will Deacon
2021-07-20 13:38 ` [PATCH v2 1/4] of: Return success from of_dma_set_restricted_buffer() when !OF_ADDRESS Will Deacon
2021-07-20 13:38   ` Will Deacon
2021-07-20 13:38 ` [PATCH v2 2/4] swiotlb: Convert io_default_tlb_mem to static allocation Will Deacon
2021-07-20 13:38   ` Will Deacon
2021-07-20 13:38 ` [PATCH v2 3/4] swiotlb: Emit diagnostic in swiotlb_exit() Will Deacon
2021-07-20 13:38   ` Will Deacon
2021-07-20 13:38 ` [PATCH v2 4/4] swiotlb: Free tbl memory " Will Deacon
2021-07-20 13:38   ` Will Deacon
2021-07-31 18:26   ` Guenter Roeck
2021-07-31 18:26     ` Guenter Roeck
2021-08-01  2:29     ` Konrad Rzeszutek Wilk
2021-08-01  2:29       ` Konrad Rzeszutek Wilk
2021-08-01  4:26       ` Guenter Roeck
2021-08-01  4:26         ` Guenter Roeck
2021-07-22 19:22 ` [PATCH v2 0/4] Fix restricted DMA vs swiotlb_exit() Christian Borntraeger
2021-07-22 19:22   ` Christian Borntraeger
2021-07-23  1:12   ` Halil Pasic [this message]
2021-07-23  1:12     ` Halil Pasic
2021-07-23  5:51     ` Christian Borntraeger
2021-07-23  5:51       ` Christian Borntraeger
2021-07-23  6:14     ` Christian Borntraeger
2021-07-23  6:14       ` Christian Borntraeger
2021-07-23  8:47       ` Halil Pasic
2021-07-23  8:47         ` Halil Pasic
2021-07-23  8:50         ` Christian Borntraeger
2021-07-23  8:50           ` Christian Borntraeger
2021-07-23 14:01           ` Konrad Rzeszutek Wilk
2021-07-23 14:01             ` Konrad Rzeszutek Wilk
2021-07-23 17:53             ` Christian Borntraeger
2021-07-23 17:53               ` Christian Borntraeger
2021-07-23 22:18               ` Halil Pasic
2021-07-23 22:18                 ` Halil Pasic
2021-07-24  0:29 ` Konrad Rzeszutek Wilk
2021-07-24  0:29   ` Konrad Rzeszutek Wilk

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=20210723031252.655d6a83.pasic@linux.ibm.com \
    --to=pasic@linux.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=hch@lst.de \
    --cc=iommu@lists.linux-foundation.org \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=nathan@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=tientzu@chromium.org \
    --cc=will@kernel.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.