On Mon, Jul 23, 2018 at 12:19:04PM +0300, Michael S. Tsirkin wrote:
> On Mon, Jul 23, 2018 at 12:59:56PM +0800, Tiwei Bie wrote:
[...]
> > @@ -815,6 +816,21 @@ Slave message types
> > This request should be sent only when
> > VHOST_USER_PROTOCOL_F_HOST_NOTIFIER
> > protocol feature has been successfully negotiated.
> >
> > + * VHOST_USER_SLAVE_VFIO_GROUP_MSG
> > +
> > + Id: 4
> > + Equivalent ioctl: N/A
> > + Slave payload: N/A
> > + Master payload: N/A
> > +
> > + When VHOST_USER_PROTOCOL_F_VFIO_GROUP is negotiated, vhost-user slave
> > + could send this request to share its VFIO group fd via ancillary data
> > + to master. After receiving this request from slave, master will close
> > + the existing VFIO group if any and do the DMA programming based on
> > the
> > + virtio device's DMA address space for the new group if the request is
> > + sent with a file descriptor.
> > +
>
> Should it also clear out any mappings that were set on the old fd
> before closing it?
Yes, more exactly it will do below things:
1. Delete VFIO group from KVM device fd;
2. Unset the container fd for this group fd;
3. Close this VFIO group fd;
Should I include above details in this doc?
>
> Also should we limit when can this message be received?
> If not you need to re-program mappings again whenever
> we get a new fd.
To keep things simple, this proposal requires the slave
to assume the mappings are invalid before receiving the
REPLY from master when the slave sends this message to
master, and master will destroy the existing VFIO group
if any and do the setup for the (new) VFIO group if the
message carries a fd.
So if a VFIO group fd has been sent and the device has
been started, before sending a VFIO group fd (could be
the same fd that has been sent), the slave should stop
the device first and shouldn't assume the mappings are
valid before receiving the REPLY.
>
> > +
[...]
> >
> > +static int vhost_user_slave_handle_vfio_group(struct vhost_dev *dev,
> > + int *fd)
> > +{
> > + struct vhost_user *u = dev->opaque;
> > + VhostUserState *user = u->user;
> > + VirtIODevice *vdev = dev->vdev;
> > + int groupfd = fd[0];
> > + VFIOGroup *group;
> > +
> > + if (!virtio_has_feature(dev->protocol_features,
> > + VHOST_USER_PROTOCOL_F_VFIO_GROUP) ||
> > + vdev == NULL) {
> > + return -1;
> > + }
> > +
> > + if (user->vfio_group) {
> > + vfio_put_group(user->vfio_group);
> > + user->vfio_group = NULL;
> > + }
> > +
> > + group = vfio_get_group_from_fd(groupfd, vdev->dma_as, NULL);
> > + if (group == NULL) {
> > + return -1;
> > + }
> > +
> > + if (group->fd != groupfd) {
> > + close(groupfd);
> > + }
> > +
> > + user->vfio_group = group;
> > + fd[0] = -1;
> > +
> > + return 0;
> > +}
> > +
>
> What will cause propagating groups to this vfio fd?
Do you mean when a VFIOGroup will be created for this
VFIO group fd?
A VFIOGroup will be created if there is no existing
VFIOGroup that references to the same group id.
Best regards,
Tiwei Bie
>
>
[...]
