From: "Michael S. Tsirkin" <mst@redhat.com>
To: Rob Miller <rob.miller@broadcom.com>
Cc: "virtio-dev@lists.oasis-open.org" <virtio-dev@lists.oasis-open.org>
Subject: Re: [virtio-dev] [PATCH] split-ring: Demand that a device must not change descriptor entries
Date: Thu, 30 Jan 2020 06:50:39 -0500 [thread overview]
Message-ID: <20200130064451-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CAJPjb1+Jnm-eHUQSFjhRBKAFNKqceHQMdRWtKEG+uncypGYKcA@mail.gmail.com>
On Mon, Nov 11, 2019 at 12:17:51PM -0500, Rob Miller wrote:
> On Mon, Nov 11, 2019 at 12:13 PM Jan Kiszka <jan.kiszka@siemens.com> wrote:
>
> From: Jan Kiszka <jan.kiszka@siemens.com>
>
> So far the spec only indirectly says that a descriptor table entry is
> not modified by a device when processing it. Make this explicit by
> adding it as normative requirement. Existing drivers already depend on
> this.
>
> See also https://lists.oasis-open.org/archives/virtio-dev/201910/
> msg00057.html.
>
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> ---
> split-ring.tex | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/split-ring.tex b/split-ring.tex
> index 123ac9f..bfef62d 100644
> --- a/split-ring.tex
> +++ b/split-ring.tex
> @@ -217,7 +217,7 @@ \subsection{The Virtqueue Descriptor Table}\label
> {sec:Basic Facilities of a Virt
> \devicenormative{\subsubsection}{The Virtqueue Descriptor Table}{Basic
> Facilities of a Virtio Device / Virtqueues / The Virtqueue Descriptor
> Table}
> A device MUST NOT write to a device-readable buffer, and a device SHOULD
> NOT
> read a device-writable buffer (it MAY do so for debugging or diagnostic
> -purposes).
> +purposes). A device MUST NOT write to any descriptor table entry.
>
> \drivernormative{\subsubsection}{The Virtqueue Descriptor Table}{Basic
> Facilities of a Virtio Device / Virtqueues / The Virtqueue Descriptor
> Table}
> Drivers MUST NOT add a descriptor chain longer than $2^{32}$ bytes in
> total;
> --
> 2.16.4
>
>
> what is trying to be solved here? There is a reason why this is allowed as some
> vendors update the table when using RX_MERABLE_BUFFERs & F_IN_ORDER features
>
> Rob Miller
> rob.miller@broadcom.com
> (919)721-3339
>
>
Going back to this, I don't see how this can work with current Linux
guests at least when VIRTIO_F_IOMMU_PLATFORM is specified, since
the data is mapped to devices as follows:
dma_addr_t addr = vring_map_one_sg(vq, sg, DMA_TO_DEVICE);
and I guess we all agreed physical devices all set this flag?
Could you explain a bit more about how writing into descriptors
is useful with RX_MERABLE_BUFFERs?
--
MST
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
prev parent reply other threads:[~2020-01-30 11:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-11 17:13 [virtio-dev] [PATCH] split-ring: Demand that a device must not change descriptor entries Jan Kiszka
2019-11-11 17:17 ` Rob Miller
2019-11-11 17:26 ` Jan Kiszka
2020-02-27 10:05 ` Michael S. Tsirkin
2020-03-02 12:01 ` Rob Miller
2020-03-02 12:13 ` Michael S. Tsirkin
2020-03-02 12:45 ` Jan Kiszka
2020-01-30 11:50 ` Michael S. Tsirkin [this message]
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=20200130064451-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=rob.miller@broadcom.com \
--cc=virtio-dev@lists.oasis-open.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