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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Aug 25, 2011 at 1:54 PM, Pekka Enberg <penberg@xxxxxxxxxx> 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@xxxxxxxxxx> 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.

>> 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.

--
Asias He
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux