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

Groups > linux.kernel > #1272479 > unrolled thread

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

Started byJulien Grall <julien.grall@citrix.com>
First post2015-11-18 20:00 +0100
Last post2015-12-08 13:30 +0100
Articles 8 — 1 participant

Back to article view | Back to linux.kernel

Contents

  [PATCH v3 0/2] block/xen-blkfront: Support non-indirect grant with 64KB page granularity Julien Grall <julien.grall@citrix.com> - 2015-11-18 20:00 +0100
    [PATCH v3 1/2] block/xen-blkfront: Introduce blkif_ring_get_request Julien Grall <julien.grall@citrix.com> - 2015-11-18 20:00 +0100
    Re: [Xen-devel] [PATCH v3 0/2] block/xen-blkfront: Support non-indirect  grant with 64KB page granularity Julien Grall <julien.grall@citrix.com> - 2015-11-30 17:20 +0100
    Re: [Xen-devel] [PATCH v3 0/2] block/xen-blkfront: Support non-indirect  grant with 64KB page granularity Julien Grall <julien.grall@citrix.com> - 2015-11-30 19:50 +0100
    Re: [Xen-devel] [PATCH v3 0/2] block/xen-blkfront: Support non-indirect  grant with 64KB page granularity Julien Grall <julien.grall@citrix.com> - 2015-12-01 19:00 +0100
      Re: [Xen-devel] [PATCH v3 0/2] block/xen-blkfront: Support non-indirect  grant with 64KB page granularity Julien Grall <julien.grall@citrix.com> - 2015-12-07 15:30 +0100
        Re: [Xen-devel] [PATCH v3 0/2] block/xen-blkfront: Support non-indirect  grant with 64KB page granularity Julien Grall <julien.grall@citrix.com> - 2015-12-08 14:00 +0100
      Re: [Xen-devel] [PATCH v3 0/2] block/xen-blkfront: Support non-indirect  grant with 64KB page granularity Julien Grall <julien.grall@citrix.com> - 2015-12-08 13:30 +0100

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

FromJulien Grall <julien.grall@citrix.com>
Date2015-11-18 20:00 +0100
Subject[PATCH v3 0/2] block/xen-blkfront: Support non-indirect grant with 64KB page granularity
Message-ID<qwg7v-6Nq-5@gated-at.bofh.it>
Hi all,

This is a follow-up on the previous discussion [1] related to guest using 64KB
page granularity which doesn't boot when the backend isn't using indirect
descriptor.

This has been successfully tested on ARM64 with both 64KB and 4KB page
granularity guests and QEMU as the backend. Indeed QEMU doesn't support
indirect descriptor.

This series is based on xentip/for-linus-4.4 which include the support for
64KB Linux guest.

For all the changes see in each patch.

Sincerely yours,

[1] http://lists.xen.org/archives/html/xen-devel/2015-08/msg01659.html

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>
Cc: Bob Liu <bob.liu@oracle.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 | 258 ++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 231 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]

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

FromJulien Grall <julien.grall@citrix.com>
Date2015-11-18 20:00 +0100
Subject[PATCH v3 1/2] block/xen-blkfront: Introduce blkif_ring_get_request
Message-ID<qwg7w-6Nq-33@gated-at.bofh.it>
In reply to#1272479
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>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>

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

    Changes in v2:
        - Add Royger's acked-by
---
 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 2fee2ee..2248a47 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]

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

FromJulien Grall <julien.grall@citrix.com>
Date2015-11-30 17:20 +0100
SubjectRe: [Xen-devel] [PATCH v3 0/2] block/xen-blkfront: Support non-indirect grant with 64KB page granularity
Message-ID<qAzlg-5Uw-17@gated-at.bofh.it>
In reply to#1272479
Hi,

Ping?

Regards,

On 18/11/15 18:57, Julien Grall wrote:
> Hi all,
> 
> This is a follow-up on the previous discussion [1] related to guest using 64KB
> page granularity which doesn't boot when the backend isn't using indirect
> descriptor.
> 
> This has been successfully tested on ARM64 with both 64KB and 4KB page
> granularity guests and QEMU as the backend. Indeed QEMU doesn't support
> indirect descriptor.
> 
> This series is based on xentip/for-linus-4.4 which include the support for
> 64KB Linux guest.
> 
> For all the changes see in each patch.
> 
> Sincerely yours,
> 
> [1] http://lists.xen.org/archives/html/xen-devel/2015-08/msg01659.html
> 
> 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>
> Cc: Bob Liu <bob.liu@oracle.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 | 258 ++++++++++++++++++++++++++++++++++++++-----
>  1 file changed, 231 insertions(+), 27 deletions(-)
> 


