qemu/hw/dataplane/Makefile.objs

ifeq ($(CONFIG_VIRTIO), y)
common-obj-$(CONFIG_VIRTIO_BLK_DATA_PLANE) += hostmem.o vring.o event-poll.o ioq.o virtio-blk.o
endif
dataplane: add host memory mapping code The data plane thread needs to map guest physical addresses to host pointers. Normally this is done with cpu_physical_memory_map() but the function assumes the global mutex is held. The data plane thread does not touch the global mutex and therefore needs a thread-safe memory mapping mechanism. Hostmem registers a MemoryListener similar to how vhost collects and pushes memory region information into the kernel. There is a fine-grained lock on the regions list which is held during lookup and when installing a new regions list. When the physical memory map changes the MemoryListener callbacks are invoked. They build up a new list of memory regions which is finally installed when the list has been completed. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> 2012-11-20 13:30:08 +04:00			`ifeq ($(CONFIG_VIRTIO), y)`
dataplane: add virtio-blk data plane code virtio-blk-data-plane is a subset implementation of virtio-blk. It only handles read, write, and flush requests. It does this using a dedicated thread that executes an epoll(2)-based event loop and processes I/O using Linux AIO. This approach performs very well but can be used for raw image files only. The number of IOPS achieved has been reported to be several times higher than the existing virtio-blk implementation. Eventually it should be possible to unify virtio-blk-data-plane with the main body of QEMU code once the block layer and hardware emulation is able to run outside the global mutex. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> 2012-11-14 18:39:30 +04:00			`common-obj-$(CONFIG_VIRTIO_BLK_DATA_PLANE) += hostmem.o vring.o event-poll.o ioq.o virtio-blk.o`
dataplane: add host memory mapping code The data plane thread needs to map guest physical addresses to host pointers. Normally this is done with cpu_physical_memory_map() but the function assumes the global mutex is held. The data plane thread does not touch the global mutex and therefore needs a thread-safe memory mapping mechanism. Hostmem registers a MemoryListener similar to how vhost collects and pushes memory region information into the kernel. There is a fine-grained lock on the regions list which is held during lookup and when installing a new regions list. When the physical memory map changes the MemoryListener callbacks are invoked. They build up a new list of memory regions which is finally installed when the list has been completed. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> 2012-11-20 13:30:08 +04:00			`endif`