Re: [Qemu-devel] [PATCH] block: unify blocksize types

[Kevin Wolf]

Am 09.02.2018 um 10:44 hat Piotr Sarna geschrieben:
> On 09.02.2018 03:19, Fam Zheng wrote:
> > On Thu, 02/08 14:28, Piotr Sarna wrote:
> > > BlockSizes structure used in block size probing has uint32_t types
> > > for logical and physical sizes. These fields are wrongfully assigned
> > > to uint16_t in BlockConf, which results, among other errors,
> > > in assigning 0 instead of 65536 (which will be the case in at least
> > > future LizardFS block device driver among other things).
> > > > This commit makes BlockConf's physical_block_size and 
> > > > logical_block_size > fields uint32_t to avoid inconsistencies.
> > > Signed-off-by: Piotr Sarna <address@hidden>
> > > ---
> > >   include/hw/block/block.h     | 4 ++--
> > >   include/hw/qdev-properties.h | 2 +-
> > >   2 files changed, 3 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/include/hw/block/block.h b/include/hw/block/block.h
> > > index 64b9298..c9e6e27 100644
> > > --- a/include/hw/block/block.h
> > > +++ b/include/hw/block/block.h
> > > @@ -17,8 +17,8 @@
> > >   typedef struct BlockConf {
> > >       BlockBackend *blk;
> > > -    uint16_t physical_block_size;
> > > -    uint16_t logical_block_size;
> > > +    uint32_t physical_block_size;
> > > +    uint32_t logical_block_size;
> > >       uint16_t min_io_size;
> > >       uint32_t opt_io_size;
> > >       int32_t bootindex;
> > > diff --git a/include/hw/qdev-properties.h b/include/hw/qdev-properties.h
> > > index 1d61a35..c68d7bf 100644
> > > --- a/include/hw/qdev-properties.h
> > > +++ b/include/hw/qdev-properties.h
> > > @@ -210,7 +210,7 @@ extern const PropertyInfo qdev_prop_off_auto_pcibar;
> > >   #define DEFINE_PROP_BIOS_CHS_TRANS(_n, _s, _f, _d) \
> > >       DEFINE_PROP_SIGNED(_n, _s, _f, _d, qdev_prop_bios_chs_trans, int)
> > >   #define DEFINE_PROP_BLOCKSIZE(_n, _s, _f) \
> > > -    DEFINE_PROP_UNSIGNED(_n, _s, _f, 0, qdev_prop_blocksize, uint16_t)
> > > +    DEFINE_PROP_UNSIGNED(_n, _s, _f, 0, qdev_prop_blocksize, uint32_t)
> > >   #define DEFINE_PROP_PCI_HOST_DEVADDR(_n, _s, _f) \
> > >       DEFINE_PROP(_n, _s, _f, qdev_prop_pci_host_devaddr, 
> > > PCIHostDeviceAddress)
> > >   #define DEFINE_PROP_MEMORY_REGION(_n, _s, _f)             \
> > Do you need to update qdev_prop_blocksize and set_blocksize as well?
> > 
> >      const PropertyInfo qdev_prop_blocksize = {
> >          .name  = "uint16",
> >          .description = "A power of two between 512 and 32768",
> >          .get   = get_uint16,
> >          .set   = set_blocksize,
> >          .set_default_value = set_default_value_uint,
> >      };
> > 
> > Fam
> Yes, I do, thanks - I'll prepare patch v2 today. Also, I haven't found any
> hidden dependencies on blocksize being <= 32768, so I assume changing the
> new max value to 2^31 is safe. Could somebody more familiar with qemu code
> confirm(or invalidate) my assumption?

The IDE code has the following line in the emulation of the IDENTIFY
DEVICE command:

    put_le16(p + 106, 0x6000 | get_physical_block_exp(&dev->conf));

That is, the result of get_physical_block_exp() is just blindly ORed to
the word. The IDE spec says that bits 0-3 contain the exponent. Four
bits mean a maximum of 15 (and 2^15 = 32768). After that, we don't
actually expose a larger block size, but start modifying reserved bits.

I haven't checked other device models, but I wouldn't rule out that they
make similar assumptions.

Kevin