lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 8 Jul 2019 11:45:46 -0700
From:   Christoph Hellwig <>
To:     Loic PALLARDY <>
Cc:     Christoph Hellwig <>,
        Clement Leger <>,
        Ohad Ben-Cohen <>,
        Bjorn Andersson <>,
        "" <>,
        "" <>
Subject: Re: [PATCH v2] remoteproc: copy parent dma_pfn_offset for vdev

On Tue, Jul 02, 2019 at 03:36:56PM +0000, Loic PALLARDY wrote:
> Agree there is definitively an issue with the way virtio device are defined.
> Today definition is based on rproc firmware ressource table and rproc 
> framework is in charge of vdev creation.
> Device tree definition was discarded as vdev is not HW but SW definition.

Well, it appears to be a firmware interface description.

> One solution would be to associate both resource table (which provides
> Firmware capabilities) and some virtio device tree nodes (declared as sub nodes
> of remote processor with associated resources like memory carveout).
> When we have a match between resource table and rproc DT sub node, we
> can register virtio device via of_platform_populate.
> Then need to adapt virtio_rpmsg or to create a virtio_rproc to be DT probe compliant
> like virtio_mmio is.
> But that's breaking legacy as all platforms will have to add a virtio device node in
> their DT file...
> Is it aligned with your view ?

Yes, that is how I'd assume it works.  But given that until recently
you did now have these subdevices for dma coherent purposes we can't
really break anything older than that, so I might still be missing

Powered by blists - more mailing lists