From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Mark Syms <mark.syms@cloud.com>
Cc: qemu-devel@nongnu.org, xen-devel@lists.xenproject.org,
sstabellini@kernel.org, anthony@xenproject.org, paul@xen.org
Subject: Re: [PATCH] [xen-block] Return BLKIF_RSP_EOPNOTSUPP for unknown operation
Date: Thu, 28 Aug 2025 09:39:13 +0200 [thread overview]
Message-ID: <aLAHoR3BtBz9G9Q0@Mac.lan> (raw)
In-Reply-To: <20250827160841.351707-1-mark.syms@cloud.com>
On Wed, Aug 27, 2025 at 05:08:41PM +0100, Mark Syms via wrote:
> Returning BLKIF_RSP_ERROR if an operation is not supoprted does not
> allow the frontend to exercise any discretion on how to handle the
> response and may lead to an operating system crash. As different
> backends may support different feature sets and we might, during a
> migration, switch backends, an in-flight request might be issued (or
> reissued) which is then not supported by this backend.
Linux blkfront at least will empty the ring on resume, and re-process
and queue the requests after having negotiated the (possibly) new set
of features with the backend. That however doesn't avoid finding
flush requests that might not longer be supported by the new backend,
in which case Linux blkfront will drop such requests.
I assume the fixes done here are not targeted at dealing with a Linux
blkfront?
> Signed-off-by: Mark Syms <mark.syms@cloud.com>
> ---
> hw/block/dataplane/xen-block.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/hw/block/dataplane/xen-block.c b/hw/block/dataplane/xen-block.c
> index 48c2e315f3..32cf919a97 100644
> --- a/hw/block/dataplane/xen-block.c
> +++ b/hw/block/dataplane/xen-block.c
> @@ -167,7 +167,8 @@ static int xen_block_parse_request(XenBlockRequest *request)
> return 0;
> default:
> error_report("error: unknown operation (%d)", request->req.operation);
> - goto err;
> + request->status = BLKIF_RSP_EOPNOTSUPP;
> + return -1;
The comment in blkif.h contains:
/* Operation not supported (only happens on barrier writes). */
#define BLKIF_RSP_EOPNOTSUPP -2
So in principle BLKIF_RSP_EOPNOTSUPP is only to be used as a response
for BLKIF_OP_WRITE_BARRIER or BLKIF_OP_FLUSH_DISKCACHE requests,
however blkback already uses it as a response to unknown request
types (like you propose here).
Would you mind also sending a patch to adjust blkif.h in Xen to remove
the "(only happens on barrier writes)" part of the comment?
Thanks Roger.
next prev parent reply other threads:[~2025-08-28 7:39 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-27 16:08 [PATCH] [xen-block] Return BLKIF_RSP_EOPNOTSUPP for unknown operation Mark Syms via
2025-08-28 7:39 ` Roger Pau Monné [this message]
2025-08-28 9:28 ` Mark Syms
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aLAHoR3BtBz9G9Q0@Mac.lan \
--to=roger.pau@citrix.com \
--cc=anthony@xenproject.org \
--cc=mark.syms@cloud.com \
--cc=paul@xen.org \
--cc=qemu-devel@nongnu.org \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).