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] VMX status report. Xen: #17630 & Xen0: #540 -- blocked

To: "Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx>
Subject: RE: [Xen-devel] VMX status report. Xen: #17630 & Xen0: #540 -- blocked
From: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Date: Fri, 16 May 2008 10:14:00 +0100
Cc: "Li, Haicheng" <haicheng.li@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>, Kevin Wolf <kwolf@xxxxxxx>
Delivery-date: Fri, 16 May 2008 02:14:27 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <FF386CB4AE0E4648B0A96060EC00F36CA7230A@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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: <FC1D1B23302A22499C60C967336B2AE002C9AE25@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <18474.49834.442492.313331@xxxxxxxxxxxxxxxxxxxxxxxx> <FC1D1B23302A22499C60C967336B2AE002C9B25F@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <FF386CB4AE0E4648B0A96060EC00F36CA72200@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <482BFBBB.6030904@xxxxxxx> <FF386CB4AE0E4648B0A96060EC00F36CA72230@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <482C0751.5000703@xxxxxxx> <18476.6533.343767.167852@xxxxxxxxxxxxxxxxxxxxxxxx> <FF386CB4AE0E4648B0A96060EC00F36CA7230A@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Xu, Dongxiao writes ("RE: [Xen-devel] VMX status report. Xen: #17630 &
> Xen0: #540 -- blocked"):
>     In your new patch, if find_protocol() function returns NULL,
> then you will let drv = &bdrv_raw, it is just guessing the image to
> be raw, I remember you mentioned it as a security problem. So I
> don't find any difference as the following one, it just reverts the
> change in block.c in C/S 17606.

Yes, I did revert that specific change; it's dealt with by
find_protocol's caller, instead.

I've also tested that  tap:qcow:/path/to/raw/image.iso  does not work.

Ian.

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