This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Problem with PV disk and iSCSI

To: Gary Grebus <ggrebus@xxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Problem with PV disk and iSCSI
From: Stefan de Konink <skinkie@xxxxxxxxx>
Date: Fri, 08 Feb 2008 21:00:33 +0100
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 08 Feb 2008 12:00:59 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1202500454.3109.141.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1202500454.3109.141.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (X11/20071225)
Hash: SHA512

Gary Grebus schreef:
> I've run into a problem on 3.1.2 with an HVM guest using PV disks.  In
> dom0, the physical disk is accessed using iSCSI.  The symptom is that
> applications in dom0 which are monitoring the iSCSI network interface
> (e.g. tcpdump) die with EFAULT errors.
> When the block I/O completes, it looks like blkback is doing a
> GNTTABOP_unmap_grant_ref on a guest page, even though the dom0 kernel
> has done get_page() on it and still holds references.  
> The page had been passed through iSCSI into the network stack, so it
> ends up referenced by one or more skb's.  Because there was an AF_PACKET
> socket open, a clone of the skb ends up queued for an indeterminate
> amount on that socket queue.  When the application finally gets around
> to reading the data, the page is no longer mapped, and the read fails
> trying to copy the data out of the kernel.
> Has anyone else seen anything similar?  I mentioned tcpdump, but the
> problem also shows up with dhcpcd, which needs to process packets at the
> ethernet layer.  
> I'm thinking blkback will have to make a dom0 copy of the page before
> doing the unmap if there are still extra references?

I'm running the same setup. Are you using iSCSI over the same interface
as your Xen bridge?

Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


Xen-devel mailing list