From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NmTGL-0003ZC-Bb for qemu-devel@nongnu.org; Tue, 02 Mar 2010 09:39:53 -0500 Received: from [199.232.76.173] (port=46071 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NmTGK-0003Yq-Ss for qemu-devel@nongnu.org; Tue, 02 Mar 2010 09:39:52 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NmTGA-00033P-Q6 for qemu-devel@nongnu.org; Tue, 02 Mar 2010 09:39:51 -0500 Received: from mail-yx0-f204.google.com ([209.85.210.204]:61903) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NmTG8-00033B-MZ for qemu-devel@nongnu.org; Tue, 02 Mar 2010 09:39:41 -0500 Received: by yxe42 with SMTP id 42so124236yxe.4 for ; Tue, 02 Mar 2010 06:39:39 -0800 (PST) Message-ID: <4B8D2320.8000608@codemonkey.ws> Date: Tue, 02 Mar 2010 08:39:28 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <201002282239.22041.paul@codesourcery.com> <4B8D1B9B.7040906@codemonkey.ws> <201003021433.51987.paul@codesourcery.com> In-Reply-To: <201003021433.51987.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCHv2 10/12] tap: add vhost/vhostfd options List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: amit.shah@redhat.com, quintela@redhat.com, kraxel@redhat.com, qemu-devel@nongnu.org, "Michael S. Tsirkin" On 03/02/2010 08:33 AM, Paul Brook wrote: >>> I think this assumption is unsafe. There are machines where RAM mappings >>> can change. It's not uncommon for a chip select (i.e. physical memory >>> address region) to be switchable to several different sources, one of >>> which may be RAM. I'm pretty sure this functionality is present (but not >>> actually implemented) on some of the current qemu targets. >>> >> But I presume this is more about switching a dim to point at a different >> region in memory. It's a rare event similar to memory hot plug. >> > Approximately that, yes. One use is to start with ROM at address zero, then > switch to RAM once you've initialised the DRAM controller (using a small > internal SRAM as a trampoline). > > >> Either way, if there are platforms where we don't treat ram with the new >> ram api, that's okay. >> >> >>> I agree that changing RAM mappings under an active DMA is a fairly >>> suspect thing to do. However I think we need to avoid cache mappings >>> between separate DMA transactions i.e. when the guest can know that no >>> DMA will occur, and safely remap things. >>> >> One thing I like about having a new ram api is it gives us a stronger >> interface than what we have today. Today, we don't have a strong >> guarantee that mappings won't be changed during a DMA transaction. >> >> With a new api, cpu_physical_memory_map() changes semantics. It only >> returns pointers for static ram mappings. Everything else is bounced >> which guarantees that an address can't change during DMA. >> > Doesn't this mean that only the initial RAM is directly DMA-able? > > While memory hotplug(and unplug) may be an infrequent event, having the > majority of ram be hotplug seems much more likely. Hotplug works fine for direct DMA'ing. map/unmap would maintain a reference count on the registered RAM region and hot unplug would not be allowed until that reference dropped to zero. For something like virtio, it means that the driver has to be unloaded in the guest before you hot unplug the region of memory if it happens to be using that region of memory for the ring storage. The key difference is that these regions are created and destroyed rarely and in such a way that the destruction is visible to the guest. If you compare that to IO memory, we currently flip IO memory's mappings dynamically without the guest really being aware (such as the VGA optimization). An API like this wouldn't work for IO memory today without some serious thinking about how to model this sort of thing. Regards, Anthony Liguori