diff mbox

[v3,09/20] xen/biomerge: Don't allow biovec to be merge when Linux is not using 4KB page

Message ID 1438966019-19322-10-git-send-email-julien.grall@citrix.com (mailing list archive)
State New, archived
Headers show

Commit Message

Julien Grall Aug. 7, 2015, 4:46 p.m. UTC
On ARM all dma-capable devices on a same platform may not be protected
by an IOMMU. The DMA requests have to use the BFN (i.e MFN on ARM) in
order to use correctly the device.

While the DOM0 memory is allocated in a 1:1 fashion (PFN == MFN), grant
mapping will screw this contiguous mapping.

When Linux is using 64KB page granularitary, the page may be split
accross multiple non-contiguous MFN (Xen is using 4KB page
granularity). Therefore a DMA request will likely fail.

Checking that a 64KB page is using contiguous MFN is tedious. For
now, always says that biovec are not mergeable.

Signed-off-by: Julien Grall <julien.grall@citrix.com>

---
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: David Vrabel <david.vrabel@citrix.com>

    There is some ideas to check whether two biovec could be merged
    (see [1]) but it's not critical and can be consider as a performance
    improvement.

    Changes in v3:
        - Update commit message
        - s/mfn/bfn/ base on the new renaming
        - Update TODO

    Changes in v2:
        - Remove the workaround and check if the Linux page granularity
        is the same as Xen or not

    [1] https://lkml.org/lkml/2015/7/17/418
---
 drivers/xen/biomerge.c | 8 ++++++++
 1 file changed, 8 insertions(+)

Comments

Stefano Stabellini Aug. 10, 2015, 10:50 a.m. UTC | #1
On Fri, 7 Aug 2015, Julien Grall wrote:
> On ARM all dma-capable devices on a same platform may not be protected
> by an IOMMU. The DMA requests have to use the BFN (i.e MFN on ARM) in
> order to use correctly the device.
> 
> While the DOM0 memory is allocated in a 1:1 fashion (PFN == MFN), grant
> mapping will screw this contiguous mapping.
> 
> When Linux is using 64KB page granularitary, the page may be split
> accross multiple non-contiguous MFN (Xen is using 4KB page
> granularity). Therefore a DMA request will likely fail.
> 
> Checking that a 64KB page is using contiguous MFN is tedious. For
> now, always says that biovec are not mergeable.
> 
> Signed-off-by: Julien Grall <julien.grall@citrix.com>

Please fix the grammar in the subject line.

Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


> ---
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Cc: David Vrabel <david.vrabel@citrix.com>
> 
>     There is some ideas to check whether two biovec could be merged
>     (see [1]) but it's not critical and can be consider as a performance
>     improvement.
> 
>     Changes in v3:
>         - Update commit message
>         - s/mfn/bfn/ base on the new renaming
>         - Update TODO
> 
>     Changes in v2:
>         - Remove the workaround and check if the Linux page granularity
>         is the same as Xen or not
> 
>     [1] https://lkml.org/lkml/2015/7/17/418
> ---
>  drivers/xen/biomerge.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/xen/biomerge.c b/drivers/xen/biomerge.c
> index 8ae2fc90..4da69db 100644
> --- a/drivers/xen/biomerge.c
> +++ b/drivers/xen/biomerge.c
> @@ -6,10 +6,18 @@
>  bool xen_biovec_phys_mergeable(const struct bio_vec *vec1,
>  			       const struct bio_vec *vec2)
>  {
> +#if XEN_PAGE_SIZE == PAGE_SIZE
>  	unsigned long bfn1 = pfn_to_bfn(page_to_pfn(vec1->bv_page));
>  	unsigned long bfn2 = pfn_to_bfn(page_to_pfn(vec2->bv_page));
>  
>  	return __BIOVEC_PHYS_MERGEABLE(vec1, vec2) &&
>  		((bfn1 == bfn2) || ((bfn1+1) == bfn2));
> +#else
> +	/*
> +	 * XXX: Add support for merging bio_vec when using different page
> +	 * size in Xen and Linux.
       ^ sizes

> +	 */
> +	return 0;
> +#endif
>  }
>  EXPORT_SYMBOL(xen_biovec_phys_mergeable);
> -- 
> 2.1.4
>
Julien Grall Aug. 10, 2015, 11:24 a.m. UTC | #2
Hi Stefano,

