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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.