-- 
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]

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

FromJulien Grall <julien.grall@citrix.com>
Date2015-11-30 19:50 +0100
SubjectRe: [Xen-devel] [PATCH v3 0/2] block/xen-blkfront: Support non-indirect grant with 64KB page granularity
Message-ID<qABGq-7gu-21@gated-at.bofh.it>
In reply to#1272479
Hi,

Just noticed that Bob and Konrad have not been correctly CCed.

Regards,

On 18/11/15 18:57, Julien Grall wrote:
> Hi all,
> 
> This is a follow-up on the previous discussion [1] related to guest using 64KB
> page granularity which doesn't boot when the backend isn't using indirect
> descriptor.
> 
> This has been successfully tested on ARM64 with both 64KB and 4KB page
> granularity guests and QEMU as the backend. Indeed QEMU doesn't support
> indirect descriptor.
> 
> This series is based on xentip/for-linus-4.4 which include the support for
> 64KB Linux guest.
> 
> For all the changes see in each patch.
> 
> Sincerely yours,
> 
> [1] http://lists.xen.org/archives/html/xen-devel/2015-08/msg01659.html
> 
> 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>
> Cc: Bob Liu <bob.liu@oracle.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 | 258 ++++++++++++++++++++++++++++++++++++++-----
>  1 file changed, 231 insertions(+), 27 deletions(-)
> 


-- 
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]

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

FromJulien Grall <julien.grall@citrix.com>
Date2015-12-01 19:00 +0100
SubjectRe: [Xen-devel] [PATCH v3 0/2] block/xen-blkfront: Support non-indirect grant with 64KB page granularity
Message-ID<qAXnB-4kq-15@gated-at.bofh.it>
In reply to#1272479
Hi Konrad,

On 01/12/15 15:37, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 18, 2015 at 06:57:23PM +0000, Julien Grall wrote:
>> Hi all,
>>
>> This is a follow-up on the previous discussion [1] related to guest using 64KB
>> page granularity which doesn't boot when the backend isn't using indirect
>> descriptor.
>>
>> This has been successfully tested on ARM64 with both 64KB and 4KB page
>> granularity guests and QEMU as the backend. Indeed QEMU doesn't support
>> indirect descriptor.
>>
>> This series is based on xentip/for-linus-4.4 which include the support for
>> 64KB Linux guest.
> 
> In the meantime the multi-queue patches have been put in the queue
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git #devel/for-jens-4.5
> 
> I will try rebasing the patches on top of that.

It will likely clash with the multiqueue changes. I will rebase this
patch series and resend it.

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]

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

FromJulien Grall <julien.grall@citrix.com>
Date2015-12-07 15:30 +0100
SubjectRe: [Xen-devel] [PATCH v3 0/2] block/xen-blkfront: Support non-indirect grant with 64KB page granularity
Message-ID<qD4XE-5GH-7@gated-at.bofh.it>
In reply to#1281090
Hi Konrad,

On 01/12/15 18:52, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 01, 2015 at 05:55:48PM +0000, Julien Grall wrote:
>> Hi Konrad,
>>
>> On 01/12/15 15:37, Konrad Rzeszutek Wilk wrote:
>>> On Wed, Nov 18, 2015 at 06:57:23PM +0000, Julien Grall wrote:
>>>> Hi all,
>>>>
>>>> This is a follow-up on the previous discussion [1] related to guest using 64KB
>>>> page granularity which doesn't boot when the backend isn't using indirect
>>>> descriptor.
>>>>
>>>> This has been successfully tested on ARM64 with both 64KB and 4KB page
>>>> granularity guests and QEMU as the backend. Indeed QEMU doesn't support
>>>> indirect descriptor.
>>>>
>>>> This series is based on xentip/for-linus-4.4 which include the support for
>>>> 64KB Linux guest.
>>>
>>> In the meantime the multi-queue patches have been put in the queue
>>>
>>> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git #devel/for-jens-4.5
>>>
>>> I will try rebasing the patches on top of that.
>>
>> It will likely clash with the multiqueue changes. I will rebase this
>> patch series and resend it.
> 
> I got patch #1 ported over (see attached). Testing it now.

Thank you, the changes look good to me. What about patch #2?

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]

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

FromJulien Grall <julien.grall@citrix.com>
Date2015-12-08 14:00 +0100
SubjectRe: [Xen-devel] [PATCH v3 0/2] block/xen-blkfront: Support non-indirect grant with 64KB page granularity
Message-ID<qDq26-2uA-19@gated-at.bofh.it>
In reply to#1285381

[Multipart message — attachments visible in raw view] — view raw

Hi Konrad,

