All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Denis Lunev <den@virtuozzo.com>
Cc: "fam@euphon.net" <fam@euphon.net>,
	"kwolf@redhat.com" <kwolf@redhat.com>,
	"ehabkost@redhat.com" <ehabkost@redhat.com>,
	"qemu-block@nongnu.org" <qemu-block@nongnu.org>,
	"stefanha@redhat.com" <stefanha@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"mreitz@redhat.com" <mreitz@redhat.com>,
	Denis Plotnikov <dplotnikov@virtuozzo.com>
Subject: Re: [PATCH v1 2/4] virtio: make seg_max virtqueue size dependent
Date: Wed, 6 Nov 2019 06:54:12 -0500	[thread overview]
Message-ID: <20191106065142-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <c32d94d1-a216-dd9e-e0cf-dee2730169e4@virtuozzo.com>

On Wed, Nov 06, 2019 at 10:07:02AM +0000, Denis Lunev wrote:
> On 11/5/19 9:51 PM, Michael S. Tsirkin wrote:
> > On Tue, Nov 05, 2019 at 07:11:03PM +0300, Denis Plotnikov wrote:
> >> seg_max has a restriction to be less or equal to virtqueue size
> >> according to Virtio 1.0 specification
> >>
> >> Although seg_max can't be set directly, it's worth to express this
> >> dependancy directly in the code for sanity purpose.
> >>
> >> Signed-off-by: Denis Plotnikov <dplotnikov@virtuozzo.com>
> > This is guest visible so needs to be machine type dependent, right?
> 
> we have discussed this verbally with Stefan and think that
> there is no need to add that to the machine type as:
> 
> - original default was 126, which matches 128 as queue
>   length in old machine types
> - queue length > 128 is not observed in the field as
>   SeaBios has quirk that asserts

Well that's just the SeaBios virtio driver. Not everyone's using that to
drive their devices.

> - if queue length will be set to something < 128 - linux
>   guest will crash

Again that's just one guest driver. Not everyone is using that either.


> If we really need to preserve original __buggy__ behavior -
> we can add boolean property, pls let us know.
> 
> Den

Looks like some drivers are buggy but I'm not sure it's
the same as saying the behavior is buggy.
So yes, I'd say it's preferable to be compatible.


> >> ---
> >>  hw/block/virtio-blk.c | 2 +-
> >>  hw/scsi/virtio-scsi.c | 2 +-
> >>  2 files changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
> >> index 06e57a4d39..21530304cf 100644
> >> --- a/hw/block/virtio-blk.c
> >> +++ b/hw/block/virtio-blk.c
> >> @@ -903,7 +903,7 @@ static void virtio_blk_update_config(VirtIODevice *vdev, uint8_t *config)
> >>      blk_get_geometry(s->blk, &capacity);
> >>      memset(&blkcfg, 0, sizeof(blkcfg));
> >>      virtio_stq_p(vdev, &blkcfg.capacity, capacity);
> >> -    virtio_stl_p(vdev, &blkcfg.seg_max, 128 - 2);
> >> +    virtio_stl_p(vdev, &blkcfg.seg_max, s->conf.queue_size - 2);
> >>      virtio_stw_p(vdev, &blkcfg.geometry.cylinders, conf->cyls);
> >>      virtio_stl_p(vdev, &blkcfg.blk_size, blk_size);
> >>      virtio_stw_p(vdev, &blkcfg.min_io_size, conf->min_io_size / blk_size);
> >> diff --git a/hw/scsi/virtio-scsi.c b/hw/scsi/virtio-scsi.c
> >> index 839f120256..f7e5533cd5 100644
> >> --- a/hw/scsi/virtio-scsi.c
> >> +++ b/hw/scsi/virtio-scsi.c
> >> @@ -650,7 +650,7 @@ static void virtio_scsi_get_config(VirtIODevice *vdev,
> >>      VirtIOSCSICommon *s = VIRTIO_SCSI_COMMON(vdev);
> >>  
> >>      virtio_stl_p(vdev, &scsiconf->num_queues, s->conf.num_queues);
> >> -    virtio_stl_p(vdev, &scsiconf->seg_max, 128 - 2);
> >> +    virtio_stl_p(vdev, &scsiconf->seg_max, s->conf.virtqueue_size - 2);
> >>      virtio_stl_p(vdev, &scsiconf->max_sectors, s->conf.max_sectors);
> >>      virtio_stl_p(vdev, &scsiconf->cmd_per_lun, s->conf.cmd_per_lun);
> >>      virtio_stl_p(vdev, &scsiconf->event_info_size, sizeof(VirtIOSCSIEvent));
> >> -- 
> >> 2.17.0
> 


  reply	other threads:[~2019-11-06 11:55 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-05 16:11 [PATCH v1 0/4] virtio: fix IO request length in virtio SCSI/block Denis Plotnikov
2019-11-05 16:11 ` [PATCH v1 1/4] virtio: protect non-modern devices from too big virtqueue size setting Denis Plotnikov
2019-11-05 20:56   ` Michael S. Tsirkin
2019-11-06  7:46     ` Denis Plotnikov
2019-11-06  9:01       ` Stefan Hajnoczi
2019-11-06  9:19       ` Stefan Hajnoczi
2019-11-06 11:33       ` Michael S. Tsirkin
2019-11-06  9:18     ` Stefan Hajnoczi
2019-11-06 11:51       ` Michael S. Tsirkin
2019-11-05 16:11 ` [PATCH v1 2/4] virtio: make seg_max virtqueue size dependent Denis Plotnikov
2019-11-05 20:51   ` Michael S. Tsirkin
2019-11-06 10:07     ` Denis Lunev
2019-11-06 11:54       ` Michael S. Tsirkin [this message]
2019-11-08  7:43         ` Denis Plotnikov
2019-11-08  9:52           ` Michael S. Tsirkin
2019-11-05 16:11 ` [PATCH v1 3/4] virtio: increase virtuqueue sizes in new machine types Denis Plotnikov
2019-11-05 20:52   ` Michael S. Tsirkin
2019-11-05 16:11 ` [PATCH v1 4/4] iotests: add test for virtio-scsi and virtio-blk machine type settings Denis Plotnikov
2019-11-06  9:24   ` Stefan Hajnoczi
2019-11-06 10:04     ` Max Reitz
2019-11-06 19:26       ` Eduardo Habkost
2019-11-07 16:30         ` Cleber Rosa
2019-11-08  7:08           ` Denis Plotnikov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191106065142-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=den@virtuozzo.com \
    --cc=dplotnikov@virtuozzo.com \
    --cc=ehabkost@redhat.com \
    --cc=fam@euphon.net \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.