If BLockLimits->MaxWriteSameLength is 0 (no limit) or >=256
then verify that both WRITESAME10 and WRITESAME16 can unmap with a
number of blocks == 2 byte field.
If not, then verify that a 256 block unmap results in INVALID FIELD IN CDB
If BLockLimits->MaxWriteSameLength is 0 (no limit) or >=65536
then verify that WRITESAME16 can unmap with a
number of blocks == 3 byte field.
If not, then verify that a 65536 block unmap results in INVALID FIELD IN CDB
From discussions on linux-scsi there are devices that support WRITESAME16
but where the implementation only looks at the low 2 bytes of the 4 bytes for
num-blocks in the CDB.
This added test aims to find and flag such devices.
Discussions on linux-scsi indicate that some SBC-2 devices may provide
some SBC-3 features and thus a SBC-3 BlockLimit page.
Supporting more than you claim is a transgression but a relatively minor
one, so lets turn a blind eye to it.
Supporting less than you claim is a serious transgression and will always
result in a harsh test failure.
If the device does not support PI (INQ->PROTECT) then
verify that PROT_EN, P_TYPE and P_I_EXP are all zero.
If the device does support PI and IF PROT_EN is clear
then verify that both P_TYPE and P_I_EXP are zero.
If the device does support PI and IF PROT_EN is set
then verify that P_TYPE is 0, 1 or 2
Verify that the page length matches up with the size of the data in buffer.
Verify that page length is 0x3c if the device claims SBC-3, and 0x0c if not.
If the device claims SBC-3 and if it claims UNMAP support (LBPU)
then we check that both MAXIMUM UNMAP LBA COUNT and
MAXIMUM UNMAP BLOCK DESCRIPTOR COUNT looks sane.
Sane here means >0, <1M or 0xffffffff
If the device claims SBC-3 and if it does not claim UNMAP support (LBPU)
then we check that both MAXIMUM UNMAP LBA COUNT and
MAXIMUM UNMAP BLOCK DESCRIPTOR COUNT are both 0.
This makes sure that CHAP authentication is disabled if the system
is running in FIPS 140-2 mode. MD5 is not a secure algorithm according
to the standard.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Default to 0 meaning no timeout.
Implement a test for iSCS to test what happens if we send a command
with CMDSN being higher than the target allows.
In this case we dont strictly know what will happen, just that what should
NOT happen is the target responding with success.
But we have to be prepared for any kind of failure, including a timeout,
scsi sense, or even iscsi reject or session failure.
Update the helpers to return -2/not supported on invalid operaction code.
Update all tests to accept that the opcode might be missing and abort the test without failing.
