Virtualization - Sep 2022 - [PATCH v2] virtio_blk: add SECURE ERASE command support

Thanks for the reply.
> This can be simplified with min_not_zero().
Ok, I will do it in the next version.
> It's worth including a comment here that the discard and secure erase
> limits are combined because the Linux block layer only has one limit
> value. If the block layer supported independent limit values we
wouldn't
> need to do this.
Ok.

I'll send a new version once we agree on the max_secure_erase_seg = 0
scenario.
Do you have an opinion on that?
Do you think that using sg_elems as the number of secure erase/discard
segments when the value in the virtio config is 0 is good enough?

On Mon, Sep 19, 2022 at 09:09:05PM +0300, Alvaro Karsz
wrote:
> Thanks for the reply.
> 
> > This can be simplified with min_not_zero().
> 
> Ok, I will do it in the next version.
> 
> > It's worth including a comment here that the discard and secure
erase
> > limits are combined because the Linux block layer only has one limit
> > value. If the block layer supported independent limit values we
wouldn't
> > need to do this.
> 
> Ok.
> 
> I'll send a new version once we agree on the max_secure_erase_seg = 0
scenario.
> Do you have an opinion on that?
> Do you think that using sg_elems as the number of secure erase/discard
> segments when the value in the virtio config is 0 is good enough?
> 
Okay, I have replied in the max_secure_erase_seg sub-thread. I think
probing the device should fail if the value is 0. There are no existing
non-compliant devices that we need to be compatible with - let's
encourage device implementors to report usable max_secure_erase_seg
values.

Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL:
<http://lists.linuxfoundation.org/pipermail/virtualization/attachments/20220920/492445c6/attachment-0001.sig>