All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Alexandre Courbot <acourbot@chromium.org>
Cc: "Dmitry Sepp" <dmitry.sepp@opensynergy.com>,
	"Keiichi Watanabe" <keiichiw@chromium.org>,
	virtio-dev@lists.oasis-open.org,
	"Linux Media Mailing List" <linux-media@vger.kernel.org>,
	"Alex Lau" <alexlau@chromium.org>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Dylan Reid" <dgreid@chromium.org>,
	"David Staessens" <dstaessens@chromium.org>,
	"Enrico Granata" <egranata@google.com>,
	"Frediano Ziglio" <fziglio@redhat.com>,
	"Hans Verkuil" <hverkuil@xs4all.nl>,
	"Gerd Hoffmann" <kraxel@redhat.com>,
	"Stéphane Marchesin" <marcheu@chromium.org>,
	"Pawel Osciak" <posciak@chromium.org>,
	spice-devel@lists.freedesktop.org,
	"David Stevens" <stevensd@chromium.org>,
	"Tomasz Figa" <tfiga@chromium.org>,
	uril@redhat.com,
	"Samiullah Khawaja" <samiullah.khawaja@opensynergy.com>,
	"Kiran Pawar" <kiran.pawar@opensynergy.com>,
	"Saket Sinha" <saket.sinha89@gmail.com>,
	"Laurent Pinchart" <laurent.pinchart@ideasonboard.com>,
	"Nicolas Dufresne" <nicolas@ndufresne.ca>
Subject: [virtio-dev] Re: [PATCH RFC v4 0/1] Virtio Video Device Specification
Date: Fri, 3 Jul 2020 05:18:20 -0400	[thread overview]
Message-ID: <20200703051756-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CAPBb6MWqYHidfaaTKq43yDtjOmKEi=AMC3O9vLdWpPBd_vFrUA@mail.gmail.com>

On Fri, Jul 03, 2020 at 02:45:15PM +0900, Alexandre Courbot wrote:
> Hi Dmitry,
> 
> On Thu, Jul 2, 2020 at 10:47 PM Dmitry Sepp <dmitry.sepp@opensynergy.com> wrote:
> >
> > Hi Keiichi,
> >
> > Thanks for the clarification. I believe we should explicitly describe this in
> > the VIRTIO_VIDEO_CMD_RESOURCE_ATTACH section. And I also still see a problem
> > there. If it is a guest allocated resource, we cannot consider it to be free
> > until the device really releases it. And it won't happen until we issue the
> > next ATTACH call. Also, as we discussed before, it might be not possible to
> > free individual buffers, but the whole queue only.
> 
> In the case of the encoder, a V4L2 driver is not supposed to let
> user-space dequeue an input frame while it is used as reference for
> the encoding process. So if we add a similar rule in the virtio-video
> specification, I suppose this would solve the problem?
> 
> For the decoder case, we have a bigger problem though. Since DMABUFs
> can be arbitrarily attached to any V4L2 buffer ID, we may end up
> re-queueing the DMABUF of a decoded frame that is still used as
> reference under a different V4L2 buffer ID. In this case I don't think
> the driver has a way to know that the memory resource should not be
> overwritten, and it will thus happily use it as a decode target. The
> easiest fix is probably to update the V4L2 stateful specification to
> require that reused DMABUFs must always be assigned to the same V4L2
> buffer ID, and must be kept alive as long as decoding is in progress,
> or until a resolution change event is received. We can then apply a
> similar rule to the virtio device.


Sounds like a generic kind of problem - how do other devices solve it?


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


WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Alexandre Courbot <acourbot@chromium.org>
Cc: "Dmitry Sepp" <dmitry.sepp@opensynergy.com>,
	"Keiichi Watanabe" <keiichiw@chromium.org>,
	virtio-dev@lists.oasis-open.org,
	"Linux Media Mailing List" <linux-media@vger.kernel.org>,
	"Alex Lau" <alexlau@chromium.org>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Dylan Reid" <dgreid@chromium.org>,
	"David Staessens" <dstaessens@chromium.org>,
	"Enrico Granata" <egranata@google.com>,
	"Frediano Ziglio" <fziglio@redhat.com>,
	"Hans Verkuil" <hverkuil@xs4all.nl>,
	"Gerd Hoffmann" <kraxel@redhat.com>,
	"Stéphane Marchesin" <marcheu@chromium.org>,
	"Pawel Osciak" <posciak@chromium.org>,
	spice-devel@lists.freedesktop.org,
	"David Stevens" <stevensd@chromium.org>,
	"Tomasz Figa" <tfiga@chromium.org>,
	uril@redhat.com,
	"Samiullah Khawaja" <samiullah.khawaja@opensynergy.com>,
	"Kiran Pawar" <kiran.pawar@opensynergy.com>,
	"Saket Sinha" <saket.sinha89@gmail.com>,
	"Laurent Pinchart" <laurent.pinchart@ideasonboard.com>,
	"Nicolas Dufresne" <nicolas@ndufresne.ca>
