From: ronnie sahlberg <ronniesahlberg@gmail.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Hannes Reinecke <hare@suse.de>, Dor Laor <dlaor@redhat.com>,
"Nicholas A. Bellinger" <nab@linux-iscsi.org>,
Christian Borntraeger <borntraeger@de.ibm.com>,
James Bottomley <James.Bottomley@hansenpartnership.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Christian Hoff <christian.hoff@de.ibm.com>,
borntrae@linux.vnet.ibm.com, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org,
rusty@rustcorp.com.au, Stefan Hajnoczi <stefanha@gmail.com>,
target-devel <target-devel@vger.kernel.org>
Subject: Re: Pe: [PATCH v5 1/3] virtio-scsi: first version
Date: Tue, 14 Feb 2012 10:30:59 +1100 [thread overview]
Message-ID: <CAN05THS_zTf2VRz6QdccHbkOacnE86LNhtxp7b8twe+XezBU6Q@mail.gmail.com> (raw)
In-Reply-To: <20120213225623.GA2988@redhat.com>
On Tue, Feb 14, 2012 at 9:59 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Tue, Feb 14, 2012 at 07:53:26AM +1100, ronnie sahlberg wrote:
>> On Tue, Feb 14, 2012 at 7:42 AM, ronnie sahlberg
>> <ronniesahlberg@gmail.com> wrote:
>> > On Tue, Feb 14, 2012 at 2:12 AM, Hannes Reinecke <hare@suse.de> wrote:
>> >> On 02/13/2012 02:18 PM, Michael S. Tsirkin wrote:
>> >>> On Tue, Feb 14, 2012 at 12:13:36AM +1100, ronnie sahlberg wrote:
>> >>>> On Tue, Feb 14, 2012 at 12:00 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
>> >>>>> On Mon, Feb 13, 2012 at 02:54:03PM +0200, Dor Laor wrote:
>> >>>>>> Only if you use the pci multi-function option but that kills
>> >>>>>> standard hot unplug
>> >>>>>
>> >>>>> It doesn't kill it as such, rather you can't unplug luns individually.
>> >>>>
>> >>>> Isnt that just a consequence of the current implementation rather than
>> >>>> a SCSI limitation?
>> >>>
>> >>> Yes.
>> >>>
>> >>>> A different way to do hoplug could be to flag all devices as removable
>> >>>> in the standard inq page then
>> >>>> leave the LUN there persistently and what you remove/add is not the
>> >>>> LUN device itself but just the media in the device.
>> >>>>
>> >>>> Instead of hot-plug remove the LUN, hot-plug becomes "media eject" or
>> >>>> "media insert".
>> >>>> The device remains present all time, you never remove it, but instead
>> >>>> hot-plug controls if the media is present or not.
>> >>>>
>> >>>>
>> >>>> This would require implementing at least START_STOP_UNIT and
>> >>>> PREVENT_ALLOW_MEDIUM_REMOVAL opcode emulation from SBC.
>> >>>>
>> >>>>
>> >>>> regards
>> >>>> ronnie sahlberg
>> >>>
>> >>> That would work.
>> >>>
>> >> Or we simply use the Peripheral Qualifier that the device is gone;
>> >> eg we could simply set PQ = 1, return sense code 0x25/00 and be done
>> >> with ...
>> >>
>> >
>> > That is still similar to "rip a device out from the guest without notice"
>> > and can cause the guest to be "surprised".
>> >
>> >
>> > Removable media is standard feature in SCSI SBC (and other commandsets).
>> > The nice part of removable media is that it activates a contract
>> > between the device and the guest
>> > to prevent removal of the media when the guest depends on the media
>> > not being removed.
>> >
>> > I.e. If you have a SBC device with the removable-media bit set,
>> > this is used to tell the initiator "this media can be removed, be
>> > prepared that this might happen".
>> > So when you mount such a SBC device in the guest, the guest will issue
>> > a "PREVENT_ALLOW_MEDIUM_REMOVAL"
>> > to tell the device "this medium is in use and may not be removed".
>> >
>>
>> What I mean is that if /dev/sdb is removable,
>> if you mount this as "mount /dev/sdb1 /mnt"
>> this will automatically cause the guest kernel to send a
>> PREVENT_ALLOW_MEDIUM_REMOVAL to /dev/sdb to prevent removal.
>>
>> When you "umount /dev/sdb1" the kernel/guest will automagically send
>> PREVENT_ALLOW_MEDIUM_REMOVEAL to /dev/sdb and allow removal of the
>> media again.
>>
>>
>> If you capture this command and track the "prevent/allow removal
>> status" you automatically get a channel where qemu will
>> know when it is safe to unplug the device and when it is not safe to
>> unplug the device.
>> This is a nice feature.
>
> Presumably there's a way for device to notify the OS
> that user requested removal, as well?
I think that is done by responding with sense to one of the commands,
like the every few second TEST_UNIT_READY that the
initiator/guest-kernel will send.
5Ah 01h DT WROM BK OPERATOR MEDIUM REMOVAL REQUEST
This sense code should be the one to use.
I dont know if linux scsi initiator honors this or what it will do.
I guess something like this could work ?
IF device is marked as prevent-removal THEN
send OPERATOR SEND MEDIUM REMOVAL REQUEST to the initiator
wait xyz seconds
IF device is still marked as prevent-removal THEN
ask operator "guest refused to release the LUN, do you want to
forcefully remove it?"
ELSE
unmount the media
FI
ELSE
unmount the media
FI
next prev parent reply other threads:[~2012-02-13 23:31 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-06 9:51 Pe: [PATCH v5 1/3] virtio-scsi: first version Christian Hoff
2012-02-07 9:54 ` Paolo Bonzini
2012-02-07 11:10 ` Michael S. Tsirkin
2012-02-07 11:26 ` Paolo Bonzini
2012-02-07 11:56 ` Christian Borntraeger
2012-02-07 12:31 ` Paolo Bonzini
2012-02-07 13:18 ` Christian Borntraeger
2012-02-07 13:59 ` Christian Hoff
2012-02-07 14:28 ` Paolo Bonzini
2012-02-08 13:37 ` Christian Hoff
2012-02-09 9:25 ` Paolo Bonzini
2012-02-09 12:18 ` Christian Hoff
2012-02-12 20:16 ` James Bottomley
2012-02-12 23:41 ` Rusty Russell
2012-02-13 7:05 ` Christian Borntraeger
2012-02-13 7:57 ` Dor Laor
2012-02-13 12:40 ` Nicholas A. Bellinger
2012-02-13 12:54 ` Dor Laor
2012-02-13 13:00 ` Michael S. Tsirkin
2012-02-13 13:13 ` ronnie sahlberg
2012-02-13 13:17 ` Paolo Bonzini
2012-02-13 13:18 ` Michael S. Tsirkin
2012-02-13 15:12 ` Hannes Reinecke
2012-02-13 20:42 ` ronnie sahlberg
2012-02-13 20:53 ` ronnie sahlberg
2012-02-13 22:59 ` Michael S. Tsirkin
2012-02-13 23:30 ` ronnie sahlberg [this message]
2012-02-13 23:33 ` Michael S. Tsirkin
2012-02-14 0:49 ` ronnie sahlberg
2012-02-14 1:11 ` Michael S. Tsirkin
2012-02-14 9:57 ` Paolo Bonzini
2012-02-13 11:08 ` Bart Van Assche
2012-02-13 9:19 ` Paolo Bonzini
2012-02-14 0:07 ` Rusty Russell
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=CAN05THS_zTf2VRz6QdccHbkOacnE86LNhtxp7b8twe+XezBU6Q@mail.gmail.com \
--to=ronniesahlberg@gmail.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=borntrae@linux.vnet.ibm.com \
--cc=borntraeger@de.ibm.com \
--cc=christian.hoff@de.ibm.com \
--cc=dlaor@redhat.com \
--cc=hare@suse.de \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=mst@redhat.com \
--cc=nab@linux-iscsi.org \
--cc=pbonzini@redhat.com \
--cc=rusty@rustcorp.com.au \
--cc=stefanha@gmail.com \
--cc=target-devel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).