From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NmUjL-0003w6-FB for qemu-devel@nongnu.org; Tue, 02 Mar 2010 11:13:55 -0500 Received: from [199.232.76.173] (port=45325 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NmUjK-0003vy-Rx for qemu-devel@nongnu.org; Tue, 02 Mar 2010 11:13:54 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NmUjJ-0004CS-5w for qemu-devel@nongnu.org; Tue, 02 Mar 2010 11:13:54 -0500 Received: from mx1.redhat.com ([209.132.183.28]:47959) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NmUjI-0004CK-QZ for qemu-devel@nongnu.org; Tue, 02 Mar 2010 11:13:53 -0500 Date: Tue, 2 Mar 2010 13:12:47 -0300 From: Marcelo Tosatti Subject: Re: [Qemu-devel] Re: [PATCHv2 10/12] tap: add vhost/vhostfd options Message-ID: <20100302161247.GA25371@amt.cnet> References: <886ef6ffeb6748f6dc4fe5431f71cb12bb74edc9.1267122331.git.mst@redhat.com> <4B86D3CF.4020601@codemonkey.ws> <20100226145155.GC23359@redhat.com> <4B87E755.9000707@codemonkey.ws> <20100227194418.GB26389@redhat.com> <4B8A94FA.5020000@codemonkey.ws> <20100228171920.GE28921@redhat.com> <4B8AD8D4.7070002@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B8AD8D4.7070002@codemonkey.ws> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: quintela@redhat.com, "Michael S. Tsirkin" , qemu-devel@nongnu.org, kraxel@redhat.com, amit.shah@redhat.com, Paul Brook On Sun, Feb 28, 2010 at 02:57:56PM -0600, Anthony Liguori wrote: > On 02/28/2010 11:19 AM, Michael S. Tsirkin wrote: > >>Both have security implications so I think it's important that they > >>be addressed. Otherwise, I'm pretty happy with how things are. > >Care suggesting some solutions? > > The obvious thing to do would be to use the memory notifier in vhost > to keep track of whenever something remaps the ring's memory region > and if that happens, issue an ioctl to vhost to change the location > of the ring. Also, you would need to merge the vhost slot > management code with the KVM slot management code. There are no security implications as long as vhost uses the qemu process mappings. But your point is valid. > 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. We can probably be smarter in qemu. > > There are areas of MMIO/ROM address space that *sometimes* end up > behaving like ram, but that's a different case. The one other case > to consider is ram hot add/remove in which case, ram may be removed > or added (but it's location will never change during its lifetime). > > Here's what I'll propose, and I'd really like to hear what Paul > think about it before we start down this path. > > I think we should add a new API that's: > > void cpu_ram_add(target_phys_addr_t start, ram_addr_t size); > > This API would do two things. It would call qemu_ram_alloc() and > cpu_register_physical_memory() just as code does today. It would > also add this region into a new table. > > There would be: > > void *cpu_ram_map(target_phys_addr_t start, ram_addr_t *size); > void cpu_ram_unmap(void *mem); > > These calls would use this new table to lookup ram addresses. These > mappings are valid as long as the guest is executed. Within the > table, each region would have a reference count. When it comes time > to do hot add/remove, we would wait to remove a region until the > reference count went to zero to avoid unmapping during DMA. > > cpu_ram_add() never gets called with overlapping regions. We'll > modify cpu_register_physical_memory() to ensure that a ram mapping > is never changed after initial registration. What is the difference between your proposal and cpu_physical_memory_map? What i'd like to see is binding between cpu_physical_memory_map and qdev devices, so that you can use different host memory mappings for device context and for CPU context (and provide the possibility for, say, map a certain memory region as read-only). > vhost no longer needs to bother keeping the dynamic table up to date > so it removes all of the slot management code from vhost. KVM still > needs the code to handle rom/ram mappings but we can take care of > that next. virtio-net's userspace code can do the same thing as > vhost and only map the ring once which should be a big performance > improvement. Pinning the host virtual addresses as you propose reduces flexibility. See above about different mappings for DMA/CPU contexes.