From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Roger Pau Monné" <roger.pau@citrix.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: Create a iSCSI DomU with disks in another DomU running on the same Dom0
Date: Fri, 11 Jan 2013 13:51:53 -0500 [thread overview]
Message-ID: <20130111185153.GA29020@phenom.dumpdata.com> (raw)
In-Reply-To: <50F03680.3020800@citrix.com>
[-- Attachment #1: Type: text/plain, Size: 4744 bytes --]
On Fri, Jan 11, 2013 at 04:57:52PM +0100, Roger Pau Monné wrote:
> Hello Konrad,
>
> I've found the problem, blkback is adding granted pages to the bio that
> is then passed to the underlying block device. When using a iscsi
> target running on another DomU in the same h/w this bios end up in
> netback, and then when performing the gnttab copy operation, it
> complains because the passed mfn belongs to a different domain.
OK, so my original theory was sound. The m2p override "sticks".
>
> I've checked this by applying the appended patch to blkback, which
> allocates a buffer to pass to the bio instead of using the granted
> page. Of course this should not applied, since it implies additional
> memcpys.
>
> I think the right way to solve this would be to change netback to
> use gnttab_map and memcpy instead of gnttab_copy, but I guess this
> will imply a performance degradation (haven't benchmarked it, but I
> assume gnttab_copy is used in netback because it is faster than
> gnttab_map + memcpy + gnttab_unmap).
Or blkback is altered to use grant_copy. Or perhaps m2p_override
can do multiple PAGE_FOREIGN? (So if it detects a collision it will
do something smart.. like allocate a new page or update the
kmap_op with extra information).
And yes, grant_map in netback is much much slower that grant_copy
(I tested 2.6.32 vs 3.7 using a Xen 4.1.3 with the grant_copy fixes
that Jan came up with).
See attached.
>
> ---
>
> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
> index 8808028..9740cbb 100644
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -80,6 +80,8 @@ struct pending_req {
> unsigned short operation;
> int status;
> struct list_head free_list;
> + struct page *grant_pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> + void *bio_pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> DECLARE_BITMAP(unmap_seg, BLKIF_MAX_SEGMENTS_PER_REQUEST);
> };
>
> @@ -701,6 +703,7 @@ static void xen_blk_drain_io(struct xen_blkif *blkif)
>
> static void __end_block_io_op(struct pending_req *pending_req, int error)
> {
> + int i;
> /* An error fails the entire request. */
> if ((pending_req->operation == BLKIF_OP_FLUSH_DISKCACHE) &&
> (error == -EOPNOTSUPP)) {
> @@ -724,6 +727,16 @@ static void __end_block_io_op(struct pending_req *pending_req, int error)
> * the proper response on the ring.
> */
> if (atomic_dec_and_test(&pending_req->pendcnt)) {
> + for (i = 0; i < pending_req->nr_pages; i++) {
> + BUG_ON(pending_req->bio_pages[i] == NULL);
> + if (pending_req->operation == BLKIF_OP_READ) {
> + void *grant = kmap_atomic(pending_req->grant_pages[i]);
> + memcpy(grant, pending_req->bio_pages[i],
> + PAGE_SIZE);
> + kunmap_atomic(grant);
> + }
> + kfree(pending_req->bio_pages[i]);
> + }
> xen_blkbk_unmap(pending_req);
> make_response(pending_req->blkif, pending_req->id,
> pending_req->operation, pending_req->status);
> @@ -846,7 +859,6 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
> int operation;
> struct blk_plug plug;
> bool drain = false;
> - struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>
> switch (req->operation) {
> case BLKIF_OP_READ:
> @@ -889,6 +901,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
> pending_req->operation = req->operation;
> pending_req->status = BLKIF_RSP_OKAY;
> pending_req->nr_pages = nseg;
> + memset(pending_req->bio_pages, 0, sizeof(pending_req->bio_pages));
>
> for (i = 0; i < nseg; i++) {
> seg[i].nsec = req->u.rw.seg[i].last_sect -
> @@ -933,7 +946,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
> * the hypercall to unmap the grants - that is all done in
> * xen_blkbk_unmap.
> */
> - if (xen_blkbk_map(req, pending_req, seg, pages))
> + if (xen_blkbk_map(req, pending_req, seg, pending_req->grant_pages))
> goto fail_flush;
>
> /*
> @@ -943,9 +956,17 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
> xen_blkif_get(blkif);
>
> for (i = 0; i < nseg; i++) {
> + void *grant;
> + pending_req->bio_pages[i] = kmalloc(PAGE_SIZE, GFP_KERNEL);
> + if (req->operation == BLKIF_OP_WRITE) {
> + grant = kmap_atomic(pending_req->grant_pages[i]);
> + memcpy(pending_req->bio_pages[i], grant,
> + PAGE_SIZE);
> + kunmap_atomic(grant);
> + }
> while ((bio == NULL) ||
> (bio_add_page(bio,
> - pages[i],
> + virt_to_page(pending_req->bio_pages[i]),
> seg[i].nsec << 9,
> seg[i].buf & ~PAGE_MASK) == 0)) {
>
>
>
[-- Attachment #2: grant_copy_vs_grant_map.png --]
[-- Type: image/png, Size: 15889 bytes --]
[-- Attachment #3: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2013-01-11 18:51 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-21 8:29 Create a iSCSI DomU with disks in another DomU running on the same Dom0 Roger Pau Monné
2012-12-21 14:03 ` Konrad Rzeszutek Wilk
2012-12-21 14:47 ` Roger Pau Monné
2012-12-21 17:35 ` Konrad Rzeszutek Wilk
2013-01-02 13:05 ` Roger Pau Monné
2013-01-02 21:36 ` Konrad Rzeszutek Wilk
2013-01-09 19:23 ` Roger Pau Monné
2013-01-11 15:06 ` Konrad Rzeszutek Wilk
2013-01-11 15:57 ` Roger Pau Monné
2013-01-11 18:51 ` Konrad Rzeszutek Wilk [this message]
2013-01-11 19:29 ` Roger Pau Monné
2013-01-11 21:09 ` Konrad Rzeszutek Wilk
2013-01-12 12:11 ` Roger Pau Monné
2013-01-14 15:24 ` Konrad Rzeszutek Wilk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130111185153.GA29020@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=roger.pau@citrix.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).