From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55003) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZX6xF-0007rW-Sg for qemu-devel@nongnu.org; Wed, 02 Sep 2015 08:15:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZX6xB-0005g1-Jy for qemu-devel@nongnu.org; Wed, 02 Sep 2015 08:15:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57576) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZX6xB-0005fi-Fb for qemu-devel@nongnu.org; Wed, 02 Sep 2015 08:15:49 -0400 Date: Wed, 2 Sep 2015 15:15:43 +0300 From: "Michael S. Tsirkin" Message-ID: <20150902151438-mutt-send-email-mst@redhat.com> References: <55E55539.4030008@siemens.com> <20150901104914-mutt-send-email-mst@redhat.com> <55E56BD8.5010202@siemens.com> <20150901121743-mutt-send-email-mst@redhat.com> <55E5B1A8.9080506@siemens.com> <20150901172239-mutt-send-email-mst@redhat.com> <55E5C58D.6000104@siemens.com> <20150901184922-mutt-send-email-mst@redhat.com> <55E5D22C.6020108@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] rfc: vhost user enhancements for vm2vm communication List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Nakajima, Jun" Cc: virtio-dev@lists.oasis-open.org, Jan Kiszka , Claudio.Fontana@huawei.com, qemu-devel@nongnu.org, Linux Virtualization , Igor Mammedov , Varun Sethi , opnfv-tech-discuss@lists.opnfv.org On Tue, Sep 01, 2015 at 05:01:07PM -0700, Nakajima, Jun wrote: > On Tue, Sep 1, 2015 at 9:28 AM, Jan Kiszka wrote: > > On 2015-09-01 18:02, Michael S. Tsirkin wrote: > ... > >> You don't need to be able to map all guest memory if you know > >> guest won't try to allow device access to all of it. > >> It's a question of how good is the bus address allocator. > > > > But those BARs need to allocate a guest-physical address range as large > > as the other guest's RAM is, possibly even larger if that RAM is not > > contiguous, and you can't put other resources into potential holes > > because VM2 does not know where those holes will be. > > > > I think you can allocate such guest-physical address ranges > efficiently if each BAR sets the base of each memory region reported > by VHOST_SET_MEM_TABLE, for example. The issue is that we would need > to 8 (VHOST_MEMORY_MAX_NREGIONS) of them vs. 6 (defined by PCI-SIG). Besides, 8 is not even a limit: we merged a patch that allows makeing it larger. > -- > Jun > Intel Open Source Technology Center