|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] [PATCH 00/21] Kemari for KVM 0.2 |
Date: | Mon, 29 Nov 2010 11:05:37 -0600 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Lightning/1.0b1 Thunderbird/3.0.10 |
On 11/29/2010 10:53 AM, Paul Brook wrote:
Is this a fair summary: any device that supports live migration workw under Kemari?It might be fair summary but practically we barely have live migration working w/o Kemari. In addition, last I checked Kemari needs additional hooks and it will be too hard to keep that out of tree until all devices get it.That's not what I've been hearing earlier in this thread. The responses from Yoshi indicate that Stefan's summary is correct. i.e. the current Kemari implementation may require per-device hooks, but that's a bug and should be fixed before merging.
It's actually really important that Kemari make use of an intermediate layer such that the hooks can distinguish between a device access and a recursive access.
You could s/bdrv_aio_multiwrite/bdrv_aio_multiwrite_internal/g and then within kemari, s/bdrv_aio_multiwrite_proxy/bdrv_aio_multiwrite/ but I don't think that results in a cleaner interface.
I don't like the _proxy naming and I think it has led to some confusion. I think having a dev_aio_multiwrite interface is a better naming scheme and ultimately provides a clearer idea of why a separate interface is needed--to distinguish between device accesses and internal accesses.
BTW, dev_aio_multiwrite should take a DeviceState * and a BlockDriverState. Regards, Anthony Liguori
Paul -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to address@hidden More majordomo info at http://vger.kernel.org/majordomo-info.html
[Prev in Thread] | Current Thread | [Next in Thread] |