From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NmpMB-0004eJ-O4 for qemu-devel@nongnu.org; Wed, 03 Mar 2010 09:15:23 -0500 Received: from [199.232.76.173] (port=56581 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NmpMB-0004eA-Ex for qemu-devel@nongnu.org; Wed, 03 Mar 2010 09:15:23 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NmpM9-0004Cm-Va for qemu-devel@nongnu.org; Wed, 03 Mar 2010 09:15:23 -0500 Received: from qw-out-1920.google.com ([74.125.92.145]:53456) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NmpM9-0004Ce-OJ for qemu-devel@nongnu.org; Wed, 03 Mar 2010 09:15:21 -0500 Received: by qw-out-1920.google.com with SMTP id 5so270502qwf.4 for ; Wed, 03 Mar 2010 06:15:20 -0800 (PST) Message-ID: <4B8E6EF3.5020605@codemonkey.ws> Date: Wed, 03 Mar 2010 08:15:15 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCHv2 10/12] tap: add vhost/vhostfd options References: <20100302161247.GA25371@amt.cnet> <4B8D4350.6040506@codemonkey.ws> <201003022241.27803.paul@codesourcery.com> In-Reply-To: <201003022241.27803.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: quintela@redhat.com, Marcelo Tosatti , qemu-devel@nongnu.org, "Michael S. Tsirkin" , kraxel@redhat.com, amit.shah@redhat.com On 03/02/2010 04:41 PM, Paul Brook wrote: >> The new function I'm proposing has the following semantics: >> >> - it always returns a persistent mapping >> - it never bounces >> - it will only fail if the mapping isn't ram >> > So you're assuming that virtio rings are in ram that is not hot-pluggable As long as the device is active, yes. This would be true with bare metal. Memory allocated for the virtio-pci ring is not reclaimable and you have to be able to reclaim the entire area of ram covered by a DIMM to hot unplug it. A user would have to unload the virtio-pci module to release the memory before hot unplug would be an option. NB, almost nothing supports memory hot remove because it's very difficult for an OS to actually do. > or > remapable, Yes, it cannot be remapable. > and the whole region is contiguous? > Yes, it has to be contiguous. > That sounds like it's likely to come back and bite you. The guest has no idea > which areas of ram happen to be contiguous on the host. > Practically speaking, with target-i386 anything that is contiguous in guest physical memory is contiguous in the host address space provided it's ram. These assumptions are important. I have a local branch (that I'll send out soon) that implements a ram API and converted virtio to make use of it. I'm seeing a ~50% increase in tx throughput. If you try to support discontiguous, remapable ram for the virtio ring, then you have to do an l1_phys_map lookup for every single ring variable access followed by a memory copy. This ends up costing an awful lot practically speaking. The changes should work equally well with syborg although I don't think I can do meaningful performance testing there (I don't actually have a syborg image to test). Regards, Anthony Liguori > Paul >