similar to: block ring interface: nr_segments = 0 results in BLKIF_RSP_ERROR

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

refactoring balback Signed-off-by: Ronghui Duan <ronghui.duan@intel.com<mailto:ronghui.duan@intel.com>> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c index 73f196c..b4767f5 100644 --- a/drivers/block/xen-blkback/blkback.c +++ b/drivers/block/xen-blkback/blkback.c @@ -64,6 +64,11 @@ MODULE_PARM_DESC(reqs, "Number of blkback requests to

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

As usual, written and (build-)tested on 2.6.27.4 and made apply to the 2.6.18 tree without further testing. Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: head-2008-11-04/drivers/xen/blktap/blktap.c =================================================================== --- head-2008-11-04.orig/drivers/xen/blktap/blktap.c 2008-10-01 16:35:04.000000000 +0200 +++

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

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

branch xen-unstable xen branch xen-unstable job test-amd64-i386-rhel6hvm-amd test redhat-install Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg *** Found and reproduced problem

I''ve been having a look through scsifront again, and I saw this bit: ring_req->timeout_per_command = (sc->timeout_per_command / HZ); ring_req->nr_segments = 0; spin_unlock_irq(host->host_lock); scsifront_do_request(info); wait_event_interruptible(info->shadow[ring_req->rqid].wq_reset, info->shadow[ring_req->rqid].wait_reset); in

This patch series introduces the shared ring used by the front-end to pass request descriptors to tapdisk, as well as responses from tapdisk to the front-end. Requests from this ring end up in tapdisk''s standard request queue. When the tapback daemon detects that the front-end tries to connect to the back-end, it spawns a tapdisk and tells it to connect to the shared ring. The shared

add segring support in blkback Signed-off-by: Ronghui Duan <ronghui.duan@intel.com> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c index 45eda98..0bbc226 100644 --- a/drivers/block/xen-blkback/blkback.c +++ b/drivers/block/xen-blkback/blkback.c @@ -60,6 +60,10 @@ static int xen_blkif_reqs = 64; module_param_named(reqs, xen_blkif_reqs, int, 0);

pvSCSI backend driver Signed-off-by: Tomonari Horikoshi <t.horikoshi@jp.fujitsu.com> Signed-off-by: Jun Kamada <kama@jp.fujitsu.com> ----- Jun Kamada _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

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, This is a simple version of something that I am trying to do. If I can sort the problem basically, I figure I should be able to sort it for the program I'm writing (which would take longer to explain). I need to know if there is any way of using different colours for different intervals of a line on a graph. Eg. If I plot the line y=x for x=1:10, and split this line into 106 intervals

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

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

Hello List, I have a small problem with the ring when transferring blocks the id on the response is different from the request. This is the boot up read, count 0. The guest requests block 0, it has to be located at 7c00. I go ahead and create a REQUEST with this data: ring_req = RING_GET_REQUEST(priv,priv->req_prod_pvt); ring_req->id = 9; ring_req->nr_segments=1; ring_req->operation

Hi, This set of patches contains initial kexec/kdump implementation for Xen v3. Currently only dom0 is supported, however, almost all infrustructure required for domU support is ready. Jan Beulich suggested to merge Xen x86 assembler code with baremetal x86 code. This could simplify and reduce a bit size of kernel code. However, this solution requires some changes in baremetal x86 code. First of

Hi, This set of patches contains initial kexec/kdump implementation for Xen v3. Currently only dom0 is supported, however, almost all infrustructure required for domU support is ready. Jan Beulich suggested to merge Xen x86 assembler code with baremetal x86 code. This could simplify and reduce a bit size of kernel code. However, this solution requires some changes in baremetal x86 code. First of

Hi, This set of patches contains initial kexec/kdump implementation for Xen v3. Currently only dom0 is supported, however, almost all infrustructure required for domU support is ready. Jan Beulich suggested to merge Xen x86 assembler code with baremetal x86 code. This could simplify and reduce a bit size of kernel code. However, this solution requires some changes in baremetal x86 code. First of

While trying to port kexec cleanly to klibc, came across this syscall usage for reboot(2). Calling reboot directly simplifies the code. Signed-off-by: maximilian attems <max at stro.at> --- kexec/kexec-syscall.h | 18 ------------------ kexec/kexec.c | 3 ++- 2 files changed, 2 insertions(+), 19 deletions(-) v2: keep LINUX_REBOOT_CMD_KEXEC defines, thus no need of