From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Fehlig Subject: regression with c/s 21223 Date: Thu, 06 May 2010 21:36:57 -0600 Message-ID: <4BE38AD9.3010701@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Xen-devel Cc: Ryan O'Connor List-Id: xen-devel@lists.xenproject.org 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 (tap2 (uname tap:aio:/mnt1/images/domu1/disk0) # xm start domu1 # xm li -l domu1 | grep tap (tap2 (uname tap:aio:/mnt1/images/domu1/disk0) (tap (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? Thanks, Jim [1] http://lists.xensource.com/archives/html/xen-devel/2010-04/msg01127.html