src/sys/dev/hyperv/storvsc, branch stable/13 FreeBSD source tree sys: Remove $FreeBSD$: one-line .c pattern 2023-08-23T17:43:25+00:00 Warner Losh imp@FreeBSD.org 2023-08-22T01:31:27+00:00 3bc80996974a61a4223eae4c1ccd47b6ee32a48a Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/ Similar commit in current: (cherry picked from commit 685dc743dc3b) 
Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/

Similar commit in current:
(cherry picked from commit 685dc743dc3b)
sys: Remove $FreeBSD$: two-line .h pattern 2023-08-23T17:43:20+00:00 Warner Losh imp@FreeBSD.org 2023-08-22T01:31:02+00:00 f8167e0404dab9ffeaca95853dd237ab7c587f82 Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/ Similar commit in current: (cherry picked from commit 95ee2897e98f) 
Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/

Similar commit in current:
(cherry picked from commit 95ee2897e98f)
spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD 2023-07-25T15:13:49+00:00 Warner Losh imp@FreeBSD.org 2023-05-10T15:40:58+00:00 caa41f641755c935b036e17440a3b49329c904ed The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch up to that fact and revert to their recommended match of BSD-2-Clause. Discussed with: pfg MFC After: 3 days Sponsored by: Netflix (cherry picked from commit 4d846d260e2b9a3d4d0a701462568268cbfe7a5b) 
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.

Discussed with:		pfg
MFC After:		3 days
Sponsored by:		Netflix

(cherry picked from commit 4d846d260e2b9a3d4d0a701462568268cbfe7a5b)
Use KERNEL_PANICKED() in more places 2022-06-23T22:19:26+00:00 Mitchell Horne mhorne@FreeBSD.org 2022-06-02T13:14:41+00:00 0db22efc94459609b99d5289c2fecf22bda646fc This is slightly more optimized than checking panicstr directly. For most of these instances performance doesn't matter, but let's make KERNEL_PANICKED() the common idiom. Reviewed by: mjg MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D35373 (cherry picked from commit 35eb9b10c265a27ce1f80a6eb74887240c7f4305) 
This is slightly more optimized than checking panicstr directly. For
most of these instances performance doesn't matter, but let's make
KERNEL_PANICKED() the common idiom.

Reviewed by:	mjg
MFC after:	3 days
Differential Revision:	https://reviews.freebsd.org/D35373

(cherry picked from commit 35eb9b10c265a27ce1f80a6eb74887240c7f4305)
hyperv storvsc: Don't abuse struct sglist to hold virtual addresses. 2022-05-11T00:03:58+00:00 John Baldwin jhb@FreeBSD.org 2022-02-01T01:11:27+00:00 95303c0646c45a7288c82fbba3ad88589fd1d641 struct sglist is intended for holding S/G lists of physical address ranges, not virtual address ranges. GCC 9.x issues several warnings due to casts between pointers and integers of different sizes as a result (vm_paddr_t is 64-bits on i386). Instead, add a local 'struct hv_sglist' which uses an array of 'struct iovec' to hold the S/G list of virtual address ranges. Differential Revision: https://reviews.freebsd.org/D31933 (cherry picked from commit 53e938e408be78a45c82012ca7a7be50b216159b) 
struct sglist is intended for holding S/G lists of physical address
ranges, not virtual address ranges.  GCC 9.x issues several warnings
due to casts between pointers and integers of different sizes as a
result (vm_paddr_t is 64-bits on i386).  Instead, add a local 'struct
hv_sglist' which uses an array of 'struct iovec' to hold the S/G list
of virtual address ranges.

Differential Revision:	https://reviews.freebsd.org/D31933

