From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:59013) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q9SfO-0003qb-2m for qemu-devel@nongnu.org; Mon, 11 Apr 2011 21:45:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q9Lcw-0006q7-AG for qemu-devel@nongnu.org; Mon, 11 Apr 2011 14:14:19 -0400 Received: from verein.lst.de ([213.95.11.211]:54590 helo=newverein.lst.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q9Lcw-0006q2-2y for qemu-devel@nongnu.org; Mon, 11 Apr 2011 14:14:18 -0400 Date: Mon, 11 Apr 2011 20:14:17 +0200 From: Christoph Hellwig Message-ID: <20110411181417.GC8877@lst.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] Question about total_sectors in block/vpc.c List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Kevin Wolf , Christoph Hellwig , Lyu Mitnick , qemu-devel@nongnu.org On Sat, Apr 09, 2011 at 09:05:41PM +0100, Stefan Hajnoczi wrote: > On Sat, Apr 9, 2011 at 5:51 PM, Lyu Mitnick wrote: > > Hell all, > > I have take a look of block/vpc.c and meet a question in vpc_create().?At > > the line > > 550, the code is: > > total_sectors = options->value.n / 512; > > I am wondering whether the size between?total_sectors * 512 > > and?options->value.n > > would be discard. > > Yes, it rounds down. This reflects the assumption that a block device > cannot be addressed below 512 byte sectors. Because of this block > devices size must be a multiple of 512 bytes. > > I think a reasonable protection would be to have block.c:bdrv_create() > fail if size is not a multiple of BDRV_SECTOR_SIZE. This way other > image formats are protected too. There are block devices that aren't alignment to 512 bytes. Audio CDROMs are the most prominent example, or AS/400 disks. I don't think these matter for emulation, but if we'd ever implement DIF/DIX emulation inside qemu we'd have to store the protection information somewhere. It still wouldn't work with existing disk format, so adding the above check into the formats bdrv_create routines sounds fine, but doing it in the core block code might not be an overly smart idea.