RE: [Xen-devel] VMX status report. Xen: #17630 & Xen0: #540 -- blocked

["Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx>]

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. 

-- Dongxiao

-----Original Message-----
From: Kevin Wolf [mailto:kwolf@xxxxxxx] 
Sent: 2008年5月15日 17:01
To: Xu, Dongxiao
Cc: Li, Haicheng; Ian Jackson; xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] VMX status report. Xen: #17630 & Xen0: #540 -- blocked

Xu, Dongxiao schrieb:
> I just looked into this issue, and I was confused by the recursive function 
> call while opening a qcow file 
> (bdrv_open2->qcow_open->bdrv_file_open->bdrv_open2->...).
>     Remove the modification in block.c in C/S 17606 could work around this 
> issue, but it is not a good way.

I think the right solution is to remove bdrv_open altogether and force
the callers to provide the driver as parameter to bdrv_open2. For qcow
itself the following patch could be enough (compiles, but completely
untested).

But then, I don't even understand why find_protocol has been crippled -
isn't this one harmless and we should rather have removed the actual
guessing in find_image_format?

Kevin


diff -r 0beee5c839ea tools/ioemu/block.c
--- a/tools/ioemu/block.c       Tue May 13 12:17:08 2008
+++ b/tools/ioemu/block.c       Thu May 15 11:51:15 2008
@@ -329,7 +329,7 @@
     bs = bdrv_new("");
     if (!bs)
         return -ENOMEM;
-    ret = bdrv_open2(bs, filename, flags | BDRV_O_FILE, NULL);
+    ret = bdrv_open2(bs, filename, flags | BDRV_O_FILE, &bdrv_raw);
     if (ret < 0) {
         bdrv_delete(bs);
         return ret;

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