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


[Xen-devel] regression with c/s 21223

To: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] regression with c/s 21223
From: Jim Fehlig <jfehlig@xxxxxxxxxx>
Date: Thu, 06 May 2010 21:36:57 -0600
Cc: Ryan O'Connor <rjo@xxxxxxxxx>
Delivery-date: Thu, 06 May 2010 20:37:53 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (X11/20081112)
Hi Keir,

Unfortunately, my fix for losing device config [1] has caused duplicate
devices to appear when successfully starting a managed domain that uses
tapdisk :(. 

# xm li -l domu1 | grep tap
            (uname tap:aio:/mnt1/images/domu1/disk0)
# xm start domu1
# xm li -l domu1 | grep tap
            (uname tap:aio:/mnt1/images/domu1/disk0)
            (uname tap:aio:/mnt1/images/domu1disk0)

This particular host does not have blktap2 driver so blktap1 is used
instead.  (NB: I do not see the problem when using blktap2, but we are
not yet supporting it.)

c/s 21223 attempted to make to_sxp() consult the stored config if no
running config was found for a given device class.  tap2 vs tap provides
an interesting twist.  If blktap2 dev controller is consulted (cls ==
tap2), no running config is returned since the device is really being
handled by blktap1.  The existing config is then consulted, in which
case a blktap2 (tap2) device is found.  When blktap1 controller is
consulted (cls == tap), it returns running config found in xenstore
resulting in duplicate devices.

Frankly, I'm not sure how best to handle this case.  The current
philosophy seems to be treat all 'tap:foo' devices as blktap2 (see c/s
19874 - author cc'd), but fall back to blktap1 if blktap2 is not found
when domU is started.  I'm certainly having problems differentiating
between the two in to_sxp().

Any suggestions on how to prevent the bug reported in [1] without this
new regression?


[1] http://lists.xensource.com/archives/html/xen-devel/2010-04/msg01127.html

Xen-devel mailing list