RE: [PATCH v6 00/20] Add VFIO mediated device support and DEV-MSI support for the idxd driver

[Tian, Kevin]

> From: Jason Gunthorpe <jgg@xxxxxxxxxx>
> Sent: Thursday, June 3, 2021 9:50 AM
> 
> On Thu, Jun 03, 2021 at 01:11:37AM +0000, Tian, Kevin wrote:
> 
> > Jason, can you clarify your attitude on mdev guid stuff? Are you
> > completely against it or case-by-case? If the former, this is a big
> > decision thus it's better to have consensus with Alex/Kirti. If the
> > latter, would like to hear your criteria for when it can be used
> > and when not...
> 
> I dislike it generally, but it exists so <shrug>. I know others feel
> more strongly about it being un-kernely and the wrong way to use sysfs.
> 
> Here I was remarking how the example in the cover letter made the mdev
> part seem totally pointless. If it is pointless then don't do it.

Is your point about that as long as a mdev requires pre-config
through driver specific sysfs then it doesn't make sense to use
mdev guid interface anymore?

The value of mdev guid interface is providing a vendor-agnostic
interface for mdev life-cycle management which allows one-
enable-fit-all in upper management stack. Requiring vendor
specific pre-config does blur the boundary here.

Alex/Kirt/Cornelia, what about your opinion here? It's better 
we can have an consensus on when and where the existing
mdev sysfs could be used, as this will affect every new mdev
implementation from now on.

> 
> Remember we have stripped away the actual special need to use
> mdev. You don't *have* to use mdev anymore to use vfio. That is a
> significant ideology change even from a few months ago.
> 

Yes, "don't have to" but if there is value of doing so  it's
not necessary to blocking it? One point in my mind is that if
we should minimize vendor-specific contracts for user to
manage mdev or subdevice...

Thanks
Kevin