Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1223062 > unrolled thread

[PATCH 0/2] block/xen-blkfront: Support non-indirect with 64KB page granularity

Back to article view | Back to linux.kernel

Contents

  [PATCH 0/2] block/xen-blkfront: Support non-indirect with 64KB page granularity Julien Grall <julien.grall@citrix.com> - 2015-09-11 21:40 +0200
    [PATCH 1/2] block/xen-blkfront: Introduce blkif_ring_get_request Julien Grall <julien.grall@citrix.com> - 2015-09-11 21:40 +0200
    Re: [Xen-devel] [PATCH 0/2] block/xen-blkfront: Support non-indirect  with 64KB page granularity Bob Liu <bob.liu@oracle.com> - 2015-09-12 11:50 +0200
      Re: [Xen-devel] [PATCH 0/2] block/xen-blkfront: Support non-indirect  with 64KB page granularity Julien Grall <julien.grall@citrix.com> - 2015-09-13 14:10 +0200
        Re: [Xen-devel] [PATCH 0/2] block/xen-blkfront: Support non-indirect  with 64KB page granularity Bob Liu <bob.liu@oracle.com> - 2015-09-13 14:50 +0200
          Re: [Xen-devel] [PATCH 0/2] block/xen-blkfront: Support non-indirect  with 64KB page granularity Julien Grall <julien.grall@citrix.com> - 2015-09-13 19:50 +0200
            Re: [Xen-devel] [PATCH 0/2] block/xen-blkfront: Support non-indirect  with 64KB page granularity Bob Liu <bob.liu@oracle.com> - 2015-09-14 02:40 +0200

#1223062 — [PATCH 0/2] block/xen-blkfront: Support non-indirect with 64KB page granularity

Hi all,

This is a follow-up on the previous discussion [1] related to guest using 64KB
page granularity not booting with backend using non-indirect grant.

This has been successly tested on ARM64 with both 64KB and 4KB page granularity
guests and QEMU as the backend. Indeed QEMU is not supported indirect.

For a summary of the previous discussion see patch #2.

This series is based on top of my 64KB page granularity support [2].

Comments are welcomed.

Sincerely yours,

[1] http://lists.xen.org/archives/html/xen-devel/2015-08/msg01659.html
[2] https://lwn.net/Articles/656797/

Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: "Roger Pau Monné" <roger.pau@citrix.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: David Vrabel <david.vrabel@citrix.com>

Julien Grall (2):
  block/xen-blkfront: Introduce blkif_ring_get_request
  block/xen-blkfront: Handle non-indirect grant with 64KB pages

 drivers/block/xen-blkfront.c | 229 ++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 202 insertions(+), 27 deletions(-)

-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1223065 — [PATCH 1/2] block/xen-blkfront: Introduce blkif_ring_get_request

The code to get a request is always the same. Therefore we can factorize
it in a single function.

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

---
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: "Roger Pau Monné" <roger.pau@citrix.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: David Vrabel <david.vrabel@citrix.com>
---
 drivers/block/xen-blkfront.c | 30 +++++++++++++++++++-----------
 1 file changed, 19 insertions(+), 11 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 43cda94..f9d55c3 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -456,6 +456,23 @@ static int blkif_ioctl(struct block_device *bdev, fmode_t mode,
 	return 0;
 }
 
