On Mon, 16 Aug 2021 21:13:59 +0300, Roman Bolshakov wrote:

On Fri, Aug 13, 2021 at 04:52:55PM +0200, David Disseldorp wrote:

quoted

Hi Sergey,

On Thu, 29 Jul 2021 23:19:43 +0300, Sergey Samoylenko wrote:
  

quoted

The 8Fh VPD page announces the capabilities supported by
the TCM XCOPY manager. It helps to expand the coverage of
the third-party copy manager with SCSI testing utilities.  

Please list which initiators use this VPD page, if you know of any.
Also, is there any test coverage for this? I don't see anything in
libiscsi...
  

Hi David,

ESXi is one of the hosts that inspects Third Party Copy VPD Page.
Windows detects ODX support using the page [1][2].

Thanks for the links. I haven't seen ESXi attempt to use it, but also
haven't checked for some time. It'd be good to get some of this
information in the commit message.

The page is also used by libiscsi to detect presence and features of
copy manager as was agreed with Bart in the PR [3]:

I'm probably missing something, but why wasn't the 3PC flag in the
standard inquiry page an option for this check?

"Implementing REPORT SUPPORTED OPERATION CODES in LIO would require more
work than implementing the third-party copy VPD page.

I'm fine with relying on the third-party copy VPD page, or in other
words, to skip the copy offloading tests if that page is not supported.

There are plans to implement XCOPY support in the Linux kernel sd
driver. If nobody else volunteers I plan to work on this myself. I'm
considering to only support SCSI targets that support the third-party
copy VPD page. Or in other words, we will need support for that VPD page
anyway."

Okay, fair enough.

1. https://www.slideshare.net/CalvinChen5/a-joint-effort-of-the-storage-industry
2. http://sg.danny.cz/sg/ddpt_xcopy_odx.html
3. https://github.com/sahlberg/libiscsi/pull/353

quoted

quoted

Reviewed-by: Konstantin Shelekhin <redacted>
Reviewed-by: Dmitry Bogdanov <redacted>
Reviewed-by: Anastasia Kovaleva <redacted>
Signed-off-by: Sergey Samoylenko <redacted>
---
 drivers/target/target_core_spc.c | 230 ++++++++++++++++++++++++++++++-
 1 file changed, 226 insertions(+), 4 deletions(-)

diff --git a/drivers/target/target_core_spc.c b/drivers/target/target_core_spc.c
index 22703a0dbd07..169341712b10 100644
--- a/drivers/target/target_core_spc.c
+++ b/drivers/target/target_core_spc.c  

...  

quoted

+/* Third-party Copy VPD page */
+static sense_reason_t
+spc_emulate_evpd_8f(struct se_cmd *cmd, unsigned char *buf)
+{
+	struct se_device *dev = cmd->se_dev;
+	int off;
+	u16 page_len;
+
+	if (!dev->dev_attrib.emulate_3pc)
+		return TCM_INVALID_CDB_FIELD;
+
+	/*
+	 * Since the Third-party copy manager in TCM is quite simple
+	 * and supports only two commands, the function sets
+	 * many descriptor parameters as constants.
+	 *
+	 * As the Copy manager supports the EXTENDED COPY(LID1) command,
+	 * the Third-party Copy VPD page should include five mandatory
+	 * Third-party copy descriptors. Its are:
+	 *   0001h - Supported Commands
+	 *   0004h - Parameter Data
+	 *   0008h - Supported Descriptors
+	 *   000Ch - Supported CSCD Descriptor IDs
+	 *   8001h - General Copy Operations
+	 *
+	 * See spc4 section 7.8.17
+	 */
+
+	off = 4;
+
+	/* fill descriptors */
+	off += spc_evpd_8f_encode_supp_cmds(&buf[off]);
+	off += spc_evpd_8f_encode_param_data(&buf[off]);
+	off += spc_evpd_8f_encode_supp_descrs(&buf[off]);
+	off += spc_evpd_8f_encode_supp_cscd_descr_id(&buf[off]);
+	off += spc_evpd_8f_encode_general_copy_ops(&buf[off]);  

This looks risky in terms of buf overrun. I think it'd be good to pass
a @remaining or @buf_end param to these helper functions.
  

It's doable but would require to change the signature of all existing
VPD handlers. SE_INQUIRY_BUF is hardcoded to 1kb but it's also capped by
EDTL to avoid buffer overruns:

  memcpy(rbuf, buf, min_t(u32, SE_INQUIRY_BUF, cmd->data_length));

That's checking the amount copied into the response buffer. My concern
is the prior writes to the staging buf.

Cheers, David