On Wed, 2012-07-18 at 08:42 -0500, Anthony Liguori wrote: > On 07/17/2012 04:50 PM, Nicholas A. Bellinger wrote: > > On Tue, 2012-07-17 at 13:55 -0500, Anthony Liguori wrote: > >> On 07/17/2012 10:05 AM, Michael S. Tsirkin wrote: > >>> On Wed, Jul 11, 2012 at 09:15:00PM +0000, Nicholas A. Bellinger wrote: > > <SNIP> > > > >> But I do think the kernel should carefully consider whether it wants to support > >> an interface like this. This an extremely complicated ABI with a lot of subtle > >> details around state and compatibility. > >> > >> Are you absolutely confident that you can support a userspace application that > >> expects to get exactly the same response from all possible commands in 20 kernel > >> versions from now? Virtualization requires absolutely precise compatibility in > >> terms of bugs and features. This is probably not something the TCM stack has > >> had to consider yet. > >> > > > > We most certainly have thought about long term userspace compatibility > > with TCM. Our userspace code (that's now available in all major > > distros) is completely forward-compatible with new fabric modules such > > as tcm_vhost. No update required. > > I'm not sure we're talking about the same thing when we say compatibility. > > I'm not talking about the API. I'm talking about the behavior of the commands > that tcm_vhost supports. > OK, I understand what your getting at now.. > If you add support for a new command, you need to provide userspace a way to > disable this command. If you change what gets reported for VPD, you need to > provide userspace a way to make VPD look like what it did in a previous version. > > Basically, you need to be able to make a TCM device behave 100% the same as it > did in an older version of the kernel. > > This is unique to virtualization due to live migration. If you migrate from a > 3.6 kernel to a 3.8 kernel, you need to make sure that the 3.8 kernel's TCM > device behaves exactly like the 3.6 kernel because the guest that is interacting > with it does not realize that live migration happened. > > Yes, you can add knobs via configfs to control this behavior, but I think the > question is, what's the plan for this? > So we already allow for some types of CDBs emulation to be toggled via backend device attributes: root@tifa:/usr/src/target-pending.git# tree /sys/kernel/config/target/core/iblock_2/fioa/attrib/ /sys/kernel/config/target/core/iblock_2/fioa/attrib/ ├── block_size ├── emulate_dpo ├── emulate_fua_read ├── emulate_fua_write ├── emulate_rest_reord ├── emulate_tas ├── emulate_tpu ├── emulate_tpws ├── emulate_ua_intlck_ctrl ├── emulate_write_cache ├── enforce_pr_isids <SNIP> Some things like SPC-3 persistent reservations + implict/explict ALUA multipath currently can't be disabled, but adding two more backend attributes to disable/enable this logic individual is easy enough to do. So that said, I don't have a problem with adding the necessary device attributes to limit what type of CDBs a backend device is capable of processing. Trying to limiting this per-guest (instead of per-device) is where things get a little more tricky.. > BTW, I think this is a good thing to cover in Documentation/vhost/tcm_vhost.txt. > I think that's probably the only change that's needed here. > Sure, but I'll need to know what else that you'd like to optionally restrict it terms of CDB processing that's not already there.. Thanks for your feedback! --nab -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