(cherry picked from commit 53e938e408be78a45c82012ca7a7be50b216159b)
storvsc: fix auto-sense reporting 2021-05-21T10:32:13+00:00 Andriy Gapon avg@FreeBSD.org 2021-05-07T07:17:57+00:00 4a7dcb174ce87c1e771486eb956ef697914fcc44 I saw a situation where the driver set CAM_AUTOSNS_VALID on a failed ccb even though SRB_STATUS_AUTOSENSE_VALID was not set in the status. The actual sense data remained all zeros. The problem seems to be that create_storvsc_request() always sets hv_storvsc_request::sense_info_len, so checking for sense_info_len != 0 is not enough to determine if any auto-sense data is actually available. Sponsored by: CyberSecure (cherry picked from commit 8afecefd57c5ac95200f43227cd00f265154acee) 
I saw a situation where the driver set CAM_AUTOSNS_VALID on a failed ccb
even though SRB_STATUS_AUTOSENSE_VALID was not set in the status.
The actual sense data remained all zeros.
The problem seems to be that create_storvsc_request() always sets
hv_storvsc_request::sense_info_len, so checking for sense_info_len != 0
is not enough to determine if any auto-sense data is actually available.

Sponsored by:	CyberSecure

(cherry picked from commit 8afecefd57c5ac95200f43227cd00f265154acee)
Hyper-V: storvsc: Enhance srb_status code handling. 2020-08-31T09:05:45+00:00 Wei Hu whu@FreeBSD.org 2020-08-31T09:05:45+00:00 2a0ce39d086ffe13782c9dc1e24bb240abbe790a In hv_storvsc_io_request() when coring, prevent changing of the send channel from the base channel to another one. storvsc_poll always probes on the base channel. Based upon conversations with Microsoft, changed the handling of srb_status codes. Most we should never get, others yes. All are treated as retry-able except for two. We should not get these statuses, but if we ever do, the I/O state is not known. Submitted by: Alexander Sideropoulos <Alexander.Sideropoulos@netapp.com> Reviewed by: trasz, allanjude, whu MFC after: 1 week Sponsored by: Netapp Inc Differential Revision: https://reviews.freebsd.org/D25756 
In hv_storvsc_io_request() when coring, prevent changing of the send channel
from the base channel to another one. storvsc_poll always probes on the base
channel.

Based upon conversations with Microsoft, changed the handling of srb_status
codes. Most we should never get, others yes. All are treated as retry-able
except for two. We should not get these statuses, but if we ever do, the I/O
state is not known.

Submitted by:	Alexander Sideropoulos <Alexander.Sideropoulos@netapp.com>
Reviewed by:	trasz, allanjude, whu
MFC after:	1 week
Sponsored by:	Netapp Inc
Differential Revision:	https://reviews.freebsd.org/D25756
storvsc: port a Linux patch, properly set residual data length on errors 2020-01-14T13:20:16+00:00 Andriy Gapon avg@FreeBSD.org 2020-01-14T13:20:16+00:00 efdba95d62e573a013dc06552c6bbb0df84dae87 This change is based on Linux commit 40630f462824ee. csio.resid should account for transfer_len only for success and SRB_STATUS_DATA_OVERRUN condition. I am not sure how exactly this change works, but I have a report from a user that they see lots of checksum errors when running a pool scrub concurrently with iozone -l 1 -s 100G. After applying this patch the problem cannot be reproduced. Reviewed by: nobody Sponsored by: CyberSecure Differential Revision: https://reviews.freebsd.org/D22312 
This change is based on Linux commit 40630f462824ee.  csio.resid should
account for transfer_len only for success and SRB_STATUS_DATA_OVERRUN
condition.

I am not sure how exactly this change works, but I have a report from a
user that they see lots of checksum errors when running a pool scrub
concurrently with iozone -l 1 -s 100G.  After applying this patch the
problem cannot be reproduced.

Reviewed by:	nobody
Sponsored by:	CyberSecure
Differential Revision: https://reviews.freebsd.org/D22312
hyperv/storvsc: stash a pointer to hv_storvsc_request in ccb 2019-11-19T07:20:59+00:00 Andriy Gapon avg@FreeBSD.org 2019-11-19T07:20:59+00:00 97d8f008afe15fbde2f1b59bd4cbddf5c22d90b3 A SIM-private field is used for that. The pointer can be useful when examining a state of a queued ccb. E.g., a ccb on a da_softc.pending_ccbs. MFC after: 2 weeks 
A SIM-private field is used for that.
The pointer can be useful when examining a state of a queued ccb.
E.g., a ccb on a da_softc.pending_ccbs.

