All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	patches@linaro.org, Alexander Graf <agraf@suse.de>,
	qemu-devel@nongnu.org, kvmarm@lists.cs.columbia.edu,
	David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [Qemu-devel] [PATCH v2 3/8] virtio: Add support for guest setting of queue size
Date: Thu, 25 Jul 2013 12:03:17 +0300	[thread overview]
Message-ID: <20130725090317.GA26648@redhat.com> (raw)
In-Reply-To: <CAFEAcA8TEdkGpCXCTCyVkN7TiaWA9WGA2FM3OtQyQsXAkJF-_A@mail.gmail.com>

On Thu, Jul 25, 2013 at 09:50:21AM +0100, Peter Maydell wrote:
> On 25 July 2013 06:38, Michael S. Tsirkin <mst@redhat.com> wrote:
> > On Fri, Jul 12, 2013 at 09:36:57PM +0100, Peter Maydell wrote:
> >> The MMIO virtio transport spec allows the guest to tell the host how
> >> large the queue size is. Add virtio_queue_set_num() function which
> >> implements this in the QEMU common virtio support code.
> >>
> >> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> >
> > Probably needs to go back to default value on reset?
> 
> Tricky, since the default value is "whatever was passed to
> virtio_add_queue()" and we don't save that anywhere.
>
> For virtio-mmio it is a guest bug to fail to write to the
> QueueNum register, so the current behaviour is not out of
> specification (and not harmful either AFAICT).

Best not to leak info across reboots.
Also if guest sets num = 0 it will cause all kind of
harm, no?

> I guess we could add a vring.defaultnum, which would be
> set by virtio_add_queue/virtio_del_queue, and have reset
> copy defaultnum into num. No migration needed for defaultnum
> because it's always the same for a particular qemu config.

Sounds good.

> > Need to migrate?
> 
> It's already migrated (though I'm not entirely sure why).
> 
> > Is the default value a max legal value? If yes probably a good
> > idea to enforce this.
> 
> virtio_add_queue() already enforces this -- it will abort()
> if you try to set up a queue with a default size greater
> than VIRTQUEUE_MAX_SIZE.

No I mean does default value have some meaning?
Does host supply a hint of a max value
besides VIRTQUEUE_MAX_SIZE?

> 
> thanks
> -- PMM

  reply	other threads:[~2013-07-25  9:02 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-12 20:36 [Qemu-devel] [PATCH v2 0/8] Add virtio-mmio and use it in vexpress Peter Maydell
2013-07-12 20:36 ` [Qemu-devel] [PATCH v2 1/8] device_tree: Add qemu_devtree_setprop_sized_cells() utility functions Peter Maydell
2013-07-15  0:30   ` Peter Crosthwaite
2013-07-15  9:44     ` Peter Maydell
2013-07-15 10:24       ` Peter Crosthwaite
2013-07-15 10:39         ` Peter Maydell
2013-07-12 20:36 ` [Qemu-devel] [PATCH v2 2/8] arm/boot: Use qemu_devtree_setprop_sized_cells() Peter Maydell
2013-07-12 20:36 ` [Qemu-devel] [PATCH v2 3/8] virtio: Add support for guest setting of queue size Peter Maydell
2013-07-25  5:38   ` Michael S. Tsirkin
2013-07-25  8:50     ` Peter Maydell
2013-07-25  9:03       ` Michael S. Tsirkin [this message]
2013-07-25  9:34         ` Peter Maydell
2013-07-25 12:30         ` Peter Maydell
2013-07-25 12:38           ` Michael S. Tsirkin
2013-07-12 20:36 ` [Qemu-devel] [PATCH v2 4/8] virtio: Support transports which can specify the vring alignment Peter Maydell
2013-07-12 20:36 ` [Qemu-devel] [PATCH v2 5/8] virtio: Implement MMIO based virtio transport Peter Maydell
2013-07-12 20:37 ` [Qemu-devel] [PATCH v2 6/8] arm/boot: Allow boards to modify the FDT blob Peter Maydell
2013-07-12 20:37 ` [Qemu-devel] [PATCH v2 7/8] vexpress: Make VEDBoardInfo extend arm_boot_info Peter Maydell
2013-07-14 11:36   ` Peter Crosthwaite
2013-07-14 12:21     ` Peter Maydell
2013-07-12 20:37 ` [Qemu-devel] [PATCH v2 8/8] vexpress: Add virtio-mmio transports Peter Maydell
2013-07-15  0:17   ` Peter Crosthwaite
2013-07-15  9:40     ` Peter Maydell

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=20130725090317.GA26648@redhat.com \
    --to=mst@redhat.com \
    --cc=agraf@suse.de \
    --cc=aliguori@us.ibm.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=patches@linaro.org \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /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.