get:
Show a patch.

patch:
Update a patch.

put:
Update a patch.

GET /api/1.1/patches/2230473/?format=api
HTTP 200 OK
Allow: GET, PUT, PATCH, HEAD, OPTIONS
Content-Type: application/json
Vary: Accept

{
    "id": 2230473,
    "url": "http://patchwork.ozlabs.org/api/1.1/patches/2230473/?format=api",
    "web_url": "http://patchwork.ozlabs.org/project/qemu-devel/patch/20260429185504.221124-1-stefanha@redhat.com/",
    "project": {
        "id": 14,
        "url": "http://patchwork.ozlabs.org/api/1.1/projects/14/?format=api",
        "name": "QEMU Development",
        "link_name": "qemu-devel",
        "list_id": "qemu-devel.nongnu.org",
        "list_email": "qemu-devel@nongnu.org",
        "web_url": "",
        "scm_url": "",
        "webscm_url": ""
    },
    "msgid": "<20260429185504.221124-1-stefanha@redhat.com>",
    "date": "2026-04-29T18:55:04",
    "name": "[RFC] vhost-user.rst: clarify when rings are started",
    "commit_ref": null,
    "pull_url": null,
    "state": "new",
    "archived": false,
    "hash": "239502f68a1858386397cc6dd7d969debde6a027",
    "submitter": {
        "id": 17227,
        "url": "http://patchwork.ozlabs.org/api/1.1/people/17227/?format=api",
        "name": "Stefan Hajnoczi",
        "email": "stefanha@redhat.com"
    },
    "delegate": null,
    "mbox": "http://patchwork.ozlabs.org/project/qemu-devel/patch/20260429185504.221124-1-stefanha@redhat.com/mbox/",
    "series": [
        {
            "id": 502135,
            "url": "http://patchwork.ozlabs.org/api/1.1/series/502135/?format=api",
            "web_url": "http://patchwork.ozlabs.org/project/qemu-devel/list/?series=502135",
            "date": "2026-04-29T18:55:04",
            "name": "[RFC] vhost-user.rst: clarify when rings are started",
            "version": 1,
            "mbox": "http://patchwork.ozlabs.org/series/502135/mbox/"
        }
    ],
    "comments": "http://patchwork.ozlabs.org/api/patches/2230473/comments/",
    "check": "pending",
    "checks": "http://patchwork.ozlabs.org/api/patches/2230473/checks/",
    "tags": {},
    "headers": {
        "Return-Path": "<qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org>",
        "X-Original-To": "incoming@patchwork.ozlabs.org",
        "Delivered-To": "patchwork-incoming@legolas.ozlabs.org",
        "Authentication-Results": [
            "legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256\n header.s=mimecast20190719 header.b=eEub15a2;\n\tdkim-atps=neutral",
            "legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists1p.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)"
        ],
        "Received": [
            "from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g5RNB6P0hz1yHZ\n\tfor <incoming@patchwork.ozlabs.org>; Thu, 30 Apr 2026 04:56:09 +1000 (AEST)",
            "from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists1p.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from <qemu-devel-bounces@nongnu.org>)\n\tid 1wIA4M-0006I2-21; Wed, 29 Apr 2026 14:55:34 -0400",
            "from eggs.gnu.org ([2001:470:142:3::10])\n by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from <stefanha@redhat.com>)\n id 1wIA47-0006F8-VF\n for qemu-devel@nongnu.org; Wed, 29 Apr 2026 14:55:22 -0400",
            "from us-smtp-delivery-124.mimecast.com ([170.10.133.124])\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from <stefanha@redhat.com>)\n id 1wIA43-0005kw-TV\n for qemu-devel@nongnu.org; Wed, 29 Apr 2026 14:55:17 -0400",
            "from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com\n (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by\n relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,\n cipher=TLS_AES_256_GCM_SHA384) id us-mta-50-Co6-PqxyNzSbWAegYjm-vA-1; Wed,\n 29 Apr 2026 14:55:10 -0400",
            "from mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com\n (mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.17])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n (No client certificate requested)\n by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS\n id C9D511956050; Wed, 29 Apr 2026 18:55:08 +0000 (UTC)",
            "from localhost (unknown [10.44.33.46])\n by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP\n id 429C6195608E; Wed, 29 Apr 2026 18:55:06 +0000 (UTC)"
        ],
        "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n s=mimecast20190719; t=1777488914;\n h=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n to:to:cc:cc:mime-version:mime-version:\n content-transfer-encoding:content-transfer-encoding;\n bh=qmAEdggD+w50lBQGh+VtjNZdFkz+DqfnR7K9I7DbZ78=;\n b=eEub15a2W7Jc2yAD2FpnsPW7AxdldFwY8k055By7BQJEJJJLi4777bcQm2YpEIhAx2eVJy\n 4o6iJGzOsf1RPaeCN56B9g/mJ00QQLC/YnIxkeI5GsOse9qHR2S9Qv7BkXpbw82ctCVMDX\n q88S6HHcoR6cqg2tJEuBXr9L1Epi7r0=",
        "X-MC-Unique": "Co6-PqxyNzSbWAegYjm-vA-1",
        "X-Mimecast-MFC-AGG-ID": "Co6-PqxyNzSbWAegYjm-vA_1777488909",
        "From": "Stefan Hajnoczi <stefanha@redhat.com>",
        "To": "qemu-devel@nongnu.org",
        "Cc": "hreitz@redhat.com, \"Michael S. Tsirkin\" <mst@redhat.com>,\n gmaglione@redhat.com, Stefano Garzarella <sgarzare@redhat.com>,\n Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>,\n Pierrick Bouvier <pierrick.bouvier@linaro.org>,\n Stefan Hajnoczi <stefanha@redhat.com>, Jorge Moreira <jemoreira@google.com>",
        "Subject": "[RFC] vhost-user.rst: clarify when rings are started",
        "Date": "Wed, 29 Apr 2026 14:55:04 -0400",
        "Message-ID": "<20260429185504.221124-1-stefanha@redhat.com>",
        "MIME-Version": "1.0",
        "Content-Transfer-Encoding": "8bit",
        "X-Scanned-By": "MIMEDefang 3.0 on 10.30.177.17",
        "Received-SPF": "pass client-ip=170.10.133.124;\n envelope-from=stefanha@redhat.com;\n helo=us-smtp-delivery-124.mimecast.com",
        "X-Spam_score_int": "12",
        "X-Spam_score": "1.2",
        "X-Spam_bar": "+",
        "X-Spam_report": "(1.2 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001,\n DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,\n RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001,\n RCVD_IN_SBL_CSS=3.335, SPF_HELO_PASS=-0.001,\n SPF_PASS=-0.001 autolearn=no autolearn_force=no",
        "X-Spam_action": "no action",
        "X-BeenThere": "qemu-devel@nongnu.org",
        "X-Mailman-Version": "2.1.29",
        "Precedence": "list",
        "List-Id": "qemu development <qemu-devel.nongnu.org>",
        "List-Unsubscribe": "<https://lists.nongnu.org/mailman/options/qemu-devel>,\n <mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>",
        "List-Archive": "<https://lists.nongnu.org/archive/html/qemu-devel>",
        "List-Post": "<mailto:qemu-devel@nongnu.org>",
        "List-Help": "<mailto:qemu-devel-request@nongnu.org?subject=help>",
        "List-Subscribe": "<https://lists.nongnu.org/mailman/listinfo/qemu-devel>,\n <mailto:qemu-devel-request@nongnu.org?subject=subscribe>",
        "Errors-To": "qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org",
        "Sender": "qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"
    },
    "content": "Jorge Moreira <jemoreira@google.com> pointed out that the ring state\nmachine is underspecified. In the discussion that followed, we\ndiscovered that the spec says one thing and implementations do something\nelse. This patch updates the spec to reflect how things are actually\nimplemented across widely-used front-ends and back-ends including QEMU,\ncrosvm, rust-vmm, and DPDK. Do this while taking care not to make any\nother existing implementations non-compliant by changing the sepc.\n\nThe spec says rings are started when a kick is received but the\nimplementations actually start rings when VHOST_USER_SET_VRING_KICK is\nreceived.\n\nReconcile this as follows:\n- Clarify that a ring can be stopped and then started again. The\n  back-end must resume processing available requests when the ring is\n  restarted.\n- Update the spec to say rings are started when\n  VHOST_USER_SET_VRING_KICK is received.\n- Ensure compatibility by saying front-ends SHOULD inject a kick in case\n  the back-end strictly implemented the old spec.\n- Avoid future back-end dependencies on injected kicks by saying that\n  back-ends SHOULD NOT expect a kick to start rings.\n\nThis way implementors have clarity on how things work while still\nallowing compatibility for existing implementations.\n\nReported-by: Jorge Moreira <jemoreira@google.com>\nCc: \"Michael S . Tsirkin\" <mst@redhat.com>\nCc: Stefano Garzarella <sgarzare@redhat.com>\nSigned-off-by: Stefan Hajnoczi <stefanha@redhat.com>\n---\nThis is an RFC because I will update hw/virtio/vhost-user.c and\nlibvhost-user once we've agreed on the spec wording.\n\n docs/interop/vhost-user.rst | 24 ++++++++++++++++++------\n 1 file changed, 18 insertions(+), 6 deletions(-)",
    "diff": "diff --git a/docs/interop/vhost-user.rst b/docs/interop/vhost-user.rst\nindex 137c9f3669..72d792930e 100644\n--- a/docs/interop/vhost-user.rst\n+++ b/docs/interop/vhost-user.rst\n@@ -462,12 +462,24 @@ Rings have two independent states: started/stopped, and enabled/disabled.\n * started and enabled: The back-end must process the ring normally, i.e.\n   process all requests and execute them.\n \n-Each ring is initialized in a stopped and disabled state.  The back-end\n-must start a ring upon receiving a kick (that is, detecting that file\n-descriptor is readable) on the descriptor specified by\n-``VHOST_USER_SET_VRING_KICK`` or receiving the in-band message\n-``VHOST_USER_VRING_KICK`` if negotiated, and stop a ring upon receiving\n-``VHOST_USER_GET_VRING_BASE``.\n+Each ring is initialized in a stopped and disabled state.  Rings are started\n+with ``VHOST_USER_SET_VRING_KICK`` and stopped with\n+``VHOST_USER_GET_VRING_BASE``. A stopped ring enters the started state again\n+with ``VHOST_USER_SET_VRING_KICK`` and the back-end resumes processing\n+requests.\n+\n+Note that previous versions of this specification stated that rings start when\n+the back-end receives a kick (that is, detecting that file descriptor is\n+readable) on the descriptor specified by ``VHOST_USER_SET_VRING_KICK`` or\n+receiving the in-band message ``VHOST_USER_VRING_KICK`` if negotiated.\n+Widely-used front-ends and back-ends did not implement this behavior and it\n+complicates poll mode back-ends that do not rely on the kick file descriptor.\n+\n+For compatibility with back-ends that implemented the start on kick behavior,\n+front-ends SHOULD inject a kick after ``VHOST_USER_SET_VRING_KICK``.  This\n+ensures that the back-end processes any available requests in the ring.\n+Back-ends SHOULD NOT rely on receiving a kick after\n+``VHOST_USER_SET_VRING_KICK``.\n \n Rings can be enabled or disabled by ``VHOST_USER_SET_VRING_ENABLE``.\n \n",
    "prefixes": [
        "RFC"
    ]
}