From: ronnie sahlberg <ronniesahlberg@gmail.com>
To: Hannes Reinecke <hare@suse.de>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
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 07:42:50 +1100 [thread overview]
Message-ID: <CAN05THT=7xJhqAMrAvDsK2Z1_4d+=tV9yhOFkr5Z-i43k5hAGA@mail.gmail.com> (raw)
In-Reply-To: <4F39287A.9030808@suse.de>
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".
This automatically provides you with a mechanism where any guest can
signal to qemu when qemu may or may not remove the device/medium.
In addition to implementing PREVENT_ALLOW_MEDIUM_REMOVAL emulation,
qemu would also need to check the prevent-allow status before it
allows the device to be removed.
If nothing else, using this approach will automatically provide a
channel from the guest kernel to qemu to tell qemu when a device may
be unplugged and when it is not safe to unplug the device.
regards
ronnie sahlberg
next prev parent reply other threads:[~2012-02-13 20:42 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 [this message]
2012-02-13 20:53 ` ronnie sahlberg
2012-02-13 22:59 ` Michael S. Tsirkin
2012-02-13 23:30 ` ronnie sahlberg
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='CAN05THT=7xJhqAMrAvDsK2Z1_4d+=tV9yhOFkr5Z-i43k5hAGA@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).