All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefano Stabellini <sstabellini@kernel.org>
To: Juergen Gross <jgross@suse.com>
Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
	iommu@lists.linux-foundation.org, konrad.wilk@oracle.com,
	boris.ostrovsky@oracle.com, sstabellini@kernel.org
Subject: Re: [PATCH 3/3] xen/swiotlb: remember having called xen_create_contiguous_region()
Date: Tue, 23 Apr 2019 10:05:54 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.10.1904230955190.24598@sstabellini-ThinkPad-X260> (raw)
In-Reply-To: <20190423105457.17502-4-jgross@suse.com>

On Tue, 23 Apr 2019, Juergen Gross wrote:
> Instead of always calling xen_destroy_contiguous_region() in case the
> memory is DMA-able for the used device, do so only in case it has been
> made DMA-able via xen_create_contiguous_region() before.
> 
> This will avoid a lot of xen_destroy_contiguous_region() calls for
> 64-bit capable devices.
> 
> As the memory in question is owned by swiotlb-xen the PG_owner_priv_1
> flag of the first allocated page can be used for remembering.

Although the patch looks OK, this sentence puzzles me. Why do you say
that the memory in question is owned by swiotlb-xen? Because it was
returned by xen_alloc_coherent_pages? Both the x86 and the Arm
implementation return fresh new memory, hence, it should be safe to set
the PageOwnerPriv1 flag?

My concern with this approach is with the semantics of PG_owner_priv_1.
Is a page marked with PG_owner_priv_1 only supposed to be used by the
owner?


> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
>  drivers/xen/swiotlb-xen.c | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 43b6e65ae256..a72f181d8e20 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -321,6 +321,7 @@ xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
>  			xen_free_coherent_pages(hwdev, size, ret, (dma_addr_t)phys, attrs);
>  			return NULL;
>  		}
> +		SetPageOwnerPriv1(virt_to_page(ret));
>  	}
>  	memset(ret, 0, size);
>  	return ret;
> @@ -344,9 +345,11 @@ 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 ((dev_addr + size - 1 <= dma_mask) &&
> -	    !WARN_ON(range_straddles_page_boundary(phys, size)))
> -		xen_destroy_contiguous_region(phys, order);
> +	if (PageOwnerPriv1(virt_to_page(vaddr))) {
> +		if (!WARN_ON(range_straddles_page_boundary(phys, size)))
> +			xen_destroy_contiguous_region(phys, order);
> +		ClearPageOwnerPriv1(virt_to_page(vaddr));
> +	}
>  
>  	xen_free_coherent_pages(hwdev, size, vaddr, (dma_addr_t)phys, attrs);
>  }

WARNING: multiple messages have this Message-ID (diff)
From: Stefano Stabellini <sstabellini@kernel.org>
To: Juergen Gross <jgross@suse.com>
Cc: sstabellini@kernel.org, konrad.wilk@oracle.com,
	linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
	xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com
Subject: Re: [PATCH 3/3] xen/swiotlb: remember having called xen_create_contiguous_region()
Date: Tue, 23 Apr 2019 10:05:54 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.10.1904230955190.24598@sstabellini-ThinkPad-X260> (raw)
Message-ID: <20190423170554.Ko59k97b2SiXxBSGAh9wX1tOG1DeojtP2BsEkZHpQts@z> (raw)
In-Reply-To: <20190423105457.17502-4-jgross@suse.com>

On Tue, 23 Apr 2019, Juergen Gross wrote:
> Instead of always calling xen_destroy_contiguous_region() in case the
> memory is DMA-able for the used device, do so only in case it has been
> made DMA-able via xen_create_contiguous_region() before.
> 
> This will avoid a lot of xen_destroy_contiguous_region() calls for
> 64-bit capable devices.
> 
> As the memory in question is owned by swiotlb-xen the PG_owner_priv_1
> flag of the first allocated page can be used for remembering.

Although the patch looks OK, this sentence puzzles me. Why do you say
that the memory in question is owned by swiotlb-xen? Because it was
returned by xen_alloc_coherent_pages? Both the x86 and the Arm
implementation return fresh new memory, hence, it should be safe to set
the PageOwnerPriv1 flag?

My concern with this approach is with the semantics of PG_owner_priv_1.
Is a page marked with PG_owner_priv_1 only supposed to be used by the
owner?


> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
>  drivers/xen/swiotlb-xen.c | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 43b6e65ae256..a72f181d8e20 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -321,6 +321,7 @@ xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
>  			xen_free_coherent_pages(hwdev, size, ret, (dma_addr_t)phys, attrs);
>  			return NULL;
>  		}
> +		SetPageOwnerPriv1(virt_to_page(ret));
>  	}
>  	memset(ret, 0, size);
>  	return ret;
> @@ -344,9 +345,11 @@ 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 ((dev_addr + size - 1 <= dma_mask) &&
> -	    !WARN_ON(range_straddles_page_boundary(phys, size)))
> -		xen_destroy_contiguous_region(phys, order);
> +	if (PageOwnerPriv1(virt_to_page(vaddr))) {
> +		if (!WARN_ON(range_straddles_page_boundary(phys, size)))
> +			xen_destroy_contiguous_region(phys, order);
> +		ClearPageOwnerPriv1(virt_to_page(vaddr));
> +	}
>  
>  	xen_free_coherent_pages(hwdev, size, vaddr, (dma_addr_t)phys, attrs);
>  }
_______________________________________________
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: Juergen Gross <jgross@suse.com>
Cc: sstabellini@kernel.org, konrad.wilk@oracle.com,
	linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
	xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH 3/3] xen/swiotlb: remember having called xen_create_contiguous_region()
