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
|
Home