From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Wolf Subject: Re: VMX status report. Xen: #17630 & Xen0: #540 -- blocked Date: Thu, 15 May 2008 11:50:09 +0200 Message-ID: <482C0751.5000703@suse.de> References: <18474.49834.442492.313331@mariner.uk.xensource.com> <482BFBBB.6030904@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Xu, Dongxiao" Cc: "Li, Haicheng" , xen-devel@lists.xensource.com, Ian Jackson List-Id: xen-devel@lists.xenproject.org Xu, Dongxiao schrieb: > I just tried your patch, and seems that it doesn't work. > Actually, find_protocol() could not find out the qcow protocol, and for qcow image, that function will always return NULL after C/S 17606. I think this is the root cause why qcow image could not be booted. find_protocol isn't even responsible for finding out that it's qcow. There is a difference between image format and protocol (IIRC, the latter is used in qemu for things like vvfat which maps a host directory to a virtual FAT floppy/harddisk). I suspect the problem arises from the bdrv_file_open call in find_image_format which won't correctly get &bdrv_raw but NULL as driver. And you're right, the patch can't work. I missed that in bdrv_open2 for BDRV_O_FILE drv is ignored and always overwritten. Kevin