From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] Add shared memory PCI device that shares a memory object betweens VMs Date: Thu, 02 Apr 2009 10:05:24 +0300 Message-ID: <49D463B4.1080309@redhat.com> References: <1238600608-9120-1-git-send-email-cam@cs.ualberta.ca> <49D3965C.1030503@codemonkey.ws> <49D3AD79.7080708@redhat.com> <49D3B7ED.4030303@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Cam Macdonell , kvm@vger.kernel.org To: Anthony Liguori Return-path: Received: from mx2.redhat.com ([66.187.237.31]:53719 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935111AbZDBHEx (ORCPT ); Thu, 2 Apr 2009 03:04:53 -0400 In-Reply-To: <49D3B7ED.4030303@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: Anthony Liguori wrote: >> I disagree with this. While virtio is excellent at exporting guest >> memory, it isn't so good at importing another guest's memory. > > First we need to separate static memory sharing and dynamic memory > sharing. Static memory sharing has to be configured on start up. I > think in practice, static memory sharing is not terribly interesting > except for maybe embedded environments. > > Dynamically memory sharing requires bidirectional communication in > order to establish mappings and tear down mappings. You'll eventually > recreate virtio once you've implemented this communication mechanism. > I guess that depends on what one uses share memory for. Cam? >>> The second is that I think instead of relying on mapping in device >>> memory to the guest, you should have the guest allocate it's own >>> memory to dedicate to sharing. >> >> That's not what you describe below. You're having the guest allocate >> parts of its address space that happen to be used by RAM, and >> overlaying those parts with the shared memory. > > But from the guest's perspective, it's RAM is being used for memory > sharing. > > If you're clever, you could start a guest with -mem-path and then use > this mechanism to map a portion of one guest's memory into another > guest without either guest ever knowing who "owns" the memory and with > exactly the same driver on both. > If it's part of the normal address space, it will just confuse the guest. Consider for example a reboot. Shared memory is not normal RAM! >>> Right now, you've got a bit of a hole in your implementation because >>> you only support files that are powers-of-two in size even though >>> that's not documented/enforced. This is a limitation of PCI >>> resource regions. >> >> While the BAR needs to be a power of two, I don't think the RAM >> backing it needs to be. > > Then you need a side channel to communicate the information to the guest. There is the PCI config space for that. >>> Since you're using qemu_ram_alloc() also, it makes hotplug >>> unworkable too since qemu_ram_alloc() is a static allocation from a >>> contiguous heap. >> >> We need to fix this anyway, for memory hotplug. > > It's going to be hard to "fix" with TCG. > Why? Instead of an offset against phys_ram_base you'd store an offset against (char *)0 in the tlb. Where do you see an issue? >> >> That will fragment the vma list. And what do you do when you unmap >> the region? ^^^ >> >> How does a 256M guest map 1G of shared memory? > > It doesn't but it couldn't today either b/c of the 32-bit BARs. Let's compare the two approaches, not how they fit or don't fit random qemu limitations which need lifting anyway. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.