Re: [RFC-v2 0/4] tcm_vhost+cmwq fabric driver code for-3.6

["Nicholas A. Bellinger" <nab@xxxxxxxxxxxxxxx>]

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