On 07/12/15 15:01, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 07, 2015 at 02:21:46PM +0000, Julien Grall wrote:
>> Thank you, the changes look good to me. What about patch #2?
> 
> Oh, I thought you said you would rebase it - so I had been waiting
> for that.
> 
> Should have communicated that much better.
> 
> If it wouldn't be too much trouble - could you rebase #2 please?

I'm also providing a rebase of #1 because your wasn't correct. See
attachments.

git://xenbits.xen.org/people/julieng/linux-arm.git
branch blkfront-64-indirect-v4

Regards,

-- 
Julien Grall

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

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

FromJulien Grall <julien.grall@citrix.com>
Date2015-12-08 13:30 +0100
SubjectRe: [Xen-devel] [PATCH v3 0/2] block/xen-blkfront: Support non-indirect grant with 64KB page granularity
Message-ID<qDpz4-2iu-17@gated-at.bofh.it>
In reply to#1281090
Hi Konrad,

The rebase of my patch is not correct. It now contains an unused variable and
missing one change.

I will post the rebase of the two patches.

On 01/12/15 18:52, Konrad Rzeszutek Wilk wrote:
> +static unsigned long blkif_ring_get_request(struct blkfront_ring_info *rinfo,
> +					    struct request *req,
> +					    struct blkif_request **ring_req)
> +{
> +	unsigned long id;
> +	struct blkfront_info *info = rinfo->dev_info;

This variable is unused within the function.

> +
> +	*ring_req = RING_GET_REQUEST(&rinfo->ring, rinfo->ring.req_prod_pvt);
> +	rinfo->ring.req_prod_pvt++;
> +
> +	id = get_id_from_freelist(rinfo);
> +	rinfo->shadow[id].request = req;
> +
> +	(*ring_req)->u.rw.id = id;
> +
> +	return id;
> +}
> +
>  static int blkif_queue_discard_req(struct request *req, struct blkfront_ring_info *rinfo)
>  {
>  	struct blkfront_info *info = rinfo->dev_info;
> @@ -488,9 +506,7 @@ static int blkif_queue_discard_req(struct request *req, struct blkfront_ring_inf
>  	unsigned long id;
>  
>  	/* Fill out a communications ring structure. */
> -	ring_req = RING_GET_REQUEST(&rinfo->ring, rinfo->ring.req_prod_pvt);
> -	id = get_id_from_freelist(rinfo);
> -	rinfo->shadow[id].request = req;
> +	id = blkif_ring_get_request(rinfo, req, &ring_req);
>  
>  	ring_req->operation = BLKIF_OP_DISCARD;
>  	ring_req->u.discard.nr_sectors = blk_rq_sectors(req);
> @@ -501,8 +517,6 @@ static int blkif_queue_discard_req(struct request *req, struct blkfront_ring_inf
>  	else
>  		ring_req->u.discard.flag = 0;
>  
> -	rinfo->ring.req_prod_pvt++;
> -
>  	/* Keep a private copy so we can reissue requests when recovering. */
>  	rinfo->shadow[id].req = *ring_req;
>  
> @@ -635,9 +649,7 @@ static int blkif_queue_rw_req(struct request *req, struct blkfront_ring_info *ri
>  		}
>  
>  	/* Fill out a communications ring structure. */
> -	ring_req = RING_GET_REQUEST(&rinfo->ring, rinfo->ring.req_prod_pvt);
> -	id = get_id_from_freelist(rinfo);
> -	rinfo->shadow[id].request = req;
> +	id = blkif_ring_get_request(rinfo, req, &ring_req);
>  
>  	BUG_ON(info->max_indirect_segments == 0 &&
>  	       GREFS(req->nr_phys_segments) > BLKIF_MAX_SEGMENTS_PER_REQUEST);

@@ -650,7 +661,6 @@ static int blkif_queue_rw_req(struct request *req, struct blkfront_ring_info *ri
        for_each_sg(rinfo->shadow[id].sg, sg, num_sg, i)
               num_grant += gnttab_count_grant(sg->offset, sg->length);
 
-       ring_req->u.rw.id = id;
        rinfo->shadow[id].num_sg = num_sg;
        if (num_grant > BLKIF_MAX_SEGMENTS_PER_REQUEST) {
                /*

> @@ -716,8 +728,6 @@ static int blkif_queue_rw_req(struct request *req, struct blkfront_ring_info *ri
>  	if (setup.segments)
>  		kunmap_atomic(setup.segments);
>  
> -	rinfo->ring.req_prod_pvt++;
> -
>  	/* Keep a private copy so we can reissue requests when recovering. */
>  	rinfo->shadow[id].req = *ring_req;

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] | [standalone]

Back to top | Article view | linux.kernel

csiph-web