On 2019/11/19 下午10:14, Jason Gunthorpe wrote:
On Tue, Nov 19, 2019 at 10:02:08PM +0800, Jason Wang wrote:
On 2019/11/19 下午8:38, Jason Gunthorpe wrote:
On Tue, Nov 19, 2019 at 10:41:31AM +0800, Jason Wang wrote:
On 2019/11/19 上午4:28, Jason Gunthorpe wrote:
On Mon, Nov 18, 2019 at 03:27:13PM -0500, Michael S. Tsirkin wrote:
On Mon, Nov 18, 2019 at 01:41:00PM +0000, Jason Gunthorpe wrote:
On Mon, Nov 18, 2019 at 06:59:21PM +0800, Jason Wang wrote:
+struct bus_type mdev_virtio_bus_type;
+
+struct mdev_virtio_device {
+ struct mdev_device mdev;
+ const struct mdev_virtio_ops *ops;
+ u16 class_id;
+};
This seems to share nothing with mdev (ie mdev-vfio), why is it on the
same bus?
I must be missing something - which bus do they share?
mdev_bus_type ?
Jason
Note: virtio has its own bus: mdev_virtio_bus_type. So they are not the same
bus.
That is even worse, why involve struct mdev_device at all then?
Jason
I don't quite get the question here.
In the driver model the bus_type and foo_device are closely
linked.
I don't get the definition of "closely linked" here. Do you think the
bus and device implement virtual bus series are closely linked? If yes,
how did they achieve that?
Creating 'mdev_device' instances and overriding the bus_type
is a very abusive thing to do.
Ok, mdev_device (without this series) had:
struct mdev_device {
struct device dev;
struct mdev_parent *parent;
guid_t uuid;
void *driver_data;
struct list_head next;
struct kobject *type_kobj;
struct device *iommu_device;
bool active;
};
So it's nothing bus or VFIO specific. And what virtual bus had is:
struct virtbus_device {
const char *name;
int id;
const struct virtbus_dev_id *dev_id;
struct device dev;
void *data;
};
Are there any fundamental issues that you think mdev_device is abused? I
won't expect the answers are generic objects like kobj, iommu device
pointer etc.
My understanding for mdev is that it was a mediator between the driver and
physical device when it's hard to let them talk directly due to the
complexity of refactoring and maintenance.
Really, mdev is to support vfio with a backend other than PCI, nothing
more.
That partially explain why it was called mdev. So for virito, we want
standard virtio driver to talk with a backend other than virtio.
For the issue of PCI, actually the API is generic enough to support
device other than PCI, e.g AP bus.
Abusing it for other things is not appropriate. ie creating an
instance and not filling in most of the vfio focused ops is an abusive
thing to do.
Well, it's only half of the mdev_parent_ops in mdev_parent, various
methods could be done do be more generic to avoid duplication of codes. No?
hardware that can offload virtio datapath but not control path. We want to
present a unified interface (standard virtio) instead of a vendor specific
interface, so a mediator level in the middle is a must. For virtio driver,
mediator present a full virtio compatible device. For hardware, mediator
will mediate the difference between the behavior defined by virtio spec and
real hardware.
If you need to bind to the VFIO driver then mdev is the right thing to
use, otherwise it is not.
It certainly should not be used to bind to random kernel drivers. This
problem is what this virtual bus idea Intel is working on might solve.
What do you mean by random here? With this series, we have dedicated bus
and dedicated driver with matching method to make sure the binding is
correct.
It seems the only thing people care about with mdev is the GUID
lifecycle stuff, but at the same time folks like Parav are saying they
don't want to use that lifecycle stuff and prefer devlink
instead.
I'm sure you will need to handle other issues besides GUID which had
been settled by mdev e.g IOMMU and types when starting to write a real
hardware driver.
Most likely, at least for virtio-net, everyone else will be able to
use devlink as well, making it much less clear if that GUID lifecycle
stuff is a good idea or not.
This assumption is wrong, we hard already had at least two concrete
examples of vDPA device that doesn't use devlink:
- Intel IFC where virtio is done at VF level
- Ali Cloud ECS instance where virtio is done at PF level
Again, the device slicing is only part of our goal. The major goal is to
have a mediator level that can take over the virtio control path between
a standard virtio driver and a hardware who datapath is virtio
compatible but not control path.
Thanks
Jason
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