On 10/08/15 11:50, Stefano Stabellini wrote:
> On Fri, 7 Aug 2015, Julien Grall wrote:
>> On ARM all dma-capable devices on a same platform may not be protected
>> by an IOMMU. The DMA requests have to use the BFN (i.e MFN on ARM) in
>> order to use correctly the device.
>>
>> While the DOM0 memory is allocated in a 1:1 fashion (PFN == MFN), grant
>> mapping will screw this contiguous mapping.
>>
>> When Linux is using 64KB page granularitary, the page may be split
>> accross multiple non-contiguous MFN (Xen is using 4KB page
>> granularity). Therefore a DMA request will likely fail.
>>
>> Checking that a 64KB page is using contiguous MFN is tedious. For
>> now, always says that biovec are not mergeable.
>>
>> Signed-off-by: Julien Grall <julien.grall@citrix.com>
> 
> Please fix the grammar in the subject line.

If I made a mistake it's unlikely that I will find myself which one I made.

Anyway, I guess you mean to replace merge by merged? I don't see any
other in the subject.

Regards,
Stefano Stabellini Aug. 10, 2015, 11:25 a.m. UTC | #3
On Mon, 10 Aug 2015, Julien Grall wrote:
> Hi Stefano,
> 
> On 10/08/15 11:50, Stefano Stabellini wrote:
> > On Fri, 7 Aug 2015, Julien Grall wrote:
> >> On ARM all dma-capable devices on a same platform may not be protected
> >> by an IOMMU. The DMA requests have to use the BFN (i.e MFN on ARM) in
> >> order to use correctly the device.
> >>
> >> While the DOM0 memory is allocated in a 1:1 fashion (PFN == MFN), grant
> >> mapping will screw this contiguous mapping.
> >>
> >> When Linux is using 64KB page granularitary, the page may be split
> >> accross multiple non-contiguous MFN (Xen is using 4KB page
> >> granularity). Therefore a DMA request will likely fail.
> >>
> >> Checking that a 64KB page is using contiguous MFN is tedious. For
> >> now, always says that biovec are not mergeable.
> >>
> >> Signed-off-by: Julien Grall <julien.grall@citrix.com>
> > 
> > Please fix the grammar in the subject line.
> 
> If I made a mistake it's unlikely that I will find myself which one I made.
> 
> Anyway, I guess you mean to replace merge by merged? I don't see any
> other in the subject.

yes and page/pages:

xen/biomerge: Don't allow biovec's to be merged when Linux is not using 4KB pages
Julien Grall Aug. 10, 2015, 11:32 a.m. UTC | #4
On 10/08/15 12:25, Stefano Stabellini wrote:
> yes and page/pages:
> 
> xen/biomerge: Don't allow biovec's to be merged when Linux is not using 4KB pages

Why the ' in biovec's ? Shouldn't we says biovecs directly?

Regards,
David Vrabel Aug. 10, 2015, 12:41 p.m. UTC | #5
On 10/08/15 12:32, Julien Grall wrote:
> On 10/08/15 12:25, Stefano Stabellini wrote:
>> yes and page/pages:
>>
>> xen/biomerge: Don't allow biovec's to be merged when Linux is not using 4KB pages
> 
> Why the ' in biovec's ? Shouldn't we says biovecs directly?

Pluralizing named C structures with apostrophes is valid.  It makes it
clear we're talking about "struct biovec" and not "struct biovecs" objects.

You could also consider "biovec's" to be a contraction for "biovec
objects" so the apostrophe is "correct".

David
diff mbox

Patch

diff --git a/drivers/xen/biomerge.c b/drivers/xen/biomerge.c
index 8ae2fc90..4da69db 100644
--- a/drivers/xen/biomerge.c
+++ b/drivers/xen/biomerge.c
@@ -6,10 +6,18 @@ 
 bool xen_biovec_phys_mergeable(const struct bio_vec *vec1,
 			       const struct bio_vec *vec2)
 {
+#if XEN_PAGE_SIZE == PAGE_SIZE
 	unsigned long bfn1 = pfn_to_bfn(page_to_pfn(vec1->bv_page));
 	unsigned long bfn2 = pfn_to_bfn(page_to_pfn(vec2->bv_page));
 
 	return __BIOVEC_PHYS_MERGEABLE(vec1, vec2) &&
 		((bfn1 == bfn2) || ((bfn1+1) == bfn2));
+#else
+	/*
+	 * XXX: Add support for merging bio_vec when using different page
+	 * size in Xen and Linux.
+	 */
+	return 0;
+#endif
 }
 EXPORT_SYMBOL(xen_biovec_phys_mergeable);