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
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
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
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
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.
>>>
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.
> Ju
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
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
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
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-bloc
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.
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_com
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
13 matches
Mail list logo
