From: Anthony Liguori <anthony@codemonkey.ws>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: mst@redhat.com, uobergfe@redhat.com, qemu-devel@nongnu.org,
armbru@redhat.com, owasserm@redhat.com, amit.shah@redhat.com
Subject: Re: [Qemu-devel] [PATCH 3/3] virtio-blk: note optional features
Date: Tue, 06 Mar 2012 11:15:26 -0600 [thread overview]
Message-ID: <4F56462E.6010003@codemonkey.ws> (raw)
In-Reply-To: <4F56457E.9010205@redhat.com>
On 03/06/2012 11:12 AM, Paolo Bonzini wrote:
> Il 06/03/2012 18:03, Anthony Liguori ha scritto:
>> I don't know how comfortable I feel about this.
>>
>> You can't just remove a feature in flight. The guest is going to behave
>> differently in such a way that the host isn't expecting. Yes, it should
>> fail gracefully, but nonetheless it will fail.
>>
>> Aren't you just delaying the inevitable? Instead of having migration
>> fail, the guest workload is going to fail. How is this an improvement?
>
> VIRTIO_BLK_F_SCSI feature was almost never used but was always marked as
> available. Because of possible security problems connected to it,
> libvirt started making it an opt-in feature.
>
> In practice, you need to configure your host specially if you want to
> use SCSI passthrough (e.g. you must not use labels and UUIDs in your
> /etc/fstab), so it's safe to assume that guests that have SG_IO disabled
> under their feet will keep working.
>
> That said, instead of this hack we can just decouple scsi=on/off from
> VIRTIO_BLK_F_SCSI, and just report the feature. After all we do not
> clear VIRTIO_BLK_F_SCSI just because the device is backed by a file or
> partition, yet SG_IO is still unavailable in those cases. I'll send
> patches for this tomorrow.
Okay, that makes more sense to me. I think this is an exceptional circumstance
so handling it as a one-off verses a generic mechanism would be preferred.
Regards,
Anthony Liguori
>
> Paolo
prev parent reply other threads:[~2012-03-06 17:16 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-06 12:22 [Qemu-devel] [PATCH 0/3] Make virtio_load permissive when possible Paolo Bonzini
2012-03-06 12:22 ` [Qemu-devel] [PATCH 1/3] virtio: let devices be permissive on enabled features Paolo Bonzini
2012-03-06 13:33 ` Michael S. Tsirkin
2012-03-06 13:57 ` Paolo Bonzini
2012-03-06 14:22 ` Orit Wasserman
2012-03-06 12:22 ` [Qemu-devel] [PATCH 2/3] virtio-balloon: note optional features Paolo Bonzini
2012-03-06 14:55 ` Michael S. Tsirkin
2012-03-06 14:59 ` Paolo Bonzini
2012-03-06 15:08 ` Michael S. Tsirkin
2012-03-06 15:13 ` Paolo Bonzini
2012-03-06 12:22 ` [Qemu-devel] [PATCH 3/3] virtio-blk: " Paolo Bonzini
2012-03-06 14:53 ` Michael S. Tsirkin
2012-03-06 15:58 ` Paolo Bonzini
2012-03-06 17:03 ` Anthony Liguori
2012-03-06 17:12 ` Paolo Bonzini
2012-03-06 17:15 ` Anthony Liguori [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F56462E.6010003@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=amit.shah@redhat.com \
--cc=armbru@redhat.com \
--cc=mst@redhat.com \
--cc=owasserm@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=uobergfe@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.