* [PATCH v3] virtio_blk: add VIRTIO_BLK_F_LIFETIME feature support
@ 2022-12-05 16:20 Alvaro Karsz
2022-12-05 18:24 ` Jens Axboe
` (5 more replies)
0 siblings, 6 replies; 20+ messages in thread
From: Alvaro Karsz @ 2022-12-05 16:20 UTC (permalink / raw)
To: virtualization
Cc: Jens Axboe, linux-scsi, Michael S. Tsirkin, linux-nvme,
linux-block, dm-devel, Stefan Hajnoczi, Paolo Bonzini
Implement the VIRTIO_BLK_F_LIFETIME feature for VirtIO block devices.
This commit introduces a new ioctl command, VBLK_LIFETIME.
VBLK_LIFETIME ioctl asks for the block device to provide lifetime
information by sending a VIRTIO_BLK_T_GET_LIFETIME command to the device.
lifetime information fields:
- pre_eol_info: specifies the percentage of reserved blocks that are
consumed.
optional values following virtio spec:
*) 0 - undefined.
*) 1 - normal, < 80% of reserved blocks are consumed.
*) 2 - warning, 80% of reserved blocks are consumed.
*) 3 - urgent, 90% of reserved blocks are consumed.
- device_lifetime_est_typ_a: this field refers to wear of SLC cells and
is provided in increments of 10used, and so
on, thru to 11 meaning estimated lifetime
exceeded. All values above 11 are reserved.
- device_lifetime_est_typ_b: this field refers to wear of MLC cells and is
provided with the same semantics as
device_lifetime_est_typ_a.
The data received from the device will be sent as is to the user.
No data check/decode is done by virtblk.
Signed-off-by: Alvaro Karsz <alvaro.karsz@solid-run.com>
--
v2:
- Remove (void *) casting.
- Fix comments format in virtio_blk.h.
- Set ioprio value for legacy devices for REQ_OP_DRV_IN
operations.
v3:
- Initialize struct virtio_blk_lifetime to 0 instead of memset.
- Rename ioctl from VBLK_LIFETIME to VBLK_GET_LIFETIME.
- Return EOPNOTSUPP insted of ENOTTY if ioctl is not supported.
- Check if process is CAP_SYS_ADMIN capable in lifetime ioctl.
- Check if vdev is not NULL before accessing it in lifetime ioctl.
--
---
drivers/block/virtio_blk.c | 106 ++++++++++++++++++++++++++++++--
include/uapi/linux/virtio_blk.h | 32 ++++++++++
2 files changed, 133 insertions(+), 5 deletions(-)
diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index 19da5defd73..392d57fd6b7 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -101,6 +101,18 @@ static inline blk_status_t virtblk_result(struct virtblk_req *vbr)
}
}
+static inline int virtblk_ioctl_result(struct virtblk_req *vbr)
+{
+ switch (vbr->status) {
+ case VIRTIO_BLK_S_OK:
+ return 0;
+ case VIRTIO_BLK_S_UNSUPP:
+ return -EOPNOTSUPP;
+ default:
+ return -EIO;
+ }
+}
+
static inline struct virtio_blk_vq *get_virtio_blk_vq(struct blk_mq_hw_ctx *hctx)
{
struct virtio_blk *vblk = hctx->queue->queuedata;
@@ -218,6 +230,7 @@ static blk_status_t virtblk_setup_cmd(struct virtio_device *vdev,
u32 type;
vbr->out_hdr.sector = 0;
+ vbr->out_hdr.ioprio = cpu_to_virtio32(vdev, req_get_ioprio(req));
switch (req_op(req)) {
case REQ_OP_READ:
@@ -244,15 +257,14 @@ static blk_status_t virtblk_setup_cmd(struct virtio_device *vdev,
type = VIRTIO_BLK_T_SECURE_ERASE;
break;
case REQ_OP_DRV_IN:
- type = VIRTIO_BLK_T_GET_ID;
- break;
+ /* type is set in virtblk_get_id/virtblk_ioctl_lifetime */
+ return 0;
default:
WARN_ON_ONCE(1);
return BLK_STS_IOERR;
}
vbr->out_hdr.type = cpu_to_virtio32(vdev, type);
- vbr->out_hdr.ioprio = cpu_to_virtio32(vdev, req_get_ioprio(req));
if (type == VIRTIO_BLK_T_DISCARD || type == VIRTIO_BLK_T_WRITE_ZEROES ||
type == VIRTIO_BLK_T_SECURE_ERASE) {
@@ -459,12 +471,16 @@ static int virtblk_get_id(struct gendisk *disk, char *id_str)
struct virtio_blk *vblk = disk->private_data;
struct request_queue *q = vblk->disk->queue;
struct request *req;
+ struct virtblk_req *vbr;
int err;
req = blk_mq_alloc_request(q, REQ_OP_DRV_IN, 0);
if (IS_ERR(req))
return PTR_ERR(req);
+ vbr = blk_mq_rq_to_pdu(req);
+ vbr->out_hdr.type = cpu_to_virtio32(vblk->vdev, VIRTIO_BLK_T_GET_ID);
+
err = blk_rq_map_kern(q, req, id_str, VIRTIO_BLK_ID_BYTES, GFP_KERNEL);
if (err)
goto out;
@@ -508,6 +524,85 @@ static int virtblk_getgeo(struct block_device *bd, struct hd_geometry *geo)
return ret;
}
+/* Get lifetime information from device */
+static int virtblk_ioctl_lifetime(struct virtio_blk *vblk, unsigned long arg)
+{
+ struct request_queue *q = vblk->disk->queue;
+ struct request *req = NULL;
+ struct virtblk_req *vbr;
+ struct virtio_blk_lifetime lifetime = {};
+ int ret;
+
+ if (!capable(CAP_SYS_ADMIN))
+ return -EPERM;
+
+ /* The virtio_blk_lifetime struct fields follow virtio spec.
+ * There is no check/decode on values received from the device.
+ * The data is sent as is to the user.
+ */
+
+ /* This ioctl is allowed only if VIRTIO_BLK_F_LIFETIME
+ * feature is negotiated.
+ */
+ if (!virtio_has_feature(vblk->vdev, VIRTIO_BLK_F_LIFETIME))
+ return -EOPNOTSUPP;
+
+ req = blk_mq_alloc_request(q, REQ_OP_DRV_IN, 0);
+ if (IS_ERR(req))
+ return PTR_ERR(req);
+
+ /* Write the correct type */
+ vbr = blk_mq_rq_to_pdu(req);
+ vbr->out_hdr.type = cpu_to_virtio32(vblk->vdev, VIRTIO_BLK_T_GET_LIFETIME);
+
+ ret = blk_rq_map_kern(q, req, &lifetime, sizeof(lifetime), GFP_KERNEL);
+ if (ret)
+ goto out;
+
+ blk_execute_rq(req, false);
+
+ ret = virtblk_ioctl_result(blk_mq_rq_to_pdu(req));
+ if (ret)
+ goto out;
+
+ /* Pass the data to the user */
+ if (copy_to_user((void __user *)arg, &lifetime, sizeof(lifetime))) {
+ ret = -EFAULT;
+ goto out;
+ }
+
+out:
+ blk_mq_free_request(req);
+ return ret;
+}
+
+static int virtblk_ioctl(struct block_device *bd, fmode_t mode,
+ unsigned int cmd, unsigned long arg)
+{
+ struct virtio_blk *vblk = bd->bd_disk->private_data;
+ int ret;
+
+ mutex_lock(&vblk->vdev_mutex);
+
+ if (!vblk->vdev) {
+ ret = -ENXIO;
+ goto exit;
+ }
+
+ switch (cmd) {
+ case VBLK_GET_LIFETIME:
+ ret = virtblk_ioctl_lifetime(vblk, arg);
+ break;
+ default:
+ ret = -EOPNOTSUPP;
+ break;
+ }
+
+exit:
+ mutex_unlock(&vblk->vdev_mutex);
+ return ret;
+}
+
static void virtblk_free_disk(struct gendisk *disk)
{
struct virtio_blk *vblk = disk->private_data;
@@ -520,6 +615,7 @@ static void virtblk_free_disk(struct gendisk *disk)
static const struct block_device_operations virtblk_fops = {
.owner = THIS_MODULE,
.getgeo = virtblk_getgeo,
+ .ioctl = virtblk_ioctl,
.free_disk = virtblk_free_disk,
};
@@ -1239,7 +1335,7 @@ static unsigned int features_legacy[] = {
VIRTIO_BLK_F_RO, VIRTIO_BLK_F_BLK_SIZE,
VIRTIO_BLK_F_FLUSH, VIRTIO_BLK_F_TOPOLOGY, VIRTIO_BLK_F_CONFIG_WCE,
VIRTIO_BLK_F_MQ, VIRTIO_BLK_F_DISCARD, VIRTIO_BLK_F_WRITE_ZEROES,
- VIRTIO_BLK_F_SECURE_ERASE,
+ VIRTIO_BLK_F_SECURE_ERASE, VIRTIO_BLK_F_LIFETIME,
}
;
static unsigned int features[] = {
@@ -1247,7 +1343,7 @@ static unsigned int features[] = {
VIRTIO_BLK_F_RO, VIRTIO_BLK_F_BLK_SIZE,
VIRTIO_BLK_F_FLUSH, VIRTIO_BLK_F_TOPOLOGY, VIRTIO_BLK_F_CONFIG_WCE,
VIRTIO_BLK_F_MQ, VIRTIO_BLK_F_DISCARD, VIRTIO_BLK_F_WRITE_ZEROES,
- VIRTIO_BLK_F_SECURE_ERASE,
+ VIRTIO_BLK_F_SECURE_ERASE, VIRTIO_BLK_F_LIFETIME,
};
static struct virtio_driver virtio_blk = {
diff --git a/include/uapi/linux/virtio_blk.h b/include/uapi/linux/virtio_blk.h
index 58e70b24b50..e755d62d2ea 100644
--- a/include/uapi/linux/virtio_blk.h
+++ b/include/uapi/linux/virtio_blk.h
@@ -40,6 +40,7 @@
#define VIRTIO_BLK_F_MQ 12 /* support more than one vq */
#define VIRTIO_BLK_F_DISCARD 13 /* DISCARD is supported */
#define VIRTIO_BLK_F_WRITE_ZEROES 14 /* WRITE ZEROES is supported */
+#define VIRTIO_BLK_F_LIFETIME 15 /* Storage lifetime information is supported */
#define VIRTIO_BLK_F_SECURE_ERASE 16 /* Secure Erase is supported */
/* Legacy feature bits */
@@ -165,6 +166,9 @@ struct virtio_blk_config {
/* Get device ID command */
#define VIRTIO_BLK_T_GET_ID 8
+/* Get lifetime information command */
+#define VIRTIO_BLK_T_GET_LIFETIME 10
+
/* Discard command */
#define VIRTIO_BLK_T_DISCARD 11
@@ -206,6 +210,30 @@ struct virtio_blk_discard_write_zeroes {
__le32 flags;
};
+/* Get lifetime information struct for each request */
+struct virtio_blk_lifetime {
+ /*
+ * specifies the percentage of reserved blocks that are consumed.
+ * optional values following virtio spec:
+ * 0 - undefined
+ * 1 - normal, < 80% of reserved blocks are consumed
+ * 2 - warning, 80% of reserved blocks are consumed
+ * 3 - urgent, 90% of reserved blocks are consumed
+ */
+ __le16 pre_eol_info;
+ /*
+ * this field refers to wear of SLC cells and is provided in increments of 10used,
+ * and so on, thru to 11 meaning estimated lifetime exceeded. All values above 11
+ * are reserved
+ */
+ __le16 device_lifetime_est_typ_a;
+ /*
+ * this field refers to wear of MLC cells and is provided with the same semantics as
+ * device_lifetime_est_typ_a
+ */
+ __le16 device_lifetime_est_typ_b;
+};
+
#ifndef VIRTIO_BLK_NO_LEGACY
struct virtio_scsi_inhdr {
__virtio32 errors;
@@ -219,4 +247,8 @@ struct virtio_scsi_inhdr {
#define VIRTIO_BLK_S_OK 0
#define VIRTIO_BLK_S_IOERR 1
#define VIRTIO_BLK_S_UNSUPP 2
+
+/* Virtblk ioctl commands */
+#define VBLK_GET_LIFETIME _IOR('r', 0, struct virtio_blk_lifetime)
+
#endif /* _LINUX_VIRTIO_BLK_H */
--
2.32.0
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [PATCH v3] virtio_blk: add VIRTIO_BLK_F_LIFETIME feature support
2022-12-05 16:20 [PATCH v3] virtio_blk: add VIRTIO_BLK_F_LIFETIME feature support Alvaro Karsz
@ 2022-12-05 18:24 ` Jens Axboe
2022-12-05 18:36 ` Alvaro Karsz
2022-12-05 18:25 ` Jens Axboe
` (4 subsequent siblings)
5 siblings, 1 reply; 20+ messages in thread
From: Jens Axboe @ 2022-12-05 18:24 UTC (permalink / raw)
To: Alvaro Karsz, virtualization
Cc: linux-scsi, Michael S. Tsirkin, linux-nvme, linux-block, dm-devel,
Stefan Hajnoczi, Paolo Bonzini
On 12/5/22 9:20 AM, Alvaro Karsz wrote:
> Implement the VIRTIO_BLK_F_LIFETIME feature for VirtIO block devices.
>
> This commit introduces a new ioctl command, VBLK_LIFETIME.
>
> VBLK_LIFETIME ioctl asks for the block device to provide lifetime
> information by sending a VIRTIO_BLK_T_GET_LIFETIME command to the device.
>
> lifetime information fields:
>
> - pre_eol_info: specifies the percentage of reserved blocks that are
> consumed.
> optional values following virtio spec:
> *) 0 - undefined.
> *) 1 - normal, < 80% of reserved blocks are consumed.
> *) 2 - warning, 80% of reserved blocks are consumed.
> *) 3 - urgent, 90% of reserved blocks are consumed.
>
> - device_lifetime_est_typ_a: this field refers to wear of SLC cells and
> is provided in increments of 10used, and so
> on, thru to 11 meaning estimated lifetime
> exceeded. All values above 11 are reserved.
>
> - device_lifetime_est_typ_b: this field refers to wear of MLC cells and is
> provided with the same semantics as
> device_lifetime_est_typ_a.
>
> The data received from the device will be sent as is to the user.
> No data check/decode is done by virtblk.
Is this based on some spec? Because it looks pretty odd to me. There
can be a pretty wide range of two/three/etc level cells with wildly
different ranges of durability. And there's really not a lot of slc
for generic devices these days, if any.
--
Jens Axboe
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v3] virtio_blk: add VIRTIO_BLK_F_LIFETIME feature support
2022-12-05 16:20 [PATCH v3] virtio_blk: add VIRTIO_BLK_F_LIFETIME feature support Alvaro Karsz
2022-12-05 18:24 ` Jens Axboe
@ 2022-12-05 18:25 ` Jens Axboe
2022-12-06 16:31 ` Stefan Hajnoczi
` (3 subsequent siblings)
5 siblings, 0 replies; 20+ messages in thread
From: Jens Axboe @ 2022-12-05 18:25 UTC (permalink / raw)
To: Alvaro Karsz, virtualization
Cc: linux-scsi, Michael S. Tsirkin, linux-nvme, linux-block, dm-devel,
Stefan Hajnoczi, Paolo Bonzini
On 12/5/22 9:20 AM, Alvaro Karsz wrote:
> Implement the VIRTIO_BLK_F_LIFETIME feature for VirtIO block devices.
>
> This commit introduces a new ioctl command, VBLK_LIFETIME.
>
> VBLK_LIFETIME ioctl asks for the block device to provide lifetime
> information by sending a VIRTIO_BLK_T_GET_LIFETIME command to the device.
s/VBLK_LIFETIME/VBLK_GET_LIFETIME
for the above.
--
Jens Axboe
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v3] virtio_blk: add VIRTIO_BLK_F_LIFETIME feature support
2022-12-05 18:24 ` Jens Axboe
@ 2022-12-05 18:36 ` Alvaro Karsz
2022-12-05 18:53 ` Jens Axboe
0 siblings, 1 reply; 20+ messages in thread
From: Alvaro Karsz @ 2022-12-05 18:36 UTC (permalink / raw)
To: Jens Axboe
Cc: linux-scsi, Michael S. Tsirkin, linux-nvme, virtualization,
linux-block, dm-devel, Stefan Hajnoczi, Paolo Bonzini
Hi,
> Is this based on some spec? Because it looks pretty odd to me. There
> can be a pretty wide range of two/three/etc level cells with wildly
> different ranges of durability. And there's really not a lot of slc
> for generic devices these days, if any.
Yes, this is based on the virtio spec
https://docs.oasis-open.org/virtio/virtio/v1.2/csd01/virtio-v1.2-csd01.html
section 5.2.6
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v3] virtio_blk: add VIRTIO_BLK_F_LIFETIME feature support
2022-12-05 18:36 ` Alvaro Karsz
@ 2022-12-05 18:53 ` Jens Axboe
2022-12-05 20:29 ` Michael S. Tsirkin
0 siblings, 1 reply; 20+ messages in thread
From: Jens Axboe @ 2022-12-05 18:53 UTC (permalink / raw)
To: Alvaro Karsz
Cc: linux-scsi, Michael S. Tsirkin, linux-nvme, virtualization,
linux-block, dm-devel, Stefan Hajnoczi, Paolo Bonzini
On 12/5/22 11:36 AM, Alvaro Karsz wrote:
> Hi,
>
>> Is this based on some spec? Because it looks pretty odd to me. There
>> can be a pretty wide range of two/three/etc level cells with wildly
>> different ranges of durability. And there's really not a lot of slc
>> for generic devices these days, if any.
>
> Yes, this is based on the virtio spec
> https://docs.oasis-open.org/virtio/virtio/v1.2/csd01/virtio-v1.2-csd01.html
> section 5.2.6
And where did this come from?
--
Jens Axboe
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v3] virtio_blk: add VIRTIO_BLK_F_LIFETIME feature support
2022-12-05 18:53 ` Jens Axboe
@ 2022-12-05 20:29 ` Michael S. Tsirkin
2022-12-05 20:36 ` Jens Axboe
0 siblings, 1 reply; 20+ messages in thread
From: Michael S. Tsirkin @ 2022-12-05 20:29 UTC (permalink / raw)
To: Jens Axboe
Cc: linux-scsi, linux-nvme, virtualization, linux-block, dm-devel,
Stefan Hajnoczi, Paolo Bonzini, Enrico Granata
On Mon, Dec 05, 2022 at 11:53:51AM -0700, Jens Axboe wrote:
> On 12/5/22 11:36 AM, Alvaro Karsz wrote:
> > Hi,
> >
> >> Is this based on some spec? Because it looks pretty odd to me. There
> >> can be a pretty wide range of two/three/etc level cells with wildly
> >> different ranges of durability. And there's really not a lot of slc
> >> for generic devices these days, if any.
> >
> > Yes, this is based on the virtio spec
> > https://docs.oasis-open.org/virtio/virtio/v1.2/csd01/virtio-v1.2-csd01.html
> > section 5.2.6
>
> And where did this come from?
Here's the commit log from the spec:
In many embedded systems, virtio-blk implementations are
backed by eMMC or UFS storage devices, which are subject to
predictable and measurable wear over time due to repeated write
cycles.
For such systems, it can be important to be able to track
accurately the amount of wear imposed on the storage over
time and surface it to applications. In a native deployments
this is generally handled by the physical block device driver
but no such provision is made in virtio-blk to expose these
metrics for devices where it makes sense to do so.
This patch adds support to virtio-blk for lifetime and wear
metrics to be exposed to the guest when a deployment of
virtio-blk is done over compatible eMMC or UFS storage.
Signed-off-by: Enrico Granata <egranata@google.com>
Cc Enrico Granata as well.
> --
> Jens Axboe
>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v3] virtio_blk: add VIRTIO_BLK_F_LIFETIME feature support
2022-12-05 20:29 ` Michael S. Tsirkin
@ 2022-12-05 20:36 ` Jens Axboe
0 siblings, 0 replies; 20+ messages in thread
From: Jens Axboe @ 2022-12-05 20:36 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: linux-scsi, linux-nvme, virtualization, linux-block, dm-devel,
Stefan Hajnoczi, Paolo Bonzini, Enrico Granata
On 12/5/22 1:29?PM, Michael S. Tsirkin wrote:
> On Mon, Dec 05, 2022 at 11:53:51AM -0700, Jens Axboe wrote:
>> On 12/5/22 11:36?AM, Alvaro Karsz wrote:
>>> Hi,
>>>
>>>> Is this based on some spec? Because it looks pretty odd to me. There
>>>> can be a pretty wide range of two/three/etc level cells with wildly
>>>> different ranges of durability. And there's really not a lot of slc
>>>> for generic devices these days, if any.
>>>
>>> Yes, this is based on the virtio spec
>>> https://docs.oasis-open.org/virtio/virtio/v1.2/csd01/virtio-v1.2-csd01.html
>>> section 5.2.6
>>
>> And where did this come from?
>
>
> Here's the commit log from the spec:
> In many embedded systems, virtio-blk implementations are
> backed by eMMC or UFS storage devices, which are subject to
> predictable and measurable wear over time due to repeated write
> cycles.
>
> For such systems, it can be important to be able to track
> accurately the amount of wear imposed on the storage over
> time and surface it to applications. In a native deployments
> this is generally handled by the physical block device driver
> but no such provision is made in virtio-blk to expose these
> metrics for devices where it makes sense to do so.
>
> This patch adds support to virtio-blk for lifetime and wear
> metrics to be exposed to the guest when a deployment of
> virtio-blk is done over compatible eMMC or UFS storage.
>
> Signed-off-by: Enrico Granata <egranata@google.com>
>
> Cc Enrico Granata as well.
Alvaro sent me this one privately too. To be honest, I don't like this
patch very much, but that's mostly because the spec for this caters to a
narrow use case of embedded flash. It's not a generic storage thing,
it's just for mmc/ufs and the embedded space. That's a missed
opportunity. And either it'll become mostly unused, or it'll actually be
used and then extended at some point.
While I'm not a fan at all, if you guys are willing to take it in
virtio-blk, then I won't stand in your way. I would rename it though to
more specifically detail what it deals with.
--
Jens Axboe
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v3] virtio_blk: add VIRTIO_BLK_F_LIFETIME feature support
2022-12-05 16:20 [PATCH v3] virtio_blk: add VIRTIO_BLK_F_LIFETIME feature support Alvaro Karsz
2022-12-05 18:24 ` Jens Axboe
2022-12-05 18:25 ` Jens Axboe
@ 2022-12-06 16:31 ` Stefan Hajnoczi
2022-12-06 16:40 ` Michael S. Tsirkin
2022-12-06 18:43 ` Bart Van Assche
` (2 subsequent siblings)
5 siblings, 1 reply; 20+ messages in thread
From: Stefan Hajnoczi @ 2022-12-06 16:31 UTC (permalink / raw)
To: Alvaro Karsz
Cc: Jens Axboe, linux-scsi, Michael S. Tsirkin, linux-nvme,
virtualization, linux-block, dm-devel, Paolo Bonzini
[-- Attachment #1.1: Type: text/plain, Size: 862 bytes --]
On Mon, Dec 05, 2022 at 06:20:34PM +0200, Alvaro Karsz wrote:
I don't like that the ioctl lifetime struct is passed through
little-endian from the device to userspace. The point of this new ioctl
is not to be a passthrough interface. The kernel should define a proper
UABI struct for the ioctl and handle endianness conversion. But I think
Michael is happy with this approach, so nevermind.
> @@ -219,4 +247,8 @@ struct virtio_scsi_inhdr {
> #define VIRTIO_BLK_S_OK 0
> #define VIRTIO_BLK_S_IOERR 1
> #define VIRTIO_BLK_S_UNSUPP 2
> +
> +/* Virtblk ioctl commands */
> +#define VBLK_GET_LIFETIME _IOR('r', 0, struct virtio_blk_lifetime)
Does something include <linux/ioctl.h> for _IOR()? Failure to include
the necessary header file could break userspace applications that
include <linux/virtio_blk.h>.
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v3] virtio_blk: add VIRTIO_BLK_F_LIFETIME feature support
2022-12-06 16:31 ` Stefan Hajnoczi
@ 2022-12-06 16:40 ` Michael S. Tsirkin
2022-12-06 18:25 ` Alvaro Karsz
0 siblings, 1 reply; 20+ messages in thread
From: Michael S. Tsirkin @ 2022-12-06 16:40 UTC (permalink / raw)
To: Stefan Hajnoczi
Cc: Jens Axboe, linux-scsi, linux-nvme, virtualization, linux-block,
dm-devel, Paolo Bonzini
On Tue, Dec 06, 2022 at 11:31:44AM -0500, Stefan Hajnoczi wrote:
> On Mon, Dec 05, 2022 at 06:20:34PM +0200, Alvaro Karsz wrote:
>
> I don't like that the ioctl lifetime struct is passed through
> little-endian from the device to userspace. The point of this new ioctl
> is not to be a passthrough interface. The kernel should define a proper
> UABI struct for the ioctl and handle endianness conversion. But I think
> Michael is happy with this approach, so nevermind.
>
> > @@ -219,4 +247,8 @@ struct virtio_scsi_inhdr {
> > #define VIRTIO_BLK_S_OK 0
> > #define VIRTIO_BLK_S_IOERR 1
> > #define VIRTIO_BLK_S_UNSUPP 2
> > +
> > +/* Virtblk ioctl commands */
> > +#define VBLK_GET_LIFETIME _IOR('r', 0, struct virtio_blk_lifetime)
>
> Does something include <linux/ioctl.h> for _IOR()? Failure to include
> the necessary header file could break userspace applications that
> include <linux/virtio_blk.h>.
>
> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Good point. I think it's preferable to add a new header
for this stuff. virtio_blk_ioctl.h ? Have that pull in linux/ioctl.h
Also VIRTIO_BLK_IOCTL_GET_LIFETIME
might be a better name to avoid confusion and collisions.
And s/Virtblk/virtio-blk/
--
MST
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v3] virtio_blk: add VIRTIO_BLK_F_LIFETIME feature support
2022-12-06 16:40 ` Michael S. Tsirkin
@ 2022-12-06 18:25 ` Alvaro Karsz
0 siblings, 0 replies; 20+ messages in thread
From: Alvaro Karsz @ 2022-12-06 18:25 UTC (permalink / raw)
To: Michael S. Tsirkin, Stefan Hajnoczi
Cc: Jens Axboe, linux-scsi, linux-nvme, virtualization, linux-block,
dm-devel, Paolo Bonzini
Thanks,
I will fix it in the next version.
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v3] virtio_blk: add VIRTIO_BLK_F_LIFETIME feature support
2022-12-05 16:20 [PATCH v3] virtio_blk: add VIRTIO_BLK_F_LIFETIME feature support Alvaro Karsz
` (2 preceding siblings ...)
2022-12-06 16:31 ` Stefan Hajnoczi
@ 2022-12-06 18:43 ` Bart Van Assche
2022-12-06 19:56 ` Alvaro Karsz
2022-12-07 7:35 ` Christoph Hellwig
2022-12-19 7:59 ` Michael S. Tsirkin
5 siblings, 1 reply; 20+ messages in thread
From: Bart Van Assche @ 2022-12-06 18:43 UTC (permalink / raw)
To: Alvaro Karsz, virtualization
Cc: Jens Axboe, linux-scsi, Michael S. Tsirkin, linux-nvme,
linux-block, dm-devel, Stefan Hajnoczi, Paolo Bonzini
On 12/5/22 08:20, Alvaro Karsz wrote:
> +/* Get lifetime information struct for each request */
> +struct virtio_blk_lifetime {
> + /*
> + * specifies the percentage of reserved blocks that are consumed.
> + * optional values following virtio spec:
> + * 0 - undefined
> + * 1 - normal, < 80% of reserved blocks are consumed
> + * 2 - warning, 80% of reserved blocks are consumed
> + * 3 - urgent, 90% of reserved blocks are consumed
> + */
> + __le16 pre_eol_info;
> + /*
> + * this field refers to wear of SLC cells and is provided in increments of 10used,
> + * and so on, thru to 11 meaning estimated lifetime exceeded. All values above 11
> + * are reserved
> + */
> + __le16 device_lifetime_est_typ_a;
> + /*
> + * this field refers to wear of MLC cells and is provided with the same semantics as
> + * device_lifetime_est_typ_a
> + */
> + __le16 device_lifetime_est_typ_b;
> +};
Why does the above data structure only refer to SLC and MLC but not to
TLC or QLC?
How will this data structure be extended without having to introduce a
new ioctl?
Thanks,
Bart.
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v3] virtio_blk: add VIRTIO_BLK_F_LIFETIME feature support
2022-12-06 18:43 ` Bart Van Assche
@ 2022-12-06 19:56 ` Alvaro Karsz
0 siblings, 0 replies; 20+ messages in thread
From: Alvaro Karsz @ 2022-12-06 19:56 UTC (permalink / raw)
To: Bart Van Assche
Cc: Jens Axboe, linux-scsi, Michael S. Tsirkin, linux-nvme,
virtualization, linux-block, dm-devel, Stefan Hajnoczi,
Paolo Bonzini
Hi Bart,
> Why does the above data structure only refer to SLC and MLC but not to
> TLC or QLC?
This has been discussed before.
The data structure follows the virtio spec
(https://docs.oasis-open.org/virtio/virtio/v1.2/csd01/virtio-v1.2-csd01.html)
> How will this data structure be extended without having to introduce a
> new ioctl?
There are no more lifetime parameters defined in the virtio spec.
Please note that this is a virtio block specific ioctl, not a block generic one.
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v3] virtio_blk: add VIRTIO_BLK_F_LIFETIME feature support
2022-12-05 16:20 [PATCH v3] virtio_blk: add VIRTIO_BLK_F_LIFETIME feature support Alvaro Karsz
` (3 preceding siblings ...)
2022-12-06 18:43 ` Bart Van Assche
@ 2022-12-07 7:35 ` Christoph Hellwig
2022-12-07 10:21 ` Michael S. Tsirkin
2022-12-19 7:59 ` Michael S. Tsirkin
5 siblings, 1 reply; 20+ messages in thread
From: Christoph Hellwig @ 2022-12-07 7:35 UTC (permalink / raw)
To: Alvaro Karsz
Cc: Jens Axboe, linux-scsi, Michael S. Tsirkin, linux-nvme,
virtualization, linux-block, dm-devel, Stefan Hajnoczi,
Paolo Bonzini
This just seems like a horrible interface. And virtio-blk should be
a simple passthrough and not grow tons of side-band crap like this.
If you want to pass through random misc information use virtio-scsi
or nvme with shadow doorbell buffers.
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v3] virtio_blk: add VIRTIO_BLK_F_LIFETIME feature support
2022-12-07 7:35 ` Christoph Hellwig
@ 2022-12-07 10:21 ` Michael S. Tsirkin
2022-12-07 16:31 ` Christoph Hellwig
0 siblings, 1 reply; 20+ messages in thread
From: Michael S. Tsirkin @ 2022-12-07 10:21 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Jens Axboe, linux-scsi, linux-nvme, virtualization, linux-block,
dm-devel, Stefan Hajnoczi, Paolo Bonzini
On Tue, Dec 06, 2022 at 11:35:31PM -0800, Christoph Hellwig wrote:
> This just seems like a horrible interface. And virtio-blk should be
> a simple passthrough and not grow tons of side-band crap like this.
>
> If you want to pass through random misc information use virtio-scsi
> or nvme with shadow doorbell buffers.
Christoph you acked the spec patch adding this to virtio blk:
Still not a fan of the encoding, but at least it is properly documented
now:
Acked-by: Christoph Hellwig <hch@lst.de>
Did you change your mind then? Or do you prefer a different encoding for
the ioctl then? could you help sugesting what kind?
Thanks,
--
MST
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v3] virtio_blk: add VIRTIO_BLK_F_LIFETIME feature support
2022-12-07 10:21 ` Michael S. Tsirkin
@ 2022-12-07 16:31 ` Christoph Hellwig
2022-12-07 20:28 ` Michael S. Tsirkin
0 siblings, 1 reply; 20+ messages in thread
From: Christoph Hellwig @ 2022-12-07 16:31 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Jens Axboe, linux-block, linux-scsi, linux-nvme, virtualization,
Christoph Hellwig, dm-devel, Stefan Hajnoczi, Paolo Bonzini
On Wed, Dec 07, 2022 at 05:21:48AM -0500, Michael S. Tsirkin wrote:
> Christoph you acked the spec patch adding this to virtio blk:
>
> Still not a fan of the encoding, but at least it is properly documented
> now:
>
> Acked-by: Christoph Hellwig <hch@lst.de>
>
> Did you change your mind then? Or do you prefer a different encoding for
> the ioctl then? could you help sugesting what kind?
Well, it is good enough documented for a spec. I don't think it is
a useful feature for Linux where virtio-blk is our minimum viable
paravirtualized block driver.
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v3] virtio_blk: add VIRTIO_BLK_F_LIFETIME feature support
2022-12-07 16:31 ` Christoph Hellwig
@ 2022-12-07 20:28 ` Michael S. Tsirkin
2022-12-11 9:49 ` Alvaro Karsz
[not found] ` <ccb5388d-4976-31a3-0559-e94c14c90573@nvidia.com>
0 siblings, 2 replies; 20+ messages in thread
From: Michael S. Tsirkin @ 2022-12-07 20:28 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Jens Axboe, linux-scsi, linux-nvme, virtualization, linux-block,
dm-devel, Stefan Hajnoczi, Paolo Bonzini
On Wed, Dec 07, 2022 at 08:31:28AM -0800, Christoph Hellwig wrote:
> On Wed, Dec 07, 2022 at 05:21:48AM -0500, Michael S. Tsirkin wrote:
> > Christoph you acked the spec patch adding this to virtio blk:
> >
> > Still not a fan of the encoding, but at least it is properly documented
> > now:
> >
> > Acked-by: Christoph Hellwig <hch@lst.de>
> >
> > Did you change your mind then? Or do you prefer a different encoding for
> > the ioctl then? could you help sugesting what kind?
>
> Well, it is good enough documented for a spec. I don't think it is
> a useful feature for Linux where virtio-blk is our minimum viable
> paravirtualized block driver.
No idea what this means, sorry. Now that's in the spec I expect (some)
devices to implement it and if they do I see no reason not to expose the
data to userspace.
Alvaro could you pls explain the use-case? Christoph has doubts that
it's useful. Do you have a device implementing this?
--
MST
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v3] virtio_blk: add VIRTIO_BLK_F_LIFETIME feature support
2022-12-07 20:28 ` Michael S. Tsirkin
@ 2022-12-11 9:49 ` Alvaro Karsz
[not found] ` <ccb5388d-4976-31a3-0559-e94c14c90573@nvidia.com>
1 sibling, 0 replies; 20+ messages in thread
From: Alvaro Karsz @ 2022-12-11 9:49 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Jens Axboe, linux-block, linux-scsi, linux-nvme, virtualization,
Christoph Hellwig, dm-devel, Stefan Hajnoczi, Paolo Bonzini
> Alvaro could you pls explain the use-case? Christoph has doubts that
> it's useful. Do you have a device implementing this?
Our HW exposes virtio devices, virtio block included.
The block device backend can be a eMMC/uSD card.
The HW can report health values (power, temp, current, voltage) and I
thought that it would be nice to be able to report lifetime values as
well.
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v3] virtio_blk: add VIRTIO_BLK_F_LIFETIME feature support
[not found] ` <ccb5388d-4976-31a3-0559-e94c14c90573@nvidia.com>
@ 2022-12-13 6:23 ` Michael S. Tsirkin
0 siblings, 0 replies; 20+ messages in thread
From: Michael S. Tsirkin @ 2022-12-13 6:23 UTC (permalink / raw)
To: Chaitanya Kulkarni
Cc: Jens Axboe, linux-block@vger.kernel.org,
linux-scsi@vger.kernel.org, linux-nvme@lists.infradead.org,
virtualization@lists.linux-foundation.org, Christoph Hellwig,
dm-devel@redhat.com, Stefan Hajnoczi, Paolo Bonzini
On Tue, Dec 13, 2022 at 04:58:47AM +0000, Chaitanya Kulkarni wrote:
> Michael,
>
> On 12/7/22 12:28, Michael S. Tsirkin wrote:
> > On Wed, Dec 07, 2022 at 08:31:28AM -0800, Christoph Hellwig wrote:
> >> On Wed, Dec 07, 2022 at 05:21:48AM -0500, Michael S. Tsirkin wrote:
> >>> Christoph you acked the spec patch adding this to virtio blk:
> >>>
> >>> Still not a fan of the encoding, but at least it is properly documented
> >>> now:
> >>>
> >>> Acked-by: Christoph Hellwig <hch@lst.de>
> >>>
> >>> Did you change your mind then? Or do you prefer a different encoding for
> >>> the ioctl then? could you help sugesting what kind?
> >>
> >> Well, it is good enough documented for a spec. I don't think it is
> >> a useful feature for Linux where virtio-blk is our minimum viable
> >> paravirtualized block driver.
> >
> > No idea what this means, sorry. Now that's in the spec I expect (some)
> > devices to implement it and if they do I see no reason not to expose the
> > data to userspace.
> >
>
> Even if any device implements is it can always use passthru commands.
> See below for more info...
>
> > Alvaro could you pls explain the use-case? Christoph has doubts that
> > it's useful. Do you have a device implementing this?
> >
>
> From what I know, virtio-blk should be kept minimal and should not
> add any storage specific IOCTLs or features that will end up loosing
> its generic nature.
>
> The IOCTL we are trying to add is Flash storage specific which
> goes against the nature of generic storage and makes it non-generic.
> In case we approve this it will open the door for non-generic
> code/IOCTL in the virtio-blk and that needs to be avoided.
Wrt these fields that horse has bolted, it's in the spec.
> For any storage specific features or IOCTL (flash/HDD) it should
> be using it's own frontend such as virtio-scsi or e.g. nvme and
> not virtio-blk.
>
> Hope this helps.
>
> -ck
I don't understand what you are suggesting, sorry. It's a hardware
device. It can't just "switch to a different frontend".
--
MST
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v3] virtio_blk: add VIRTIO_BLK_F_LIFETIME feature support
2022-12-05 16:20 [PATCH v3] virtio_blk: add VIRTIO_BLK_F_LIFETIME feature support Alvaro Karsz
` (4 preceding siblings ...)
2022-12-07 7:35 ` Christoph Hellwig
@ 2022-12-19 7:59 ` Michael S. Tsirkin
2022-12-19 8:39 ` Alvaro Karsz
5 siblings, 1 reply; 20+ messages in thread
From: Michael S. Tsirkin @ 2022-12-19 7:59 UTC (permalink / raw)
To: Alvaro Karsz
Cc: Jens Axboe, linux-scsi, linux-nvme, virtualization, linux-block,
dm-devel, Stefan Hajnoczi, Paolo Bonzini
On Mon, Dec 05, 2022 at 06:20:34PM +0200, Alvaro Karsz wrote:
> Implement the VIRTIO_BLK_F_LIFETIME feature for VirtIO block devices.
>
> This commit introduces a new ioctl command, VBLK_LIFETIME.
>
> VBLK_LIFETIME ioctl asks for the block device to provide lifetime
> information by sending a VIRTIO_BLK_T_GET_LIFETIME command to the device.
>
> lifetime information fields:
>
> - pre_eol_info: specifies the percentage of reserved blocks that are
> consumed.
> optional values following virtio spec:
> *) 0 - undefined.
> *) 1 - normal, < 80% of reserved blocks are consumed.
> *) 2 - warning, 80% of reserved blocks are consumed.
> *) 3 - urgent, 90% of reserved blocks are consumed.
>
> - device_lifetime_est_typ_a: this field refers to wear of SLC cells and
> is provided in increments of 10used, and so
> on, thru to 11 meaning estimated lifetime
> exceeded. All values above 11 are reserved.
>
> - device_lifetime_est_typ_b: this field refers to wear of MLC cells and is
> provided with the same semantics as
> device_lifetime_est_typ_a.
>
> The data received from the device will be sent as is to the user.
> No data check/decode is done by virtblk.
>
> Signed-off-by: Alvaro Karsz <alvaro.karsz@solid-run.com>
> --
> v2:
> - Remove (void *) casting.
> - Fix comments format in virtio_blk.h.
> - Set ioprio value for legacy devices for REQ_OP_DRV_IN
> operations.
>
> v3:
> - Initialize struct virtio_blk_lifetime to 0 instead of memset.
> - Rename ioctl from VBLK_LIFETIME to VBLK_GET_LIFETIME.
> - Return EOPNOTSUPP insted of ENOTTY if ioctl is not supported.
> - Check if process is CAP_SYS_ADMIN capable in lifetime ioctl.
> - Check if vdev is not NULL before accessing it in lifetime ioctl.
> --
> ---
> drivers/block/virtio_blk.c | 106 ++++++++++++++++++++++++++++++--
> include/uapi/linux/virtio_blk.h | 32 ++++++++++
> 2 files changed, 133 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
> index 19da5defd73..392d57fd6b7 100644
> --- a/drivers/block/virtio_blk.c
> +++ b/drivers/block/virtio_blk.c
> @@ -101,6 +101,18 @@ static inline blk_status_t virtblk_result(struct virtblk_req *vbr)
> }
> }
>
> +static inline int virtblk_ioctl_result(struct virtblk_req *vbr)
> +{
> + switch (vbr->status) {
> + case VIRTIO_BLK_S_OK:
> + return 0;
> + case VIRTIO_BLK_S_UNSUPP:
> + return -EOPNOTSUPP;
> + default:
> + return -EIO;
> + }
> +}
> +
> static inline struct virtio_blk_vq *get_virtio_blk_vq(struct blk_mq_hw_ctx *hctx)
> {
> struct virtio_blk *vblk = hctx->queue->queuedata;
> @@ -218,6 +230,7 @@ static blk_status_t virtblk_setup_cmd(struct virtio_device *vdev,
> u32 type;
>
> vbr->out_hdr.sector = 0;
> + vbr->out_hdr.ioprio = cpu_to_virtio32(vdev, req_get_ioprio(req));
>
> switch (req_op(req)) {
> case REQ_OP_READ:
> @@ -244,15 +257,14 @@ static blk_status_t virtblk_setup_cmd(struct virtio_device *vdev,
> type = VIRTIO_BLK_T_SECURE_ERASE;
> break;
> case REQ_OP_DRV_IN:
> - type = VIRTIO_BLK_T_GET_ID;
> - break;
> + /* type is set in virtblk_get_id/virtblk_ioctl_lifetime */
> + return 0;
> default:
> WARN_ON_ONCE(1);
> return BLK_STS_IOERR;
> }
>
> vbr->out_hdr.type = cpu_to_virtio32(vdev, type);
> - vbr->out_hdr.ioprio = cpu_to_virtio32(vdev, req_get_ioprio(req));
>
> if (type == VIRTIO_BLK_T_DISCARD || type == VIRTIO_BLK_T_WRITE_ZEROES ||
> type == VIRTIO_BLK_T_SECURE_ERASE) {
> @@ -459,12 +471,16 @@ static int virtblk_get_id(struct gendisk *disk, char *id_str)
> struct virtio_blk *vblk = disk->private_data;
> struct request_queue *q = vblk->disk->queue;
> struct request *req;
> + struct virtblk_req *vbr;
> int err;
>
> req = blk_mq_alloc_request(q, REQ_OP_DRV_IN, 0);
> if (IS_ERR(req))
> return PTR_ERR(req);
>
> + vbr = blk_mq_rq_to_pdu(req);
> + vbr->out_hdr.type = cpu_to_virtio32(vblk->vdev, VIRTIO_BLK_T_GET_ID);
> +
> err = blk_rq_map_kern(q, req, id_str, VIRTIO_BLK_ID_BYTES, GFP_KERNEL);
> if (err)
> goto out;
> @@ -508,6 +524,85 @@ static int virtblk_getgeo(struct block_device *bd, struct hd_geometry *geo)
> return ret;
> }
>
> +/* Get lifetime information from device */
> +static int virtblk_ioctl_lifetime(struct virtio_blk *vblk, unsigned long arg)
> +{
> + struct request_queue *q = vblk->disk->queue;
> + struct request *req = NULL;
> + struct virtblk_req *vbr;
> + struct virtio_blk_lifetime lifetime = {};
> + int ret;
> +
> + if (!capable(CAP_SYS_ADMIN))
> + return -EPERM;
> +
> + /* The virtio_blk_lifetime struct fields follow virtio spec.
> + * There is no check/decode on values received from the device.
> + * The data is sent as is to the user.
> + */
> +
> + /* This ioctl is allowed only if VIRTIO_BLK_F_LIFETIME
> + * feature is negotiated.
> + */
> + if (!virtio_has_feature(vblk->vdev, VIRTIO_BLK_F_LIFETIME))
> + return -EOPNOTSUPP;
> +
> + req = blk_mq_alloc_request(q, REQ_OP_DRV_IN, 0);
> + if (IS_ERR(req))
> + return PTR_ERR(req);
> +
> + /* Write the correct type */
> + vbr = blk_mq_rq_to_pdu(req);
> + vbr->out_hdr.type = cpu_to_virtio32(vblk->vdev, VIRTIO_BLK_T_GET_LIFETIME);
> +
> + ret = blk_rq_map_kern(q, req, &lifetime, sizeof(lifetime), GFP_KERNEL);
> + if (ret)
> + goto out;
> +
> + blk_execute_rq(req, false);
> +
> + ret = virtblk_ioctl_result(blk_mq_rq_to_pdu(req));
> + if (ret)
> + goto out;
> +
> + /* Pass the data to the user */
> + if (copy_to_user((void __user *)arg, &lifetime, sizeof(lifetime))) {
> + ret = -EFAULT;
> + goto out;
> + }
> +
> +out:
> + blk_mq_free_request(req);
> + return ret;
> +}
> +
> +static int virtblk_ioctl(struct block_device *bd, fmode_t mode,
> + unsigned int cmd, unsigned long arg)
> +{
> + struct virtio_blk *vblk = bd->bd_disk->private_data;
> + int ret;
> +
> + mutex_lock(&vblk->vdev_mutex);
> +
> + if (!vblk->vdev) {
> + ret = -ENXIO;
> + goto exit;
> + }
> +
> + switch (cmd) {
> + case VBLK_GET_LIFETIME:
> + ret = virtblk_ioctl_lifetime(vblk, arg);
> + break;
> + default:
> + ret = -EOPNOTSUPP;
> + break;
> + }
> +
> +exit:
> + mutex_unlock(&vblk->vdev_mutex);
> + return ret;
> +}
> +
> static void virtblk_free_disk(struct gendisk *disk)
> {
> struct virtio_blk *vblk = disk->private_data;
> @@ -520,6 +615,7 @@ static void virtblk_free_disk(struct gendisk *disk)
> static const struct block_device_operations virtblk_fops = {
> .owner = THIS_MODULE,
> .getgeo = virtblk_getgeo,
> + .ioctl = virtblk_ioctl,
> .free_disk = virtblk_free_disk,
> };
>
> @@ -1239,7 +1335,7 @@ static unsigned int features_legacy[] = {
> VIRTIO_BLK_F_RO, VIRTIO_BLK_F_BLK_SIZE,
> VIRTIO_BLK_F_FLUSH, VIRTIO_BLK_F_TOPOLOGY, VIRTIO_BLK_F_CONFIG_WCE,
> VIRTIO_BLK_F_MQ, VIRTIO_BLK_F_DISCARD, VIRTIO_BLK_F_WRITE_ZEROES,
> - VIRTIO_BLK_F_SECURE_ERASE,
> + VIRTIO_BLK_F_SECURE_ERASE, VIRTIO_BLK_F_LIFETIME,
> }
> ;
> static unsigned int features[] = {
> @@ -1247,7 +1343,7 @@ static unsigned int features[] = {
> VIRTIO_BLK_F_RO, VIRTIO_BLK_F_BLK_SIZE,
> VIRTIO_BLK_F_FLUSH, VIRTIO_BLK_F_TOPOLOGY, VIRTIO_BLK_F_CONFIG_WCE,
> VIRTIO_BLK_F_MQ, VIRTIO_BLK_F_DISCARD, VIRTIO_BLK_F_WRITE_ZEROES,
> - VIRTIO_BLK_F_SECURE_ERASE,
> + VIRTIO_BLK_F_SECURE_ERASE, VIRTIO_BLK_F_LIFETIME,
> };
>
> static struct virtio_driver virtio_blk = {
> diff --git a/include/uapi/linux/virtio_blk.h b/include/uapi/linux/virtio_blk.h
> index 58e70b24b50..e755d62d2ea 100644
> --- a/include/uapi/linux/virtio_blk.h
> +++ b/include/uapi/linux/virtio_blk.h
> @@ -40,6 +40,7 @@
> #define VIRTIO_BLK_F_MQ 12 /* support more than one vq */
> #define VIRTIO_BLK_F_DISCARD 13 /* DISCARD is supported */
> #define VIRTIO_BLK_F_WRITE_ZEROES 14 /* WRITE ZEROES is supported */
> +#define VIRTIO_BLK_F_LIFETIME 15 /* Storage lifetime information is supported */
> #define VIRTIO_BLK_F_SECURE_ERASE 16 /* Secure Erase is supported */
>
> /* Legacy feature bits */
> @@ -165,6 +166,9 @@ struct virtio_blk_config {
> /* Get device ID command */
> #define VIRTIO_BLK_T_GET_ID 8
>
> +/* Get lifetime information command */
> +#define VIRTIO_BLK_T_GET_LIFETIME 10
> +
> /* Discard command */
> #define VIRTIO_BLK_T_DISCARD 11
>
> @@ -206,6 +210,30 @@ struct virtio_blk_discard_write_zeroes {
> __le32 flags;
> };
>
> +/* Get lifetime information struct for each request */
> +struct virtio_blk_lifetime {
> + /*
> + * specifies the percentage of reserved blocks that are consumed.
> + * optional values following virtio spec:
> + * 0 - undefined
> + * 1 - normal, < 80% of reserved blocks are consumed
> + * 2 - warning, 80% of reserved blocks are consumed
> + * 3 - urgent, 90% of reserved blocks are consumed
> + */
> + __le16 pre_eol_info;
> + /*
> + * this field refers to wear of SLC cells and is provided in increments of 10used,
> + * and so on, thru to 11 meaning estimated lifetime exceeded. All values above 11
> + * are reserved
> + */
> + __le16 device_lifetime_est_typ_a;
> + /*
> + * this field refers to wear of MLC cells and is provided with the same semantics as
> + * device_lifetime_est_typ_a
> + */
> + __le16 device_lifetime_est_typ_b;
> +};
> +
> #ifndef VIRTIO_BLK_NO_LEGACY
> struct virtio_scsi_inhdr {
> __virtio32 errors;
> @@ -219,4 +247,8 @@ struct virtio_scsi_inhdr {
> #define VIRTIO_BLK_S_OK 0
> #define VIRTIO_BLK_S_IOERR 1
> #define VIRTIO_BLK_S_UNSUPP 2
> +
> +/* Virtblk ioctl commands */
> +#define VBLK_GET_LIFETIME _IOR('r', 0, struct virtio_blk_lifetime)
> +
> #endif /* _LINUX_VIRTIO_BLK_H */
So this makes the header not self-contained: you need to
pull in ioctl.h. And that's a bit annoying to people
who are used to just have spec defines in this header.
Maybe add a new one virtio_blk_ioctl.h ?
And I'd still like to change VBLK_ prefix here to something like
VIRTIO_BLK_IOCTL_
And maybe document that this is just for specific type of backend
device, and mention the types which benefit, in code comment
if not in the ioctl name.
Thanks!
> --
> 2.32.0
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v3] virtio_blk: add VIRTIO_BLK_F_LIFETIME feature support
2022-12-19 7:59 ` Michael S. Tsirkin
@ 2022-12-19 8:39 ` Alvaro Karsz
0 siblings, 0 replies; 20+ messages in thread
From: Alvaro Karsz @ 2022-12-19 8:39 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Jens Axboe, linux-scsi, linux-nvme, virtualization, linux-block,
dm-devel, Stefan Hajnoczi, Paolo Bonzini
Hi Michael,
Sorry, I had no time to create a new version.
I'll do it today.
Alvaro
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2022-12-19 8:40 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-12-05 16:20 [PATCH v3] virtio_blk: add VIRTIO_BLK_F_LIFETIME feature support Alvaro Karsz
2022-12-05 18:24 ` Jens Axboe
2022-12-05 18:36 ` Alvaro Karsz
2022-12-05 18:53 ` Jens Axboe
2022-12-05 20:29 ` Michael S. Tsirkin
2022-12-05 20:36 ` Jens Axboe
2022-12-05 18:25 ` Jens Axboe
2022-12-06 16:31 ` Stefan Hajnoczi
2022-12-06 16:40 ` Michael S. Tsirkin
2022-12-06 18:25 ` Alvaro Karsz
2022-12-06 18:43 ` Bart Van Assche
2022-12-06 19:56 ` Alvaro Karsz
2022-12-07 7:35 ` Christoph Hellwig
2022-12-07 10:21 ` Michael S. Tsirkin
2022-12-07 16:31 ` Christoph Hellwig
2022-12-07 20:28 ` Michael S. Tsirkin
2022-12-11 9:49 ` Alvaro Karsz
[not found] ` <ccb5388d-4976-31a3-0559-e94c14c90573@nvidia.com>
2022-12-13 6:23 ` Michael S. Tsirkin
2022-12-19 7:59 ` Michael S. Tsirkin
2022-12-19 8:39 ` Alvaro Karsz
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).