From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40490) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YsSLx-00071w-Sc for qemu-devel@nongnu.org; Wed, 13 May 2015 04:49:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YsSLt-0001CH-IH for qemu-devel@nongnu.org; Wed, 13 May 2015 04:49:21 -0400 Date: Wed, 13 May 2015 10:16:57 +0200 From: "Michael S. Tsirkin" Message-ID: <20150513101234-mutt-send-email-mst@redhat.com> References: <1429770109-23873-1-git-send-email-jasowang@redhat.com> <1429770109-23873-16-git-send-email-jasowang@redhat.com> <20150427130035-mutt-send-email-mst@redhat.com> <1430190730.9163.1@smtp.corp.redhat.com> <20150428091541-mutt-send-email-mst@redhat.com> <555301A7.1000102@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <555301A7.1000102@redhat.com> Subject: Re: [Qemu-devel] [PATCH V7 15/16] virtio-pci: increase the maximum number of virtqueues to 513 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jason Wang Cc: Paolo Bonzini , Alexander Graf , qemu-ppc@nongnu.org, qemu-devel@nongnu.org, Richard Henderson 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 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