Re: [PATCH] kvm tools: adds a PCI device that exports a host shared segment as a PCI BAR in the guest

[Pekka Enberg <penberg@kernel.org>]

On 8/25/11 9:30 AM, Asias He wrote:
> On Thu, Aug 25, 2011 at 1:54 PM, Pekka Enberg<penberg@kernel.org>  wrote:
>> On 8/25/11 8:34 AM, Asias He wrote:
>>
>> Hi, David
>>
>> On Thu, Aug 25, 2011 at 6:25 AM, David Evensky<evensky@sandia.gov>  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