MFC after:	2 weeks
hyperv/storvsc: storvsc_io_done(): do not use CAM_SEL_TIMEOUT 2018-04-10T18:05:02+00:00 Dexuan Cui dexuan@FreeBSD.org 2018-04-10T18:05:02+00:00 0d880ef42219fd9642e8dce9af11541e49f65834 CAM_SEL_TIMEOUT was introduced in https://reviews.freebsd.org/D7521 (r304251), which claimed: "VM shall response to CAM layer with CAM_SEL_TIMEOUT to filter those invalid LUNs. Never use CAM_DEV_NOT_THERE which will block LUN scan for LUN number higher than 7." But it turns out this is not correct: I think what really filters the invalid LUNs in r304251 is that: before r304251, we could set the CAM_REQ_CMP without checking vm_srb->srb_status at all: ccb->ccb_h.status |= CAM_REQ_CMP. r304251 checks vm_srb->srb_status and sets ccb->ccb_h.status properly, so the invalid LUNs are filtered. I changed my code version to r304251 but replaced the CAM_SEL_TIMEOUT with CAM_DEV_NOT_THERE, and I confirmed the invalid LUNs can also be filtered, and I successfully hot-added and hot-removed 8 disks to/from the VM without any issue. CAM_SEL_TIMEOUT has an unwanted side effect -- see cam_periph_error(): For a selection timeout, we consider all of the LUNs on the target to be gone. If the status is CAM_DEV_NOT_THERE, then we only get rid of the device(s) specified by the path in the original CCB. This means: for a VM with a valid LUN on 3:0:0:0, when the VM inquires 3:0:0:1 and the host reports 3:0:0:1 doesn't exist and storvsc returns CAM_SEL_TIMEOUT to the CAM layer, CAM will detech 3:0:0:0 as well: this is the bug I reported recently: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226583 PR: 226583 Reviewed by: mav MFC after: 1 week Sponsored by: Microsoft Differential Revision: https://reviews.freebsd.org/D14690 
CAM_SEL_TIMEOUT was introduced in
https://reviews.freebsd.org/D7521 (r304251), which claimed:

"VM shall response to CAM layer with CAM_SEL_TIMEOUT to filter those
invalid LUNs. Never use CAM_DEV_NOT_THERE which will block LUN scan
for LUN number higher than 7."

But it turns out this is not correct:

I think what really filters the invalid LUNs in r304251 is that:
before r304251, we could set the CAM_REQ_CMP without checking
vm_srb->srb_status at all:
ccb->ccb_h.status |= CAM_REQ_CMP.

r304251 checks vm_srb->srb_status and sets ccb->ccb_h.status properly,
so the invalid LUNs are filtered.

I changed my code version to r304251 but replaced the CAM_SEL_TIMEOUT
with CAM_DEV_NOT_THERE, and I confirmed the invalid LUNs can also be
filtered, and I successfully hot-added and hot-removed 8 disks to/from
the VM without any issue.

CAM_SEL_TIMEOUT has an unwanted side effect -- see cam_periph_error():
For a selection timeout, we consider all of the LUNs on
the target to be gone. If the status is CAM_DEV_NOT_THERE,
then we only get rid of the device(s) specified by the
path in the original CCB.

This means: for a VM with a valid LUN on 3:0:0:0, when the VM inquires
3:0:0:1 and the host reports 3:0:0:1 doesn't exist and storvsc returns
CAM_SEL_TIMEOUT to the CAM layer, CAM will detech 3:0:0:0 as well: this
is the bug I reported recently:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226583

PR:	226583
Reviewed by:	mav
MFC after:	1 week
Sponsored by:	Microsoft
Differential Revision:	https://reviews.freebsd.org/D14690