Message-ID: <20240721192530.GD23783@pendragon.ideasonboard.com>
Date: Sun, 21 Jul 2024 22:25:30 +0300
From: Laurent Pinchart <laurent.pinchart@...asonboard.com>
To: Dan Williams <dan.j.williams@...el.com>
Cc: James Bottomley <James.Bottomley@...senpartnership.com>,
	ksummit@...ts.linux.dev, linux-cxl@...r.kernel.org,
	linux-rdma@...r.kernel.org, netdev@...r.kernel.org, jgg@...dia.com
Subject: Re: [MAINTAINERS SUMMIT] Device Passthrough Considered Harmful?

On Tue, Jul 09, 2024 at 03:15:13PM -0700, Dan Williams wrote:
> James Bottomley wrote:
> > > The upstream discussion has yielded the full spectrum of positions on
> > > device specific functionality, and it is a topic that needs cross-
> > > kernel consensus as hardware increasingly spans cross-subsystem
> > > concerns. Please consider it for a Maintainers Summit discussion.
> > 
> > I'm with Greg on this ... can you point to some of the contrary
> > positions?
> 
> This thread has that discussion:
> 
> http://lore.kernel.org/0-v1-9912f1a11620+2a-fwctl_jgg@nvidia.com
> 
> I do not want to speak for others on the saliency of their points, all I
> can say is that the contrary positions have so far not moved me to drop
> consideration of fwctl for CXL.
> 
> Where CXL has a Command Effects Log that is a reasonable protocol for
> making decisions about opaque command codes, and that CXL already has a
> few years of experience with the commands that *do* need a Linux-command
> wrapper.
> 
> Some open questions from that thread are: what does it mean for the fate
> of a proposal if one subsystem Acks the ABI and another Naks it for a
> device that crosses subsystem functionality? Would a cynical hardware
> response just lead to plumbing an NVME admin queue, or CXL mailbox to
> get device-specific commands past another subsystem's objection?

My default answer would be to trust the maintainers of the relevant
subsystems (or try to convince them when you disagree :-)). Not only
should they know the technical implications best, they should also have
a good view of the whole vertical stack, and the implications of
pass-through for their ecosystem. This may result in a single NAK
overriding ACKs, but we could also try to find technical solutions when
we'll face such issues, to enforce different sets of rules for the
different functions of a device.

Subsystem hopping is something we're recently noticed for camera ISPs,
where a vendor wanted to move from V4L2 to DRM. Technical reasons for
doing so were given, and they were (in my opinion) rather excuses. The
unspoken real (again in my opinion) reason was to avoid documenting the
firmware interface and ship userspace binary blobs with no way for free
software to use all the device's features. That's something we have been
fighting against for years, trying to convince vendors that they can
provide better and more open camera support without the world
collapsing, with increasing success recently. Saying amen to
pass-through in this case would be a huge step back that would hurt
users and the whole ecosystem in the short and long term.

> My reconsideration of the "debug-build only" policy for CXL
> device-specific commands was influenced by a conversation with a distro
> developer where they asserted, paraphrasing: "at what point is a device
> vendor incentivized to ship an out-of-tree module just to restore their
> passthrough functionality?. At that point upstream has lost out on
> collaboration and distro kernel ABI has gained another out-of-tree
> consumer."
> 
> So the tension is healthy, but it has diminishing returns past a certain
> point.

-- 
Regards,

Laurent Pinchart

Powered by blists - more mailing lists