On Wed, Aug 12, 2009 at 02:18:20PM -0500, Anthony Liguori wrote:
Michael S. Tsirkin wrote:
On
Why bother switching to userspace for migration? Can't you just have
get/set ioctls for the state?
I have these. But live migration requires dirty page logging.
I do not want to
On 08/13/2009 09:15 AM, Michael S. Tsirkin wrote:
I wonder though if mmu notifiers can be used to make it transparent...
Maybe they can, but that decision belongs to KVM.
Avi, what do you think?
I don't see how mmu notifiers help. You can use mmu notifiers to sync
an external
On Thu, Aug 13, 2009 at 12:28:52PM +0300, Avi Kivity wrote:
On 08/13/2009 09:15 AM, Michael S. Tsirkin wrote:
I wonder though if mmu notifiers can be used to make it transparent...
Maybe they can, but that decision belongs to KVM.
Avi, what do you think?
I don't see how mmu
Michael S. Tsirkin wrote:
On
Why bother switching to userspace for migration? Can't you just have
get/set ioctls for the state?
I have these. But live migration requires dirty page logging.
I do not want to implement it in kernel.
Is it really that difficult? I think it
On Mon, Aug 10, 2009 at 05:35:13PM -0500, Anthony Liguori wrote:
Michael S. Tsirkin wrote:
On Mon, Aug 10, 2009 at 03:33:59PM -0500, Anthony Liguori wrote:
There ought to be a way to layer qdev properties that achieves this
goal so that when you create a virtio-pci-block device, you have
Michael S. Tsirkin wrote:
On Mon, Aug 10, 2009 at 05:35:13PM -0500, Anthony Liguori wrote:
What I'm saying is that virtio-blk-pci, which is the qdev instantiation
of virtio-pci + virtio-blk, should be able to have a set of qdev
properties that is composed of a combination of at least
On Tue, Aug 11, 2009 at 08:15:23AM -0500, Anthony Liguori wrote:
Michael S. Tsirkin wrote:
On Mon, Aug 10, 2009 at 05:35:13PM -0500, Anthony Liguori wrote:
What I'm saying is that virtio-blk-pci, which is the qdev
instantiation of virtio-pci + virtio-blk, should be able to have a
set
Michael S. Tsirkin wrote:
Let's say we supported virtio-vbus along with virtio-pci. What does
virtio_blk_get_features() do to mask out sg_indirect? For all
virtio-blk knows, it could be on top of virtio-vbus.
So? VIRTIO_RING_F_INDIRECT_DESC applies to all transports.
Just clear
On Tue, Aug 11, 2009 at 11:08:32AM -0500, Anthony Liguori wrote:
Michael S. Tsirkin wrote:
Let's say we supported virtio-vbus along with virtio-pci. What does
virtio_blk_get_features() do to mask out sg_indirect? For all
virtio-blk knows, it could be on top of virtio-vbus.
So?
On Mon, Aug 10, 2009 at 02:37:20PM -0500, Anthony Liguori wrote:
Michael S. Tsirkin wrote:
devices should have the final say over which virtio features they
support. E.g. indirect entries may or may not make sense in the context
of virtio-console. Move the common bits from virtio-pci to an
Michael S. Tsirkin wrote:
Normally, the common features are transport features and the devices
should have absolutely no knowledge of transport feature (since they're
transport dependent).
Good point. But
1. note that with my patch they don't. They call
virtio_get_common_features
On Mon, Aug 10, 2009 at 03:33:59PM -0500, Anthony Liguori wrote:
Michael S. Tsirkin wrote:
Normally, the common features are transport features and the devices
should have absolutely no knowledge of transport feature (since
they're transport dependent).
Good point. But
1. note
Michael S. Tsirkin wrote:
On Mon, Aug 10, 2009 at 03:33:59PM -0500, Anthony Liguori wrote:
There ought to be a way to layer qdev properties that achieves this goal
so that when you create a virtio-pci-block device, you have the ability
to turn off indirect sg without virtio-block
13 matches
Mail list logo
