similar to: xen-blkback: move free persistent grants code

This patch contains fixes for persistent grants implementation v2: * handle == 0 is a valid handle, so initialize grants in blkback setting the handle to BLKBACK_INVALID_HANDLE instead of 0. Reported by Konrad Rzeszutek Wilk. * new_map is a boolean, use "true" or "false" instead of 1 and 0. Reported by Konrad Rzeszutek Wilk. * blkfront announces the

Moving grant ref handles from blkbk to pending_req will allow us to get rid of the shared blkbk structure. Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: xen-devel@lists.xen.org --- drivers/block/xen-blkback/blkback.c | 16 ++++------------ 1 files changed, 4 insertions(+), 12 deletions(-) diff --git

Hello Roger Pau Monne, The patch 0a8704a51f38: "xen/blkback: Persistent grant maps for xen blk drivers" from Oct 24, 2012, leads to the following warning: drivers/block/xen-blkfront.c:807 blkif_free() warn: 'persistent_gnt' was already freed. 807 llist_for_each_entry(persistent_gnt, all_gnts, node) { 808

Hello Roger Pau Monne, The patch 0a8704a51f38: "xen/blkback: Persistent grant maps for xen blk drivers" from Oct 24, 2012, leads to the following warning: drivers/block/xen-blkfront.c:807 blkif_free() warn: 'persistent_gnt' was already freed. 807 llist_for_each_entry(persistent_gnt, all_gnts, node) { 808

This patch implements persistent grants for the xen-blk{front,back} mechanism. The effect of this change is to reduce the number of unmap operations performed, since they cause a (costly) TLB shootdown. This allows the I/O performance to scale better when a large number of VMs are performing I/O. Previously, the blkfront driver was supplied a bvec[] from the request queue. This was granted to

This patch is a significant performance improvement for the m2p_override: about 6% using the gntdev device. Each m2p_add/remove_override call issues a MULTI_grant_table_op and a __flush_tlb_single if kmap_op != NULL. Batching all the calls together is a great performance benefit because it means issuing one hypercall total rather than two hypercall per page. If paravirt_lazy_mode is set

(This is a continuation of "[PATCH v9] xen/grant-table: Avoid m2p_override during mapping") The grant mapping API does m2p_override unnecessarily: only gntdev needs it, for blkback and future netback patches it just cause a lock contention, as those pages never go to userspace. Therefore this series does the following: - the bulk of the original function (everything after the mapping

(This is a continuation of "[PATCH v9] xen/grant-table: Avoid m2p_override during mapping") The grant mapping API does m2p_override unnecessarily: only gntdev needs it, for blkback and future netback patches it just cause a lock contention, as those pages never go to userspace. Therefore this series does the following: - the bulk of the original function (everything after the mapping

Hi have 4 dom0 with debian lenny running xen. When I run ps axf|grep xvd I see it''s different on diferent dom0s. dom0-A 15677 ? S< 0:00 \_ [blkback.139.xvd] 15678 ? S< 0:38 \_ [blkback.139.xvd] 17015 ? S< 0:00 \_ [blkback.140.xvd] 17016 ? S< 2:34 \_ [blkback.140.xvd] 21309 ? S< 0:00 \_ [blkback.142.xvd] 21310 ?

Hi Everyone, When you want to use ionice to limit the amount of disk a DomU has, due to have to run ionice on every blkback process? Incidently, what is the format of the blkback process? I see the following in ps aux: blkback.xx.xvda blkback.xx.xvda1 blkback.xx.xvd where xx appears to be the domain ID. I''m curious as to the last few letters mean? Thanks

With the introduction of indirect segments we can receive requests with a number of segments bigger than the maximum number of allowed iovecs in a bios, so make sure that blkback doesn't try to allocate a bios with more iovecs than BIO_MAX_PAGES Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> ---

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 -

...because vbd_size() dereferences bd_disk if bd_part is NULL. Signed-off-by: Laszlo Ersek<lersek@redhat.com> --- drivers/xen/blkback/vbd.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff -r 415a9b435fef drivers/xen/blkback/vbd.c --- a/drivers/xen/blkback/vbd.c Mon May 23 18:36:33 2011 +0100 +++ b/drivers/xen/blkback/vbd.c Wed May 25 12:15:26 2011 +0200 @@ -73,7 +73,6 @@

Hi, One of our colleagues spotted a problem in xentop. Sometimes the VBD_WSECT value suddenly becomes unreasonably high, and it turned out xentop reads /sys/bus/xen-backend/devices/vbd-(domid)-(devID)/statistics/wr_sect into an unsigned long long. That value is exposed by blkback, and among other stat counters, it''s a signed integer: drivers/block/xen-blkback/common.h struct

Hi all, I want to use ionice command change the priority of threads of blkback(in domain0) for each corresponding blkfront . However, I do not know how to recognize which is the thread for the corresponding blkfront using ps aux. Anybody can give me some advice? Thanks in advance! -- View this message in context:

When backend disconnect, sync IO requests to the disk. Signed-off-by: Joe Jin <joe.jin@oracle.com> Cc: Jens Axboe <jaxboe@fusionio.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Ian Campbell <Ian.Campbell@eu.citrix.com> --- drivers/block/xen-blkback/xenbus.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/block/xen-blkback/xenbus.c

From: Matt Wilson <msw@amazon.com> Commit f62805f1 introduced a bug where lazy MMU mode isn''t exited if a m2p_add/remove_override call fails. Cc: 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> Cc: Anthony

Hi, Here is the refreshed version of the multi-page ring patch for blkfront and blkback. I currently don''t have time to refresh the blktap part of the patch. The patch should apply cleanly to the following changeset in the linux 2.6.18 tree: changeset: 752:0b859c9516ba tag: qparent parent: 751:6591b4869889 parent: 748:5012c470f875 user: Keir Fraser

Hi Everyone, I''m seeing this message pop up on my console every now and again (or something similar): blkback: ring-ref 8, event-channel 6, protocol 2 (x86_32-abi) Is this a cause for concern? I''m using Xen 4.1.0 from Gitco and using the CentOS Dom0 kernel (2.6.18-238.12.1.el5xen) Any help is appreciated Thanks _______________________________________________ Xen-users

>>> On 03.04.13 at 15:25, William Dauchy <wdauchy@gmail.com> wrote: > On Wed, Apr 3, 2013 at 3:01 PM, Jan Beulich <JBeulich@suse.com> wrote: >> Iirc we requested the earlier commit to be removed from stable >> trees, and I think Greg also did so. > > I''m sorry but I''m unable to find a revert of 01c681d in stable tree. ChangeLog-3.8.3