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

Groups > linux.kernel > #1281090 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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

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

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

#1285381

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

[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

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