- User Since
- Jun 4 2014, 7:07 AM (313 w, 5 h)
Apr 22 2020
In a pinch, I'd take it back to being a page size. I can see an argument that oversized CDBs and CAM_CDB_POINTER are underused to the point of creating unnecessary complication and risk to the code (as is evident from Alexander breaking it in r307205). No API was ever developed to make the feature easier to use, so it's been hit-and-miss on whether SIMs even support it. Maybe we eliminate it and deal with oversized CDBs via a new CCB type. We should also look into whether the embedded layout is creating unnecessary cache pollution in the CCB; maybe it makes sense to always have the CDB be a pointer to a scratch area at the end of the CCB that can grow as needed. Either way, we could bring everything into a conforming pattern that's easier and less risky.
Apr 21 2020
Blah, but thanks for the history on it, I guess I never noticed before. I would be surprised if this hasn't caused bugs. There's no longer an active standards group, and even if there was I'd advocate that this is wrong. Let's follow up with a change on it.
The point of all of this is that CDB's were predicted to grow larger than 16 bytes, and CAM was trying to optimize the common case of 6/10/12/16 byte CDB's without creating an API incompatibility for handling future growth. If a device came along that needed 32 byte CDB's, you could still use the stock CCB fields, but tack on the CDB as a separate allocation rather than have it be embedded in the CCB. So, while I agree with the original problem statement that the use of alloca() was unsafe, I disagree with the resolution.
The problem isn't the existence of bi-directional commands, it's that DIR_BOTH == 0, not an OR'ing of DIR_IN and DIR_OUT, as would be expected.
Yep, can tackle the CAM_DIR problem separately.
Apr 19 2020
Apr 16 2020
Apr 15 2020
Works on my Icelake system
Mar 31 2020
Works for my Icelake laptop Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz
Mar 28 2020
Looks really good.
Mar 20 2020
Mar 10 2020
Mar 9 2020
Mar 1 2020
Feb 28 2020
FC isn't part of the problem here, so I ask that we stop reverting to it in the discussion.
Feb 27 2020
I think it's much less likely that a SIM will internally map UINT_MAX to a valid target than what has already been demonstrated where it'll map an errant initiator_id to a valid target.
Initiator ID has no meaning for SAS initiators, your comment about this function scanning targets that it should not within the domain of XPORT_SAS doesn't make sense to me. Numerical bus ID's don't even make sense within SAS topology, and at some point we need to fix all of this to use port UUIDs as the definitive identifier. We also need to fix the entire SIM API and model so that the buses are truly self-announcing and self-identifying, not this crummy hybrid we have of still pretending that the SAS transport is sequentially scanned like parallel SCSI is. But until that happens, what Andriy is proposing is a seat belt for XPORT_SAS initiator SIMs so that they don't shoot themselves in the foot due to the poor API that we've provided.
The patch only impacts XPT_SCAN_TGT/XPT_SCAN_BUS operations that don't apply to target SIMs. Again, I see no reason not to proceed.
This commit only affects the behavior of XPT_SCAN_TGT/XPT_SCAN_BUS and has no bearing on the behavior of target SIMs. It also is specific to XPORT_SAS, and has no effect on XPORT_FC. I see no reason for it not to proceed.
This is good enough for now. Long term the transport needs to move to auto discovery instead of active scanning.
Feb 17 2020
Feb 16 2020
Feb 10 2020
Feb 7 2020
I agree with Alexander, I really don't like that this perpetuates bad design.
Jan 30 2020
Also, this should be MFC'd to 12 and even 11. With that, you can remove in 13 instead of waiting for 14
My recommendation is to change the rotating and unmapped sysctls to be SYSCTL_PROC, and have them read the flag. That way you can retire the fields out of the softc now.
Jan 15 2020
Jan 2 2020
Dec 26 2019
Dec 24 2019
Dec 23 2019
Change function names for better consistency. Add bus_dma_template_clone().
Update the man page.
I also have an large update to bus_dma.9 that I'll add to the review.
I already changed the names in an upcoming revision; I agree that simple wasn't a good name. For the purposes of cloning an existing tag, what I'd propose is to have a function, bus_dma_template_clone(*template, *dmat) that serializes the opaque fields of the tag back into a template, then lets you optionally modify the template, and then turn it into a new tag with bus_dma_template_tag(*template, *tag). I'll code that up and submit it in the next patch.
Switch to a typedef for the template. Be type-correct with
NULL field assignments.
Dec 22 2019
Dec 14 2019
Dec 13 2019
Dec 10 2019
Dec 6 2019
Dec 5 2019
Dec 2 2019
Nov 28 2019
Nov 27 2019
Nov 26 2019
Nov 25 2019
Nov 24 2019
Nov 23 2019
Nov 22 2019
Nov 18 2019
Minor request, if the MSR_OP_LOCAL/SCHED/RENDEVOUS opcodes are mutually exclusive from each other then don't make them be bitfield definitions, just have them be sequential numbers.
This looks great. My only complaint is using the name "tweak", I think it's too casual and poorly descriptive. Maybe x86_program_msr_smp()?
Nov 16 2019
Nov 15 2019
Move taa into its own sysctl node, machdep.mitigations.taa.(enable|state)
Move the sysctls and tunables to the new machdep.mitigations
tree. Rename the code in accordance, and rename the sysctls
themselves to have neutral wording.
Address several comments