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
26 matches
Mail list logo