On 24.08.2011, at 23:49, David Evensky wrote: > On Wed, Aug 24, 2011 at 10:27:18PM -0500, Alexander Graf wrote: >> >> On 24.08.2011, at 17:25, 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. 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. >> >> Did you have a look at ivshmem? It does that today, but also gives you an IRQ line so the guests can poke each other. For something as simple as this, I don't see why we'd need two competing implementations. > > Isn't ivshmem in QEMU? If so, then I don't think there isn't any > competition. How do you feel that these are competing? Well, it means that you will inside the guest have two different devices depending whether you're using QEMU or kvm-tool. I don't see the point in exposing different devices to the guest just because of NIH. Why should a guest care which device emulation framework you're using? Alex -- 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
