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:24:17 +0300 Message-ID: <4E55F8A1.5040801@kernel.org> References: <20110824222510.GC14835@dancer.ca.sandia.gov> <4E55E378.4060904@kernel.org> <4E55F38C.5080303@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-ww0-f44.google.com ([74.125.82.44]:48701 "EHLO mail-ww0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751336Ab1HYHYW (ORCPT ); Thu, 25 Aug 2011 03:24:22 -0400 Received: by wwf5 with SMTP id 5so2048887wwf.1 for ; Thu, 25 Aug 2011 00:24:21 -0700 (PDT) In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 8/25/11 10:20 AM, Asias He wrote: > On Thu, Aug 25, 2011 at 3:02 PM, Pekka Enberg wrote: >> 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. > 1. Print it on startup like, like we do for --name. > # kvm run -k ./bzImage -m 448 -c 4 --name guest-26676 --shmem bar=0xc8000000 > > or > > 2. kvm stat --shmem > > David has chosen a default BAR already. > #define SHMEM_DEFAULT_ADDR (0xc8000000) OK. Makes sense. Pekka