OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [PATCH v2 1/1] video_video: Add the Virtio Video V4L2 driver


On Fri, Mar 13, 2020 at 11:27 AM Dmitry Sepp
<dmitry.sepp@opensynergy.com> wrote:
>
> Hi Tomasz,
>
> On Freitag, 13. MÃrz 2020 11:05:35 CET Tomasz Figa wrote:
> > On Thu, Mar 12, 2020 at 12:48 PM Dmitry Sepp
> >
> > <dmitry.sepp@opensynergy.com> wrote:
> > > Hi Hans,
> > >
> > > One more thing:
> > > > GFP_DMA? That's unusual. I'd expect GFP_DMA32. All V4L2 drivers use
> > > > that.
> > >
> > > GFP_DMA32 had no effect for me on arm64. Probably I need to recheck.
> >
> > What's the reason to use any specific GFP flags at all? GFP_DMA(32)
> > memory in the guest would typically correspond to host pages without
> > any specific location guarantee.
> >
>
> Typically, but not always, especially for non x86. Say, some platforms don't
> have IOMMUs for codec devices and those devices require physically contig low
> memory. We had to find a way to handle that.

So basically your hypervisor guarantees that the guest pages inside
the GFP_DMA zone are contiguous and DMA-able on the host as well?
Given the Linux-specific aspect of GFP flags and differences in the
implementation across architectures, perhaps it would be a better idea
to use the DMA mask instead? That wouldn't currently affect vb2_dma_sg
allocations, but in that case the host decoder would have some IOMMU
anyway, right?

>
> Best regards,
> Dmitry.
>
> > Best regards,
> > Tomasz
> >
> > > Best regards,
> > > Dmitry.
> > >
> > > On Donnerstag, 12. MÃrz 2020 11:18:26 CET Hans Verkuil wrote:
> > > > On 3/12/20 11:15 AM, Dmitry Sepp wrote:
> > > > > Hi Hans,
> > > > >
> > > > > Thank you for your great detailed review!
> > > > >
> > > > > I won't provide inline answers as your comments totally make sense.
> > > > > There
> > > > > is>
> > > > >
> > > > > only one thing I want to mention:
> > > > >>> + struct video_plane_format plane_format[VIRTIO_VIDEO_MAX_PLANES];
> > > > >>
> > > > >> Why is this virtio specific? Any reason for not using
> > > > >> VIDEO_MAX_PLANES?
> > > > >
> > > > > I'd say this is because VIDEO_MAX_PLANES does not exist outside of the
> > > > > Linux OS, so for whatever other system we need a virtio specific
> > > > > definition.
> > > >
> > > > OK, good reason :-)
> > > >
> > > > It's probably a good thing to add a comment where
> > > > VIRTIO_VIDEO_MAX_PLANES is defined that explains this.
> > > >
> > > > Regards,
> > > >
> > > >       Hans
>
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]