Subject: Re: [PATCH RFC v4 0/1] Virtio Video Device Specification
Date: Fri, 3 Jul 2020 05:18:20 -0400	[thread overview]
Message-ID: <20200703051756-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CAPBb6MWqYHidfaaTKq43yDtjOmKEi=AMC3O9vLdWpPBd_vFrUA@mail.gmail.com>

On Fri, Jul 03, 2020 at 02:45:15PM +0900, Alexandre Courbot wrote:
> Hi Dmitry,
> 
> On Thu, Jul 2, 2020 at 10:47 PM Dmitry Sepp <dmitry.sepp@opensynergy.com> wrote:
> >
> > Hi Keiichi,
> >
> > Thanks for the clarification. I believe we should explicitly describe this in
> > the VIRTIO_VIDEO_CMD_RESOURCE_ATTACH section. And I also still see a problem
> > there. If it is a guest allocated resource, we cannot consider it to be free
> > until the device really releases it. And it won't happen until we issue the
> > next ATTACH call. Also, as we discussed before, it might be not possible to
> > free individual buffers, but the whole queue only.
> 
> In the case of the encoder, a V4L2 driver is not supposed to let
> user-space dequeue an input frame while it is used as reference for
> the encoding process. So if we add a similar rule in the virtio-video
> specification, I suppose this would solve the problem?
> 
> For the decoder case, we have a bigger problem though. Since DMABUFs
> can be arbitrarily attached to any V4L2 buffer ID, we may end up
> re-queueing the DMABUF of a decoded frame that is still used as
> reference under a different V4L2 buffer ID. In this case I don't think
> the driver has a way to know that the memory resource should not be
> overwritten, and it will thus happily use it as a decode target. The
> easiest fix is probably to update the V4L2 stateful specification to
> require that reused DMABUFs must always be assigned to the same V4L2
> buffer ID, and must be kept alive as long as decoding is in progress,
> or until a resolution change event is received. We can then apply a
> similar rule to the virtio device.


Sounds like a generic kind of problem - how do other devices solve it?


  reply	other threads:[~2020-07-03  9:18 UTC|newest]

Thread overview: 31+ 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 ` Keiichi Watanabe
2020-06-23 11:13 ` [virtio-dev] [PATCH RFC v4 1/1] virtio-video: Add virtio video device specification Keiichi Watanabe
2020-06-23 11:13   ` Keiichi Watanabe
2020-07-02  7:32 ` [virtio-dev] Re: [PATCH RFC v4 0/1] Virtio Video Device Specification Dmitry Sepp
2020-07-02  7:32   ` Dmitry Sepp
2020-07-02 12:50   ` [virtio-dev] " Keiichi Watanabe
2020-07-02 12:50     ` Keiichi Watanabe
2020-07-02 13:47     ` [virtio-dev] " Dmitry Sepp
2020-07-02 13:47       ` Dmitry Sepp
2020-07-03  5:45       ` [virtio-dev] " Alexandre Courbot
2020-07-03  5:45         ` Alexandre Courbot
2020-07-03  9:18         ` Michael S. Tsirkin [this message]
2020-07-03  9:18           ` Michael S. Tsirkin
2020-07-03  9:26           ` [virtio-dev] " Alexandre Courbot
2020-07-03  9:26             ` Alexandre Courbot
2020-07-03  9:55             ` [virtio-dev] " Tomasz Figa
2020-07-03  9:55               ` Tomasz Figa
2020-07-06 10:49               ` [virtio-dev] " Dmitry Sepp
2020-07-06 10:49                 ` Dmitry Sepp
2020-07-08  4:35               ` [virtio-dev] " Alexandre Courbot
2020-07-08  4:35                 ` Alexandre Courbot
2020-07-08 12:55                 ` [virtio-dev] " Tomasz Figa
2020-07-08 12:55                   ` Tomasz Figa
2021-01-14 17:55 ` [virtio-dev] " Alex Bennée
2021-01-14 17:55   ` Alex Bennée
2021-01-15 14:25   ` Keiichi Watanabe
2021-01-15 16:55     ` Matti Moell
2021-01-15 16:55       ` Matti Moell
2021-01-18 11:15       ` Alexandre Courbot
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=20200703051756-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --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=nicolas@ndufresne.ca \
    --cc=posciak@chromium.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 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.