[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 2/2] qdisk - hw/block/xen_disk: grant copy implementation
On Mon, 2016-06-13 at 11:15 +0100, David Vrabel wrote: > On 13/06/16 10:43, Paulina Szubarczyk wrote: > > Copy data operated on during request from/to local buffers to/from > > the grant references. > > > > Before grant copy operation local buffers must be allocated what is > > done by calling ioreq_init_copy_buffers. For the 'read' operation, > > first, the qemu device invokes the read operation on local buffers > > and on the completion grant copy is called and buffers are freed. > > For the 'write' operation grant copy is performed before invoking > > write by qemu device. > > > > A new value 'feature_grant_copy' is added to recognize when the > > grant copy operation is supported by a guest. > > The body of the function 'ioreq_runio_qemu_aio' is moved to > > 'ioreq_runio_qemu_aio_blk' and in the 'ioreq_runio_qemu_aio' depending > > on the support for grant copy according checks, initialization, grant > > operation are made, then the 'ioreq_runio_qemu_aio_blk' function is > > called. > > I think you should add an option to force the use of grant mapping even > if copy support is detected. If future changes to the grant map > infrastructure makes it faster or if grant map scales better in some > systems, then it would be useful to be able to use it. The 'feature_grant_copy' is a boolean and could be set to false in such case. There could be added a node in XenStore, for example 'feature-force-grant-map', which when set by frontend will be read during a connection and changed the value to false forcing the grant map operation. > > + rc = xc_gnttab_grant_copy(gnt, count, segs); > > + > > + if (rc) { > > + xen_be_printf(&ioreq->blkdev->xendev, 0, > > + "failed to copy data %d \n", rc); > > I don't think you want to log anything here. A guest could spam the > logs by repeatedly submitting requests with (for example) bad grant > references. I might removed that log or change the level, though when the mapping fails for grant map it is logged in a similar manner. > > + ioreq->aio_errors++; > > + r = -1; goto out; > > return -1; > > > @@ -1020,10 +1163,18 @@ static int blk_connect(struct XenDevice *xendev) > > > > xen_be_bind_evtchn(&blkdev->xendev); > > > > + xc_gnttab_grant_copy_segment_t seg; > > + blkdev->feature_grant_copy = > > + (xc_gnttab_grant_copy(blkdev->xendev.gnttabdev, 0, &seg) > > == 0); > > You can pass NULL for the segments here. Yes, thank you. > > > + > > + xen_be_printf(&blkdev->xendev, 3, "GRANT COPY %s\n", > > + blkdev->feature_grant_copy ? "ENABLED" : "DISABLED"); > > + > > xen_be_printf(&blkdev->xendev, 1, "ok: proto %s, ring-ref %d, " > > "remote port %d, local port %d\n", > > blkdev->xendev.protocol, blkdev->ring_ref, > > blkdev->xendev.remote_port, blkdev->xendev.local_port); > > + > > return 0; > > } > > David > Paulina _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |