On Tue, 2021-11-30 at 19:12 -0800, Jakub Kicinski wrote:

On Tue, 30 Nov 2021 22:17:29 +0000 Sunil Sudhakar Rani wrote:

quoted

quoted

On Mon, 22 Nov 2021 16:43:06 +0200 Sunil Rani wrote:  

quoted

The device/firmware decides how to define privileges and access
to resources.

Great API definition. Nack  

Sorry for the late response. We agree that the current definition
is vague.

What we meant is that the enforcement is done by device/FW.
We simply want to allow VF/SF to access privileged or restricted
resource such as physical port counters.
So how about defining the api such that:
This knob allows the VF/SF to access restricted resource such as
physical port counters.

You need to say more about the use case, I don't understand 
what you're doing.

Some device features/registers/units are not available by default to
VFs/SFs (e.g restricted), examples are: physical port
registers/counters and similar global attributes.

Some customers want to use SF/VF in specialized VM/container for
management and monitoring, thus they want SF/VF to have similar
privileges to PF in terms of access to restricted resources.

Note: this doesn't break the sriov/sf model, trusted SF/VF will not be
allowed to alter device attributes, they will simply enjoy access to
more resources/features.

We would've pushed for a more fine-grained per "capability" API, but
where do we start/end? I think "trust" concept is the right approach.