WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] Add blktap disk type check

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] [PATCH] Add blktap disk type check
From: Masaki Kanno <kanno.masaki@xxxxxxxxxxxxxx>
Date: Fri, 31 Aug 2007 21:52:21 +0900
Delivery-date: Fri, 31 Aug 2007 05:53:55 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <4CC7E3D067611Ckanno.masaki@xxxxxxxxxxxxxx>
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: <4CC7E3D067611Ckanno.masaki@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Hi,

Could you apply this patch?

If without the patch, a wrong blktap disk is attached to a guest domain. 
But the state of the wrong blktap disk remains "3", it does not become 
"4".  If the wrong blktap disk is root image for the guest domain, the 
guest kernel shows the following messages, and does a panic. 
I'd like to point out a disk type error of the blktap disk by the patch 
for users. 


# xm create /xen/vm1.conf disk='tap:xxx:/xen/root-vm1.img,hda1,w'
Using config file "/xen/vm1.conf".
Started domain vm1
# xm block-list vm1
Vdev  BE handle state evt-ch ring-ref BE-path
769    0    0     3      6      8     /local/domain/0/backend/tap/4/769  

XENBUS: Waiting for devices to initialise: 295s...290s...285s...280s...
275s...270s...265s...260s...255s...250s...245s...240s...235s...230s...
225s...220s...215s...210s...205s...200s...195s...190s...185s...180s...
175s...170s...165s...160s...155s...150s...145s...140s...135s...130s...
125s...120s...115s...110s...105s...100s...95s...90s...85s...80s...75s...
70s...65s...60s...55s...50s...45s...40s...35s...30s...25s...20s...15s...
10s...5s...0s...
XENBUS: Timeout connecting to device: device/vbd/769 (local state 3, 
remote state 2)
XENBUS: Device with no driver: device/console/0
BIOS EDD facility v0.16 2004-Jun-25, 0 devices found
EDD information not available.
Freeing unused kernel memory: 196k freed
usbcore: no version for "struct_module" found: kernel tainted.
usbcore: registered new driver usbfs
usbcore: registered new driver hub
USB Universal Host Controller Interface driver v3.0
SCSI subsystem initialized
Adaptec aacraid driver (1.1-5[2409]-mh2)
Kernel panic - not syncing: Attempted to kill init!


Best regards,
 Kan


Tue, 21 Aug 2007 17:51:03 +0900, Masaki Kanno wrote:

>Hi,
>
>This patch adds a check of disk type for blktap.  You get the 
>following error messages by the patch when you give a wrong disk 
>type to xm commands. 
>
># xm create /xen/vm1.conf disk='tap:xxx:/xen/root-vm1.img,hda1,w'
>Using config file "/xen/vm1.conf".
>Error: tap:xxx not a valid disk type
>
># xm block-attach vm2 tap:yyy:/xen/second.img hdb1 w
>Error: tap:yyy not a valid disk type
>Usage: xm block-attach <Domain> <BackDev> <FrontDev> <Mode> [BackDomain]
>
>Create a new virtual block device.
>
>
>Signed-off-by: Masaki Kanno <kanno.masaki@xxxxxxxxxxxxxx>
>
>Best regards,
> Kan
>
>
>-------------------------------text/plain-------------------------------
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@xxxxxxxxxxxxxxxxxxx
>http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>