All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Jürgen Groß" <jgross@suse.com>, joe.jin@oracle.com
Cc: Peng Fan <peng.fan@nxp.com>,
	"sstabellini@kernel.org" <sstabellini@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	dl-linux-imx <linux-imx@nxp.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"boris.ostrovsky@oracle.com" <boris.ostrovsky@oracle.com>
Subject: Re: [PATCH] xen/swiotlb: correct the check for xen_destroy_contiguous_region
Date: Tue, 28 Apr 2020 13:25:14 -0400	[thread overview]
Message-ID: <20200428172514.GA24178@char.us.oracle.com> (raw)
In-Reply-To: <dba804ea-4268-24ff-7447-ddef00e9e20c@suse.com>

On Tue, Apr 28, 2020 at 12:19:41PM +0200, Jürgen Groß wrote:
> On 28.04.20 10:25, Peng Fan wrote:

Adding Joe Jin.

Joe, didn't you have some ideas on how this could be implemented?

> > > Subject: Re: [PATCH] xen/swiotlb: correct the check for
> > > xen_destroy_contiguous_region
> > > 
> > > On 28.04.20 09:33, peng.fan@nxp.com wrote:
> > > > From: Peng Fan <peng.fan@nxp.com>
> > > > 
> > > > When booting xen on i.MX8QM, met:
> > > > "
> > > > [    3.602128] Unable to handle kernel paging request at virtual address
> > > 0000000000272d40
> > > > [    3.610804] Mem abort info:
> > > > [    3.613905]   ESR = 0x96000004
> > > > [    3.617332]   EC = 0x25: DABT (current EL), IL = 32 bits
> > > > [    3.623211]   SET = 0, FnV = 0
> > > > [    3.626628]   EA = 0, S1PTW = 0
> > > > [    3.630128] Data abort info:
> > > > [    3.633362]   ISV = 0, ISS = 0x00000004
> > > > [    3.637630]   CM = 0, WnR = 0
> > > > [    3.640955] [0000000000272d40] user address but active_mm is
> > > swapper
> > > > [    3.647983] Internal error: Oops: 96000004 [#1] PREEMPT SMP
> > > > [    3.654137] Modules linked in:
> > > > [    3.677285] Hardware name: Freescale i.MX8QM MEK (DT)
> > > > [    3.677302] Workqueue: events deferred_probe_work_func
> > > > [    3.684253] imx6q-pcie 5f000000.pcie: PCI host bridge to bus 0000:00
> > > > [    3.688297] pstate: 60000005 (nZCv daif -PAN -UAO)
> > > > [    3.688310] pc : xen_swiotlb_free_coherent+0x180/0x1c0
> > > > [    3.693993] pci_bus 0000:00: root bus resource [bus 00-ff]
> > > > [    3.701002] lr : xen_swiotlb_free_coherent+0x44/0x1c0
> > > > "
> > > > 
> > > > In xen_swiotlb_alloc_coherent, if !(dev_addr + size - 1 <= dma_mask)
> > > > or range_straddles_page_boundary(phys, size) are true, it will create
> > > > contiguous region. So when free, we need to free contiguous region use
> > > > upper check condition.
> > > 
> > > No, this will break PV guests on x86.
> > 
> > Could you share more details why alloc and free not matching for the check?
> 
> xen_create_contiguous_region() is needed only in case:
> 
> - the bus address is not within dma_mask, or
> - the memory region is not physically contiguous (can happen only for
>   PV guests)
> 
> In any case it should arrange for the memory to be suitable for the
> DMA operation, so to be contiguous and within dma_mask afterwards. So
> xen_destroy_contiguous_region() should only ever called for areas
> which match above criteria, as otherwise we can be sure
> xen_create_contiguous_region() was not used for making the area DMA-able
> in the beginning.
> 
> And this is very important in the PV case, as in those guests the page
> tables are containing the host-PFNs, not the guest-PFNS, and
> xen_create_contiguous_region() will fiddle with host- vs. guest-PFN
> arrangements, and xen_destroy_contiguous_region() is reverting this
> fiddling. Any call of xen_destroy_contiguous_region() for an area it
> was not intended to be called for might swap physical pages beneath
> random virtual addresses, which was the reason for this test to be
> added by me.
> 
> 
> Juergen
> 
> > 
> > Thanks,
> > Peng.
> > 
> > > 
> > > I think there is something wrong with your setup in combination with the ARM
> > > xen_create_contiguous_region() implementation.
> > > 
> > > Stefano?
> > > 
> > > 
> > > Juergen
> > > 
> > > > 
> > > > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > > > ---
> > > >    drivers/xen/swiotlb-xen.c | 4 ++--
> > > >    1 file changed, 2 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> > > > index b6d27762c6f8..ab96e468584f 100644
> > > > --- a/drivers/xen/swiotlb-xen.c
> > > > +++ b/drivers/xen/swiotlb-xen.c
> > > > @@ -346,8 +346,8 @@ xen_swiotlb_free_coherent(struct device *hwdev,
> > > size_t size, void *vaddr,
> > > >    	/* Convert the size to actually allocated. */
> > > >    	size = 1UL << (order + XEN_PAGE_SHIFT);
> > > > 
> > > > -	if (!WARN_ON((dev_addr + size - 1 > dma_mask) ||
> > > > -		     range_straddles_page_boundary(phys, size)) &&
> > > > +	if (((dev_addr + size - 1 > dma_mask) ||
> > > > +	    range_straddles_page_boundary(phys, size)) &&
> > > >    	    TestClearPageXenRemapped(virt_to_page(vaddr)))
> > > >    		xen_destroy_contiguous_region(phys, order);
> > > > 
> > > > 
> > 
> 
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Jürgen Groß" <jgross@suse.com>, joe.jin@oracle.com
Cc: Peng Fan <peng.fan@nxp.com>,
	"sstabellini@kernel.org" <sstabellini@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	dl-linux-imx <linux-imx@nxp.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"boris.ostrovsky@oracle.com" <boris.ostrovsky@oracle.com>
Subject: Re: [PATCH] xen/swiotlb: correct the check for xen_destroy_contiguous_region
Date: Tue, 28 Apr 2020 13:25:14 -0400	[thread overview]
Message-ID: <20200428172514.GA24178@char.us.oracle.com> (raw)
In-Reply-To: <dba804ea-4268-24ff-7447-ddef00e9e20c@suse.com>

On Tue, Apr 28, 2020 at 12:19:41PM +0200, Jürgen Groß wrote:
> On 28.04.20 10:25, Peng Fan wrote:

Adding Joe Jin.

Joe, didn't you have some ideas on how this could be implemented?

> > > Subject: Re: [PATCH] xen/swiotlb: correct the check for
> > > xen_destroy_contiguous_region
> > > 
> > > On 28.04.20 09:33, peng.fan@nxp.com wrote:
> > > > From: Peng Fan <peng.fan@nxp.com>
> > > > 
> > > > When booting xen on i.MX8QM, met:
> > > > "
> > > > [    3.602128] Unable to handle kernel paging request at virtual address
> > > 0000000000272d40
> > > > [    3.610804] Mem abort info:
> > > > [    3.613905]   ESR = 0x96000004
> > > > [    3.617332]   EC = 0x25: DABT (current EL), IL = 32 bits
> > > > [    3.623211]   SET = 0, FnV = 0
> > > > [    3.626628]   EA = 0, S1PTW = 0
> > > > [    3.630128] Data abort info:
> > > > [    3.633362]   ISV = 0, ISS = 0x00000004
> > > > [    3.637630]   CM = 0, WnR = 0
> > > > [    3.640955] [0000000000272d40] user address but active_mm is
> > > swapper
> > > > [    3.647983] Internal error: Oops: 96000004 [#1] PREEMPT SMP
> > > > [    3.654137] Modules linked in:
> > > > [    3.677285] Hardware name: Freescale i.MX8QM MEK (DT)
> > > > [    3.677302] Workqueue: events deferred_probe_work_func
> > > > [    3.684253] imx6q-pcie 5f000000.pcie: PCI host bridge to bus 0000:00
> > > > [    3.688297] pstate: 60000005 (nZCv daif -PAN -UAO)
> > > > [    3.688310] pc : xen_swiotlb_free_coherent+0x180/0x1c0
> > > > [    3.693993] pci_bus 0000:00: root bus resource [bus 00-ff]
> > > > [    3.701002] lr : xen_swiotlb_free_coherent+0x44/0x1c0
> > > > "
> > > > 
> > > > In xen_swiotlb_alloc_coherent, if !(dev_addr + size - 1 <= dma_mask)
> > > > or range_straddles_page_boundary(phys, size) are true, it will create
> > > > contiguous region. So when free, we need to free contiguous region use
> > > > upper check condition.
> > > 
> > > No, this will break PV guests on x86.
> > 
> > Could you share more details why alloc and free not matching for the check?
> 
> xen_create_contiguous_region() is needed only in case:
> 
> - the bus address is not within dma_mask, or
> - the memory region is not physically contiguous (can happen only for
>   PV guests)
> 
> In any case it should arrange for the memory to be suitable for the
> DMA operation, so to be contiguous and within dma_mask afterwards. So
> xen_destroy_contiguous_region() should only ever called for areas
> which match above criteria, as otherwise we can be sure
> xen_create_contiguous_region() was not used for making the area DMA-able
> in the beginning.
> 
> And this is very important in the PV case, as in those guests the page
> tables are containing the host-PFNs, not the guest-PFNS, and
> xen_create_contiguous_region() will fiddle with host- vs. guest-PFN
> arrangements, and xen_destroy_contiguous_region() is reverting this
> fiddling. Any call of xen_destroy_contiguous_region() for an area it
> was not intended to be called for might swap physical pages beneath
> random virtual addresses, which was the reason for this test to be
> added by me.
> 
> 
> Juergen
> 
> > 
> > Thanks,
> > Peng.
> > 
> > > 
> > > I think there is something wrong with your setup in combination with the ARM
> > > xen_create_contiguous_region() implementation.
> > > 
> > > Stefano?
> > > 
> > > 
> > > Juergen
> > > 
> > > > 
> > > > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > > > ---
> > > >    drivers/xen/swiotlb-xen.c | 4 ++--
> > > >    1 file changed, 2 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> > > > index b6d27762c6f8..ab96e468584f 100644
> > > > --- a/drivers/xen/swiotlb-xen.c
> > > > +++ b/drivers/xen/swiotlb-xen.c
> > > > @@ -346,8 +346,8 @@ xen_swiotlb_free_coherent(struct device *hwdev,
> > > size_t size, void *vaddr,
> > > >    	/* Convert the size to actually allocated. */
> > > >    	size = 1UL << (order + XEN_PAGE_SHIFT);
> > > > 
> > > > -	if (!WARN_ON((dev_addr + size - 1 > dma_mask) ||
> > > > -		     range_straddles_page_boundary(phys, size)) &&
> > > > +	if (((dev_addr + size - 1 > dma_mask) ||
> > > > +	    range_straddles_page_boundary(phys, size)) &&
> > > >    	    TestClearPageXenRemapped(virt_to_page(vaddr)))
> > > >    		xen_destroy_contiguous_region(phys, order);
> > > > 
> > > > 
> > 
> 


WARNING: multiple messages have this Message-ID (diff)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Jürgen Groß" <jgross@suse.com>, joe.jin@oracle.com
Cc: Peng Fan <peng.fan@nxp.com>,
	"boris.ostrovsky@oracle.com" <boris.ostrovsky@oracle.com>,
	"sstabellini@kernel.org" <sstabellini@kernel.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	dl-linux-imx <linux-imx@nxp.com>
Subject: Re: [PATCH] xen/swiotlb: correct the check for xen_destroy_contiguous_region
Date: Tue, 28 Apr 2020 13:25:14 -0400	[thread overview]
Message-ID: <20200428172514.GA24178@char.us.oracle.com> (raw)
In-Reply-To: <dba804ea-4268-24ff-7447-ddef00e9e20c@suse.com>

On Tue, Apr 28, 2020 at 12:19:41PM +0200, Jürgen Groß wrote:
> On 28.04.20 10:25, Peng Fan wrote:

Adding Joe Jin.

Joe, didn't you have some ideas on how this could be implemented?

> > > Subject: Re: [PATCH] xen/swiotlb: correct the check for
> > > xen_destroy_contiguous_region
> > > 
> > > On 28.04.20 09:33, peng.fan@nxp.com wrote:
> > > > From: Peng Fan <peng.fan@nxp.com>
> > > > 
> > > > When booting xen on i.MX8QM, met:
> > > > "
> > > > [    3.602128] Unable to handle kernel paging request at virtual address
> > > 0000000000272d40
> > > > [    3.610804] Mem abort info:
> > > > [    3.613905]   ESR = 0x96000004
> > > > [    3.617332]   EC = 0x25: DABT (current EL), IL = 32 bits
> > > > [    3.623211]   SET = 0, FnV = 0
> > > > [    3.626628]   EA = 0, S1PTW = 0
> > > > [    3.630128] Data abort info:
> > > > [    3.633362]   ISV = 0, ISS = 0x00000004
> > > > [    3.637630]   CM = 0, WnR = 0
> > > > [    3.640955] [0000000000272d40] user address but active_mm is
> > > swapper
> > > > [    3.647983] Internal error: Oops: 96000004 [#1] PREEMPT SMP
> > > > [    3.654137] Modules linked in:
> > > > [    3.677285] Hardware name: Freescale i.MX8QM MEK (DT)
> > > > [    3.677302] Workqueue: events deferred_probe_work_func
> > > > [    3.684253] imx6q-pcie 5f000000.pcie: PCI host bridge to bus 0000:00
> > > > [    3.688297] pstate: 60000005 (nZCv daif -PAN -UAO)
> > > > [    3.688310] pc : xen_swiotlb_free_coherent+0x180/0x1c0
> > > > [    3.693993] pci_bus 0000:00: root bus resource [bus 00-ff]
> > > > [    3.701002] lr : xen_swiotlb_free_coherent+0x44/0x1c0
> > > > "
> > > > 
> > > > In xen_swiotlb_alloc_coherent, if !(dev_addr + size - 1 <= dma_mask)
> > > > or range_straddles_page_boundary(phys, size) are true, it will create
> > > > contiguous region. So when free, we need to free contiguous region use
> > > > upper check condition.
> > > 
> > > No, this will break PV guests on x86.
> > 
> > Could you share more details why alloc and free not matching for the check?
> 
> xen_create_contiguous_region() is needed only in case:
> 
> - the bus address is not within dma_mask, or
> - the memory region is not physically contiguous (can happen only for
>   PV guests)
> 
> In any case it should arrange for the memory to be suitable for the
> DMA operation, so to be contiguous and within dma_mask afterwards. So
> xen_destroy_contiguous_region() should only ever called for areas
> which match above criteria, as otherwise we can be sure
> xen_create_contiguous_region() was not used for making the area DMA-able
> in the beginning.
> 
> And this is very important in the PV case, as in those guests the page
> tables are containing the host-PFNs, not the guest-PFNS, and
> xen_create_contiguous_region() will fiddle with host- vs. guest-PFN
> arrangements, and xen_destroy_contiguous_region() is reverting this
> fiddling. Any call of xen_destroy_contiguous_region() for an area it
> was not intended to be called for might swap physical pages beneath
> random virtual addresses, which was the reason for this test to be
> added by me.
> 
> 
> Juergen
> 
> > 
> > Thanks,
> > Peng.
> > 
> > > 
> > > I think there is something wrong with your setup in combination with the ARM
> > > xen_create_contiguous_region() implementation.
> > > 
> > > Stefano?
> > > 
> > > 
> > > Juergen
> > > 
> > > > 
> > > > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > > > ---
> > > >    drivers/xen/swiotlb-xen.c | 4 ++--
> > > >    1 file changed, 2 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> > > > index b6d27762c6f8..ab96e468584f 100644
> > > > --- a/drivers/xen/swiotlb-xen.c
> > > > +++ b/drivers/xen/swiotlb-xen.c
> > > > @@ -346,8 +346,8 @@ xen_swiotlb_free_coherent(struct device *hwdev,
> > > size_t size, void *vaddr,
> > > >    	/* Convert the size to actually allocated. */
> > > >    	size = 1UL << (order + XEN_PAGE_SHIFT);
> > > > 
> > > > -	if (!WARN_ON((dev_addr + size - 1 > dma_mask) ||
> > > > -		     range_straddles_page_boundary(phys, size)) &&
> > > > +	if (((dev_addr + size - 1 > dma_mask) ||
> > > > +	    range_straddles_page_boundary(phys, size)) &&
> > > >    	    TestClearPageXenRemapped(virt_to_page(vaddr)))
> > > >    		xen_destroy_contiguous_region(phys, order);
> > > > 
> > > > 
> > 
> 

  reply	other threads:[~2020-04-28 17:25 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-28  7:33 [PATCH] xen/swiotlb: correct the check for xen_destroy_contiguous_region peng.fan
2020-04-28  7:33 ` peng.fan
2020-04-28  7:33 ` peng.fan
2020-04-28  8:02 ` Christoph Hellwig
2020-04-28  8:02   ` Christoph Hellwig
2020-04-28  8:02   ` Christoph Hellwig
2020-04-28  8:21   ` Peng Fan
2020-04-28  8:21     ` Peng Fan
2020-04-28  8:21     ` Peng Fan
2020-04-28  8:09 ` Jürgen Groß
2020-04-28  8:09   ` Jürgen Groß
2020-04-28  8:25   ` Peng Fan
2020-04-28  8:25     ` Peng Fan
2020-04-28 10:19     ` Jürgen Groß
2020-04-28 10:19       ` Jürgen Groß
2020-04-28 17:25       ` Konrad Rzeszutek Wilk [this message]
2020-04-28 17:25         ` Konrad Rzeszutek Wilk
2020-04-28 17:25         ` Konrad Rzeszutek Wilk
2020-04-28 18:37         ` Joe Jin
2020-04-28 18:37           ` Joe Jin
2020-04-28 18:37           ` Joe Jin
2020-04-28 18:46   ` Stefano Stabellini
2020-04-28 18:46     ` Stefano Stabellini
2020-04-28 18:46     ` Stefano Stabellini

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=20200428172514.GA24178@char.us.oracle.com \
    --to=konrad.wilk@oracle.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jgross@suse.com \
    --cc=joe.jin@oracle.com \
    --cc=linux-imx@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peng.fan@nxp.com \
    --cc=sstabellini@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.