Hi everyone,
Thanks for all the comments.
As Gerd created a separate thread for buffer sharing
(https://markmail.org/message/jeh5xjjxvylyrbur), I wonder if we can start a
discussion on the protocol details in this thread now. I think the details of
buffer sharing shouldn't affect overall design o
[Resending after subscribing to virtio-dev, sorry for the noise]
> When running drm-misc-next you should be able to test whenever that'll
> actually work without any virtio-gpu driver changes.
I did some experimentation with the Chrome OS kernel-next branch
(based on v5.4-rc3) plus drm-misc-next.
Hi, I just sent a patch for our virtio-vdec driver to the Linux Media
mailing list:
https://patchwork.kernel.org/patch/11220661/
This implementation uses the initial version of virtio-vdec I proposed
in this thread and doesn't contain David's recent patch for DMA
addresses of virtio-gpu buffers.
I
On Thu, Oct 17, 2019 at 8:00 AM Frank Yang wrote:
>
>
> On Wed, Oct 16, 2019 at 11:58 PM Tomasz Figa wrote:
>
>> On Mon, Oct 14, 2019 at 9:19 PM Gerd Hoffmann wrote:
>> >
>> > > > Well. I think before even discussing the protocol details we need a
>> > > > reasonable plan for buffer handling.
On Wed, Oct 16, 2019 at 11:58 PM Tomasz Figa wrote:
> On Mon, Oct 14, 2019 at 9:19 PM Gerd Hoffmann wrote:
> >
> > > > Well. I think before even discussing the protocol details we need a
> > > > reasonable plan for buffer handling. I think using virtio-gpu
> buffers
> > > > should be an option
> > I doubt you can handle pci memory bars like regular ram when it comes to
> > dma and iommu support. There is a reason we have p2pdma in the first
> > place ...
>
> The thing is that such bars would be actually backed by regular host
> RAM. Do we really need the complexity of real PCI bar hand
Hi,
> That could be still a guest physical address. Like on a bare metal
> system with TrustZone, there could be physical memory that is not
> accessible to the CPU.
Hmm. Yes, maybe. We could use the dma address of the (first page of
the) guest buffer. In case of a secure buffer the guest ha
On Thu, Oct 17, 2019 at 4:44 PM Gerd Hoffmann wrote:
>
> Hi,
>
> > > Also note that the guest manages the address space, so the host can't
> > > simply allocate guest page addresses.
> >
> > Is this really true? I'm not an expert in this area, but on a bare
> > metal system it's the hardware or
On Thu, Oct 17, 2019 at 4:19 PM Gerd Hoffmann wrote:
>
> Hi,
>
> > That said, Chrome OS would use a similar model, except that we don't
> > use ION. We would likely use minigbm backed by virtio-gpu to allocate
> > appropriate secure buffers for us and then import them to the V4L2
> > driver.
>
>
On Tue, Oct 15, 2019 at 11:06 PM Dmitry Morozov
wrote:
>
> Hello Gerd,
>
> On Dienstag, 15. Oktober 2019 09:54:22 CEST Gerd Hoffmann wrote:
> > On Mon, Oct 14, 2019 at 03:05:03PM +0200, Dmitry Morozov wrote:
> > > On Montag, 14. Oktober 2019 14:34:43 CEST Gerd Hoffmann wrote:
> > > > Hi,
> > > >
Hi,
> > Also note that the guest manages the address space, so the host can't
> > simply allocate guest page addresses.
>
> Is this really true? I'm not an expert in this area, but on a bare
> metal system it's the hardware or firmware that sets up the various
> physical address allocations on
Hi,
> That said, Chrome OS would use a similar model, except that we don't
> use ION. We would likely use minigbm backed by virtio-gpu to allocate
> appropriate secure buffers for us and then import them to the V4L2
> driver.
What exactly is a "secure buffer"? I guess a gem object where read
a
On Mon, Oct 14, 2019 at 9:19 PM Gerd Hoffmann wrote:
>
> > > Well. I think before even discussing the protocol details we need a
> > > reasonable plan for buffer handling. I think using virtio-gpu buffers
> > > should be an optional optimization and not a requirement. Also the
> > > motivation
On Fri, Oct 11, 2019 at 5:54 PM Dmitry Morozov
wrote:
>
> Hi Tomasz,
>
> On Mittwoch, 9. Oktober 2019 05:55:45 CEST Tomasz Figa wrote:
> > On Tue, Oct 8, 2019 at 12:09 AM Dmitry Morozov
> >
> > wrote:
> > > Hi Tomasz,
> > >
> > > On Montag, 7. Oktober 2019 16:14:13 CEST Tomasz Figa wrote:
> > > >
Hello Gerd,
On Dienstag, 15. Oktober 2019 09:54:22 CEST Gerd Hoffmann wrote:
> On Mon, Oct 14, 2019 at 03:05:03PM +0200, Dmitry Morozov wrote:
> > On Montag, 14. Oktober 2019 14:34:43 CEST Gerd Hoffmann wrote:
> > > Hi,
> > >
> > > > My take on this (for a decoder) would be to allocate memory
On Mon, Oct 14, 2019 at 03:05:03PM +0200, Dmitry Morozov wrote:
>
> On Montag, 14. Oktober 2019 14:34:43 CEST Gerd Hoffmann wrote:
> > Hi,
> >
> > > My take on this (for a decoder) would be to allocate memory for output
> > > buffers from a secure ION heap, import in the v4l2 driver, and then t
On Montag, 14. Oktober 2019 14:34:43 CEST Gerd Hoffmann wrote:
> Hi,
>
> > My take on this (for a decoder) would be to allocate memory for output
> > buffers from a secure ION heap, import in the v4l2 driver, and then to
> > provide those to the device using virtio. The device side then uses t
Hi,
> My take on this (for a decoder) would be to allocate memory for output
> buffers
> from a secure ION heap, import in the v4l2 driver, and then to provide those
> to the device using virtio. The device side then uses the dmabuf framework to
> make the buffers accessible for the hardware
> > Well. I think before even discussing the protocol details we need a
> > reasonable plan for buffer handling. I think using virtio-gpu buffers
> > should be an optional optimization and not a requirement. Also the
> > motivation for that should be clear (Let the host decoder write directly
>
Hi Tomasz,
On Mittwoch, 9. Oktober 2019 05:55:45 CEST Tomasz Figa wrote:
> On Tue, Oct 8, 2019 at 12:09 AM Dmitry Morozov
>
> wrote:
> > Hi Tomasz,
> >
> > On Montag, 7. Oktober 2019 16:14:13 CEST Tomasz Figa wrote:
> > > Hi Dmitry,
> > >
> > > On Mon, Oct 7, 2019 at 11:01 PM Dmitry Morozov
>
On Tue, Oct 8, 2019 at 12:09 AM Dmitry Morozov
wrote:
>
> Hi Tomasz,
>
> On Montag, 7. Oktober 2019 16:14:13 CEST Tomasz Figa wrote:
> > Hi Dmitry,
> >
> > On Mon, Oct 7, 2019 at 11:01 PM Dmitry Morozov
> >
> > wrote:
> > > Hello,
> > >
> > > We at OpenSynergy are also working on an abstract para
Hi Tomasz,
On Montag, 7. Oktober 2019 16:14:13 CEST Tomasz Figa wrote:
> Hi Dmitry,
>
> On Mon, Oct 7, 2019 at 11:01 PM Dmitry Morozov
>
> wrote:
> > Hello,
> >
> > We at OpenSynergy are also working on an abstract paravirtualized video
> > streaming device that operates input and/or output da
Hi Dmitry,
On Mon, Oct 7, 2019 at 11:01 PM Dmitry Morozov
wrote:
>
> Hello,
>
> We at OpenSynergy are also working on an abstract paravirtualized video
> streaming device that operates input and/or output data buffers and can be
> used
> as a generic video decoder/encoder/input/output device.
>
Hello,
We at OpenSynergy are also working on an abstract paravirtualized video
streaming device that operates input and/or output data buffers and can be used
as a generic video decoder/encoder/input/output device.
We would be glad to share our thoughts and contribute to the discussion.
Please
Hi Gerd,
On Mon, Sep 23, 2019 at 5:56 PM Gerd Hoffmann wrote:
>
> Hi,
>
> > Our prototype implementation uses [4], which allows the virtio-vdec
> > device to use buffers allocated by virtio-gpu device.
>
> > [4] https://lkml.org/lkml/2019/9/12/157
First of all, thanks for taking a look at this
Hi,
> Our prototype implementation uses [4], which allows the virtio-vdec
> device to use buffers allocated by virtio-gpu device.
> [4] https://lkml.org/lkml/2019/9/12/157
Well. I think before even discussing the protocol details we need a
reasonable plan for buffer handling. I think using v
[Resending because of some issues with sending to virtio-dev. Sorry for the
noise.]
This patch proposes virtio specification for new virtio video decode
device.
This device provides the functionality of hardware accelerated video
decoding from encoded video contents provided by the guest into fra
27 matches
Mail list logo
