qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: fam@euphon.net, kwolf@redhat.com, den@virtuozzo.com,
	qemu-block@nongnu.org, qemu-devel@nongnu.org, mreitz@redhat.com,
	Denis Plotnikov <dplotnikov@virtuozzo.com>,
	ehabkost@redhat.com
Subject: Re: [PATCH v1 1/4] virtio: protect non-modern devices from too big virtqueue size setting
Date: Wed, 6 Nov 2019 06:51:25 -0500	[thread overview]
Message-ID: <20191106064157-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20191106091812.GF189998@stefanha-x1.localdomain>

On Wed, Nov 06, 2019 at 10:18:12AM +0100, Stefan Hajnoczi wrote:
> On Tue, Nov 05, 2019 at 03:56:43PM -0500, Michael S. Tsirkin wrote:
> > On Tue, Nov 05, 2019 at 07:11:02PM +0300, Denis Plotnikov wrote:
> > > @@ -47,6 +48,15 @@ static void virtio_scsi_pci_realize(VirtIOPCIProxy *vpci_dev, Error **errp)
> > >      VirtIOSCSICommon *vs = VIRTIO_SCSI_COMMON(vdev);
> > >      DeviceState *proxy = DEVICE(vpci_dev);
> > >      char *bus_name;
> > > +    bool modern = virtio_pci_modern(vpci_dev);
> > > +    uint32_t virtqueue_size = vs->conf.virtqueue_size;
> > > +
> > > +    if (!modern && virtqueue_size > 128) {
> > > +        error_setg(errp,
> > > +                   "too big virtqueue size (%u, max: 128) "
> > > +                   "for non-modern virtio device", virtqueue_size);
> > > +        return;
> > > +    }
> > 
> > why? what is illegal about 256 for legacy?
> 
> I think it was mentioned that this limit is specific to SeaBIOS
> src/hw/virtio-pci.c:vp_find_vq():
> 
>   #define MAX_QUEUE_NUM      (128)
>   ...
>   if (num > MAX_QUEUE_NUM) {
>       dprintf(1, "ERROR: queue size %d > %d\n", num, MAX_QUEUE_NUM);
>       goto fail;
>   }

OK I see. It's worth documenting this (with version of seabios
that has the issue).
And yes virtio_pci_modern will not do the right thing.
This checks whether device has the modern interface, but
an old seabios will not use the modern interface even
if it's there.

You want to start with small queues and then check after features have
been negotiated with firmware, and make them bigger.


But even then I am not so sure we should just block
bigger queues by default. kernel can use bigger queues fine,
and not all disks are necessarily used by seabios.


If you want a user friendly option, we can add a flag that tells
qemu to adjust the size to a known safe value.
Then we'd start small and make it bigger if guest is a modern one.




> I'm not sure there is anything we can do in QEMU.  Either you can let
> SeaBIOS fail, or if you want something more user-friendly, then the
> management tool can implement a check based on the SeaBIOS version and
> the -device virtio-blk-pci,queue-size=SIZE property value.
> 
> Stefan




  reply	other threads:[~2019-11-06 11:52 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 [this message]
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
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=20191106064157-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).