> One of the release valves in the CXL space is openly specified > commands with opaque payloads, like "Read Vendor Debug Log". That is > clear what it does, likely a payload the kernel need never worry > about, and the "Command Effects" is empty. However, going forward there > is a new class of commands called "Set/Get Feature" that allow a wide > range of vendor toggles to be deployed which will need an upstream > response for the driver policy to vendor-specific "Features". Irrelevant rat hole time ;) I don't see those Set / Get feature as any different from other commands. I see them as a convenience mostly there to cut down on spec duplication and enforce some consistency across multiple similar commands, but they are just commands like any other, validation is just one step further into the payload. There are already a bunch of them in the main CXL spec and like you mention above if someone brings a well documented vendor feature (or feature from another standard etc), then if appropriate we could let that through the filter as well. Same will be true of tunneled commands (I think we can ignore the cross host security aspect of those). Ultimately we can sanity check the payload much like a top level command. So I mostly agree with rest of what you've said, but think this detail doesn't matter. > > So if fwctl, or something like it, can strike a balance of enforcing > integrity and introspection while encouraging collaboration on the > aspects that are worth upstream collaboration, I think that is a > conversation worth having. > > [1]: http://lore.kernel.org/r/CAPcyv4gDShAYih5iWabKg_eTHhuHm54vEAei8ZkcmHnPp3B0cw@xxxxxxxxxxxxxx/ > [2]: http://lore.kernel.org/r/20240321174423.00007e0d@xxxxxxxxxx >
