From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NlrnL-0006Z5-3n for qemu-devel@nongnu.org; Sun, 28 Feb 2010 17:39:27 -0500 Received: from [199.232.76.173] (port=53185 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NlrnK-0006YU-KA for qemu-devel@nongnu.org; Sun, 28 Feb 2010 17:39:26 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NlrnJ-0005KY-Sn for qemu-devel@nongnu.org; Sun, 28 Feb 2010 17:39:26 -0500 Received: from mx20.gnu.org ([199.232.41.8]:4430) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NlrnJ-0005KS-ME for qemu-devel@nongnu.org; Sun, 28 Feb 2010 17:39:25 -0500 Received: from mail.codesourcery.com ([38.113.113.100]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NlrnI-0000Do-Vf for qemu-devel@nongnu.org; Sun, 28 Feb 2010 17:39:25 -0500 From: Paul Brook Date: Sun, 28 Feb 2010 22:39:21 +0000 References: <20100228171920.GE28921@redhat.com> <4B8AD8D4.7070002@codemonkey.ws> In-Reply-To: <4B8AD8D4.7070002@codemonkey.ws> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201002282239.22041.paul@codesourcery.com> 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: Anthony Liguori Cc: amit.shah@redhat.com, quintela@redhat.com, kraxel@redhat.com, qemu-devel@nongnu.org, "Michael S. Tsirkin" > I'm sympathetic to your arguments though. As qemu is today, the above > is definitely the right thing to do. But ram is always ram and ram > always has a fixed (albeit non-linear) mapping within a guest. 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. 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. I'm also of the opinion that virtio devices should behave the same as any other device. i.e. if you put a virtio-net-pci device on a PCI bus behind an IOMMU, then it should see the same address space as any other PCI device in that location. Apart from anything else, failure to do this breaks nested virtualization. While qemu doesn't currently implement an IOMMU, the DMA interfaces have been designed to allow it. > void cpu_ram_add(target_phys_addr_t start, ram_addr_t size); We need to support aliased memory regions. For example the ARM RealView boards expose the first 256M RAM at both address 0x0 and 0x70000000. It's also common for systems to create aliases by ignoring certain address bits. e.g. each sim slot is allocated a fixed 256M region. Populating that slot with a 128M stick will cause the contents to be aliased in both the top and bottom halves of that region. Paul