From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mh65Y-0004aN-3L for qemu-devel@nongnu.org; Fri, 28 Aug 2009 14:22:16 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mh65T-0004Wa-01 for qemu-devel@nongnu.org; Fri, 28 Aug 2009 14:22:15 -0400 Received: from [199.232.76.173] (port=51611 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mh65S-0004WR-PE for qemu-devel@nongnu.org; Fri, 28 Aug 2009 14:22:10 -0400 Received: from mail-ew0-f223.google.com ([209.85.219.223]:43660) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mh65S-00022E-Cy for qemu-devel@nongnu.org; Fri, 28 Aug 2009 14:22:10 -0400 Received: by ewy23 with SMTP id 23so2658570ewy.8 for ; Fri, 28 Aug 2009 11:22:08 -0700 (PDT) From: Bique Alexandre Subject: Re: [Qemu-devel] [PATCH 0/7] ATAPI CDROM passthrough v5 Date: Fri, 28 Aug 2009 20:21:45 +0000 References: <19074.63829.151234.423348@mariner.uk.xensource.com> In-Reply-To: <19074.63829.151234.423348@mariner.uk.xensource.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200908282021.45227.bique.alexandre@gmail.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Ian Jackson On Wednesday 12 August 2009 17:18:13 Ian Jackson wrote: > I've picked up Alex's patch series for this. Changes since v4: > * rebased to current tip as of approximately yesterday > * passthrough of firmware update is enabled by default > * fixed some build issues > > Anthony Liguori wrote: > > This series breaks the cris-softmmu build. > > I think I've fixed it up. It builds for me, anyway. If it now > doesn't build do please tell me the error message and I'l fix it. > > > Also, I think Paul and I both requested that fw upgrade not be > > disabled by default. > > As previously discussed I think this is a mistake, but it's a decision > for qemu upstream to make so I have changed this. > > > I would also suggest that you only expose this as an option > > through qdev properties instead of a new command line option as it > > should be controllable on a per-device basis. > > The reason to disable it is not to prevent the guest breaking the > hardware. It is to prevent the guest escaping the containment > entirely, which it can probably do if firmware updates are allowed. > This seems to me to be a general property of the guest, rather than of > the device. So I think disabling it in one place is better. > > Patches follow. Hi Ian, Are you going to continue to work on this patch queue or do you want me to finish the job ? Thanks a lot. -- Alexandre Bique