From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [Qemu-devel] [PATCH 0/5][RFC] virtio-net: MAC filtering Date: Sun, 11 Jan 2009 10:32:05 +0200 Message-ID: <4969AE85.60200@redhat.com> References: <1231349852.7109.79.camel@lappy> <200901091127.32987.paul@codesourcery.com> <4967A84E.9080908@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Paul Brook , Mark McLoughlin , Alex Williamson , kvm To: qemu-devel@nongnu.org Return-path: Received: from mx2.redhat.com ([66.187.237.31]:50673 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750821AbZAKIdL (ORCPT ); Sun, 11 Jan 2009 03:33:11 -0500 In-Reply-To: <4967A84E.9080908@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: 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