On 05/25/2010 05:02 PM, Anthony Liguori wrote:
On 05/25/2010 08:57 AM, Avi Kivity wrote:
On 05/25/2010 04:54 PM, Anthony Liguori wrote:
On 05/25/2010 08:36 AM, Avi Kivity wrote:
We'd need a kernel-level generic snapshot API for this eventually.
or (2) implement BUSE to complement FUSE and CUSE to enable proper
userspace block devices.
Likely slow due do lots of copying. Also needs a snapshot API.
The kernel could use splice.
Still can't make guest memory appear in (A)BUSE process memory
without either mmu tricks (vmsplice in reverse) or a copy. May be
workable for an (A)BUSE driver that talks over a network, and thus
can splice() its way out.
splice() actually takes offset parameter so it may be possible to
treat that offset parameter as a file offset. That would essentially
allow you to implement a splice() based thread pool where splice()
replaces preadv/pwritev.
Right.
(note: need splicev() here)
It's not quite linux-aio, but it should take you pretty far. I think
the main point is that the problem of allowing block plugins to qemu
is the same as block plugins for the kernel. The kernel doesn't
provide a stable interface (and we probably can't for the same
reasons) and it's generally discourage from a code quality perspective.
The kernel does provide a stable interface for FUSE, and it could
provide a stable interface for ABUSE. Why can the kernel support these
and qemu can't support essentially the same thing?
That said, making an external program work well as a block backend is
identical to making userspace block devices fast.
More or less, yes.
--
error compiling committee.c: too many arguments to function
--
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
