From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NmDZ3-0006D5-72 for qemu-devel@nongnu.org; Mon, 01 Mar 2010 16:54:09 -0500 Received: from [199.232.76.173] (port=36574 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NmDZ2-0006BB-EG for qemu-devel@nongnu.org; Mon, 01 Mar 2010 16:54:08 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NmDZ0-0002WT-DV for qemu-devel@nongnu.org; Mon, 01 Mar 2010 16:54:08 -0500 Received: from mail-yw0-f197.google.com ([209.85.211.197]:36680) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NmDZ0-0002WD-0H for qemu-devel@nongnu.org; Mon, 01 Mar 2010 16:54:06 -0500 Received: by ywh35 with SMTP id 35so1418201ywh.4 for ; Mon, 01 Mar 2010 13:54:04 -0800 (PST) Message-ID: <4B8C3778.8000108@codemonkey.ws> Date: Mon, 01 Mar 2010 15:54:00 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <20100228171920.GE28921@redhat.com> <4B8AD8D4.7070002@codemonkey.ws> <201002282239.22041.paul@codesourcery.com> <20100301192732.GA3239@redhat.com> In-Reply-To: <20100301192732.GA3239@redhat.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: "Michael S. Tsirkin" Cc: amit.shah@redhat.com, quintela@redhat.com, kraxel@redhat.com, Paul Brook , qemu-devel@nongnu.org On 03/01/2010 01:27 PM, Michael S. Tsirkin wrote: > On Sun, Feb 28, 2010 at 10:39:21PM +0000, Paul Brook wrote: > >>> 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. >> > It already doesn't. virtio passes physical memory addresses > to device instead of DMA addresses. > That's technically a bug. >> Apart from anything else, failure to do this breaks nested >> virtualization. >> > Assigning PV device in nested virtualization? It could work, but not > sure what the point would be. > It misses the point really. vhost-net is not a device model and it shouldn't have to care about things like PCI IOMMU. If we did ever implement a PCI IOMMU, then we would perform ring translation (or not use vhost-net). Regards, Anthony Liguori >> 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 >>