Re: [PATCH 5/5] node_device: mdev vfio-ccw support

Erik Skultety <eskultet(a)redhat.com&gt; [2020-09-08, 06:01PM +0200]: > On Mon, Aug 24, 2020 at 01:59:15PM +0200, Bjoern Walk wrote: > > From: Boris Fiuczynski <fiuczy(a)linux.ibm.com&gt; > > + case VIR_NODE_DEV_CAP_SYSTEM: > > + case VIR_NODE_DEV_CAP_USB_DEV: > > + case VIR_NODE_DEV_CAP_USB_INTERFACE: > > + case VIR_NODE_DEV_CAP_NET: > > + case VIR_NODE_DEV_CAP_SCSI_HOST: > > + case VIR_NODE_DEV_CAP_SCSI_TARGET: > > + case VIR_NODE_DEV_CAP_SCSI: > > + case VIR_NODE_DEV_CAP_STORAGE: > > + case VIR_NODE_DEV_CAP_FC_HOST: > > + case VIR_NODE_DEV_CAP_VPORTS: > > + case VIR_NODE_DEV_CAP_SCSI_GENERIC: > > + case VIR_NODE_DEV_CAP_DRM: > > + case VIR_NODE_DEV_CAP_MDEV_TYPES: > > + case VIR_NODE_DEV_CAP_MDEV: > > + case VIR_NODE_DEV_CAP_CCW_DEV: > > What about ccw mdevs? I would think that it's CCW end point device that > we would want to assign concurrently, but we're only "slicing" the root channel > subsystem device. If you have and CSS mdev, are the CCW subchannels separate > for each VM or does it behave kind of like NPIV with its vHBAs? OR I'm > completely off here? You are correct. This is an unfortunate architectural decision on our platform. For vfio-ccw, we instatiate the mdevs on the CSS layer, which has a 1-to-1 relation to the underlying CCW device. That's why we need the information about the CSS devices in libvirt, to give the user a chance to easily find this relation when he wants to do passthrough with a DASD for example. It's a bit unintuitive and even silly for the end user, but it's architecturally correct and hence it was implemented like this in the vfio-ccw kernel driver. We don't even get the benefits of something like NPIV because for every subchannel there is only one CCW device (at least to my knowledge).