From: "Michael S. Tsirkin" <mst@redhat.com>
To: Tiwei Bie <tiwei.bie@intel.com>
Cc: alex.williamson@redhat.com, jasowang@redhat.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC 3/3] vhost-user: support programming VFIO group in master
Date: Mon, 23 Jul 2018 12:20:12 +0300 [thread overview]
Message-ID: <20180723121919-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20180723045956.27521-4-tiwei.bie@intel.com>
On Mon, Jul 23, 2018 at 12:59:56PM +0800, Tiwei Bie wrote:
> Introduce a slave message to allow slave to share its
> VFIO group fd to master and do the IOMMU programming
> based on virtio device's DMA address space for this
> group in QEMU.
>
> For the vhost backends which support vDPA, they could
> leverage this message to ask master to do the IOMMU
> programming in QEMU for the vDPA device in backend.
>
> Signed-off-by: Tiwei Bie <tiwei.bie@intel.com>
> ---
> docs/interop/vhost-user.txt | 16 ++++++++++++++
> hw/virtio/vhost-user.c | 40 ++++++++++++++++++++++++++++++++++
> include/hw/virtio/vhost-user.h | 2 ++
> 3 files changed, 58 insertions(+)
>
> diff --git a/docs/interop/vhost-user.txt b/docs/interop/vhost-user.txt
> index f59667f498..a57a8f9451 100644
> --- a/docs/interop/vhost-user.txt
> +++ b/docs/interop/vhost-user.txt
> @@ -397,6 +397,7 @@ Protocol features
> #define VHOST_USER_PROTOCOL_F_CONFIG 9
> #define VHOST_USER_PROTOCOL_F_SLAVE_SEND_FD 10
> #define VHOST_USER_PROTOCOL_F_HOST_NOTIFIER 11
> +#define VHOST_USER_PROTOCOL_F_VFIO_GROUP 12
>
> Master message types
> --------------------
> @@ -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.
> +
> +
> VHOST_USER_PROTOCOL_F_REPLY_ACK:
> -------------------------------
> The original vhost-user specification only demands replies for certain
> diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c
> index b041343632..db958e24c7 100644
> --- a/hw/virtio/vhost-user.c
> +++ b/hw/virtio/vhost-user.c
> @@ -52,6 +52,7 @@ enum VhostUserProtocolFeature {
> VHOST_USER_PROTOCOL_F_CONFIG = 9,
> VHOST_USER_PROTOCOL_F_SLAVE_SEND_FD = 10,
> VHOST_USER_PROTOCOL_F_HOST_NOTIFIER = 11,
> + VHOST_USER_PROTOCOL_F_VFIO_GROUP = 12,
> VHOST_USER_PROTOCOL_F_MAX
> };
>
> @@ -97,6 +98,7 @@ typedef enum VhostUserSlaveRequest {
> VHOST_USER_SLAVE_IOTLB_MSG = 1,
> VHOST_USER_SLAVE_CONFIG_CHANGE_MSG = 2,
> VHOST_USER_SLAVE_VRING_HOST_NOTIFIER_MSG = 3,
> + VHOST_USER_SLAVE_VFIO_GROUP_MSG = 4,
> VHOST_USER_SLAVE_MAX
> } VhostUserSlaveRequest;
>
> @@ -949,6 +951,41 @@ static int vhost_user_slave_handle_vring_host_notifier(struct vhost_dev *dev,
> return 0;
> }
>
> +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;
Seems to create a window where mappings are invalid
even if the same fd is re-sent. Is that OK?
> + }
> +
> + 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;
> +}
> +
> static void slave_read(void *opaque)
> {
> struct vhost_dev *dev = opaque;
> @@ -1021,6 +1058,9 @@ static void slave_read(void *opaque)
> ret = vhost_user_slave_handle_vring_host_notifier(dev, &payload.area,
> fd[0]);
> break;
> + case VHOST_USER_SLAVE_VFIO_GROUP_MSG:
> + ret = vhost_user_slave_handle_vfio_group(dev, fd);
> + break;
> default:
> error_report("Received unexpected msg type.");
> ret = -EINVAL;
> diff --git a/include/hw/virtio/vhost-user.h b/include/hw/virtio/vhost-user.h
> index fd660393a0..9e11473274 100644
> --- a/include/hw/virtio/vhost-user.h
> +++ b/include/hw/virtio/vhost-user.h
> @@ -10,6 +10,7 @@
>
> #include "chardev/char-fe.h"
> #include "hw/virtio/virtio.h"
> +#include "hw/vfio/vfio-common.h"
>
> typedef struct VhostUserHostNotifier {
> MemoryRegion mr;
> @@ -20,6 +21,7 @@ typedef struct VhostUserHostNotifier {
> typedef struct VhostUserState {
> CharBackend *chr;
> VhostUserHostNotifier notifier[VIRTIO_QUEUE_MAX];
> + VFIOGroup *vfio_group;
> } VhostUserState;
>
> VhostUserState *vhost_user_init(void);
> --
> 2.18.0
next prev parent reply other threads:[~2018-07-23 9:20 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-23 4:59 [Qemu-devel] [RFC 0/3] Supporting programming IOMMU in QEMU (vDPA/vhost-user) Tiwei Bie
2018-07-23 4:59 ` [Qemu-devel] [RFC 1/3] vfio: split vfio_get_group() into small functions Tiwei Bie
2018-07-23 4:59 ` [Qemu-devel] [RFC 2/3] vfio: support getting VFIOGroup from groupfd Tiwei Bie
2018-07-23 4:59 ` [Qemu-devel] [RFC 3/3] vhost-user: support programming VFIO group in master Tiwei Bie
2018-07-23 9:19 ` Michael S. Tsirkin
2018-07-23 11:59 ` Tiwei Bie
2018-07-23 9:20 ` Michael S. Tsirkin [this message]
2018-07-23 12:04 ` Tiwei Bie
2018-07-26 20:45 ` Alex Williamson
2018-07-27 1:58 ` Tiwei Bie
2018-07-27 20:03 ` Alex Williamson
2018-07-30 8:10 ` Tiwei Bie
2018-07-30 9:30 ` Michael S. Tsirkin
2018-07-30 16:20 ` Alex Williamson
2018-07-31 7:47 ` Tiwei Bie
2018-09-12 8:04 ` Tiwei Bie
2018-09-12 16:14 ` Michael S. Tsirkin
2018-09-12 16:34 ` Alex Williamson
2018-09-12 16:44 ` Michael S. Tsirkin
2018-09-12 17:15 ` Alex Williamson
2018-09-12 17:29 ` Michael S. Tsirkin
2018-09-12 18:09 ` Alex Williamson
2018-09-13 5:26 ` Tian, Kevin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180723121919-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=jasowang@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=tiwei.bie@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.