2011-04-15 06:25:47 +08:00
|
|
|
/* Xenbus code for blkif backend
|
|
|
|
Copyright (C) 2005 Rusty Russell <rusty@rustcorp.com.au>
|
|
|
|
Copyright (C) 2005 XenSource Ltd
|
|
|
|
|
|
|
|
This program is free software; you can redistribute it and/or modify
|
|
|
|
it under the terms of the GNU General Public License as published by
|
|
|
|
the Free Software Foundation; either version 2 of the License, or
|
|
|
|
(at your option) any later version.
|
|
|
|
|
|
|
|
This program is distributed in the hope that it will be useful,
|
|
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
GNU General Public License for more details.
|
|
|
|
|
|
|
|
*/
|
|
|
|
|
2015-04-01 23:04:22 +08:00
|
|
|
#define pr_fmt(fmt) "xen-blkback: " fmt
|
|
|
|
|
2011-04-15 06:25:47 +08:00
|
|
|
#include <stdarg.h>
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/kthread.h>
|
2011-04-20 22:57:29 +08:00
|
|
|
#include <xen/events.h>
|
|
|
|
#include <xen/grant_table.h>
|
2011-04-15 06:25:47 +08:00
|
|
|
#include "common.h"
|
|
|
|
|
2015-03-27 21:15:54 +08:00
|
|
|
/* Enlarge the array size in order to fully show blkback name. */
|
|
|
|
#define BLKBACK_NAME_LEN (20)
|
2015-06-03 13:40:03 +08:00
|
|
|
#define RINGREF_NAME_LEN (20)
|
2015-03-27 21:15:54 +08:00
|
|
|
|
2011-04-15 05:33:30 +08:00
|
|
|
struct backend_info {
|
2011-05-12 03:57:09 +08:00
|
|
|
struct xenbus_device *dev;
|
2011-05-13 06:02:28 +08:00
|
|
|
struct xen_blkif *blkif;
|
2011-05-12 03:57:09 +08:00
|
|
|
struct xenbus_watch backend_watch;
|
|
|
|
unsigned major;
|
|
|
|
unsigned minor;
|
|
|
|
char *mode;
|
2011-04-15 06:25:47 +08:00
|
|
|
};
|
|
|
|
|
2011-04-20 23:50:43 +08:00
|
|
|
static struct kmem_cache *xen_blkif_cachep;
|
2011-04-15 06:25:47 +08:00
|
|
|
static void connect(struct backend_info *);
|
|
|
|
static int connect_ring(struct backend_info *);
|
|
|
|
static void backend_changed(struct xenbus_watch *, const char **,
|
|
|
|
unsigned int);
|
2014-05-21 04:28:50 +08:00
|
|
|
static void xen_blkif_free(struct xen_blkif *blkif);
|
|
|
|
static void xen_vbd_free(struct xen_vbd *vbd);
|
2011-04-15 06:25:47 +08:00
|
|
|
|
2011-04-20 23:50:43 +08:00
|
|
|
struct xenbus_device *xen_blkbk_xenbus(struct backend_info *be)
|
2010-03-19 06:35:05 +08:00
|
|
|
{
|
|
|
|
return be->dev;
|
|
|
|
}
|
|
|
|
|
2014-05-21 04:28:50 +08:00
|
|
|
/*
|
|
|
|
* The last request could free the device from softirq context and
|
|
|
|
* xen_blkif_free() can sleep.
|
|
|
|
*/
|
|
|
|
static void xen_blkif_deferred_free(struct work_struct *work)
|
|
|
|
{
|
|
|
|
struct xen_blkif *blkif;
|
|
|
|
|
|
|
|
blkif = container_of(work, struct xen_blkif, free_work);
|
|
|
|
xen_blkif_free(blkif);
|
|
|
|
}
|
|
|
|
|
2011-05-13 04:47:48 +08:00
|
|
|
static int blkback_name(struct xen_blkif *blkif, char *buf)
|
2011-04-15 06:25:47 +08:00
|
|
|
{
|
|
|
|
char *devpath, *devname;
|
|
|
|
struct xenbus_device *dev = blkif->be->dev;
|
|
|
|
|
|
|
|
devpath = xenbus_read(XBT_NIL, dev->nodename, "dev", NULL);
|
|
|
|
if (IS_ERR(devpath))
|
|
|
|
return PTR_ERR(devpath);
|
|
|
|
|
2011-04-15 05:33:30 +08:00
|
|
|
devname = strstr(devpath, "/dev/");
|
|
|
|
if (devname != NULL)
|
2011-04-15 06:25:47 +08:00
|
|
|
devname += strlen("/dev/");
|
|
|
|
else
|
|
|
|
devname = devpath;
|
|
|
|
|
2015-03-27 21:15:54 +08:00
|
|
|
snprintf(buf, BLKBACK_NAME_LEN, "blkback.%d.%s", blkif->domid, devname);
|
2011-04-15 06:25:47 +08:00
|
|
|
kfree(devpath);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-05-13 04:47:48 +08:00
|
|
|
static void xen_update_blkif_status(struct xen_blkif *blkif)
|
2011-04-15 06:25:47 +08:00
|
|
|
{
|
|
|
|
int err;
|
2015-03-27 21:15:54 +08:00
|
|
|
char name[BLKBACK_NAME_LEN];
|
2011-04-15 06:25:47 +08:00
|
|
|
|
|
|
|
/* Not ready to connect? */
|
|
|
|
if (!blkif->irq || !blkif->vbd.bdev)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* Already connected? */
|
|
|
|
if (blkif->be->dev->state == XenbusStateConnected)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* Attempt to connect: exit if we fail to. */
|
|
|
|
connect(blkif->be);
|
|
|
|
if (blkif->be->dev->state != XenbusStateConnected)
|
|
|
|
return;
|
|
|
|
|
|
|
|
err = blkback_name(blkif, name);
|
|
|
|
if (err) {
|
|
|
|
xenbus_dev_error(blkif->be->dev, err, "get blkback dev name");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2010-07-22 03:41:45 +08:00
|
|
|
err = filemap_write_and_wait(blkif->vbd.bdev->bd_inode->i_mapping);
|
|
|
|
if (err) {
|
|
|
|
xenbus_dev_error(blkif->be->dev, err, "block flush");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
invalidate_inode_pages2(blkif->vbd.bdev->bd_inode->i_mapping);
|
|
|
|
|
2013-07-04 06:04:58 +08:00
|
|
|
blkif->xenblkd = kthread_run(xen_blkif_schedule, blkif, "%s", name);
|
2011-04-15 06:25:47 +08:00
|
|
|
if (IS_ERR(blkif->xenblkd)) {
|
|
|
|
err = PTR_ERR(blkif->xenblkd);
|
|
|
|
blkif->xenblkd = NULL;
|
|
|
|
xenbus_dev_error(blkif->be->dev, err, "start xenblkd");
|
2013-04-18 02:18:57 +08:00
|
|
|
return;
|
2011-04-15 06:25:47 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-05-13 04:47:48 +08:00
|
|
|
static struct xen_blkif *xen_blkif_alloc(domid_t domid)
|
2011-04-20 22:57:29 +08:00
|
|
|
{
|
2011-05-13 04:47:48 +08:00
|
|
|
struct xen_blkif *blkif;
|
2011-04-20 22:57:29 +08:00
|
|
|
|
2013-04-18 22:06:54 +08:00
|
|
|
BUILD_BUG_ON(MAX_INDIRECT_PAGES > BLKIF_MAX_INDIRECT_PAGES_PER_REQUEST);
|
2011-04-20 22:57:29 +08:00
|
|
|
|
2012-08-27 12:28:57 +08:00
|
|
|
blkif = kmem_cache_zalloc(xen_blkif_cachep, GFP_KERNEL);
|
2011-04-20 22:57:29 +08:00
|
|
|
if (!blkif)
|
|
|
|
return ERR_PTR(-ENOMEM);
|
|
|
|
|
|
|
|
blkif->domid = domid;
|
|
|
|
spin_lock_init(&blkif->blk_ring_lock);
|
|
|
|
atomic_set(&blkif->refcnt, 1);
|
|
|
|
init_waitqueue_head(&blkif->wq);
|
2011-10-10 12:42:22 +08:00
|
|
|
init_completion(&blkif->drain_complete);
|
|
|
|
atomic_set(&blkif->drain, 0);
|
2011-04-20 22:57:29 +08:00
|
|
|
blkif->st_print = jiffies;
|
xen/blkback: Persistent grant maps for xen blk drivers
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 dom0; dom0 performed the I/O and wrote
directly into the grant-mapped memory and unmapped it; blkfront then
removed foreign access for that grant. The cost of unmapping scales
badly with the number of CPUs in Dom0. An experiment showed that when
Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
(at which point 650,000 IOPS are being performed in total). If more
than 5 guests are used, the performance declines. By 10 guests, only
400,000 IOPS are being performed.
This patch improves performance by only unmapping when the connection
between blkfront and back is broken.
On startup blkfront notifies blkback that it is using persistent
grants, and blkback will do the same. If blkback is not capable of
persistent mapping, blkfront will still use the same grants, since it
is compatible with the previous protocol, and simplifies the code
complexity in blkfront.
To perform a read, in persistent mode, blkfront uses a separate pool
of pages that it maps to dom0. When a request comes in, blkfront
transmutes the request so that blkback will write into one of these
free pages. Blkback keeps note of which grefs it has already
mapped. When a new ring request comes to blkback, it looks to see if
it has already mapped that page. If so, it will not map it again. If
the page hasn't been previously mapped, it is mapped now, and a record
is kept of this mapping. Blkback proceeds as usual. When blkfront is
notified that blkback has completed a request, it memcpy's from the
shared memory, into the bvec supplied. A record that the {gref, page}
tuple is mapped, and not inflight is kept.
Writes are similar, except that the memcpy is peformed from the
supplied bvecs, into the shared pages, before the request is put onto
the ring.
Blkback stores a mapping of grefs=>{page mapped to by gref} in
a red-black tree. As the grefs are not known apriori, and provide no
guarantees on their ordering, we have to perform a search
through this tree to find the page, for every gref we receive. This
operation takes O(log n) time in the worst case. In blkfront grants
are stored using a single linked list.
The maximum number of grants that blkback will persistenly map is
currently set to RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, to
prevent a malicios guest from attempting a DoS, by supplying fresh
grefs, causing the Dom0 kernel to map excessively. If a guest
is using persistent grants and exceeds the maximum number of grants to
map persistenly the newly passed grefs will be mapped and unmaped.
Using this approach, we can have requests that mix persistent and
non-persistent grants, and we need to handle them correctly.
This allows us to set the maximum number of persistent grants to a
lower value than RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, although
setting it will lead to unpredictable performance.
In writing this patch, the question arrises as to if the additional
cost of performing memcpys in the guest (to/from the pool of granted
pages) outweigh the gains of not performing TLB shootdowns. The answer
to that question is `no'. There appears to be very little, if any
additional cost to the guest of using persistent grants. There is
perhaps a small saving, from the reduced number of hypercalls
performed in granting, and ending foreign access.
Signed-off-by: Oliver Chick <oliver.chick@citrix.com>
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
[v1: Fixed up the misuse of bool as int]
2012-10-25 00:58:45 +08:00
|
|
|
blkif->persistent_gnts.rb_node = NULL;
|
2013-04-18 02:18:56 +08:00
|
|
|
spin_lock_init(&blkif->free_pages_lock);
|
|
|
|
INIT_LIST_HEAD(&blkif->free_pages);
|
2014-02-04 18:26:13 +08:00
|
|
|
INIT_LIST_HEAD(&blkif->persistent_purge_list);
|
2013-04-18 02:18:56 +08:00
|
|
|
blkif->free_pages_num = 0;
|
2013-04-18 02:18:57 +08:00
|
|
|
atomic_set(&blkif->persistent_gnt_in_use, 0);
|
2014-02-04 18:26:14 +08:00
|
|
|
atomic_set(&blkif->inflight, 0);
|
2014-02-12 11:34:03 +08:00
|
|
|
INIT_WORK(&blkif->persistent_purge_work, xen_blkbk_unmap_purged_grants);
|
2011-04-20 22:57:29 +08:00
|
|
|
|
2013-04-18 02:18:59 +08:00
|
|
|
INIT_LIST_HEAD(&blkif->pending_free);
|
2014-05-21 04:28:50 +08:00
|
|
|
INIT_WORK(&blkif->free_work, xen_blkif_deferred_free);
|
2013-04-18 02:18:59 +08:00
|
|
|
spin_lock_init(&blkif->pending_free_lock);
|
|
|
|
init_waitqueue_head(&blkif->pending_free_wq);
|
xen/blkback: Check for insane amounts of request on the ring (v6).
Check that the ring does not have an insane amount of requests
(more than there could fit on the ring).
If we detect this case we will stop processing the requests
and wait until the XenBus disconnects the ring.
The existing check RING_REQUEST_CONS_OVERFLOW which checks for how
many responses we have created in the past (rsp_prod_pvt) vs
requests consumed (req_cons) and whether said difference is greater or
equal to the size of the ring, does not catch this case.
Wha the condition does check if there is a need to process more
as we still have a backlog of responses to finish. Note that both
of those values (rsp_prod_pvt and req_cons) are not exposed on the
shared ring.
To understand this problem a mini crash course in ring protocol
response/request updates is in place.
There are four entries: req_prod and rsp_prod; req_event and rsp_event
to track the ring entries. We are only concerned about the first two -
which set the tone of this bug.
The req_prod is a value incremented by frontend for each request put
on the ring. Conversely the rsp_prod is a value incremented by the backend
for each response put on the ring (rsp_prod gets set by rsp_prod_pvt when
pushing the responses on the ring). Both values can
wrap and are modulo the size of the ring (in block case that is 32).
Please see RING_GET_REQUEST and RING_GET_RESPONSE for the more details.
The culprit here is that if the difference between the
req_prod and req_cons is greater than the ring size we have a problem.
Fortunately for us, the '__do_block_io_op' loop:
rc = blk_rings->common.req_cons;
rp = blk_rings->common.sring->req_prod;
while (rc != rp) {
..
blk_rings->common.req_cons = ++rc; /* before make_response() */
}
will loop up to the point when rc == rp. The macros inside of the
loop (RING_GET_REQUEST) is smart and is indexing based on the modulo
of the ring size. If the frontend has provided a bogus req_prod value
we will loop until the 'rc == rp' - which means we could be processing
already processed requests (or responses) often.
The reason the RING_REQUEST_CONS_OVERFLOW is not helping here is
b/c it only tracks how many responses we have internally produced
and whether we would should process more. The astute reader will
notice that the macro RING_REQUEST_CONS_OVERFLOW provides two
arguments - more on this later.
For example, if we were to enter this function with these values:
blk_rings->common.sring->req_prod = X+31415 (X is the value from
the last time __do_block_io_op was called).
blk_rings->common.req_cons = X
blk_rings->common.rsp_prod_pvt = X
The RING_REQUEST_CONS_OVERFLOW(&blk_rings->common, blk_rings->common.req_cons)
is doing:
req_cons - rsp_prod_pvt >= 32
Which is,
X - X >= 32 or 0 >= 32
And that is false, so we continue on looping (this bug).
If we re-use said macro RING_REQUEST_CONS_OVERFLOW and pass in the rp
instead (sring->req_prod) of rc, the this macro can do the check:
req_prod - rsp_prov_pvt >= 32
Which is,
X + 31415 - X >= 32 , or 31415 >= 32
which is true, so we can error out and break out of the function.
Unfortunatly the difference between rsp_prov_pvt and req_prod can be
at 32 (which would error out in the macro). This condition exists when
the backend is lagging behind with the responses and still has not finished
responding to all of them (so make_response has not been called), and
the rsp_prov_pvt + 32 == req_cons. This ends up with us not being able
to use said macro.
Hence introducing a new macro called RING_REQUEST_PROD_OVERFLOW which does
a simple check of:
req_prod - rsp_prod_pvt > RING_SIZE
And with the X values from above:
X + 31415 - X > 32
Returns true. Also not that if the ring is full (which is where
the RING_REQUEST_CONS_OVERFLOW triggered), we would not hit the
same condition:
X + 32 - X > 32
Which is false.
Lets use that macro.
Note that in v5 of this patchset the macro was different - we used an
earlier version.
Cc: stable@vger.kernel.org
[v1: Move the check outside the loop]
[v2: Add a pr_warn as suggested by David]
[v3: Use RING_REQUEST_CONS_OVERFLOW as suggested by Jan]
[v4: Move wake_up after kthread_stop as suggested by Jan]
[v5: Use RING_REQUEST_PROD_OVERFLOW instead]
[v6: Use RING_REQUEST_PROD_OVERFLOW - Jan's version]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
gadsa
2013-01-24 05:54:32 +08:00
|
|
|
init_waitqueue_head(&blkif->shutdown_wq);
|
2011-04-20 22:57:29 +08:00
|
|
|
|
|
|
|
return blkif;
|
|
|
|
}
|
|
|
|
|
2015-06-03 13:40:03 +08:00
|
|
|
static int xen_blkif_map(struct xen_blkif *blkif, grant_ref_t *gref,
|
|
|
|
unsigned int nr_grefs, unsigned int evtchn)
|
2011-04-20 22:57:29 +08:00
|
|
|
{
|
|
|
|
int err;
|
|
|
|
|
|
|
|
/* Already connected through? */
|
|
|
|
if (blkif->irq)
|
|
|
|
return 0;
|
|
|
|
|
2015-06-03 13:40:03 +08:00
|
|
|
err = xenbus_map_ring_valloc(blkif->be->dev, gref, nr_grefs,
|
2015-04-03 14:44:59 +08:00
|
|
|
&blkif->blk_ring);
|
2011-09-29 23:53:30 +08:00
|
|
|
if (err < 0)
|
2011-04-20 22:57:29 +08:00
|
|
|
return err;
|
|
|
|
|
|
|
|
switch (blkif->blk_protocol) {
|
|
|
|
case BLKIF_PROTOCOL_NATIVE:
|
|
|
|
{
|
|
|
|
struct blkif_sring *sring;
|
2011-09-29 23:53:30 +08:00
|
|
|
sring = (struct blkif_sring *)blkif->blk_ring;
|
2015-05-05 23:25:56 +08:00
|
|
|
BACK_RING_INIT(&blkif->blk_rings.native, sring,
|
|
|
|
XEN_PAGE_SIZE * nr_grefs);
|
2011-04-20 22:57:29 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
case BLKIF_PROTOCOL_X86_32:
|
|
|
|
{
|
|
|
|
struct blkif_x86_32_sring *sring_x86_32;
|
2011-09-29 23:53:30 +08:00
|
|
|
sring_x86_32 = (struct blkif_x86_32_sring *)blkif->blk_ring;
|
2015-05-05 23:25:56 +08:00
|
|
|
BACK_RING_INIT(&blkif->blk_rings.x86_32, sring_x86_32,
|
|
|
|
XEN_PAGE_SIZE * nr_grefs);
|
2011-04-20 22:57:29 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
case BLKIF_PROTOCOL_X86_64:
|
|
|
|
{
|
|
|
|
struct blkif_x86_64_sring *sring_x86_64;
|
2011-09-29 23:53:30 +08:00
|
|
|
sring_x86_64 = (struct blkif_x86_64_sring *)blkif->blk_ring;
|
2015-05-05 23:25:56 +08:00
|
|
|
BACK_RING_INIT(&blkif->blk_rings.x86_64, sring_x86_64,
|
|
|
|
XEN_PAGE_SIZE * nr_grefs);
|
2011-04-20 22:57:29 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
default:
|
|
|
|
BUG();
|
|
|
|
}
|
|
|
|
|
2011-04-20 23:50:43 +08:00
|
|
|
err = bind_interdomain_evtchn_to_irqhandler(blkif->domid, evtchn,
|
|
|
|
xen_blkif_be_int, 0,
|
|
|
|
"blkif-backend", blkif);
|
2011-04-20 22:57:29 +08:00
|
|
|
if (err < 0) {
|
2011-09-29 23:53:30 +08:00
|
|
|
xenbus_unmap_ring_vfree(blkif->be->dev, blkif->blk_ring);
|
2011-04-20 22:57:29 +08:00
|
|
|
blkif->blk_rings.common.sring = NULL;
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
blkif->irq = err;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2014-05-21 04:28:50 +08:00
|
|
|
static int xen_blkif_disconnect(struct xen_blkif *blkif)
|
2011-04-20 22:57:29 +08:00
|
|
|
{
|
2015-09-04 18:08:07 +08:00
|
|
|
struct pending_req *req, *n;
|
|
|
|
int i = 0, j;
|
|
|
|
|
2011-04-20 22:57:29 +08:00
|
|
|
if (blkif->xenblkd) {
|
|
|
|
kthread_stop(blkif->xenblkd);
|
xen/blkback: Check for insane amounts of request on the ring (v6).
Check that the ring does not have an insane amount of requests
(more than there could fit on the ring).
If we detect this case we will stop processing the requests
and wait until the XenBus disconnects the ring.
The existing check RING_REQUEST_CONS_OVERFLOW which checks for how
many responses we have created in the past (rsp_prod_pvt) vs
requests consumed (req_cons) and whether said difference is greater or
equal to the size of the ring, does not catch this case.
Wha the condition does check if there is a need to process more
as we still have a backlog of responses to finish. Note that both
of those values (rsp_prod_pvt and req_cons) are not exposed on the
shared ring.
To understand this problem a mini crash course in ring protocol
response/request updates is in place.
There are four entries: req_prod and rsp_prod; req_event and rsp_event
to track the ring entries. We are only concerned about the first two -
which set the tone of this bug.
The req_prod is a value incremented by frontend for each request put
on the ring. Conversely the rsp_prod is a value incremented by the backend
for each response put on the ring (rsp_prod gets set by rsp_prod_pvt when
pushing the responses on the ring). Both values can
wrap and are modulo the size of the ring (in block case that is 32).
Please see RING_GET_REQUEST and RING_GET_RESPONSE for the more details.
The culprit here is that if the difference between the
req_prod and req_cons is greater than the ring size we have a problem.
Fortunately for us, the '__do_block_io_op' loop:
rc = blk_rings->common.req_cons;
rp = blk_rings->common.sring->req_prod;
while (rc != rp) {
..
blk_rings->common.req_cons = ++rc; /* before make_response() */
}
will loop up to the point when rc == rp. The macros inside of the
loop (RING_GET_REQUEST) is smart and is indexing based on the modulo
of the ring size. If the frontend has provided a bogus req_prod value
we will loop until the 'rc == rp' - which means we could be processing
already processed requests (or responses) often.
The reason the RING_REQUEST_CONS_OVERFLOW is not helping here is
b/c it only tracks how many responses we have internally produced
and whether we would should process more. The astute reader will
notice that the macro RING_REQUEST_CONS_OVERFLOW provides two
arguments - more on this later.
For example, if we were to enter this function with these values:
blk_rings->common.sring->req_prod = X+31415 (X is the value from
the last time __do_block_io_op was called).
blk_rings->common.req_cons = X
blk_rings->common.rsp_prod_pvt = X
The RING_REQUEST_CONS_OVERFLOW(&blk_rings->common, blk_rings->common.req_cons)
is doing:
req_cons - rsp_prod_pvt >= 32
Which is,
X - X >= 32 or 0 >= 32
And that is false, so we continue on looping (this bug).
If we re-use said macro RING_REQUEST_CONS_OVERFLOW and pass in the rp
instead (sring->req_prod) of rc, the this macro can do the check:
req_prod - rsp_prov_pvt >= 32
Which is,
X + 31415 - X >= 32 , or 31415 >= 32
which is true, so we can error out and break out of the function.
Unfortunatly the difference between rsp_prov_pvt and req_prod can be
at 32 (which would error out in the macro). This condition exists when
the backend is lagging behind with the responses and still has not finished
responding to all of them (so make_response has not been called), and
the rsp_prov_pvt + 32 == req_cons. This ends up with us not being able
to use said macro.
Hence introducing a new macro called RING_REQUEST_PROD_OVERFLOW which does
a simple check of:
req_prod - rsp_prod_pvt > RING_SIZE
And with the X values from above:
X + 31415 - X > 32
Returns true. Also not that if the ring is full (which is where
the RING_REQUEST_CONS_OVERFLOW triggered), we would not hit the
same condition:
X + 32 - X > 32
Which is false.
Lets use that macro.
Note that in v5 of this patchset the macro was different - we used an
earlier version.
Cc: stable@vger.kernel.org
[v1: Move the check outside the loop]
[v2: Add a pr_warn as suggested by David]
[v3: Use RING_REQUEST_CONS_OVERFLOW as suggested by Jan]
[v4: Move wake_up after kthread_stop as suggested by Jan]
[v5: Use RING_REQUEST_PROD_OVERFLOW instead]
[v6: Use RING_REQUEST_PROD_OVERFLOW - Jan's version]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
gadsa
2013-01-24 05:54:32 +08:00
|
|
|
wake_up(&blkif->shutdown_wq);
|
2011-04-20 22:57:29 +08:00
|
|
|
blkif->xenblkd = NULL;
|
|
|
|
}
|
|
|
|
|
2014-05-21 04:28:50 +08:00
|
|
|
/* The above kthread_stop() guarantees that at this point we
|
|
|
|
* don't have any discard_io or other_io requests. So, checking
|
|
|
|
* for inflight IO is enough.
|
|
|
|
*/
|
|
|
|
if (atomic_read(&blkif->inflight) > 0)
|
|
|
|
return -EBUSY;
|
2011-04-20 22:57:29 +08:00
|
|
|
|
|
|
|
if (blkif->irq) {
|
|
|
|
unbind_from_irqhandler(blkif->irq, blkif);
|
|
|
|
blkif->irq = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (blkif->blk_rings.common.sring) {
|
2011-09-29 23:53:30 +08:00
|
|
|
xenbus_unmap_ring_vfree(blkif->be->dev, blkif->blk_ring);
|
2011-04-20 22:57:29 +08:00
|
|
|
blkif->blk_rings.common.sring = NULL;
|
|
|
|
}
|
2014-05-21 04:28:50 +08:00
|
|
|
|
2014-09-08 21:21:33 +08:00
|
|
|
/* Remove all persistent grants and the cache of ballooned pages. */
|
|
|
|
xen_blkbk_free_caches(blkif);
|
|
|
|
|
2015-09-04 18:08:07 +08:00
|
|
|
/* Check that there is no request in use */
|
|
|
|
list_for_each_entry_safe(req, n, &blkif->pending_free, free_list) {
|
|
|
|
list_del(&req->free_list);
|
|
|
|
|
|
|
|
for (j = 0; j < MAX_INDIRECT_SEGMENTS; j++)
|
|
|
|
kfree(req->segments[j]);
|
|
|
|
|
|
|
|
for (j = 0; j < MAX_INDIRECT_PAGES; j++)
|
|
|
|
kfree(req->indirect_pages[j]);
|
|
|
|
|
|
|
|
kfree(req);
|
|
|
|
i++;
|
|
|
|
}
|
|
|
|
|
|
|
|
WARN_ON(i != (XEN_BLKIF_REQS_PER_PAGE * blkif->nr_ring_pages));
|
|
|
|
blkif->nr_ring_pages = 0;
|
|
|
|
|
2014-05-21 04:28:50 +08:00
|
|
|
return 0;
|
2011-04-20 22:57:29 +08:00
|
|
|
}
|
|
|
|
|
2012-08-13 22:53:17 +08:00
|
|
|
static void xen_blkif_free(struct xen_blkif *blkif)
|
2011-04-20 22:57:29 +08:00
|
|
|
{
|
2013-04-18 02:18:59 +08:00
|
|
|
|
2014-05-21 04:28:50 +08:00
|
|
|
xen_blkif_disconnect(blkif);
|
|
|
|
xen_vbd_free(&blkif->vbd);
|
2013-04-18 02:18:59 +08:00
|
|
|
|
2014-02-04 18:26:13 +08:00
|
|
|
/* Make sure everything is drained before shutting down */
|
|
|
|
BUG_ON(blkif->persistent_gnt_c != 0);
|
|
|
|
BUG_ON(atomic_read(&blkif->persistent_gnt_in_use) != 0);
|
|
|
|
BUG_ON(blkif->free_pages_num != 0);
|
|
|
|
BUG_ON(!list_empty(&blkif->persistent_purge_list));
|
|
|
|
BUG_ON(!list_empty(&blkif->free_pages));
|
|
|
|
BUG_ON(!RB_EMPTY_ROOT(&blkif->persistent_gnts));
|
|
|
|
|
2011-04-20 23:50:43 +08:00
|
|
|
kmem_cache_free(xen_blkif_cachep, blkif);
|
2011-04-20 22:57:29 +08:00
|
|
|
}
|
|
|
|
|
2011-04-20 23:50:43 +08:00
|
|
|
int __init xen_blkif_interface_init(void)
|
2011-04-20 22:57:29 +08:00
|
|
|
{
|
2011-04-20 23:50:43 +08:00
|
|
|
xen_blkif_cachep = kmem_cache_create("blkif_cache",
|
2011-05-13 04:47:48 +08:00
|
|
|
sizeof(struct xen_blkif),
|
2011-04-20 23:50:43 +08:00
|
|
|
0, 0, NULL);
|
|
|
|
if (!xen_blkif_cachep)
|
2011-04-20 22:57:29 +08:00
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2011-04-15 06:25:47 +08:00
|
|
|
|
2011-04-15 05:05:23 +08:00
|
|
|
/*
|
2011-04-15 06:25:47 +08:00
|
|
|
* sysfs interface for VBD I/O requests
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define VBD_SHOW(name, format, args...) \
|
|
|
|
static ssize_t show_##name(struct device *_dev, \
|
|
|
|
struct device_attribute *attr, \
|
|
|
|
char *buf) \
|
|
|
|
{ \
|
|
|
|
struct xenbus_device *dev = to_xenbus_device(_dev); \
|
2010-02-12 08:07:31 +08:00
|
|
|
struct backend_info *be = dev_get_drvdata(&dev->dev); \
|
2011-04-15 06:25:47 +08:00
|
|
|
\
|
|
|
|
return sprintf(buf, format, ##args); \
|
|
|
|
} \
|
|
|
|
static DEVICE_ATTR(name, S_IRUGO, show_##name, NULL)
|
|
|
|
|
2013-03-12 00:15:50 +08:00
|
|
|
VBD_SHOW(oo_req, "%llu\n", be->blkif->st_oo_req);
|
|
|
|
VBD_SHOW(rd_req, "%llu\n", be->blkif->st_rd_req);
|
|
|
|
VBD_SHOW(wr_req, "%llu\n", be->blkif->st_wr_req);
|
|
|
|
VBD_SHOW(f_req, "%llu\n", be->blkif->st_f_req);
|
|
|
|
VBD_SHOW(ds_req, "%llu\n", be->blkif->st_ds_req);
|
|
|
|
VBD_SHOW(rd_sect, "%llu\n", be->blkif->st_rd_sect);
|
|
|
|
VBD_SHOW(wr_sect, "%llu\n", be->blkif->st_wr_sect);
|
2011-04-15 06:25:47 +08:00
|
|
|
|
2011-05-13 04:53:56 +08:00
|
|
|
static struct attribute *xen_vbdstat_attrs[] = {
|
2011-04-15 06:25:47 +08:00
|
|
|
&dev_attr_oo_req.attr,
|
|
|
|
&dev_attr_rd_req.attr,
|
|
|
|
&dev_attr_wr_req.attr,
|
2011-05-05 05:07:27 +08:00
|
|
|
&dev_attr_f_req.attr,
|
2011-09-01 18:39:10 +08:00
|
|
|
&dev_attr_ds_req.attr,
|
2011-04-15 06:25:47 +08:00
|
|
|
&dev_attr_rd_sect.attr,
|
|
|
|
&dev_attr_wr_sect.attr,
|
|
|
|
NULL
|
|
|
|
};
|
|
|
|
|
2011-05-13 04:53:56 +08:00
|
|
|
static struct attribute_group xen_vbdstat_group = {
|
2011-04-15 06:25:47 +08:00
|
|
|
.name = "statistics",
|
2011-05-13 04:53:56 +08:00
|
|
|
.attrs = xen_vbdstat_attrs,
|
2011-04-15 06:25:47 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
VBD_SHOW(physical_device, "%x:%x\n", be->major, be->minor);
|
|
|
|
VBD_SHOW(mode, "%s\n", be->mode);
|
|
|
|
|
2012-08-13 22:53:17 +08:00
|
|
|
static int xenvbd_sysfs_addif(struct xenbus_device *dev)
|
2011-04-15 06:25:47 +08:00
|
|
|
{
|
|
|
|
int error;
|
|
|
|
|
|
|
|
error = device_create_file(&dev->dev, &dev_attr_physical_device);
|
2011-04-15 05:33:30 +08:00
|
|
|
if (error)
|
2011-04-15 06:25:47 +08:00
|
|
|
goto fail1;
|
|
|
|
|
|
|
|
error = device_create_file(&dev->dev, &dev_attr_mode);
|
|
|
|
if (error)
|
|
|
|
goto fail2;
|
|
|
|
|
2011-05-13 04:53:56 +08:00
|
|
|
error = sysfs_create_group(&dev->dev.kobj, &xen_vbdstat_group);
|
2011-04-15 06:25:47 +08:00
|
|
|
if (error)
|
|
|
|
goto fail3;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
2011-05-13 04:53:56 +08:00
|
|
|
fail3: sysfs_remove_group(&dev->dev.kobj, &xen_vbdstat_group);
|
2011-04-15 06:25:47 +08:00
|
|
|
fail2: device_remove_file(&dev->dev, &dev_attr_mode);
|
|
|
|
fail1: device_remove_file(&dev->dev, &dev_attr_physical_device);
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
2012-08-13 22:53:17 +08:00
|
|
|
static void xenvbd_sysfs_delif(struct xenbus_device *dev)
|
2011-04-15 06:25:47 +08:00
|
|
|
{
|
2011-05-13 04:53:56 +08:00
|
|
|
sysfs_remove_group(&dev->dev.kobj, &xen_vbdstat_group);
|
2011-04-15 06:25:47 +08:00
|
|
|
device_remove_file(&dev->dev, &dev_attr_mode);
|
|
|
|
device_remove_file(&dev->dev, &dev_attr_physical_device);
|
|
|
|
}
|
|
|
|
|
2011-04-20 23:21:43 +08:00
|
|
|
|
2011-05-13 04:53:56 +08:00
|
|
|
static void xen_vbd_free(struct xen_vbd *vbd)
|
2011-04-20 23:21:43 +08:00
|
|
|
{
|
|
|
|
if (vbd->bdev)
|
|
|
|
blkdev_put(vbd->bdev, vbd->readonly ? FMODE_READ : FMODE_WRITE);
|
|
|
|
vbd->bdev = NULL;
|
|
|
|
}
|
|
|
|
|
2011-05-13 04:53:56 +08:00
|
|
|
static int xen_vbd_create(struct xen_blkif *blkif, blkif_vdev_t handle,
|
|
|
|
unsigned major, unsigned minor, int readonly,
|
|
|
|
int cdrom)
|
2011-04-20 23:21:43 +08:00
|
|
|
{
|
2011-05-13 04:53:56 +08:00
|
|
|
struct xen_vbd *vbd;
|
2011-04-20 23:21:43 +08:00
|
|
|
struct block_device *bdev;
|
2011-05-05 05:07:27 +08:00
|
|
|
struct request_queue *q;
|
2011-04-20 23:21:43 +08:00
|
|
|
|
|
|
|
vbd = &blkif->vbd;
|
|
|
|
vbd->handle = handle;
|
|
|
|
vbd->readonly = readonly;
|
|
|
|
vbd->type = 0;
|
|
|
|
|
|
|
|
vbd->pdevice = MKDEV(major, minor);
|
|
|
|
|
|
|
|
bdev = blkdev_get_by_dev(vbd->pdevice, vbd->readonly ?
|
|
|
|
FMODE_READ : FMODE_WRITE, NULL);
|
|
|
|
|
|
|
|
if (IS_ERR(bdev)) {
|
2015-04-01 23:04:22 +08:00
|
|
|
pr_warn("xen_vbd_create: device %08x could not be opened\n",
|
2011-04-20 23:21:43 +08:00
|
|
|
vbd->pdevice);
|
|
|
|
return -ENOENT;
|
|
|
|
}
|
|
|
|
|
|
|
|
vbd->bdev = bdev;
|
|
|
|
if (vbd->bdev->bd_disk == NULL) {
|
2015-04-01 23:04:22 +08:00
|
|
|
pr_warn("xen_vbd_create: device %08x doesn't exist\n",
|
2011-04-20 23:21:43 +08:00
|
|
|
vbd->pdevice);
|
2011-05-13 04:53:56 +08:00
|
|
|
xen_vbd_free(vbd);
|
2011-04-20 23:21:43 +08:00
|
|
|
return -ENOENT;
|
|
|
|
}
|
2011-05-25 18:24:25 +08:00
|
|
|
vbd->size = vbd_sz(vbd);
|
2011-04-20 23:21:43 +08:00
|
|
|
|
|
|
|
if (vbd->bdev->bd_disk->flags & GENHD_FL_CD || cdrom)
|
|
|
|
vbd->type |= VDISK_CDROM;
|
|
|
|
if (vbd->bdev->bd_disk->flags & GENHD_FL_REMOVABLE)
|
|
|
|
vbd->type |= VDISK_REMOVABLE;
|
|
|
|
|
2011-05-05 05:07:27 +08:00
|
|
|
q = bdev_get_queue(bdev);
|
|
|
|
if (q && q->flush_flags)
|
|
|
|
vbd->flush_support = true;
|
|
|
|
|
2011-10-13 04:23:30 +08:00
|
|
|
if (q && blk_queue_secdiscard(q))
|
|
|
|
vbd->discard_secure = true;
|
|
|
|
|
2015-04-01 23:04:22 +08:00
|
|
|
pr_debug("Successful creation of handle=%04x (dom=%u)\n",
|
2011-04-20 23:21:43 +08:00
|
|
|
handle, blkif->domid);
|
|
|
|
return 0;
|
|
|
|
}
|
2011-04-20 23:50:43 +08:00
|
|
|
static int xen_blkbk_remove(struct xenbus_device *dev)
|
2011-04-15 06:25:47 +08:00
|
|
|
{
|
2010-02-12 08:07:31 +08:00
|
|
|
struct backend_info *be = dev_get_drvdata(&dev->dev);
|
2011-04-15 06:25:47 +08:00
|
|
|
|
2015-04-01 23:04:22 +08:00
|
|
|
pr_debug("%s %p %d\n", __func__, dev, dev->otherend_id);
|
2011-04-15 06:25:47 +08:00
|
|
|
|
|
|
|
if (be->major || be->minor)
|
|
|
|
xenvbd_sysfs_delif(dev);
|
|
|
|
|
|
|
|
if (be->backend_watch.node) {
|
|
|
|
unregister_xenbus_watch(&be->backend_watch);
|
|
|
|
kfree(be->backend_watch.node);
|
|
|
|
be->backend_watch.node = NULL;
|
|
|
|
}
|
|
|
|
|
2014-05-21 04:28:50 +08:00
|
|
|
dev_set_drvdata(&dev->dev, NULL);
|
|
|
|
|
2011-04-15 06:25:47 +08:00
|
|
|
if (be->blkif) {
|
2011-04-20 23:50:43 +08:00
|
|
|
xen_blkif_disconnect(be->blkif);
|
2014-05-21 04:28:50 +08:00
|
|
|
xen_blkif_put(be->blkif);
|
2011-04-15 06:25:47 +08:00
|
|
|
}
|
|
|
|
|
2012-12-20 18:31:11 +08:00
|
|
|
kfree(be->mode);
|
2011-04-15 06:25:47 +08:00
|
|
|
kfree(be);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-05-05 05:07:27 +08:00
|
|
|
int xen_blkbk_flush_diskcache(struct xenbus_transaction xbt,
|
|
|
|
struct backend_info *be, int state)
|
2011-04-15 06:25:47 +08:00
|
|
|
{
|
|
|
|
struct xenbus_device *dev = be->dev;
|
|
|
|
int err;
|
|
|
|
|
2011-05-05 05:07:27 +08:00
|
|
|
err = xenbus_printf(xbt, dev->nodename, "feature-flush-cache",
|
2011-04-15 06:25:47 +08:00
|
|
|
"%d", state);
|
|
|
|
if (err)
|
2012-03-15 01:04:00 +08:00
|
|
|
dev_warn(&dev->dev, "writing feature-flush-cache (%d)", err);
|
2011-04-15 06:25:47 +08:00
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2012-03-15 01:04:00 +08:00
|
|
|
static void xen_blkbk_discard(struct xenbus_transaction xbt, struct backend_info *be)
|
2011-09-01 18:39:10 +08:00
|
|
|
{
|
|
|
|
struct xenbus_device *dev = be->dev;
|
|
|
|
struct xen_blkif *blkif = be->blkif;
|
|
|
|
int err;
|
2014-05-21 22:32:42 +08:00
|
|
|
int state = 0, discard_enable;
|
2012-03-14 06:43:23 +08:00
|
|
|
struct block_device *bdev = be->blkif->vbd.bdev;
|
|
|
|
struct request_queue *q = bdev_get_queue(bdev);
|
|
|
|
|
2014-05-21 22:32:42 +08:00
|
|
|
err = xenbus_scanf(XBT_NIL, dev->nodename, "discard-enable", "%d",
|
|
|
|
&discard_enable);
|
|
|
|
if (err == 1 && !discard_enable)
|
|
|
|
return;
|
|
|
|
|
2012-03-14 06:43:23 +08:00
|
|
|
if (blk_queue_discard(q)) {
|
|
|
|
err = xenbus_printf(xbt, dev->nodename,
|
|
|
|
"discard-granularity", "%u",
|
|
|
|
q->limits.discard_granularity);
|
|
|
|
if (err) {
|
2012-03-15 01:04:00 +08:00
|
|
|
dev_warn(&dev->dev, "writing discard-granularity (%d)", err);
|
|
|
|
return;
|
2012-03-14 06:43:23 +08:00
|
|
|
}
|
|
|
|
err = xenbus_printf(xbt, dev->nodename,
|
|
|
|
"discard-alignment", "%u",
|
|
|
|
q->limits.discard_alignment);
|
|
|
|
if (err) {
|
2012-03-15 01:04:00 +08:00
|
|
|
dev_warn(&dev->dev, "writing discard-alignment (%d)", err);
|
|
|
|
return;
|
2011-09-01 18:39:10 +08:00
|
|
|
}
|
2012-03-14 06:43:23 +08:00
|
|
|
state = 1;
|
|
|
|
/* Optional. */
|
|
|
|
err = xenbus_printf(xbt, dev->nodename,
|
|
|
|
"discard-secure", "%d",
|
|
|
|
blkif->vbd.discard_secure);
|
|
|
|
if (err) {
|
2012-04-17 09:55:04 +08:00
|
|
|
dev_warn(&dev->dev, "writing discard-secure (%d)", err);
|
2012-03-15 01:04:00 +08:00
|
|
|
return;
|
2011-09-01 18:39:10 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
err = xenbus_printf(xbt, dev->nodename, "feature-discard",
|
|
|
|
"%d", state);
|
|
|
|
if (err)
|
2012-03-15 01:04:00 +08:00
|
|
|
dev_warn(&dev->dev, "writing feature-discard (%d)", err);
|
2011-09-01 18:39:10 +08:00
|
|
|
}
|
2011-10-10 12:42:22 +08:00
|
|
|
int xen_blkbk_barrier(struct xenbus_transaction xbt,
|
|
|
|
struct backend_info *be, int state)
|
|
|
|
{
|
|
|
|
struct xenbus_device *dev = be->dev;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
err = xenbus_printf(xbt, dev->nodename, "feature-barrier",
|
|
|
|
"%d", state);
|
|
|
|
if (err)
|
2012-03-15 01:04:00 +08:00
|
|
|
dev_warn(&dev->dev, "writing feature-barrier (%d)", err);
|
2011-10-10 12:42:22 +08:00
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
2011-09-01 18:39:10 +08:00
|
|
|
|
2011-05-12 03:57:09 +08:00
|
|
|
/*
|
2011-04-15 06:25:47 +08:00
|
|
|
* Entry point to this code when a new device is created. Allocate the basic
|
|
|
|
* structures, and watch the store waiting for the hotplug scripts to tell us
|
|
|
|
* the device's physical major and minor numbers. Switch to InitWait.
|
|
|
|
*/
|
2011-04-20 23:50:43 +08:00
|
|
|
static int xen_blkbk_probe(struct xenbus_device *dev,
|
|
|
|
const struct xenbus_device_id *id)
|
2011-04-15 06:25:47 +08:00
|
|
|
{
|
|
|
|
int err;
|
|
|
|
struct backend_info *be = kzalloc(sizeof(struct backend_info),
|
|
|
|
GFP_KERNEL);
|
2015-04-01 23:04:22 +08:00
|
|
|
|
|
|
|
/* match the pr_debug in xen_blkbk_remove */
|
|
|
|
pr_debug("%s %p %d\n", __func__, dev, dev->otherend_id);
|
|
|
|
|
2011-04-15 06:25:47 +08:00
|
|
|
if (!be) {
|
|
|
|
xenbus_dev_fatal(dev, -ENOMEM,
|
|
|
|
"allocating backend structure");
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
be->dev = dev;
|
2010-02-12 08:07:31 +08:00
|
|
|
dev_set_drvdata(&dev->dev, be);
|
2011-04-15 06:25:47 +08:00
|
|
|
|
2011-04-20 23:50:43 +08:00
|
|
|
be->blkif = xen_blkif_alloc(dev->otherend_id);
|
2011-04-15 06:25:47 +08:00
|
|
|
if (IS_ERR(be->blkif)) {
|
|
|
|
err = PTR_ERR(be->blkif);
|
|
|
|
be->blkif = NULL;
|
|
|
|
xenbus_dev_fatal(dev, err, "creating block interface");
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* setup back pointer */
|
|
|
|
be->blkif->be = be;
|
|
|
|
|
2009-02-10 04:05:51 +08:00
|
|
|
err = xenbus_watch_pathfmt(dev, &be->backend_watch, backend_changed,
|
|
|
|
"%s/%s", dev->nodename, "physical-device");
|
2011-04-15 06:25:47 +08:00
|
|
|
if (err)
|
|
|
|
goto fail;
|
|
|
|
|
2015-06-03 13:40:03 +08:00
|
|
|
err = xenbus_printf(XBT_NIL, dev->nodename, "max-ring-page-order", "%u",
|
|
|
|
xen_blkif_max_ring_order);
|
|
|
|
if (err)
|
|
|
|
pr_warn("%s write out 'max-ring-page-order' failed\n", __func__);
|
|
|
|
|
2011-04-15 06:25:47 +08:00
|
|
|
err = xenbus_switch_state(dev, XenbusStateInitWait);
|
|
|
|
if (err)
|
|
|
|
goto fail;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
fail:
|
2015-04-01 23:04:22 +08:00
|
|
|
pr_warn("%s failed\n", __func__);
|
2011-04-20 23:50:43 +08:00
|
|
|
xen_blkbk_remove(dev);
|
2011-04-15 06:25:47 +08:00
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2011-05-12 03:57:09 +08:00
|
|
|
/*
|
2011-04-15 06:25:47 +08:00
|
|
|
* Callback received when the hotplug scripts have placed the physical-device
|
|
|
|
* node. Read it and the mode node, and create a vbd. If the frontend is
|
|
|
|
* ready, connect.
|
|
|
|
*/
|
|
|
|
static void backend_changed(struct xenbus_watch *watch,
|
|
|
|
const char **vec, unsigned int len)
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
unsigned major;
|
|
|
|
unsigned minor;
|
|
|
|
struct backend_info *be
|
|
|
|
= container_of(watch, struct backend_info, backend_watch);
|
|
|
|
struct xenbus_device *dev = be->dev;
|
|
|
|
int cdrom = 0;
|
2012-12-20 18:31:11 +08:00
|
|
|
unsigned long handle;
|
2011-04-15 06:25:47 +08:00
|
|
|
char *device_type;
|
|
|
|
|
2015-04-01 23:04:22 +08:00
|
|
|
pr_debug("%s %p %d\n", __func__, dev, dev->otherend_id);
|
2011-04-15 06:25:47 +08:00
|
|
|
|
|
|
|
err = xenbus_scanf(XBT_NIL, dev->nodename, "physical-device", "%x:%x",
|
|
|
|
&major, &minor);
|
|
|
|
if (XENBUS_EXIST_ERR(err)) {
|
2011-05-12 03:57:09 +08:00
|
|
|
/*
|
|
|
|
* Since this watch will fire once immediately after it is
|
|
|
|
* registered, we expect this. Ignore it, and wait for the
|
|
|
|
* hotplug scripts.
|
|
|
|
*/
|
2011-04-15 06:25:47 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
if (err != 2) {
|
|
|
|
xenbus_dev_fatal(dev, err, "reading physical-device");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2012-12-20 18:31:11 +08:00
|
|
|
if (be->major | be->minor) {
|
|
|
|
if (be->major != major || be->minor != minor)
|
2015-04-01 23:04:22 +08:00
|
|
|
pr_warn("changing physical device (from %x:%x to %x:%x) not supported.\n",
|
2012-12-20 18:31:11 +08:00
|
|
|
be->major, be->minor, major, minor);
|
2011-04-15 06:25:47 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
be->mode = xenbus_read(XBT_NIL, dev->nodename, "mode", NULL);
|
|
|
|
if (IS_ERR(be->mode)) {
|
|
|
|
err = PTR_ERR(be->mode);
|
|
|
|
be->mode = NULL;
|
|
|
|
xenbus_dev_fatal(dev, err, "reading mode");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
device_type = xenbus_read(XBT_NIL, dev->otherend, "device-type", NULL);
|
|
|
|
if (!IS_ERR(device_type)) {
|
|
|
|
cdrom = strcmp(device_type, "cdrom") == 0;
|
|
|
|
kfree(device_type);
|
|
|
|
}
|
|
|
|
|
2012-12-20 18:31:11 +08:00
|
|
|
/* Front end dir is a number, which is used as the handle. */
|
2013-09-12 05:20:07 +08:00
|
|
|
err = kstrtoul(strrchr(dev->otherend, '/') + 1, 0, &handle);
|
2012-12-20 18:31:11 +08:00
|
|
|
if (err)
|
|
|
|
return;
|
2011-04-15 06:25:47 +08:00
|
|
|
|
2012-12-20 18:31:11 +08:00
|
|
|
be->major = major;
|
|
|
|
be->minor = minor;
|
2011-04-15 06:25:47 +08:00
|
|
|
|
2012-12-20 18:31:11 +08:00
|
|
|
err = xen_vbd_create(be->blkif, handle, major, minor,
|
|
|
|
!strchr(be->mode, 'w'), cdrom);
|
2011-04-15 06:25:47 +08:00
|
|
|
|
2012-12-20 18:31:11 +08:00
|
|
|
if (err)
|
|
|
|
xenbus_dev_fatal(dev, err, "creating vbd structure");
|
|
|
|
else {
|
2011-04-15 06:25:47 +08:00
|
|
|
err = xenvbd_sysfs_addif(dev);
|
|
|
|
if (err) {
|
2011-05-13 04:53:56 +08:00
|
|
|
xen_vbd_free(&be->blkif->vbd);
|
2011-04-15 06:25:47 +08:00
|
|
|
xenbus_dev_fatal(dev, err, "creating sysfs entries");
|
|
|
|
}
|
2012-12-20 18:31:11 +08:00
|
|
|
}
|
2011-04-15 06:25:47 +08:00
|
|
|
|
2012-12-20 18:31:11 +08:00
|
|
|
if (err) {
|
|
|
|
kfree(be->mode);
|
|
|
|
be->mode = NULL;
|
|
|
|
be->major = 0;
|
|
|
|
be->minor = 0;
|
|
|
|
} else {
|
2011-04-15 06:25:47 +08:00
|
|
|
/* We're potentially connected now */
|
2011-04-20 23:50:43 +08:00
|
|
|
xen_update_blkif_status(be->blkif);
|
2011-04-15 06:25:47 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2011-05-12 03:57:09 +08:00
|
|
|
/*
|
2011-04-15 06:25:47 +08:00
|
|
|
* Callback received when the frontend's state changes.
|
|
|
|
*/
|
|
|
|
static void frontend_changed(struct xenbus_device *dev,
|
|
|
|
enum xenbus_state frontend_state)
|
|
|
|
{
|
2010-02-12 08:07:31 +08:00
|
|
|
struct backend_info *be = dev_get_drvdata(&dev->dev);
|
2011-04-15 06:25:47 +08:00
|
|
|
int err;
|
|
|
|
|
2015-04-01 23:04:22 +08:00
|
|
|
pr_debug("%s %p %s\n", __func__, dev, xenbus_strstate(frontend_state));
|
2011-04-15 06:25:47 +08:00
|
|
|
|
|
|
|
switch (frontend_state) {
|
|
|
|
case XenbusStateInitialising:
|
|
|
|
if (dev->state == XenbusStateClosed) {
|
2015-04-01 23:04:22 +08:00
|
|
|
pr_info("%s: prepare for reconnect\n", dev->nodename);
|
2011-04-15 06:25:47 +08:00
|
|
|
xenbus_switch_state(dev, XenbusStateInitWait);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case XenbusStateInitialised:
|
|
|
|
case XenbusStateConnected:
|
2011-05-12 03:57:09 +08:00
|
|
|
/*
|
|
|
|
* Ensure we connect even when two watches fire in
|
2011-11-29 12:31:00 +08:00
|
|
|
* close succession and we miss the intermediate value
|
2011-05-12 03:57:09 +08:00
|
|
|
* of frontend_state.
|
|
|
|
*/
|
2011-04-15 06:25:47 +08:00
|
|
|
if (dev->state == XenbusStateConnected)
|
|
|
|
break;
|
|
|
|
|
2011-05-12 03:57:09 +08:00
|
|
|
/*
|
|
|
|
* Enforce precondition before potential leak point.
|
2011-08-15 12:57:07 +08:00
|
|
|
* xen_blkif_disconnect() is idempotent.
|
2010-11-25 14:08:20 +08:00
|
|
|
*/
|
2014-05-21 04:28:50 +08:00
|
|
|
err = xen_blkif_disconnect(be->blkif);
|
|
|
|
if (err) {
|
|
|
|
xenbus_dev_fatal(dev, err, "pending I/O");
|
|
|
|
break;
|
|
|
|
}
|
2010-11-25 14:08:20 +08:00
|
|
|
|
2011-04-15 06:25:47 +08:00
|
|
|
err = connect_ring(be);
|
|
|
|
if (err)
|
|
|
|
break;
|
2011-04-20 23:50:43 +08:00
|
|
|
xen_update_blkif_status(be->blkif);
|
2011-04-15 06:25:47 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
case XenbusStateClosing:
|
|
|
|
xenbus_switch_state(dev, XenbusStateClosing);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case XenbusStateClosed:
|
xen-blkback: Don't disconnect backend until state switched to XenbusStateClosed.
When do block-attach/block-detach test with below steps, umount hangs
in the guest. Furthermore shutdown ends up being stuck when umounting file-systems.
1. start guest.
2. attach new block device by xm block-attach in Dom0.
3. mount new disk in guest.
4. execute xm block-detach to detach the block device in dom0 until timeout
5. Any request to the disk will hung.
Root cause:
This issue is caused when setting backend device's state to
'XenbusStateClosing', which sends to the frontend the XenbusStateClosing
notification. When frontend receives the notification it tries to release
the disk in blkfront_closing(), but at that moment the disk is still in use
by guest, so frontend refuses to close. Specifically it sets the disk state to
XenbusStateClosing and sends the notification to backend - when backend receives the
event, it disconnects the vbd from real device, and sets the vbd device state to
XenbusStateClosing. The backend disconnects the real device/file, and any IO
requests to the disk in guest will end up in ether, leaving disk DEAD and set to
XenbusStateClosing. When the guest wants to disconnect the disk, umount will
hang on blkif_release()->xlvbd_release_gendisk() as it is unable to send any IO
to the disk, which prevents clean system shutdown.
Solution:
Don't disconnect backend until frontend state switched to XenbusStateClosed.
Signed-off-by: Joe Jin <joe.jin@oracle.com>
Cc: Daniel Stodden <daniel.stodden@citrix.com>
Cc: Jens Axboe <jaxboe@fusionio.com>
Cc: Annie Li <annie.li@oracle.com>
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>
[v1: Modified description a bit]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2011-08-15 12:51:31 +08:00
|
|
|
xen_blkif_disconnect(be->blkif);
|
2011-04-15 06:25:47 +08:00
|
|
|
xenbus_switch_state(dev, XenbusStateClosed);
|
|
|
|
if (xenbus_dev_is_online(dev))
|
|
|
|
break;
|
|
|
|
/* fall through if not online */
|
|
|
|
case XenbusStateUnknown:
|
2011-08-15 12:57:07 +08:00
|
|
|
/* implies xen_blkif_disconnect() via xen_blkbk_remove() */
|
2011-04-15 06:25:47 +08:00
|
|
|
device_unregister(&dev->dev);
|
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
|
|
|
xenbus_dev_fatal(dev, -EINVAL, "saw state %d at frontend",
|
|
|
|
frontend_state);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* ** Connection ** */
|
|
|
|
|
|
|
|
|
2011-05-12 03:57:09 +08:00
|
|
|
/*
|
2011-04-15 06:25:47 +08:00
|
|
|
* Write the physical details regarding the block device to the store, and
|
|
|
|
* switch to Connected state.
|
|
|
|
*/
|
|
|
|
static void connect(struct backend_info *be)
|
|
|
|
{
|
|
|
|
struct xenbus_transaction xbt;
|
|
|
|
int err;
|
|
|
|
struct xenbus_device *dev = be->dev;
|
|
|
|
|
2015-04-01 23:04:22 +08:00
|
|
|
pr_debug("%s %s\n", __func__, dev->otherend);
|
2011-04-15 06:25:47 +08:00
|
|
|
|
|
|
|
/* Supply the information about the device the frontend needs */
|
|
|
|
again:
|
|
|
|
err = xenbus_transaction_start(&xbt);
|
|
|
|
if (err) {
|
|
|
|
xenbus_dev_fatal(dev, err, "starting transaction");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2012-03-15 01:04:00 +08:00
|
|
|
/* If we can't advertise it is OK. */
|
|
|
|
xen_blkbk_flush_diskcache(xbt, be, be->blkif->vbd.flush_support);
|
2011-04-15 06:25:47 +08:00
|
|
|
|
2012-03-15 01:04:00 +08:00
|
|
|
xen_blkbk_discard(xbt, be);
|
2011-09-01 18:39:10 +08:00
|
|
|
|
2012-03-15 01:04:00 +08:00
|
|
|
xen_blkbk_barrier(xbt, be, be->blkif->vbd.flush_support);
|
2011-10-10 12:42:22 +08:00
|
|
|
|
xen/blkback: Persistent grant maps for xen blk drivers
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 dom0; dom0 performed the I/O and wrote
directly into the grant-mapped memory and unmapped it; blkfront then
removed foreign access for that grant. The cost of unmapping scales
badly with the number of CPUs in Dom0. An experiment showed that when
Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
(at which point 650,000 IOPS are being performed in total). If more
than 5 guests are used, the performance declines. By 10 guests, only
400,000 IOPS are being performed.
This patch improves performance by only unmapping when the connection
between blkfront and back is broken.
On startup blkfront notifies blkback that it is using persistent
grants, and blkback will do the same. If blkback is not capable of
persistent mapping, blkfront will still use the same grants, since it
is compatible with the previous protocol, and simplifies the code
complexity in blkfront.
To perform a read, in persistent mode, blkfront uses a separate pool
of pages that it maps to dom0. When a request comes in, blkfront
transmutes the request so that blkback will write into one of these
free pages. Blkback keeps note of which grefs it has already
mapped. When a new ring request comes to blkback, it looks to see if
it has already mapped that page. If so, it will not map it again. If
the page hasn't been previously mapped, it is mapped now, and a record
is kept of this mapping. Blkback proceeds as usual. When blkfront is
notified that blkback has completed a request, it memcpy's from the
shared memory, into the bvec supplied. A record that the {gref, page}
tuple is mapped, and not inflight is kept.
Writes are similar, except that the memcpy is peformed from the
supplied bvecs, into the shared pages, before the request is put onto
the ring.
Blkback stores a mapping of grefs=>{page mapped to by gref} in
a red-black tree. As the grefs are not known apriori, and provide no
guarantees on their ordering, we have to perform a search
through this tree to find the page, for every gref we receive. This
operation takes O(log n) time in the worst case. In blkfront grants
are stored using a single linked list.
The maximum number of grants that blkback will persistenly map is
currently set to RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, to
prevent a malicios guest from attempting a DoS, by supplying fresh
grefs, causing the Dom0 kernel to map excessively. If a guest
is using persistent grants and exceeds the maximum number of grants to
map persistenly the newly passed grefs will be mapped and unmaped.
Using this approach, we can have requests that mix persistent and
non-persistent grants, and we need to handle them correctly.
This allows us to set the maximum number of persistent grants to a
lower value than RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, although
setting it will lead to unpredictable performance.
In writing this patch, the question arrises as to if the additional
cost of performing memcpys in the guest (to/from the pool of granted
pages) outweigh the gains of not performing TLB shootdowns. The answer
to that question is `no'. There appears to be very little, if any
additional cost to the guest of using persistent grants. There is
perhaps a small saving, from the reduced number of hypercalls
performed in granting, and ending foreign access.
Signed-off-by: Oliver Chick <oliver.chick@citrix.com>
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
[v1: Fixed up the misuse of bool as int]
2012-10-25 00:58:45 +08:00
|
|
|
err = xenbus_printf(xbt, dev->nodename, "feature-persistent", "%u", 1);
|
|
|
|
if (err) {
|
|
|
|
xenbus_dev_fatal(dev, err, "writing %s/feature-persistent",
|
|
|
|
dev->nodename);
|
|
|
|
goto abort;
|
|
|
|
}
|
2013-04-18 22:06:54 +08:00
|
|
|
err = xenbus_printf(xbt, dev->nodename, "feature-max-indirect-segments", "%u",
|
|
|
|
MAX_INDIRECT_SEGMENTS);
|
|
|
|
if (err)
|
|
|
|
dev_warn(&dev->dev, "writing %s/feature-max-indirect-segments (%d)",
|
|
|
|
dev->nodename, err);
|
xen/blkback: Persistent grant maps for xen blk drivers
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 dom0; dom0 performed the I/O and wrote
directly into the grant-mapped memory and unmapped it; blkfront then
removed foreign access for that grant. The cost of unmapping scales
badly with the number of CPUs in Dom0. An experiment showed that when
Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
(at which point 650,000 IOPS are being performed in total). If more
than 5 guests are used, the performance declines. By 10 guests, only
400,000 IOPS are being performed.
This patch improves performance by only unmapping when the connection
between blkfront and back is broken.
On startup blkfront notifies blkback that it is using persistent
grants, and blkback will do the same. If blkback is not capable of
persistent mapping, blkfront will still use the same grants, since it
is compatible with the previous protocol, and simplifies the code
complexity in blkfront.
To perform a read, in persistent mode, blkfront uses a separate pool
of pages that it maps to dom0. When a request comes in, blkfront
transmutes the request so that blkback will write into one of these
free pages. Blkback keeps note of which grefs it has already
mapped. When a new ring request comes to blkback, it looks to see if
it has already mapped that page. If so, it will not map it again. If
the page hasn't been previously mapped, it is mapped now, and a record
is kept of this mapping. Blkback proceeds as usual. When blkfront is
notified that blkback has completed a request, it memcpy's from the
shared memory, into the bvec supplied. A record that the {gref, page}
tuple is mapped, and not inflight is kept.
Writes are similar, except that the memcpy is peformed from the
supplied bvecs, into the shared pages, before the request is put onto
the ring.
Blkback stores a mapping of grefs=>{page mapped to by gref} in
a red-black tree. As the grefs are not known apriori, and provide no
guarantees on their ordering, we have to perform a search
through this tree to find the page, for every gref we receive. This
operation takes O(log n) time in the worst case. In blkfront grants
are stored using a single linked list.
The maximum number of grants that blkback will persistenly map is
currently set to RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, to
prevent a malicios guest from attempting a DoS, by supplying fresh
grefs, causing the Dom0 kernel to map excessively. If a guest
is using persistent grants and exceeds the maximum number of grants to
map persistenly the newly passed grefs will be mapped and unmaped.
Using this approach, we can have requests that mix persistent and
non-persistent grants, and we need to handle them correctly.
This allows us to set the maximum number of persistent grants to a
lower value than RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, although
setting it will lead to unpredictable performance.
In writing this patch, the question arrises as to if the additional
cost of performing memcpys in the guest (to/from the pool of granted
pages) outweigh the gains of not performing TLB shootdowns. The answer
to that question is `no'. There appears to be very little, if any
additional cost to the guest of using persistent grants. There is
perhaps a small saving, from the reduced number of hypercalls
performed in granting, and ending foreign access.
Signed-off-by: Oliver Chick <oliver.chick@citrix.com>
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
[v1: Fixed up the misuse of bool as int]
2012-10-25 00:58:45 +08:00
|
|
|
|
2011-04-15 06:25:47 +08:00
|
|
|
err = xenbus_printf(xbt, dev->nodename, "sectors", "%llu",
|
2011-04-20 23:21:43 +08:00
|
|
|
(unsigned long long)vbd_sz(&be->blkif->vbd));
|
2011-04-15 06:25:47 +08:00
|
|
|
if (err) {
|
|
|
|
xenbus_dev_fatal(dev, err, "writing %s/sectors",
|
|
|
|
dev->nodename);
|
|
|
|
goto abort;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* FIXME: use a typename instead */
|
|
|
|
err = xenbus_printf(xbt, dev->nodename, "info", "%u",
|
2011-04-20 23:21:43 +08:00
|
|
|
be->blkif->vbd.type |
|
|
|
|
(be->blkif->vbd.readonly ? VDISK_READONLY : 0));
|
2011-04-15 06:25:47 +08:00
|
|
|
if (err) {
|
|
|
|
xenbus_dev_fatal(dev, err, "writing %s/info",
|
|
|
|
dev->nodename);
|
|
|
|
goto abort;
|
|
|
|
}
|
|
|
|
err = xenbus_printf(xbt, dev->nodename, "sector-size", "%lu",
|
2011-04-20 23:21:43 +08:00
|
|
|
(unsigned long)
|
|
|
|
bdev_logical_block_size(be->blkif->vbd.bdev));
|
2011-04-15 06:25:47 +08:00
|
|
|
if (err) {
|
|
|
|
xenbus_dev_fatal(dev, err, "writing %s/sector-size",
|
|
|
|
dev->nodename);
|
|
|
|
goto abort;
|
|
|
|
}
|
2013-05-13 22:28:15 +08:00
|
|
|
err = xenbus_printf(xbt, dev->nodename, "physical-sector-size", "%u",
|
|
|
|
bdev_physical_block_size(be->blkif->vbd.bdev));
|
|
|
|
if (err)
|
|
|
|
xenbus_dev_error(dev, err, "writing %s/physical-sector-size",
|
|
|
|
dev->nodename);
|
2011-04-15 06:25:47 +08:00
|
|
|
|
|
|
|
err = xenbus_transaction_end(xbt, 0);
|
|
|
|
if (err == -EAGAIN)
|
|
|
|
goto again;
|
|
|
|
if (err)
|
|
|
|
xenbus_dev_fatal(dev, err, "ending transaction");
|
|
|
|
|
|
|
|
err = xenbus_switch_state(dev, XenbusStateConnected);
|
|
|
|
if (err)
|
2011-06-13 00:21:13 +08:00
|
|
|
xenbus_dev_fatal(dev, err, "%s: switching to Connected state",
|
2011-04-15 06:25:47 +08:00
|
|
|
dev->nodename);
|
|
|
|
|
|
|
|
return;
|
|
|
|
abort:
|
|
|
|
xenbus_transaction_end(xbt, 1);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static int connect_ring(struct backend_info *be)
|
|
|
|
{
|
|
|
|
struct xenbus_device *dev = be->dev;
|
2015-10-14 00:50:11 +08:00
|
|
|
unsigned int ring_ref[XENBUS_MAX_RING_GRANTS];
|
2015-06-03 13:40:03 +08:00
|
|
|
unsigned int evtchn, nr_grefs, ring_page_order;
|
xen/blkback: Persistent grant maps for xen blk drivers
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 dom0; dom0 performed the I/O and wrote
directly into the grant-mapped memory and unmapped it; blkfront then
removed foreign access for that grant. The cost of unmapping scales
badly with the number of CPUs in Dom0. An experiment showed that when
Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
(at which point 650,000 IOPS are being performed in total). If more
than 5 guests are used, the performance declines. By 10 guests, only
400,000 IOPS are being performed.
This patch improves performance by only unmapping when the connection
between blkfront and back is broken.
On startup blkfront notifies blkback that it is using persistent
grants, and blkback will do the same. If blkback is not capable of
persistent mapping, blkfront will still use the same grants, since it
is compatible with the previous protocol, and simplifies the code
complexity in blkfront.
To perform a read, in persistent mode, blkfront uses a separate pool
of pages that it maps to dom0. When a request comes in, blkfront
transmutes the request so that blkback will write into one of these
free pages. Blkback keeps note of which grefs it has already
mapped. When a new ring request comes to blkback, it looks to see if
it has already mapped that page. If so, it will not map it again. If
the page hasn't been previously mapped, it is mapped now, and a record
is kept of this mapping. Blkback proceeds as usual. When blkfront is
notified that blkback has completed a request, it memcpy's from the
shared memory, into the bvec supplied. A record that the {gref, page}
tuple is mapped, and not inflight is kept.
Writes are similar, except that the memcpy is peformed from the
supplied bvecs, into the shared pages, before the request is put onto
the ring.
Blkback stores a mapping of grefs=>{page mapped to by gref} in
a red-black tree. As the grefs are not known apriori, and provide no
guarantees on their ordering, we have to perform a search
through this tree to find the page, for every gref we receive. This
operation takes O(log n) time in the worst case. In blkfront grants
are stored using a single linked list.
The maximum number of grants that blkback will persistenly map is
currently set to RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, to
prevent a malicios guest from attempting a DoS, by supplying fresh
grefs, causing the Dom0 kernel to map excessively. If a guest
is using persistent grants and exceeds the maximum number of grants to
map persistenly the newly passed grefs will be mapped and unmaped.
Using this approach, we can have requests that mix persistent and
non-persistent grants, and we need to handle them correctly.
This allows us to set the maximum number of persistent grants to a
lower value than RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, although
setting it will lead to unpredictable performance.
In writing this patch, the question arrises as to if the additional
cost of performing memcpys in the guest (to/from the pool of granted
pages) outweigh the gains of not performing TLB shootdowns. The answer
to that question is `no'. There appears to be very little, if any
additional cost to the guest of using persistent grants. There is
perhaps a small saving, from the reduced number of hypercalls
performed in granting, and ending foreign access.
Signed-off-by: Oliver Chick <oliver.chick@citrix.com>
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
[v1: Fixed up the misuse of bool as int]
2012-10-25 00:58:45 +08:00
|
|
|
unsigned int pers_grants;
|
2011-04-15 06:25:47 +08:00
|
|
|
char protocol[64] = "";
|
2015-06-03 13:40:01 +08:00
|
|
|
struct pending_req *req, *n;
|
|
|
|
int err, i, j;
|
2011-04-15 06:25:47 +08:00
|
|
|
|
2015-04-01 23:04:22 +08:00
|
|
|
pr_debug("%s %s\n", __func__, dev->otherend);
|
2011-04-15 06:25:47 +08:00
|
|
|
|
2015-06-03 13:40:03 +08:00
|
|
|
err = xenbus_scanf(XBT_NIL, dev->otherend, "event-channel", "%u",
|
|
|
|
&evtchn);
|
|
|
|
if (err != 1) {
|
|
|
|
err = -EINVAL;
|
|
|
|
xenbus_dev_fatal(dev, err, "reading %s/event-channel",
|
2011-04-15 06:25:47 +08:00
|
|
|
dev->otherend);
|
|
|
|
return err;
|
|
|
|
}
|
2015-06-03 13:40:03 +08:00
|
|
|
pr_info("event-channel %u\n", evtchn);
|
|
|
|
|
|
|
|
err = xenbus_scanf(XBT_NIL, dev->otherend, "ring-page-order", "%u",
|
|
|
|
&ring_page_order);
|
|
|
|
if (err != 1) {
|
|
|
|
err = xenbus_scanf(XBT_NIL, dev->otherend, "ring-ref",
|
|
|
|
"%u", &ring_ref[0]);
|
|
|
|
if (err != 1) {
|
|
|
|
err = -EINVAL;
|
|
|
|
xenbus_dev_fatal(dev, err, "reading %s/ring-ref",
|
|
|
|
dev->otherend);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
nr_grefs = 1;
|
|
|
|
pr_info("%s:using single page: ring-ref %d\n", dev->otherend,
|
|
|
|
ring_ref[0]);
|
|
|
|
} else {
|
|
|
|
unsigned int i;
|
|
|
|
|
|
|
|
if (ring_page_order > xen_blkif_max_ring_order) {
|
|
|
|
err = -EINVAL;
|
|
|
|
xenbus_dev_fatal(dev, err, "%s/request %d ring page order exceed max:%d",
|
|
|
|
dev->otherend, ring_page_order,
|
|
|
|
xen_blkif_max_ring_order);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
nr_grefs = 1 << ring_page_order;
|
|
|
|
for (i = 0; i < nr_grefs; i++) {
|
|
|
|
char ring_ref_name[RINGREF_NAME_LEN];
|
|
|
|
|
|
|
|
snprintf(ring_ref_name, RINGREF_NAME_LEN, "ring-ref%u", i);
|
|
|
|
err = xenbus_scanf(XBT_NIL, dev->otherend, ring_ref_name,
|
|
|
|
"%u", &ring_ref[i]);
|
|
|
|
if (err != 1) {
|
|
|
|
err = -EINVAL;
|
|
|
|
xenbus_dev_fatal(dev, err, "reading %s/%s",
|
|
|
|
dev->otherend, ring_ref_name);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
pr_info("ring-ref%u: %u\n", i, ring_ref[i]);
|
|
|
|
}
|
|
|
|
}
|
2011-04-15 06:25:47 +08:00
|
|
|
|
2015-02-06 01:09:56 +08:00
|
|
|
be->blkif->blk_protocol = BLKIF_PROTOCOL_DEFAULT;
|
2011-04-15 06:25:47 +08:00
|
|
|
err = xenbus_gather(XBT_NIL, dev->otherend, "protocol",
|
|
|
|
"%63s", protocol, NULL);
|
|
|
|
if (err)
|
2015-02-06 01:09:56 +08:00
|
|
|
strcpy(protocol, "unspecified, assuming default");
|
2011-04-15 06:25:47 +08:00
|
|
|
else if (0 == strcmp(protocol, XEN_IO_PROTO_ABI_NATIVE))
|
|
|
|
be->blkif->blk_protocol = BLKIF_PROTOCOL_NATIVE;
|
|
|
|
else if (0 == strcmp(protocol, XEN_IO_PROTO_ABI_X86_32))
|
|
|
|
be->blkif->blk_protocol = BLKIF_PROTOCOL_X86_32;
|
|
|
|
else if (0 == strcmp(protocol, XEN_IO_PROTO_ABI_X86_64))
|
|
|
|
be->blkif->blk_protocol = BLKIF_PROTOCOL_X86_64;
|
|
|
|
else {
|
|
|
|
xenbus_dev_fatal(dev, err, "unknown fe protocol %s", protocol);
|
|
|
|
return -1;
|
|
|
|
}
|
xen/blkback: Persistent grant maps for xen blk drivers
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 dom0; dom0 performed the I/O and wrote
directly into the grant-mapped memory and unmapped it; blkfront then
removed foreign access for that grant. The cost of unmapping scales
badly with the number of CPUs in Dom0. An experiment showed that when
Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
(at which point 650,000 IOPS are being performed in total). If more
than 5 guests are used, the performance declines. By 10 guests, only
400,000 IOPS are being performed.
This patch improves performance by only unmapping when the connection
between blkfront and back is broken.
On startup blkfront notifies blkback that it is using persistent
grants, and blkback will do the same. If blkback is not capable of
persistent mapping, blkfront will still use the same grants, since it
is compatible with the previous protocol, and simplifies the code
complexity in blkfront.
To perform a read, in persistent mode, blkfront uses a separate pool
of pages that it maps to dom0. When a request comes in, blkfront
transmutes the request so that blkback will write into one of these
free pages. Blkback keeps note of which grefs it has already
mapped. When a new ring request comes to blkback, it looks to see if
it has already mapped that page. If so, it will not map it again. If
the page hasn't been previously mapped, it is mapped now, and a record
is kept of this mapping. Blkback proceeds as usual. When blkfront is
notified that blkback has completed a request, it memcpy's from the
shared memory, into the bvec supplied. A record that the {gref, page}
tuple is mapped, and not inflight is kept.
Writes are similar, except that the memcpy is peformed from the
supplied bvecs, into the shared pages, before the request is put onto
the ring.
Blkback stores a mapping of grefs=>{page mapped to by gref} in
a red-black tree. As the grefs are not known apriori, and provide no
guarantees on their ordering, we have to perform a search
through this tree to find the page, for every gref we receive. This
operation takes O(log n) time in the worst case. In blkfront grants
are stored using a single linked list.
The maximum number of grants that blkback will persistenly map is
currently set to RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, to
prevent a malicios guest from attempting a DoS, by supplying fresh
grefs, causing the Dom0 kernel to map excessively. If a guest
is using persistent grants and exceeds the maximum number of grants to
map persistenly the newly passed grefs will be mapped and unmaped.
Using this approach, we can have requests that mix persistent and
non-persistent grants, and we need to handle them correctly.
This allows us to set the maximum number of persistent grants to a
lower value than RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, although
setting it will lead to unpredictable performance.
In writing this patch, the question arrises as to if the additional
cost of performing memcpys in the guest (to/from the pool of granted
pages) outweigh the gains of not performing TLB shootdowns. The answer
to that question is `no'. There appears to be very little, if any
additional cost to the guest of using persistent grants. There is
perhaps a small saving, from the reduced number of hypercalls
performed in granting, and ending foreign access.
Signed-off-by: Oliver Chick <oliver.chick@citrix.com>
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
[v1: Fixed up the misuse of bool as int]
2012-10-25 00:58:45 +08:00
|
|
|
err = xenbus_gather(XBT_NIL, dev->otherend,
|
2012-11-02 23:43:04 +08:00
|
|
|
"feature-persistent", "%u",
|
xen/blkback: Persistent grant maps for xen blk drivers
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 dom0; dom0 performed the I/O and wrote
directly into the grant-mapped memory and unmapped it; blkfront then
removed foreign access for that grant. The cost of unmapping scales
badly with the number of CPUs in Dom0. An experiment showed that when
Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
(at which point 650,000 IOPS are being performed in total). If more
than 5 guests are used, the performance declines. By 10 guests, only
400,000 IOPS are being performed.
This patch improves performance by only unmapping when the connection
between blkfront and back is broken.
On startup blkfront notifies blkback that it is using persistent
grants, and blkback will do the same. If blkback is not capable of
persistent mapping, blkfront will still use the same grants, since it
is compatible with the previous protocol, and simplifies the code
complexity in blkfront.
To perform a read, in persistent mode, blkfront uses a separate pool
of pages that it maps to dom0. When a request comes in, blkfront
transmutes the request so that blkback will write into one of these
free pages. Blkback keeps note of which grefs it has already
mapped. When a new ring request comes to blkback, it looks to see if
it has already mapped that page. If so, it will not map it again. If
the page hasn't been previously mapped, it is mapped now, and a record
is kept of this mapping. Blkback proceeds as usual. When blkfront is
notified that blkback has completed a request, it memcpy's from the
shared memory, into the bvec supplied. A record that the {gref, page}
tuple is mapped, and not inflight is kept.
Writes are similar, except that the memcpy is peformed from the
supplied bvecs, into the shared pages, before the request is put onto
the ring.
Blkback stores a mapping of grefs=>{page mapped to by gref} in
a red-black tree. As the grefs are not known apriori, and provide no
guarantees on their ordering, we have to perform a search
through this tree to find the page, for every gref we receive. This
operation takes O(log n) time in the worst case. In blkfront grants
are stored using a single linked list.
The maximum number of grants that blkback will persistenly map is
currently set to RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, to
prevent a malicios guest from attempting a DoS, by supplying fresh
grefs, causing the Dom0 kernel to map excessively. If a guest
is using persistent grants and exceeds the maximum number of grants to
map persistenly the newly passed grefs will be mapped and unmaped.
Using this approach, we can have requests that mix persistent and
non-persistent grants, and we need to handle them correctly.
This allows us to set the maximum number of persistent grants to a
lower value than RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, although
setting it will lead to unpredictable performance.
In writing this patch, the question arrises as to if the additional
cost of performing memcpys in the guest (to/from the pool of granted
pages) outweigh the gains of not performing TLB shootdowns. The answer
to that question is `no'. There appears to be very little, if any
additional cost to the guest of using persistent grants. There is
perhaps a small saving, from the reduced number of hypercalls
performed in granting, and ending foreign access.
Signed-off-by: Oliver Chick <oliver.chick@citrix.com>
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
[v1: Fixed up the misuse of bool as int]
2012-10-25 00:58:45 +08:00
|
|
|
&pers_grants, NULL);
|
|
|
|
if (err)
|
|
|
|
pers_grants = 0;
|
|
|
|
|
|
|
|
be->blkif->vbd.feature_gnt_persistent = pers_grants;
|
|
|
|
be->blkif->vbd.overflow_max_grants = 0;
|
2015-06-03 13:40:03 +08:00
|
|
|
be->blkif->nr_ring_pages = nr_grefs;
|
xen/blkback: Persistent grant maps for xen blk drivers
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 dom0; dom0 performed the I/O and wrote
directly into the grant-mapped memory and unmapped it; blkfront then
removed foreign access for that grant. The cost of unmapping scales
badly with the number of CPUs in Dom0. An experiment showed that when
Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
(at which point 650,000 IOPS are being performed in total). If more
than 5 guests are used, the performance declines. By 10 guests, only
400,000 IOPS are being performed.
This patch improves performance by only unmapping when the connection
between blkfront and back is broken.
On startup blkfront notifies blkback that it is using persistent
grants, and blkback will do the same. If blkback is not capable of
persistent mapping, blkfront will still use the same grants, since it
is compatible with the previous protocol, and simplifies the code
complexity in blkfront.
To perform a read, in persistent mode, blkfront uses a separate pool
of pages that it maps to dom0. When a request comes in, blkfront
transmutes the request so that blkback will write into one of these
free pages. Blkback keeps note of which grefs it has already
mapped. When a new ring request comes to blkback, it looks to see if
it has already mapped that page. If so, it will not map it again. If
the page hasn't been previously mapped, it is mapped now, and a record
is kept of this mapping. Blkback proceeds as usual. When blkfront is
notified that blkback has completed a request, it memcpy's from the
shared memory, into the bvec supplied. A record that the {gref, page}
tuple is mapped, and not inflight is kept.
Writes are similar, except that the memcpy is peformed from the
supplied bvecs, into the shared pages, before the request is put onto
the ring.
Blkback stores a mapping of grefs=>{page mapped to by gref} in
a red-black tree. As the grefs are not known apriori, and provide no
guarantees on their ordering, we have to perform a search
through this tree to find the page, for every gref we receive. This
operation takes O(log n) time in the worst case. In blkfront grants
are stored using a single linked list.
The maximum number of grants that blkback will persistenly map is
currently set to RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, to
prevent a malicios guest from attempting a DoS, by supplying fresh
grefs, causing the Dom0 kernel to map excessively. If a guest
is using persistent grants and exceeds the maximum number of grants to
map persistenly the newly passed grefs will be mapped and unmaped.
Using this approach, we can have requests that mix persistent and
non-persistent grants, and we need to handle them correctly.
This allows us to set the maximum number of persistent grants to a
lower value than RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, although
setting it will lead to unpredictable performance.
In writing this patch, the question arrises as to if the additional
cost of performing memcpys in the guest (to/from the pool of granted
pages) outweigh the gains of not performing TLB shootdowns. The answer
to that question is `no'. There appears to be very little, if any
additional cost to the guest of using persistent grants. There is
perhaps a small saving, from the reduced number of hypercalls
performed in granting, and ending foreign access.
Signed-off-by: Oliver Chick <oliver.chick@citrix.com>
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
[v1: Fixed up the misuse of bool as int]
2012-10-25 00:58:45 +08:00
|
|
|
|
2015-06-03 13:40:03 +08:00
|
|
|
pr_info("ring-pages:%d, event-channel %d, protocol %d (%s) %s\n",
|
|
|
|
nr_grefs, evtchn, be->blkif->blk_protocol, protocol,
|
xen/blkback: Persistent grant maps for xen blk drivers
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 dom0; dom0 performed the I/O and wrote
directly into the grant-mapped memory and unmapped it; blkfront then
removed foreign access for that grant. The cost of unmapping scales
badly with the number of CPUs in Dom0. An experiment showed that when
Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
(at which point 650,000 IOPS are being performed in total). If more
than 5 guests are used, the performance declines. By 10 guests, only
400,000 IOPS are being performed.
This patch improves performance by only unmapping when the connection
between blkfront and back is broken.
On startup blkfront notifies blkback that it is using persistent
grants, and blkback will do the same. If blkback is not capable of
persistent mapping, blkfront will still use the same grants, since it
is compatible with the previous protocol, and simplifies the code
complexity in blkfront.
To perform a read, in persistent mode, blkfront uses a separate pool
of pages that it maps to dom0. When a request comes in, blkfront
transmutes the request so that blkback will write into one of these
free pages. Blkback keeps note of which grefs it has already
mapped. When a new ring request comes to blkback, it looks to see if
it has already mapped that page. If so, it will not map it again. If
the page hasn't been previously mapped, it is mapped now, and a record
is kept of this mapping. Blkback proceeds as usual. When blkfront is
notified that blkback has completed a request, it memcpy's from the
shared memory, into the bvec supplied. A record that the {gref, page}
tuple is mapped, and not inflight is kept.
Writes are similar, except that the memcpy is peformed from the
supplied bvecs, into the shared pages, before the request is put onto
the ring.
Blkback stores a mapping of grefs=>{page mapped to by gref} in
a red-black tree. As the grefs are not known apriori, and provide no
guarantees on their ordering, we have to perform a search
through this tree to find the page, for every gref we receive. This
operation takes O(log n) time in the worst case. In blkfront grants
are stored using a single linked list.
The maximum number of grants that blkback will persistenly map is
currently set to RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, to
prevent a malicios guest from attempting a DoS, by supplying fresh
grefs, causing the Dom0 kernel to map excessively. If a guest
is using persistent grants and exceeds the maximum number of grants to
map persistenly the newly passed grefs will be mapped and unmaped.
Using this approach, we can have requests that mix persistent and
non-persistent grants, and we need to handle them correctly.
This allows us to set the maximum number of persistent grants to a
lower value than RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, although
setting it will lead to unpredictable performance.
In writing this patch, the question arrises as to if the additional
cost of performing memcpys in the guest (to/from the pool of granted
pages) outweigh the gains of not performing TLB shootdowns. The answer
to that question is `no'. There appears to be very little, if any
additional cost to the guest of using persistent grants. There is
perhaps a small saving, from the reduced number of hypercalls
performed in granting, and ending foreign access.
Signed-off-by: Oliver Chick <oliver.chick@citrix.com>
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
[v1: Fixed up the misuse of bool as int]
2012-10-25 00:58:45 +08:00
|
|
|
pers_grants ? "persistent grants" : "");
|
2011-04-15 06:25:47 +08:00
|
|
|
|
2015-06-03 13:40:03 +08:00
|
|
|
for (i = 0; i < nr_grefs * XEN_BLKIF_REQS_PER_PAGE; i++) {
|
2015-06-03 13:40:01 +08:00
|
|
|
req = kzalloc(sizeof(*req), GFP_KERNEL);
|
|
|
|
if (!req)
|
|
|
|
goto fail;
|
|
|
|
list_add_tail(&req->free_list, &be->blkif->pending_free);
|
|
|
|
for (j = 0; j < MAX_INDIRECT_SEGMENTS; j++) {
|
|
|
|
req->segments[j] = kzalloc(sizeof(*req->segments[0]), GFP_KERNEL);
|
|
|
|
if (!req->segments[j])
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
for (j = 0; j < MAX_INDIRECT_PAGES; j++) {
|
|
|
|
req->indirect_pages[j] = kzalloc(sizeof(*req->indirect_pages[0]),
|
|
|
|
GFP_KERNEL);
|
|
|
|
if (!req->indirect_pages[j])
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-04-15 06:25:47 +08:00
|
|
|
/* Map the shared frame, irq etc. */
|
2015-06-03 13:40:03 +08:00
|
|
|
err = xen_blkif_map(be->blkif, ring_ref, nr_grefs, evtchn);
|
2011-04-15 06:25:47 +08:00
|
|
|
if (err) {
|
2015-06-03 13:40:03 +08:00
|
|
|
xenbus_dev_fatal(dev, err, "mapping ring-ref port %u", evtchn);
|
2011-04-15 06:25:47 +08:00
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
2015-06-03 13:40:01 +08:00
|
|
|
|
|
|
|
fail:
|
|
|
|
list_for_each_entry_safe(req, n, &be->blkif->pending_free, free_list) {
|
|
|
|
list_del(&req->free_list);
|
|
|
|
for (j = 0; j < MAX_INDIRECT_SEGMENTS; j++) {
|
|
|
|
if (!req->segments[j])
|
|
|
|
break;
|
|
|
|
kfree(req->segments[j]);
|
|
|
|
}
|
|
|
|
for (j = 0; j < MAX_INDIRECT_PAGES; j++) {
|
|
|
|
if (!req->indirect_pages[j])
|
|
|
|
break;
|
|
|
|
kfree(req->indirect_pages[j]);
|
|
|
|
}
|
|
|
|
kfree(req);
|
|
|
|
}
|
|
|
|
return -ENOMEM;
|
2011-04-15 06:25:47 +08:00
|
|
|
}
|
|
|
|
|
2011-04-20 23:50:43 +08:00
|
|
|
static const struct xenbus_device_id xen_blkbk_ids[] = {
|
2011-04-15 06:25:47 +08:00
|
|
|
{ "vbd" },
|
|
|
|
{ "" }
|
|
|
|
};
|
|
|
|
|
2014-09-09 00:30:41 +08:00
|
|
|
static struct xenbus_driver xen_blkbk_driver = {
|
|
|
|
.ids = xen_blkbk_ids,
|
2011-04-20 23:50:43 +08:00
|
|
|
.probe = xen_blkbk_probe,
|
|
|
|
.remove = xen_blkbk_remove,
|
2011-04-15 06:25:47 +08:00
|
|
|
.otherend_changed = frontend_changed
|
2014-09-09 00:30:41 +08:00
|
|
|
};
|
2011-04-15 06:25:47 +08:00
|
|
|
|
2011-04-20 23:50:43 +08:00
|
|
|
int xen_blkif_xenbus_init(void)
|
2011-04-15 06:25:47 +08:00
|
|
|
{
|
2011-12-22 17:08:13 +08:00
|
|
|
return xenbus_register_backend(&xen_blkbk_driver);
|
2011-04-15 06:25:47 +08:00
|
|
|
}
|