qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Question about total_sectors in block/vpc.c


From: Lyu Mitnick
Subject: Re: [Qemu-devel] Question about total_sectors in block/vpc.c
Date: Tue, 12 Apr 2011 06:40:56 +0800

Hello Christoph, Stefan

I am wondering whether the problem occurred that value of BDRV_SECTOR_SIZE is 
a macro constant (defined at block.h). This problem could be fixed if we use variable
instead of macro to implement BDRV_SECTOR_SIZE. Each block device may reassign
the value if needed. Is it right??

Thanks a lot

2011/4/12 Christoph Hellwig <address@hidden>
On Sat, Apr 09, 2011 at 09:05:41PM +0100, Stefan Hajnoczi wrote:
> On Sat, Apr 9, 2011 at 5:51 PM, Lyu Mitnick <address@hidden> 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.


Mitnick

reply via email to

[Prev in Thread] Current Thread [Next in Thread]