Date: Tue, 23 Apr 2019 10:05:54 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.10.1904230955190.24598@sstabellini-ThinkPad-X260> (raw)
In-Reply-To: <20190423105457.17502-4-jgross@suse.com>

On Tue, 23 Apr 2019, Juergen Gross wrote:
> Instead of always calling xen_destroy_contiguous_region() in case the
> memory is DMA-able for the used device, do so only in case it has been
> made DMA-able via xen_create_contiguous_region() before.
> 
> This will avoid a lot of xen_destroy_contiguous_region() calls for
> 64-bit capable devices.
> 
> As the memory in question is owned by swiotlb-xen the PG_owner_priv_1
> flag of the first allocated page can be used for remembering.

Although the patch looks OK, this sentence puzzles me. Why do you say
that the memory in question is owned by swiotlb-xen? Because it was
returned by xen_alloc_coherent_pages? Both the x86 and the Arm
implementation return fresh new memory, hence, it should be safe to set
the PageOwnerPriv1 flag?

My concern with this approach is with the semantics of PG_owner_priv_1.
Is a page marked with PG_owner_priv_1 only supposed to be used by the
owner?


> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
>  drivers/xen/swiotlb-xen.c | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 43b6e65ae256..a72f181d8e20 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -321,6 +321,7 @@ xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
>  			xen_free_coherent_pages(hwdev, size, ret, (dma_addr_t)phys, attrs);
>  			return NULL;
>  		}
> +		SetPageOwnerPriv1(virt_to_page(ret));
>  	}
>  	memset(ret, 0, size);
>  	return ret;
> @@ -344,9 +345,11 @@ 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 ((dev_addr + size - 1 <= dma_mask) &&
> -	    !WARN_ON(range_straddles_page_boundary(phys, size)))
> -		xen_destroy_contiguous_region(phys, order);
> +	if (PageOwnerPriv1(virt_to_page(vaddr))) {
> +		if (!WARN_ON(range_straddles_page_boundary(phys, size)))
> +			xen_destroy_contiguous_region(phys, order);
> +		ClearPageOwnerPriv1(virt_to_page(vaddr));
> +	}
>  
>  	xen_free_coherent_pages(hwdev, size, vaddr, (dma_addr_t)phys, attrs);
>  }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  parent reply	other threads:[~2019-04-23 17:06 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-23 10:54 [PATCH 0/3] xen/swiotlb: fix an issue and improve swiotlb-xen Juergen Gross
2019-04-23 10:54 ` [Xen-devel] " Juergen Gross
2019-04-23 10:54 ` Juergen Gross
2019-04-23 10:54 ` [PATCH 1/3] xen/swiotlb: fix condition for calling xen_destroy_contiguous_region() Juergen Gross
2019-04-23 10:54   ` [Xen-devel] " Juergen Gross
2019-04-23 10:54   ` Juergen Gross
2019-04-23 14:20   ` Boris Ostrovsky
2019-04-23 14:20     ` [Xen-devel] " Boris Ostrovsky
2019-04-23 14:20     ` Boris Ostrovsky
2019-04-23 14:20     ` Boris Ostrovsky
2019-04-23 14:20   ` Boris Ostrovsky
2019-04-25  8:53   ` [Xen-devel] " Jan Beulich
2019-04-25  8:53     ` Jan Beulich
2019-04-25  8:53     ` Jan Beulich
2019-04-25  8:53     ` Jan Beulich
2019-04-23 10:54 ` Juergen Gross
2019-04-23 10:54 ` [PATCH 2/3] xen/swiotlb: simplify range_straddles_page_boundary() Juergen Gross
2019-04-23 10:54 ` Juergen Gross
2019-04-23 10:54   ` [Xen-devel] " Juergen Gross
2019-04-23 10:54   ` Juergen Gross
2019-04-23 14:25   ` Boris Ostrovsky
2019-04-23 14:25     ` [Xen-devel] " Boris Ostrovsky
2019-04-23 14:25     ` Boris Ostrovsky
2019-04-23 14:25     ` Boris Ostrovsky
2019-04-23 14:25   ` Boris Ostrovsky
2019-04-23 10:54 ` [PATCH 3/3] xen/swiotlb: remember having called xen_create_contiguous_region() Juergen Gross
2019-04-23 10:54 ` Juergen Gross
2019-04-23 10:54   ` [Xen-devel] " Juergen Gross
2019-04-23 10:54   ` Juergen Gross
2019-04-23 10:54   ` Juergen Gross
2019-04-23 14:31   ` Boris Ostrovsky
2019-04-23 14:31     ` [Xen-devel] " Boris Ostrovsky
2019-04-23 14:31     ` Boris Ostrovsky
2019-04-23 14:31     ` Boris Ostrovsky
2019-04-23 14:31   ` Boris Ostrovsky
2019-04-23 17:05   ` Stefano Stabellini
2019-04-23 17:05   ` Stefano Stabellini [this message]
2019-04-23 17:05     ` [Xen-devel] " Stefano Stabellini
2019-04-23 17:05     ` Stefano Stabellini
2019-04-23 18:36     ` Juergen Gross
2019-04-23 18:36       ` [Xen-devel] " Juergen Gross
2019-04-23 18:36       ` Juergen Gross
2019-04-25  9:01       ` Jan Beulich
2019-04-25  9:01       ` [Xen-devel] " Jan Beulich
2019-04-25  9:01         ` Jan Beulich
2019-04-25  9:01         ` Jan Beulich
2019-04-25  9:01         ` Jan Beulich
2019-04-23 18:36     ` Juergen Gross
2019-04-25  9:07 Juergen Gross

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.10.1904230955190.24598@sstabellini-ThinkPad-X260 \
    --to=sstabellini@kernel.org \
    --cc=boris.ostrovsky@oracle.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jgross@suse.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.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.