Re: [Qemu-devel] [PATCH V7 15/16] virtio-pci: increase the maximum number of virtqueues to 513

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, May 13, 2015 at 03:47:51PM +0800, Jason Wang wrote:
> 
> 
> On 04/28/2015 03:17 PM, Michael S. Tsirkin wrote:
> > On Tue, Apr 28, 2015 at 11:12:10AM +0800, Jason Wang wrote:
> >> > 
> >> > 
> >> > On Mon, Apr 27, 2015 at 7:02 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> >>> > >On Thu, Apr 23, 2015 at 02:21:48PM +0800, Jason Wang wrote:
> >>>> > >> This patch increases the maximum number of virtqueues for pci from 64
> >>>> > >> to 513. This will allow booting a virtio-net-pci device with 256 queue
> >>>> > >> pairs on recent Linux host (which supports up to 256 tuntap queue
> >>>> > >>pairs).
> >>>> > >> To keep migration compatibility, 64 was kept for legacy machine
> >>>> > >> types. This is because qemu in fact allows guest to probe the limit of
> >>>> > >> virtqueues through trying to set queue_sel. So for legacy machine
> >>>> > >> type, we should make sure setting queue_sel to more than 63 won't
> >>>> > >> make effect.
> >>> > >
> >>> > >This isn't a documented interface, and no guest that I know of does
> >>> > >this.  Accordingly, I think we should drop everything except the
> >>> > >hw/virtio/virtio-pci.c change.
> >> > 
> >> > We leave a chance for guest to use such undocumented behavior, so
> >> > technically we'd better keep it and it maybe too late for us to fix if we
> >> > find such a guest in the future. And consider keeping this compatibility was
> >> > really not hard, so I suggest to include this.
> > Reminds me of  https://xkcd.com/1172/
> > We don't do this kind of thing.
> 
> Ok, but let's consider for management:
> 
> If we don't do this, consider src has qemu 2.4 and dst has qemu 2.3.
> Then libvirt can create 2.3 machine on src with more than 64 queues.
> What happens if it want to migrate to dst?
> I believe we don't want to
> teach libvirt about the queue limit for each machine type?

The basic requirement for migration is to supply identical
configuration at both sides. If you don't, migration won't
work, and that's expected.

-- 
MST