search for: dispatch_rw_block_io

...age_range(info->vma, MMAP_VADDR(info->user_vstart, u_idx, 0), req->nr_pages << PAGE_SHIFT, NULL); + } + + if (locked) + up_write(&mm->mmap_sem); } /****************************************************************** @@ -1356,6 +1373,7 @@ static void dispatch_rw_block_io(blkif_t int pending_idx = RTN_PEND_IDX(pending_req,pending_req->mem_idx); int usr_idx; uint16_t mmap_idx = pending_req->mem_idx; + struct mm_struct *mm; if (blkif->dev_num < 0 || blkif->dev_num > MAX_TAP_DEV) goto fail_response; @@ -1416,6 +1434,9 @@ static void dispa...

...__LINE__, ##args) + /* * These are rather arbitrary. They are fairly large because adjacent requests * pulled from a communication ring are quite likely to end up being part of @@ -110,7 +115,8 @@ static inline unsigned long vaddr(pendin static int do_block_io_op(blkif_t *blkif); static int dispatch_rw_block_io(blkif_t *blkif, blkif_request_t *req, - pending_req_t *pending_req); + pending_req_t *pending_req, + int *done_nr_sects); static void make_response(blkif_t *blkif, u64 id, unsigned short op, int st); @@ -206,10 +212,20 @@ static void print_stats(blkif_t *blkif) blkif-&g...

...__LINE__, ##args) + /* * These are rather arbitrary. They are fairly large because adjacent requests * pulled from a communication ring are quite likely to end up being part of @@ -110,7 +115,8 @@ static inline unsigned long vaddr(pendin static int do_block_io_op(blkif_t *blkif); static int dispatch_rw_block_io(blkif_t *blkif, blkif_request_t *req, - pending_req_t *pending_req); + pending_req_t *pending_req, + int *done_nr_sects); static void make_response(blkif_t *blkif, u64 id, unsigned short op, int st); @@ -206,10 +212,20 @@ static void print_stats(blkif_t *blkif) blkif-&g...

...ct seg_buf *seg; + struct bio **biolist; + struct page **pages; }; #define BLKBACK_INVALID_HANDLE (~0) @@ -123,28 +133,9 @@ static inline unsigned long vaddr(struct pending_req *req, int seg) static int do_block_io_op(struct xen_blkif *blkif); static int dispatch_rw_block_io(struct xen_blkif *blkif, - struct blkif_request *req, struct pending_req *pending_req); static void make_response(struct xen_blkif *blkif, u64 id, - unsigned short op, int st); - -/* - * Retrieve from the ''pending_reqs'' a free...

...k.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c index d622d86..876116b 100644 --- a/drivers/block/xen-blkback/blkback.c +++ b/drivers/block/xen-blkback/blkback.c @@ -1236,7 +1236,8 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif, seg[i].nsec << 9, seg[i].offset) == 0)) { - bio = bio_alloc(GFP_KERNEL, nseg-i); + int nr_iovecs = (nseg-i) > BIO_MAX_PAGES ? BIO_MAX_PAGES : (nseg-i); + bio = bio_alloc(GFP_KERNEL, nr_iovecs); if (unlikely(bio == NULL)) goto fa...

Patrick, there following patches fix xenpaging for me. Granttable handling is incomplete. If a page is gone, a GNTST_eagain should be returned to the caller to inidcate the hypercall has to be retried after a while, until the page is available again. Please review. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com

I am proposing these two patches for 3.2. They allow the backend to process the REQ_FUA request as well. Previous to these patches it only did REQ_FLUSH. There is also a bug-fix for the logic of how barrier/flushes were handled. The patches are based on a branch which also has ''feature-discard'' patches, so they won''t apply nativly on top of 3.1-rc5. Please review and

Just moving a chunk of files from one filesysstem on xvba to another on xvdb, and was monitoring with xentop as it was taking longer than expected. The VBD_RD and VBD_WR counters were both clocking-up as expected, as was the VBD_RSECT counter, but the VBD_WSECT counter was stuck on zero, I toggled on the individual VBD device counters and these showed the same (with the RD and WR counters

Just moving a chunk of files from one filesysstem on xvba to another on xvdb, and was monitoring with xentop as it was taking longer than expected. The VBD_RD and VBD_WR counters were both clocking-up as expected, as was the VBD_RSECT counter, but the VBD_WSECT counter was stuck on zero, I toggled on the individual VBD device counters and these showed the same (with the RD and WR counters

An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos/attachments/20100405/b0bb4b91/attachment-0003.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: GilbertoNunesFerreira_html_185aa38c.jpg Type: image/jpeg Size: 16538 bytes Desc: not available URL:

...ee9 100644 --- a/drivers/block/xen-blkback/blkback.c +++ b/drivers/block/xen-blkback/blkback.c @@ -78,6 +78,7 @@ struct pending_req { unsigned short operation; int status; struct list_head free_list; + u8 is_pers; }; #define BLKBACK_INVALID_HANDLE (~0) @@ -128,6 +129,24 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif, static void make_response(struct xen_blkif *blkif, u64 id, unsigned short op, int st); +static void add_pers_gnt(struct pers_gnt *pers_gnt, struct xen_blkif *blkif) +{ + BUG_ON(blkif->pers_gnt_c >= BLKIF_MAX_PERS_REQUESTS_PER_DEV * + BLKIF_MAX_SEGMENTS...

...make_request_checks+0x1eb/0x370 [242640.332269] [<ffffffff812f0194>] generic_make_request.part.50+0x74/0xb0 [242640.332274] [<ffffffff812f05a8>] generic_make_request+0x68/0x70 [242640.332278] [<ffffffff812f0635>] submit_bio+0x85/0x110 [242640.332284] [<ffffffffa01b8f0f>] dispatch_rw_block_io+0x44f/0x700 [xen_blkback] [242640.332292] [<ffffffff8100330e>] ? xen_end_context_switch+0x1e/0x30 [242640.332298] [<ffffffffa01b93df>] __do_block_io_op+0x21f/0x360 [xen_blkback] [242640.332304] [<ffffffffa01b9608>] xen_blkif_schedule+0xb8/0x320 [xen_blkback] [242640.332309] [&...

Hi,all In the vbd blkback driver(linux/drivers/xen/blkback/blkback.c), when function dispatch_rw_block_io() try to do the real I/O job, it will do a sanity check on I/O request sent from DomU in the following code fragment: ... 430 for (i = 0; i < nseg; i++) { 431 uint32_t flags; 432 433 seg[i].nsec = req->seg[i].last_sect - 434...

...5 09:03:07 zebra kernel: [<ffffffff8023824d>] kref_get+0x38/0x3d Apr 5 09:03:07 zebra kernel: [<ffffffff8025a440>] kobject_get+0x12/0x17 Apr 5 09:03:07 zebra kernel: [<ffffffff8024b57f>] blk_get_queue+0x1f/0x26 Apr 5 09:03:07 zebra kernel: [<ffffffff887198f7>] :blkbk:dispatch_rw_block_io+0x4db/0x5a2 Apr 5 09:03:07 zebra kernel: [<ffffffff80340368>] __next_cpu+0x19/0x28 Apr 5 09:03:07 zebra kernel: [<ffffffff8026082b>] error_exit+0x0/0x6e Apr 5 09:03:07 zebra kernel: [<ffffffff8028792a>] find_busiest_group+0x1db/0x44d Apr 5 09:03:07 zebra kernel: [<fffff...

I am currently developing a blkfront.c for a custom OS over Xen 3.0.2-2. Typical I/O is working, however, I ran into an error while testing a corner case. On standard I/O, where { 1 <= nr_segments < BLKIF_MAX_SEGMENTS_PER_REQUEST } blkif_int()''s bret->status returns BLKIF_RSP_OKAY. Yet when { nr_segments == 0 } blkif_int''s bret->status is non-zero. (Yes

Hi, i''m prepering to upgrade my servers from xen 3.0.3 32-bit to 3.2.1 64-bit. The old system: Debian 4.0 i386 with included hypervisor 3.0.3 (pae) and dom0 kernel. The new systen: Debian lenny amd64 with the included hypervisor 3.2.1 and dom0 kernel from Debian 4.0 amd64. My domUs have a self compiled kernel out of the dom0 kernel of the old system (mainly the dom0 kernel but

In dispatch_rw_block_io after a call to HYPERVISOR_grant_table_op, there is the following code which calls fast_flush_area and breaks out of the loop early if one of the handles returned from HYPERVISOR_grant_table_op is negative: for (i = 0; i < nseg; i++) { if (unlikely(map[i].handle < 0)) { DPRINTK("i...

...10 +635,12 @@ do_block_io_op(struct xen_blkif *blkif) return more_to_do; } + /* * Transmutation of the ''struct blkif_request'' to a proper ''struct bio'' * and call the ''submit_bio'' to pass it to the underlying storage. */ + static int dispatch_rw_block_io(struct xen_blkif *blkif, struct pending_req *pending_req) { @@ -774,54 +824,89 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif, return -EIO; } -struct blkif_segment_back_ring * - get_seg_back_ring(struct xen_blkif *blkif) +void push_back_ring_rsp(struct xen_blkif *blkif, int n...

Dear list, This is the V4 of the trim support for xen-blkfront/blkback, Now we move BLKIF_OP_TRIM to BLKIF_OP_DISCARD, and dropped all "trim" stuffs in the patches, and use "discard" instead. Also we updated the helpers of blkif_x86_{32|64}_request or we will meet problems using a non-native protocol. And this patch has been tested with both SSD and raw file, with SSD we will

This is a cherry pick of two patches that add support for guest paged out frames in the XCP 2.6.32 dom0 patch queue. First patch propagates the ENOENT returned by the hypervisor in the case of a paged out page, all the way up the call chain to the MMAPBATCH_V2 ioctl. The ioctl is mainly used to harvest those return values and retry. The second patch adds retry loops to all backend grant