linux-kernel - Re: [RFC PATCH 0/6] virtio: Add support for Virtio message transport

lists.openwall.net		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 linux-hardening linux-cve-announce 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]

Message-ID: <CAL_JsqKHGFPF-2d-cH4KhxFQ-KA1WO+TuDn722vYbs4Jyx8iYw@mail.gmail.com>
Date: Tue, 12 Aug 2025 08:28:53 -0500
From: Rob Herring <robh@...nel.org>
To: Viresh Kumar <viresh.kumar@...aro.org>
Cc: linux-kernel@...r.kernel.org, Eugenio Pérez <eperezma@...hat.com>, 
	Jason Wang <jasowang@...hat.com>, "Michael S. Tsirkin" <mst@...hat.com>, 
	Saravana Kannan <saravanak@...gle.com>, Xuan Zhuo <xuanzhuo@...ux.alibaba.com>, 
	Arnd Bergmann <arnd@...nel.org>, Vincent Guittot <vincent.guittot@...aro.org>, 
	Alex Bennée <alex.bennee@...aro.org>, 
	Bill Mills <bill.mills@...aro.org>, devicetree@...r.kernel.org, 
	virtualization@...ts.linux.dev, Sudeep Holla <sudeep.holla@....com>, 
	Bertrand Marquis <bertrand.marquis@....com>, "Edgar E . Iglesias" <edgar.iglesias@....com>, 
	Arnaud Pouliquen <arnaud.pouliquen@...s.st.com>, Krzysztof Kozlowski <krzk+dt@...nel.org>, 
	Conor Dooley <conor+dt@...nel.org>
Subject: Re: [RFC PATCH 0/6] virtio: Add support for Virtio message transport

On Tue, Aug 12, 2025 at 4:50 AM Viresh Kumar <viresh.kumar@...aro.org> wrote:
>
> Hi Rob,
>
> On 30-07-25, 08:39, Rob Herring wrote:
> > On Wed, Jul 30, 2025 at 4:29 AM Viresh Kumar <viresh.kumar@...aro.org> wrote:
> > > ### Memory Mapping and Reserved Memory Usage
> > >
> > > The first two patches enhance the reserved-memory subsystem to support attaching
> > > struct device`s that do not originate from DT nodes — essential for virtual or
> > > dynamically discovered devices like the FF-A or loopback buses.
> >
> > We support creating devices from reserved-memory nodes.
>
> I didn't know about this.
>
> > Just add a
> > compatible which you should do anyways because node names are not
> > supposed to be that specific or an ABI.
>
> Yeah, I already knew that the node-names thing isn't going to fly as
> you and Krzysztof rightly pointed out. I just wanted inputs from you
> guys and so did that as a first implementation to get the discussion
> started.
>
> I tried something like this now:
>
>       reserved-memory {
>         #address-cells = <2>;
>         #size-cells   = <2>;
>         ranges;
>
>         rmem@...000000 {
>           compatible = "restricted-dma-pool", "virtio-msg,loopback";

The order is wrong here. The 2nd one seems more specific to me. But is
"restricted-dma-pool" useful? Should an OS that only understands that
and not "virtio-msg,loopback" use it?

The format of compatibles is <vendor>,<device/block/interface> and
"virtio-msg" is not a vendor.

>           reg = <0x00000001 0x00000000  0x0 0x00400000>; /* 4 MiB */
>         };
>       };
>
> and this works fine. I am adding two compatibles for virtio-msg:
> "virtio-msg,loopback" and "virtio-msg,ffa". Yes I will properly
> document them in the next version.

Why do you need 2 compatibles? Can't you discover what the remote end
is with some message? We only define "virtio-mmio" in DT for example,
not that the device is a console, rng, etc.

Rob