From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pekka Enberg Subject: Re: [PATCH] kvm tools: adds a PCI device that exports a host shared segment as a PCI BAR in the guest Date: Thu, 25 Aug 2011 10:02:36 +0300 Message-ID: <4E55F38C.5080303@kernel.org> References: <20110824222510.GC14835@dancer.ca.sandia.gov> <4E55E378.4060904@kernel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: David Evensky , Sasha Levin , kvm@vger.kernel.org To: Asias He Return-path: Received: from mail-wy0-f174.google.com ([74.125.82.174]:56504 "EHLO mail-wy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753013Ab1HYHCk (ORCPT ); Thu, 25 Aug 2011 03:02:40 -0400 Received: by wyg24 with SMTP id 24so1413111wyg.19 for ; Thu, 25 Aug 2011 00:02:39 -0700 (PDT) In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 8/25/11 9:30 AM, Asias He wrote: > On Thu, Aug 25, 2011 at 1:54 PM, Pekka Enberg wrote: >> On 8/25/11 8:34 AM, Asias He wrote: >> >> Hi, David >> >> On Thu, Aug 25, 2011 at 6:25 AM, David Evensky wrote: >>> >>> This patch adds a PCI device that provides PCI device memory to the >>> guest. This memory in the guest exists as a shared memory segment in >>> the host. This is similar memory sharing capability of Nahanni >>> (ivshmem) available in QEMU. In this case, the shared memory segment >>> is exposed as a PCI BAR only. >>> >>> A new command line argument is added as: >>> --shmem pci:0xc8000000:16MB:handle=/newmem:create >>> >>> which will set the PCI BAR at 0xc8000000, the shared memory segment >>> and the region pointed to by the BAR will be 16MB. On the host side >>> the shm_open handle will be '/newmem', and the kvm tool will create >>> the shared segment, set its size, and initialize it. If the size, >>> handle, or create flag are absent, they will default to 16MB, >>> handle=/kvm_shmem, and create will be false. >> I think it's better to use a default BAR address if user does not specify one as well. >> This way, >> >> ./kvm --shmem >> >> will work with default values with zero configuration. >> >> Does that sort of thing make sense here? It's a special purpose device >> and the guest is expected to ioremap() the memory so it needs to >> know the BAR. > I mean a default bar address for --shmem device. Yes, guest needs to know > this address, but even if we specify the address at command line the guest still > does not know this address, no? So having a default bar address does no harm. How does the user discover what the default BAR is? Which default BAR should we use? I don't think default BAR adds much value here. >>> The address family, >>> 'pci:' is also optional as it is the only address family currently >>> supported. Only a single --shmem is supported at this time. >> So, let's drop the 'pci:' prefix. >> >> That means the user interface will change if someone adds new address >> families. So we should keep the prefix, no? > We can have a more flexible option format which does not depend on the order of > args, e.g.: > > --shmem bar=0xc8000000,size=16MB,handle=/newmem,ops=create, type=pci > > if user does not specify sub-args, just use the default one. Sure, makes sense. Pekka