From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LLvku-0008FD-Kn for qemu-devel@nongnu.org; Sun, 11 Jan 2009 03:33:12 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LLvku-0008ES-0R for qemu-devel@nongnu.org; Sun, 11 Jan 2009 03:33:12 -0500 Received: from [199.232.76.173] (port=38264 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LLvkt-0008DO-U3 for qemu-devel@nongnu.org; Sun, 11 Jan 2009 03:33:11 -0500 Received: from mx2.redhat.com ([66.187.237.31]:33484) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LLvks-0004cH-Qq for qemu-devel@nongnu.org; Sun, 11 Jan 2009 03:33:11 -0500 Message-ID: <4969AE85.60200@redhat.com> Date: Sun, 11 Jan 2009 10:32:05 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0/5][RFC] virtio-net: MAC filtering References: <1231349852.7109.79.camel@lappy> <200901091127.32987.paul@codesourcery.com> <4967A84E.9080908@codemonkey.ws> In-Reply-To: <4967A84E.9080908@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Mark McLoughlin , Paul Brook , Alex Williamson , kvm Anthony Liguori wrote: > Paul Brook wrote: >>> A concern here is the growing size of the virtio-net I/O port space >>> config. This series brings it up to 256 bytes with PCI resource >>> rounding. The VLAN filter bitmap would increase that by another 512 >>> bytes, making it 1kB and limiting us to something less than 64 such >>> devices per guest. Is anyone worried? Should filter tables live in >>> MMIO space for virtio devices? I'll send out the guest side patches >>> for >>> virtio-net in a separate thread. Thanks, >>> >> >> This is one reason why IO ports are a reallybad idea. Use memory >> mapped register spaces like any other sane system and you won't have >> a problem. >> > > IO ports are much faster for notification than MMIO in KVM which is > why the space is currently IO ports. It was never meant to hold very > large amounts of data. We can, btw, fix the mmio speed issue by adding two new hypercalls: mmio_read() and mmio_write(). We could then hook to use the hypercalls instead of reading directly. This would speed up most emulated devices, not just virtio. I don't know whether Windows drivers access mmio using helpers or directly. -- error compiling committee.c: too many arguments to function