On Thu, Jul 27, 2017 at 12:29:45AM +0000, Liu, Changpeng wrote:
> > > + .fields = (VMStateField[]) {
> > > + VMSTATE_VIRTIO_DEVICE,
> > > + VMSTATE_END_OF_LIST()
> > > + },
> > > +};
> > > +
> > > +static Property vhost_user_blk_properties[] = {
> > > + DEFINE_PROP_CHR("chardev", VHostUserBlk, chardev),
> > > + DEFINE_BLOCK_PROPERTIES(VHostUserBlk, blkcfg),
> >
> > DEFINE_BLOCK_PROPERTIES cannot be used directly because it includes the
> > 'drive' (blkcfg.blk) parameter. The command-line should not allow a
> > drive= parameter.
> >
> > Also, parameters like the discard granularity, optimal I/O size, logical
> > block size, etc can be initialized to sensible defaults by QEMU's block
> > layer when drive= is used. Since you are bypassing QEMU's block layer
> > there is no way for QEMU to set good defaults.
> >
> > Are you relying on the managment tools populating these parameters with
> > the correct values from the vhost-user-blk process? Or did you have
> > some other mechanism in mind?
> Actually for this part and your comments about block resize, I think maybe
> add several
> additional vhost user messages such like:
> VHOST_USER_GET_BLK_CFG/VHOST_USER_SET_BLK_CFG
> makes the code more clear, I'm okay to add such messages.New messages for virtio config space read/write might be useful for other devices besides virtio-blk. It's worth checking how virtio config space is live migrated and how to do that consistently if the vhost-user process is involved. Stefan
signature.asc
Description: PGP signature