+static unsigned long blkif_ring_get_request(struct blkfront_info *info,
+					    struct request *req,
+					    struct blkif_request **ring_req)
+{
+	unsigned long id;
+
+	*ring_req = RING_GET_REQUEST(&info->ring, info->ring.req_prod_pvt);
+	info->ring.req_prod_pvt++;
+
+	id = get_id_from_freelist(info);
+	info->shadow[id].request = req;
+
+	(*ring_req)->u.rw.id = id;
+
+	return id;
+}
+
 static int blkif_queue_discard_req(struct request *req)
 {
 	struct blkfront_info *info = req->rq_disk->private_data;
@@ -463,9 +480,7 @@ static int blkif_queue_discard_req(struct request *req)
 	unsigned long id;
 
 	/* Fill out a communications ring structure. */
-	ring_req = RING_GET_REQUEST(&info->ring, info->ring.req_prod_pvt);
-	id = get_id_from_freelist(info);
-	info->shadow[id].request = req;
+	id = blkif_ring_get_request(info, req, &ring_req);
 
 	ring_req->operation = BLKIF_OP_DISCARD;
 	ring_req->u.discard.nr_sectors = blk_rq_sectors(req);
@@ -476,8 +491,6 @@ static int blkif_queue_discard_req(struct request *req)
 	else
 		ring_req->u.discard.flag = 0;
 
-	info->ring.req_prod_pvt++;
-
 	/* Keep a private copy so we can reissue requests when recovering. */
 	info->shadow[id].req = *ring_req;
 
@@ -613,9 +626,7 @@ static int blkif_queue_rw_req(struct request *req)
 		new_persistent_gnts = 0;
 
 	/* Fill out a communications ring structure. */
-	ring_req = RING_GET_REQUEST(&info->ring, info->ring.req_prod_pvt);
-	id = get_id_from_freelist(info);
-	info->shadow[id].request = req;
+	id = blkif_ring_get_request(info, req, &ring_req);
 
 	BUG_ON(info->max_indirect_segments == 0 &&
 	       GREFS(req->nr_phys_segments) > BLKIF_MAX_SEGMENTS_PER_REQUEST);
@@ -628,7 +639,6 @@ static int blkif_queue_rw_req(struct request *req)
 	for_each_sg(info->shadow[id].sg, sg, num_sg, i)
 	       num_grant += gnttab_count_grant(sg->offset, sg->length);
 
-	ring_req->u.rw.id = id;
 	info->shadow[id].num_sg = num_sg;
 	if (num_grant > BLKIF_MAX_SEGMENTS_PER_REQUEST) {
 		/*
@@ -694,8 +704,6 @@ static int blkif_queue_rw_req(struct request *req)
 	if (setup.segments)
 		kunmap_atomic(setup.segments);
 
-	info->ring.req_prod_pvt++;
-
 	/* Keep a private copy so we can reissue requests when recovering. */
 	info->shadow[id].req = *ring_req;
 
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1223359 — Re: [Xen-devel] [PATCH 0/2] block/xen-blkfront: Support non-indirect with 64KB page granularity

Hi Julien,

On 09/12/2015 03:31 AM, Julien Grall wrote:
> Hi all,
> 
> This is a follow-up on the previous discussion [1] related to guest using 64KB
> page granularity not booting with backend using non-indirect grant.
> 
> This has been successly tested on ARM64 with both 64KB and 4KB page granularity
> guests and QEMU as the backend. Indeed QEMU is not supported indirect.
> 

What's the linux kernel page granularity of the backend(dom0) in your test?

Did you test if using xen-blkback as the backend? Especially when linux kernel page
granularity of dom0 is 4kB while domU is 64KB.

Thanks,
-Bob

> For a summary of the previous discussion see patch #2.
> 
> This series is based on top of my 64KB page granularity support [2].
> 
> Comments are welcomed.
> 
> Sincerely yours,
> 
> [1] http://lists.xen.org/archives/html/xen-devel/2015-08/msg01659.html
> [2] https://lwn.net/Articles/656797/
> 
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: "Roger Pau Monné" <roger.pau@citrix.com>
> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Cc: David Vrabel <david.vrabel@citrix.com>
> 
> Julien Grall (2):
>   block/xen-blkfront: Introduce blkif_ring_get_request
>   block/xen-blkfront: Handle non-indirect grant with 64KB pages
> 
>  drivers/block/xen-blkfront.c | 229 ++++++++++++++++++++++++++++++++++++++-----
>  1 file changed, 202 insertions(+), 27 deletions(-)
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1223623 — Re: [Xen-devel] [PATCH 0/2] block/xen-blkfront: Support non-indirect with 64KB page granularity

On 12/09/2015 10:46, Bob Liu wrote:
> Hi Julien,

Hi Bob,


> On 09/12/2015 03:31 AM, Julien Grall wrote:
>> Hi all,
>>
>> This is a follow-up on the previous discussion [1] related to guest using 64KB
>> page granularity not booting with backend using non-indirect grant.
>>
>> This has been successly tested on ARM64 with both 64KB and 4KB page granularity
>> guests and QEMU as the backend. Indeed QEMU is not supported indirect.
>>
>
> What's the linux kernel page granularity of the backend(dom0) in your test?

The PV protocol and the grant are always based on 4KB page granularity. 
So the backend page granularity doesn't matter.

>
> Did you test if using xen-blkback as the backend? Especially when linux kernel page
> granularity of dom0 is 4kB while domU is 64KB.

Sorry, but I don't understand what you are trying to know with those 2 
questions.

xen-blkback is always supporting indirect grant mapping (AFAICT it's not 
possible for the user to disable it). The issue is only happening when 
the backend is not supporting non-indirect grant (such as QEMU).

What matters while testing this series is having a backend which doesn't 
not support indirect grant. All the code added should never be called if 
the backend is support indirect grant and/or the frontend is using 4KB 
page granularity. There is some safeguard in patch #2 to ensure that 
this extra request is never created in those situations (see the 
definition of HAS_EXTRA_REQ).
That means that there is no difference for x86 and arm32 given that the 
page granularity is always 4KB.

Nonetheless, this patchset has been tested with DOM0 4KB using both QEMU 
and xen-blkback for the backend.

I have done testing on backend using 64KB page but with some patches not 
yet sent upstream. This is because gnttdev doesn't yet support 64KB pages.

Regards,

-- 
Julien Grall
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1223668 — Re: [Xen-devel] [PATCH 0/2] block/xen-blkfront: Support non-indirect with 64KB page granularity

On 09/13/2015 08:06 PM, Julien Grall wrote:
> 
> 
> On 12/09/2015 10:46, Bob Liu wrote:
>> Hi Julien,
> 
> Hi Bob,
> 
> 
>> On 09/12/2015 03:31 AM, Julien Grall wrote:
>>> Hi all,
>>>
>>> This is a follow-up on the previous discussion [1] related to guest using 64KB
>>> page granularity not booting with backend using non-indirect grant.
>>>
>>> This has been successly tested on ARM64 with both 64KB and 4KB page granularity
>>> guests and QEMU as the backend. Indeed QEMU is not supported indirect.
>>>
>>
>> What's the linux kernel page granularity of the backend(dom0) in your test?
> 
> The PV protocol and the grant are always based on 4KB page granularity. So the backend page granularity doesn't matter.
> 
>>
>> Did you test if using xen-blkback as the backend? Especially when linux kernel page
>> granularity of dom0 is 4kB while domU is 64KB.
> 
> Sorry, but I don't understand what you are trying to know with those 2 questions.
> 
> xen-blkback is always supporting indirect grant mapping (AFAICT it's not possible for the user to disable it). 
> The issue is only happening when the backend is not supporting non-indirect grant (such as QEMU).
> What matters while testing this series is having a backend which doesn't not support indirect grant. 
> All the code added should never be called if the backend is support indirect grant and/or the frontend is using 4KB page granularity.

I may misunderstood here.
But I think same changes are also required even if backend supports indirect grant when frontend is using 64KB page granularity.
Else
1) How to set up the grant map for requests in domU?
The minimum segment buffer size in a request is PAGE_SIZE(64KB) while grant is 4KB based.

2) Codes like below in blkback.c may not work correctly?
if ((req->u.rw.seg[i].last_sect >= (PAGE_SIZE >> 9)) ||

Because PAGE_SIZE in backend is 4KB, while the written value by domU is 64KB based.

Thanks,
-Bob

> There is some safeguard in patch #2 to ensure that this extra request is never created in those situations (see the definition of HAS_EXTRA_REQ).
> That means that there is no difference for x86 and arm32 given that the page granularity is always 4KB.
> 
> Nonetheless, this patchset has been tested with DOM0 4KB using both QEMU and xen-blkback for the backend.
> 
> I have done testing on backend using 64KB page but with some patches not yet sent upstream. This is because gnttdev doesn't yet support 64KB pages.
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1223729 — Re: [Xen-devel] [PATCH 0/2] block/xen-blkfront: Support non-indirect with 64KB page granularity

On 13/09/2015 13:44, Bob Liu wrote:
> I may misunderstood here.
> But I think same changes are also required even if backend supports indirect grant when frontend is using 64KB page granularity.
> Else
> 1) How to set up the grant map for requests in domU?
> The minimum segment buffer size in a request is PAGE_SIZE(64KB) while grant is 4KB based.
>
> 2) Codes like below in blkback.c may not work correctly?
> if ((req->u.rw.seg[i].last_sect >= (PAGE_SIZE >> 9)) ||
>
> Because PAGE_SIZE in backend is 4KB, while the written value by domU is 64KB based.

As mention in my cover letter, this patch is not self-sufficient to 
support 64KB guest. It's a follow-up of the 64KB page granularity 
support I sent on the ML (the new version was sent earlier this week [1]).

One of the patch [2] is taking care of breaking down the I/O request in 
multiple 4KB segment that will be used in the ring request. You may want 
to give a look to this patch before looking to this series.

Regards,

[1] https://lwn.net/Articles/656797/
[2] http://www.spinics.net/lists/arm-kernel/msg430468.html

-- 
Julien Grall
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1223780 — Re: [Xen-devel] [PATCH 0/2] block/xen-blkfront: Support non-indirect with 64KB page granularity

On 09/14/2015 01:47 AM, Julien Grall wrote:
> 
> 
> On 13/09/2015 13:44, Bob Liu wrote:
>> I may misunderstood here.
>> But I think same changes are also required even if backend supports indirect grant when frontend is using 64KB page granularity.
>> Else
>> 1) How to set up the grant map for requests in domU?
>> The minimum segment buffer size in a request is PAGE_SIZE(64KB) while grant is 4KB based.
>>
>> 2) Codes like below in blkback.c may not work correctly?
>> if ((req->u.rw.seg[i].last_sect >= (PAGE_SIZE >> 9)) ||
>>
>> Because PAGE_SIZE in backend is 4KB, while the written value by domU is 64KB based.
> 
> As mention in my cover letter, this patch is not self-sufficient to support 64KB guest. It's a follow-up of the 64KB page granularity support I sent on the ML (the new version was sent earlier this week [1]).
> 
> One of the patch [2] is taking care of breaking down the I/O request in multiple 4KB segment that will be used in the ring request. You may want to give a look to this patch before looking to this series.
> 

Oh, sorry! I'll have a look at those patches.

Thanks,
-Bob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web