[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.

Best regards,
-- Dongxiao

-----Original Message-----
From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Li, Haicheng
Sent: 2008年5月15日 15:40
To: Ian Jackson
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Xen-devel] VMX status report. Xen: #17630 & Xen0: #540 -- blocked

Ian Jackson wrote:
> Li, Haicheng writes ("[Xen-devel] VMX status report. Xen: #17630 &
> Xen0: #540 -- blocked"): 
>> Today's nightly testing is still blocked for both PAE and 32E, c/s
>> 17606 introduced this issue.
> ...
>> New issue:
>> [Bug 1250] HVM guest can not boot with Qcow image
>> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1250
> 
> I'm afraid you are using the wrong syntax.
> file:... is for raw images.
> 
> Prior to changeset 17606, the emulated IDE controller would, if the
> specified file looked like a qcow image, interpret it that way - but
> the PV presentation of the same device (via blktap) to the same guest
> would treat it as a raw image.  This (and other related scenarios)
> allows a malicious guest to read any file on the host (including for
> example the host's underlying disk devices), because the qcow image
> format contains the (host) pathname of the backing file.
> 
> In changeset 17606 the behaviour was changed so that file:... always
> treats the specified file as a raw disk image.  To use a file
> containing a qcow image, you have to say tap:qcow:...
> 
> This was discussed here on the list quite recently; feel free to
> comment further if you think the fix is the wrong one.
> 
> Ian.

Ian, 

even with syntax like "tap:qcow:" as following, it still doesn't work,
guest bios shows the size of this disk is 0 MB. 
        disk = [
'tap:qcow:/mnt/sda5/hli22/xen-test/manual-test/xpsp2_smp_ia32.qcow,hda,w
']



Qemu log is pasted here:

domid: 5
qemu: the number of cpus is 4
Strip off blktap sub-type prefix to
/mnt/sda5/hli22/xen-test/manual-test/xpsp2_smp_ia32.qcow (drv 'qcow')
qemu: could not open vbd '/local/domain/5/device/vbd/768/phantom_vbd' or
hard disk image
'/mnt/sda5/hli22/xen-test/manual-test/xpsp2_smp_ia32.qcow' (drv 'qcow')
Watching /local/domain/0/device-model/5/logdirty/next-active
Watching /local/domain/0/device-model/5/command
char device redirected to /dev/pts/5
qemu_map_cache_init nr_buckets = 4000 size 196608
shared page at pfn 3fffe
buffered io page at pfn 3fffc
Time offset set 0
Register xen platform.
Done register platform.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0

-- haicheng

_______________________________________________
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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.