Discussion of the implementations of VIRTIO specification
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Keiichi Watanabe <keiichiw@chromium.org>
Cc: linux-media@vger.kernel.org, acourbot@chromium.org,
	alexlau@chromium.org, daniel@ffwll.ch, dgreid@chromium.org,
	dstaessens@chromium.org, dmitry.sepp@opensynergy.com,
	egranata@google.com, fziglio@redhat.com, hverkuil@xs4all.nl,
	kraxel@redhat.com, marcheu@chromium.org, posciak@chromium.org,
	spice-devel@lists.freedesktop.org, stevensd@chromium.org,
	tfiga@chromium.org, uril@redhat.com,
	samiullah.khawaja@opensynergy.com, kiran.pawar@opensynergy.com,
	saket.sinha89@gmail.com, laurent.pinchart@ideasonboard.com,
	nicolas@ndufresne.ca, mst@redhat.com,
	virtio-dev@lists.oasis-open.org,
	Ruchika Gupta <ruchika.gupta@linaro.org>,
	Peter Griffin <peter.griffin@linaro.org>,
	Mike Holmes <mike.holmes@linaro.org>
Subject: Re: [virtio-dev] [PATCH RFC v4 0/1] Virtio Video Device Specification
Date: Thu, 14 Jan 2021 17:55:39 +0000	[thread overview]
Message-ID: <87czy7l6uu.fsf@linaro.org> (raw)
In-Reply-To: <20200623111325.237158-1-keiichiw@chromium.org>


Keiichi Watanabe <keiichiw@chromium.org> writes:

> This is the v4 RFC of virtio video device specification.
> PDF versions are available at [1, 2].
>
> Note that this patch depends on a recent patchset "Cross-device resource
> sharing" [3].
>
> Here is a list of major changes from v3:
> * Redesingned struct definitions for each command and request based on
>   discussions at [4].
> * Renamed commands/structs/enums to more descriptive names.
> * Had different structs and fields for image formats and bitstream formats.
> * Added more detailed specification for supported video codecs.
> * Made stream_id be allocated by the device.
> * Had a single parameter struct per-stream instead of per-queue parameters and
>   controls.
> * Allowed the driver to specify the number of buffers to use via
>   "cur_{image,bitstream}_buffers".
> * Renamed RESOURCE_CREATE command to RESOURCE_ATTACH command and allow the
>   driver to use this command when replacing backing memories as well.
>
> [5] is the diff of the header file from v3. Note that it only contains changes
> in the header. We haven't updated the driver nor device implementation to focus
> on protocol design discussion first.
>
> While it may appear that many parts have been changed since the previous
> revision, these changes are to address the issues raised in previous discussions
> or/and to make the protocol simpler and easier to prevent misuse.
> I'd appreciate any types of feedback.
>
> Best regards,
> Keiichi
>
> [1] (full): https://drive.google.com/file/d/1DiOJZfUJ5wvFtnNFQicxt0zkp4Ob1o9C/view?usp=sharing
> [2] (only video section): https://drive.google.com/file/d/188uAkIWE0BsXETECez98y5fJKw8rslj3/view?usp=sharing
> [3] https://lists.oasis-open.org/archives/virtio-comment/202003/msg00035.html
> [4] https://markmail.org/thread/c6h3e3zn647qli3w
> [5]
> https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2164411

Hi Keiichi,

I wanted to ask what the current status of this spec was. Are you
planning to submit a new revision of the specification due or are things
fairly stable now?

We are starting to think about next steps for virtualised video as part
of Linaro's Stratos work. Specifically we are thinking about
implementing backends and getting a stack up and running which we can
use to experiment with multiple hypervisors and VM deployment
approaches.

Longer term goals included looking at how to integrate virtio-video with
a secure world on ARM (e.g. feed video data to a secure world device for
playback via virtio). As part of that we will also be looking at how to
minimise the memory profile of the backend to do this.

Looking at the virtio-spec repo it looks like the cross-device resource
sharing is now merged:

  87fa6b5 * virtio-gpu: add support for mapping/unmapping blob resources
  89e7eb5 * virtio-gpu: add resource create blob
  162578b * virtio-gpu: add the ability to export resources
  68f66ff * content: define what an exported object is

are there any other prerequisites?

From a backend implementation point of view it makes sense to wait until
there is a working frontend driver up-streamed into the kernel. I guess
that is blocked on the final call for vote on the virtio spec?

I'm sure there is scope for parallelism here but I wanted to get a sense
of the current direction before embarking on work that would require a
big re-write down the line.

Regards,

-- 
Alex Bennée

---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org


  parent reply	other threads:[~2021-01-14 18:18 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-23 11:13 [virtio-dev] [PATCH RFC v4 0/1] Virtio Video Device Specification Keiichi Watanabe
2020-06-23 11:13 ` [virtio-dev] [PATCH RFC v4 1/1] virtio-video: Add virtio video device specification Keiichi Watanabe
2020-07-02  7:32 ` [virtio-dev] Re: [PATCH RFC v4 0/1] Virtio Video Device Specification Dmitry Sepp
2020-07-02 12:50   ` Keiichi Watanabe
2020-07-02 13:47     ` Dmitry Sepp
2020-07-03  5:45       ` Alexandre Courbot
2020-07-03  9:18         ` Michael S. Tsirkin
2020-07-03  9:26           ` Alexandre Courbot
2020-07-03  9:55             ` Tomasz Figa
2020-07-06 10:49               ` Dmitry Sepp
2020-07-08  4:35               ` Alexandre Courbot
2020-07-08 12:55                 ` Tomasz Figa
2021-01-14 17:55 ` Alex Bennée [this message]
2021-01-15 14:25   ` [virtio-dev] " Keiichi Watanabe
2021-01-15 16:55     ` Matti Moell
2021-01-18 11:15       ` Alexandre Courbot

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=87czy7l6uu.fsf@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=acourbot@chromium.org \
    --cc=alexlau@chromium.org \
    --cc=daniel@ffwll.ch \
    --cc=dgreid@chromium.org \
    --cc=dmitry.sepp@opensynergy.com \
    --cc=dstaessens@chromium.org \
    --cc=egranata@google.com \
    --cc=fziglio@redhat.com \
    --cc=hverkuil@xs4all.nl \
    --cc=keiichiw@chromium.org \
    --cc=kiran.pawar@opensynergy.com \
    --cc=kraxel@redhat.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    --cc=marcheu@chromium.org \
    --cc=mike.holmes@linaro.org \
    --cc=mst@redhat.com \
    --cc=nicolas@ndufresne.ca \
    --cc=peter.griffin@linaro.org \
    --cc=posciak@chromium.org \
    --cc=ruchika.gupta@linaro.org \
    --cc=saket.sinha89@gmail.com \
    --cc=samiullah.khawaja@opensynergy.com \
    --cc=spice-devel@lists.freedesktop.org \
    --cc=stevensd@chromium.org \
    --cc=tfiga@chromium.org \
    --cc=uril@redhat.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