From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37966) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YYV7C-0007J7-EB for qemu-devel@nongnu.org; Thu, 19 Mar 2015 03:43:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YYV79-0003mp-72 for qemu-devel@nongnu.org; Thu, 19 Mar 2015 03:43:38 -0400 Date: Thu, 19 Mar 2015 15:42:56 +0800 From: Jason Wang Message-Id: <1426750976.5002.10@smtp.corp.redhat.com> In-Reply-To: <20150319083220-mutt-send-email-mst@redhat.com> References: <1426671309-13645-1-git-send-email-jasowang@redhat.com> <20150318135804-mutt-send-email-mst@redhat.com> <1426742693.5002.5@smtp.corp.redhat.com> <20150319083220-mutt-send-email-mst@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Subject: Re: [Qemu-devel] [PATCH V4 00/19] Support more virtio queues List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Kevin Wolf , cornelia.huck@de.ibm.com, Alexander Graf , qemu-devel@nongnu.org, Keith Busch , Christian Borntraeger , qemu-ppc@nongnu.org, Stefan Hajnoczi , Amit Shah , Paolo Bonzini , Richard Henderson On Thu, Mar 19, 2015 at 3:32 PM, Michael S. Tsirkin wrote: > On Thu, Mar 19, 2015 at 01:24:53PM +0800, Jason Wang wrote: >> >> >> On Wed, Mar 18, 2015 at 8:58 PM, Michael S. Tsirkin >> wrote: >> >On Wed, Mar 18, 2015 at 05:34:50PM +0800, Jason Wang wrote: >> >> We current limit the max virtio queues to 64. This is not >> sufficient >> >> to support multiqueue devices (e.g recent Linux support up to 256 >> >> tap queues). So this series tries to let virtio to support more >> queues. >> >> No much works need to be done except: >> >> - Introducing transport specific queue limitation. >> >> - Let each virtio transport to use specific limit. >> >> - Speedup the MSI-X masking and unmasking through per vector >> queue >> >> list, and increase the maximum MSI-X vectors supported by qemu. >> >> - With the above enhancements, increase the maximum number of >> >> virtqueues supported by PCI from 64 to 513. >> >> - Compat the changes for legacy machine types. >> > >> >What are the compatibility considerations here? >> >> Two considerations: >> 1) To keep msix bar size to 4K for legacy machine types >> 2) Limit the pci queue max to 64 for legacy machine types > > 2 seems not relevant to me. If we don't limit this. Consider migration from 2.4 to 2.3 Before migration write 0 to queue_sel write 100 to queue_sel read queue_sel will get 100 but after migration write 0 to queue_sel write 100 to queue_sel read queue_sel will get 0 The hardware behavior was changed after migration. Another reason is not wasting memory for the extra virtqueues allocated for legacy machine types.