search for: sector_numb

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

...bute__((__packed__)); +struct blkif_x86_32_request_rw_v2 { + uint8_t nr_segments; /* number of segments */ + blkif_vdev_t handle; /* only for read/write requests */ + uint64_t id; /* private guest value, echoed in resp */ + blkif_sector_t sector_number;/* start sector idx on disk (r/w only) */ + uint64_t seg_id;/* segment offset in the segment ring */ +} __attribute__((__packed__)); + +struct blkif_x86_32_request_v2 { + uint8_t operation; /* BLKIF_OP_??? */ + union { + struct blkif_x86_32_request_rw_v...

Hey guys, Pasi mentioned on Li''s (and Owen''s) patches which provide TRIM/UNMAP support to the Linux backend/frontend that: " Isn''t the generic name for this functionality "discard" in Linux? and "trim" being the ATA specific discard-implementation, and "scsi unmap" the SAS/SCSI specific discard-implementation? Just

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

Am I right in saying that first_sect & last_sect in blkif_request_segment are the relative sector numbers in the transfer? So if I wanted to transfer 9 sectors starting at 100, the resultant contents of the request would look like: req->sector_number = 100 req->seg[0].first_sect = 0 req->seg[0].last_sect = 3 req->seg[1].first_sect = 4 req->seg[1].last_sect = 7 req->seg[2].first_sect = 8 req->seg[2].last_sect = 8 ? Thanks James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensou...

...his 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 = BLKIF_OP_READ; ring_req->sector_number = (int)op->lba; //sector to be read ring_req->seg[0].gref = (bi->buffer_gref); //this should be get_free_gref(); ring_req->seg[0].first_sect = 0;//op->lba; ring_req->seg[0].last_sect = 7;//op->lba + op->count; RING_PUSH_REQUESTS_AND_CHECK_NOTIFY((priv),notify); //return...

...e (but built successfully in the past) The build fails on 3.14 kernel with the following error: /var/lib/dkms/blktap/2.0.93/build/ring.c: In function ?blktap_ring_make_tr_request?: /var/lib/dkms/blktap/2.0.93/build/ring.c:314:32: error: ?struct bio? has no member named ?bi_sector? breq->u.tr.sector_number = bio->bi_sector; ^ Struct bio was changed by commit https://github.com/torvalds/linux/commit/4f024f3797c43cb4b73cd2c50cec728842d0e49e Changing bio->bi_sector; to bio->bi_iter.bi_sector; allows the module to compile. -- System Information: Debian Release...

..._t(on 2.0.7) for me. From what I make out from the bsd and linux drivers, these entries specify a machine frame and the section of the machine frame to write from/copy to. Where I''m confused is the definition of the size of these sections. Are they each 512 bytes in size? Then there is the sector_number field. Are all requests written within this sector, with the second entry in frames_and_sects being written directly after the first entry which is written at the very start of the segment, etc? Regards Ivan Kelly _______________________________________________ Xen-devel mailing list Xen-devel@l...

...f, xen_blkif_get(blkif); secure = (blkif->vbd.discard_secure && - (req->u.discard.flag & BLKIF_DISCARD_SECURE)) ? + (req->flag & BLKIF_DISCARD_SECURE)) ? BLKDEV_DISCARD_SECURE : 0; - err = blkdev_issue_discard(bdev, req->u.discard.sector_number, - req->u.discard.nr_sectors, + err = blkdev_issue_discard(bdev, req->sector_number, + req->nr_sectors, GFP_KERNEL, secure); if (err == -EOPNOTSUPP) { @@ -417,7 +447,7 @@ static int dispatch_discard_io(struct xen_...

...extern unsigned long do_mmap_pgoff(struct file *file, unsigned long addr, ^ /var/lib/dkms/blktap/2.0.91/build/ring.c: In function ?blktap_ring_make_tr_request?: /var/lib/dkms/blktap/2.0.91/build/ring.c:306:32: error: ?struct bio? has no member named ?bi_sector? breq->u.tr.sector_number = bio->bi_sector; ^ /var/lib/dkms/blktap/2.0.91/build/ring.c: In function ?blktap_ring_mmap_request?: /var/lib/dkms/blktap/2.0.91/build/ring.c:438:19: error: ?VM_RESERVED? undeclared (first use in this function) vma->vm_flags |= VM_RESERVED;...

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

I accidentally realized today that any domU''s using the paravirt disk driver potentially suffer from poor performance when they get handed in a physical volume and partitioning is done inside the guest. The physical volume passed in has to be one that has the compat 512 logical sector size but hints its real sector size (eg. 4096) as physical sector size. In dom0 handling is correct and

This patch series copies the core of the tapdisk process from blktap2, with updates coming from blktap2.5. Signed-off-by: Thanos Makatos <thanos.makatos@citrix.com>

When I submitted the qcow2 patch for blktap, suggestions came up that the qemu block drivers should be used also for blktap to eliminate the current code duplication in ioemu and blktap. The attached patch adds support for a tap:ioemu pseudo driver. Devices using this driver won''t use tapdisk (containing the code duplication) any more, but will connect to the qemu-dm of the domain. In

This patch series implements the Linux Xen guest in terms of the paravirt-ops interface. The features in implemented this patch series are: * domU only * UP only (most code is SMP-safe, but there's no way to create a new vcpu) * writable pagetables, with late pinning/early unpinning (no shadow pagetable support) * supports both PAE and non-PAE modes * xen console * virtual block

This patch series implements the Linux Xen guest in terms of the paravirt-ops interface. The features in implemented this patch series are: * domU only * UP only (most code is SMP-safe, but there's no way to create a new vcpu) * writable pagetables, with late pinning/early unpinning (no shadow pagetable support) * supports both PAE and non-PAE modes * xen console * virtual block

This patch series implements the Linux Xen guest in terms of the paravirt-ops interface. The features in implemented this patch series are: * domU only * UP only (most code is SMP-safe, but there's no way to create a new vcpu) * writable pagetables, with late pinning/early unpinning (no shadow pagetable support) * supports both PAE and non-PAE modes * xen console * virtual block

Hi Andi, This patch series implements the Linux Xen guest as a paravirt_ops backend. The features in implemented this patch series are: * domU only * UP only (most code is SMP-safe, but there's no way to create a new vcpu) * writable pagetables, with late pinning/early unpinning (no shadow pagetable support) * supports both PAE and non-PAE modes * xen hvc console (console=hvc0) *

Hi Andi, This patch series implements the Linux Xen guest as a paravirt_ops backend. The features in implemented this patch series are: * domU only * UP only (most code is SMP-safe, but there's no way to create a new vcpu) * writable pagetables, with late pinning/early unpinning (no shadow pagetable support) * supports both PAE and non-PAE modes * xen hvc console (console=hvc0) *

Hi Andi, This patch series implements the Linux Xen guest as a paravirt_ops backend. The features in implemented this patch series are: * domU only * UP only (most code is SMP-safe, but there's no way to create a new vcpu) * writable pagetables, with late pinning/early unpinning (no shadow pagetable support) * supports both PAE and non-PAE modes * xen hvc console (console=hvc0) *