qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/3] virtio: let devices be permissive on enable


From: Orit Wasserman
Subject: Re: [Qemu-devel] [PATCH 1/3] virtio: let devices be permissive on enabled features
Date: Tue, 06 Mar 2012 16:22:06 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120131 Thunderbird/10.0

On 03/06/2012 03:57 PM, Paolo Bonzini wrote:
> Il 06/03/2012 14:33, Michael S. Tsirkin ha scritto:
>>>> virtio_load checks features that are enabled by the guest and
>>>> blocks migration if they are not available in the destination
>>>> host.  However, in some cases we can let features through because
>>>> we know that guests will be able to proceed even without it.
>>>>
>>>> Signed-off-by: Paolo Bonzini <address@hidden>
>>
>> So why do we need these hacks? You are saying things
>> work fine without this information. Then,
>> why not just have the bit set in supported features always?
> 
> Not sure what you mean.
> 
> virtio-balloon works fine only because our implementation does not set
> the bit.  I found it just by inspection, but it's wrong.  If QEMU
> started setting VIRTIO_F_BALLOON_MUST_TELL_HOST, migration would fail to
> a version that does not set it.
> 
> virtio-blk is what prompted the patch and it is a real bug.  Updating
> libvirt on the destination causes the source's scsi=on to become
> scsi=off on the destination.  Then migration fails (it used to crash,
> Orit fixed the crash, I'm fixing the rest). 

To be more accurate we don't crash but give an error message:
"Features 0x100006d4 unsupported. Allowed features: 0x71000654"
The migration succeeds (from the user point of view ) but the virtio-blk device 
is not 
working properly.
I changed the code to fail the migration.
Paolo patch fixes the migration.

Orit

 However, a kernel update
> can cause the same behavioral change can happen even if
> VIRTIO_BLK_F_SCSI remains on, so it is not a good reason to fail migration.
> 
> Paolo




reply via email to

[Prev in Thread] Current Thread [Next in Thread]