[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJSP0QX7H5F=rzz=STeWWYZbTxog0S-MARXgoHkR=u04qTD+_w@mail.gmail.com>
Date: Mon, 22 Jan 2024 12:47:25 -0500
From: Stefan Hajnoczi <stefanha@...il.com>
To: Chaitanya Kulkarni <chaitanyak@...dia.com>
Cc: Stefan Hajnoczi <stefanha@...hat.com>,
"virtualization@...ts.linux.dev" <virtualization@...ts.linux.dev>,
"linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "mst@...hat.com" <mst@...hat.com>, "hch@....de" <hch@....de>,
"jasowang@...hat.com" <jasowang@...hat.com>, "pbonzini@...hat.com" <pbonzini@...hat.com>,
"xuanzhuo@...ux.alibaba.com" <xuanzhuo@...ux.alibaba.com>, "axboe@...nel.dk" <axboe@...nel.dk>,
Ming Lei <ming.lei@...hat.com>
Subject: Re: [RFC PATCH 1/1] virtio-blk: process block layer timedout request
On Mon, 8 Jan 2024 at 22:33, Chaitanya Kulkarni <chaitanyak@...dia.com> wrote:
> On 11/30/23 17:25, Stefan Hajnoczi wrote:
> > On Wed, Nov 29, 2023 at 11:01:33PM -0800, Chaitanya Kulkarni wrote:
> >> diff --git a/include/uapi/linux/virtio_blk.h b/include/uapi/linux/virtio_blk.h
> >> index 3744e4da1b2a..ed864195ab26 100644
> >> --- a/include/uapi/linux/virtio_blk.h
> >> +++ b/include/uapi/linux/virtio_blk.h
> >> @@ -317,6 +317,7 @@ struct virtio_scsi_inhdr {
> >> #define VIRTIO_BLK_S_OK 0
> >> #define VIRTIO_BLK_S_IOERR 1
> >> #define VIRTIO_BLK_S_UNSUPP 2
> >> +#define VIRTIO_BLK_S_TIMEOUT 3
> > The structs and constants in this header file come from the VIRTIO
> > specification. Anything changed in this file must first be accepted into
> > the VIRTIO spec because this is the hardware interface definition.
> >
> > VIRTIO_BLK_S_TIMEOUT seems to be synthetic value that is purely used by
> > software, not the device. Maybe there is no need to update the spec.
> > Just avoid using in_hdr.status to signal timeouts and use a separate
> > flag/field instead in a block layer or virtio_blk driver request struct.
>
> It is a specific error hence I've added that on the similar lines,
> do you have a specific field in mind that you would prefer ?
I didn't have a specific flag or field in mind, but it's probably no
longer necessary in v2 because the code needs to wait for the device
to complete the request anyway.
Stefan
Powered by blists - more mailing lists