From: Auger Eric <eric.auger@redhat.com>
To: Liu Yi L <yi.l.liu@intel.com>,
qemu-devel@nongnu.org, alex.williamson@redhat.com,
peterx@redhat.com
Cc: jean-philippe@linaro.org, kevin.tian@intel.com,
Jacob Pan <jacob.jun.pan@linux.intel.com>,
Yi Sun <yi.y.sun@linux.intel.com>,
kvm@vger.kernel.org, mst@redhat.com, jun.j.tian@intel.com,
yi.y.sun@intel.com, pbonzini@redhat.com, hao.wu@intel.com,
david@gibson.dropbear.id.au
Subject: Re: [PATCH v2 04/22] hw/iommu: introduce HostIOMMUContext
Date: Mon, 30 Mar 2020 19:22:36 +0200 [thread overview]
Message-ID: <aa1bfbd5-e6de-6475-809e-a6ca46089aaa@redhat.com> (raw)
In-Reply-To: <1585542301-84087-5-git-send-email-yi.l.liu@intel.com>
Yi,
On 3/30/20 6:24 AM, Liu Yi L wrote:
> Currently, many platform vendors provide the capability of dual stage
> DMA address translation in hardware. For example, nested translation
> on Intel VT-d scalable mode, nested stage translation on ARM SMMUv3,
> and etc. In dual stage DMA address translation, there are two stages
> address translation, stage-1 (a.k.a first-level) and stage-2 (a.k.a
> second-level) translation structures. Stage-1 translation results are
> also subjected to stage-2 translation structures. Take vSVA (Virtual
> Shared Virtual Addressing) as an example, guest IOMMU driver owns
> stage-1 translation structures (covers GVA->GPA translation), and host
> IOMMU driver owns stage-2 translation structures (covers GPA->HPA
> translation). VMM is responsible to bind stage-1 translation structures
> to host, thus hardware could achieve GVA->GPA and then GPA->HPA
> translation. For more background on SVA, refer the below links.
> - https://www.youtube.com/watch?v=Kq_nfGK5MwQ
> - https://events19.lfasiallc.com/wp-content/uploads/2017/11/\
> Shared-Virtual-Memory-in-KVM_Yi-Liu.pdf
>
> In QEMU, vIOMMU emulators expose IOMMUs to VM per their own spec (e.g.
> Intel VT-d spec). Devices are pass-through to guest via device pass-
> through components like VFIO. VFIO is a userspace driver framework
> which exposes host IOMMU programming capability to userspace in a
> secure manner. e.g. IOVA MAP/UNMAP requests. Thus the major connection
> between VFIO and vIOMMU are MAP/UNMAP. However, with the dual stage
> DMA translation support, there are more interactions between vIOMMU and
> VFIO as below:
I think it is key to justify at some point why the IOMMU MR notifiers
are not usable for that purpose. If I remember correctly this is due to
the fact MR notifiers are not active on x86 in that use xase, which is
not the case on ARM dual stage enablement.
maybe: "Information, different from map/unmap notifications need to be
passed from QEMU vIOMMU device to/from the host IOMMU driver through the
VFIO/IOMMU layer: ..."
> 1) PASID allocation (allow host to intercept in PASID allocation)
> 2) bind stage-1 translation structures to host
> 3) propagate stage-1 cache invalidation to host
> 4) DMA address translation fault (I/O page fault) servicing etc.
>
> With the above new interactions in QEMU, it requires an abstract layer
> to facilitate the above operations and expose to vIOMMU emulators as an
> explicit way for vIOMMU emulators call into VFIO. This patch introduces
> HostIOMMUContext to stand for hardware IOMMU w/ dual stage DMA address
> translation capability. And introduces HostIOMMUContextClass to provide
> methods for vIOMMU emulators to propagate dual-stage translation related
> requests to host. As a beginning, PASID allocation/free are defined to
> propagate PASID allocation/free requests to host which is helpful for the
> vendors who manage PASID in system-wide. In future, there will be more
> operations like bind_stage1_pgtbl, flush_stage1_cache and etc.
>
> Cc: Kevin Tian <kevin.tian@intel.com>
> Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
> Cc: Peter Xu <peterx@redhat.com>
> Cc: Eric Auger <eric.auger@redhat.com>
> Cc: Yi Sun <yi.y.sun@linux.intel.com>
> Cc: David Gibson <david@gibson.dropbear.id.au>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Signed-off-by: Liu Yi L <yi.l.liu@intel.com>
> ---
> hw/Makefile.objs | 1 +
> hw/iommu/Makefile.objs | 1 +
> hw/iommu/host_iommu_context.c | 97 +++++++++++++++++++++++++++++++++++
> include/hw/iommu/host_iommu_context.h | 75 +++++++++++++++++++++++++++
> 4 files changed, 174 insertions(+)
> create mode 100644 hw/iommu/Makefile.objs
> create mode 100644 hw/iommu/host_iommu_context.c
> create mode 100644 include/hw/iommu/host_iommu_context.h
>
> diff --git a/hw/Makefile.objs b/hw/Makefile.objs
> index 660e2b4..cab83fe 100644
> --- a/hw/Makefile.objs
> +++ b/hw/Makefile.objs
> @@ -40,6 +40,7 @@ devices-dirs-$(CONFIG_MEM_DEVICE) += mem/
> devices-dirs-$(CONFIG_NUBUS) += nubus/
> devices-dirs-y += semihosting/
> devices-dirs-y += smbios/
> +devices-dirs-y += iommu/
> endif
>
> common-obj-y += $(devices-dirs-y)
> diff --git a/hw/iommu/Makefile.objs b/hw/iommu/Makefile.objs
> new file mode 100644
> index 0000000..e6eed4e
> --- /dev/null
> +++ b/hw/iommu/Makefile.objs
> @@ -0,0 +1 @@
> +obj-y += host_iommu_context.o
> diff --git a/hw/iommu/host_iommu_context.c b/hw/iommu/host_iommu_context.c
> new file mode 100644
> index 0000000..5fb2223
> --- /dev/null
> +++ b/hw/iommu/host_iommu_context.c
> @@ -0,0 +1,97 @@
> +/*
> + * QEMU abstract of Host IOMMU
> + *
> + * Copyright (C) 2020 Intel Corporation.
> + *
> + * Authors: Liu Yi L <yi.l.liu@intel.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> +
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> +
> + * You should have received a copy of the GNU General Public License along
> + * with this program; if not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include "qemu/osdep.h"
> +#include "qapi/error.h"
> +#include "qom/object.h"
> +#include "qapi/visitor.h"
> +#include "hw/iommu/host_iommu_context.h"
> +
> +int host_iommu_ctx_pasid_alloc(HostIOMMUContext *iommu_ctx, uint32_t min,
> + uint32_t max, uint32_t *pasid)
> +{
> + HostIOMMUContextClass *hicxc;
> +
> + if (!iommu_ctx) {
> + return -EINVAL;
> + }
> +
> + hicxc = HOST_IOMMU_CONTEXT_GET_CLASS(iommu_ctx);
> +
> + if (!hicxc) {
> + return -EINVAL;
> + }
> +
> + if (!(iommu_ctx->flags & HOST_IOMMU_PASID_REQUEST) ||
> + !hicxc->pasid_alloc) {
At this point of the reading, I fail to understand why we need the flag.
Why isn't it sufficient to test whether the ops is set?
> + return -EINVAL;
> + }
> +
> + return hicxc->pasid_alloc(iommu_ctx, min, max, pasid);
> +}
> +
> +int host_iommu_ctx_pasid_free(HostIOMMUContext *iommu_ctx, uint32_t pasid)
> +{
> + HostIOMMUContextClass *hicxc;
> +
> + if (!iommu_ctx) {
> + return -EINVAL;
> + }
> +
> + hicxc = HOST_IOMMU_CONTEXT_GET_CLASS(iommu_ctx);
> + if (!hicxc) {
> + return -EINVAL;
> + }
> +
> + if (!(iommu_ctx->flags & HOST_IOMMU_PASID_REQUEST) ||
> + !hicxc->pasid_free) {
> + return -EINVAL;
> + }
> +
> + return hicxc->pasid_free(iommu_ctx, pasid);
> +}
> +
> +void host_iommu_ctx_init(void *_iommu_ctx, size_t instance_size,
> + const char *mrtypename,
> + uint64_t flags)
> +{
> + HostIOMMUContext *iommu_ctx;
> +
> + object_initialize(_iommu_ctx, instance_size, mrtypename);
> + iommu_ctx = HOST_IOMMU_CONTEXT(_iommu_ctx);
> + iommu_ctx->flags = flags;
> + iommu_ctx->initialized = true;
> +}
> +
> +static const TypeInfo host_iommu_context_info = {
> + .parent = TYPE_OBJECT,
> + .name = TYPE_HOST_IOMMU_CONTEXT,
> + .class_size = sizeof(HostIOMMUContextClass),
> + .instance_size = sizeof(HostIOMMUContext),
> + .abstract = true,
Can't we use the usual .instance_init and .instance_finalize?
> +};
> +
> +static void host_iommu_ctx_register_types(void)
> +{
> + type_register_static(&host_iommu_context_info);
> +}
> +
> +type_init(host_iommu_ctx_register_types)
> diff --git a/include/hw/iommu/host_iommu_context.h b/include/hw/iommu/host_iommu_context.h
> new file mode 100644
> index 0000000..35c4861
> --- /dev/null
> +++ b/include/hw/iommu/host_iommu_context.h
> @@ -0,0 +1,75 @@
> +/*
> + * QEMU abstraction of Host IOMMU
> + *
> + * Copyright (C) 2020 Intel Corporation.
> + *
> + * Authors: Liu Yi L <yi.l.liu@intel.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> +
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> +
> + * You should have received a copy of the GNU General Public License along
> + * with this program; if not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#ifndef HW_IOMMU_CONTEXT_H
> +#define HW_IOMMU_CONTEXT_H
> +
> +#include "qemu/queue.h"
> +#include "qemu/thread.h"
> +#include "qom/object.h"
> +#include <linux/iommu.h>
> +#ifndef CONFIG_USER_ONLY
> +#include "exec/hwaddr.h"
> +#endif
> +
> +#define TYPE_HOST_IOMMU_CONTEXT "qemu:host-iommu-context"
> +#define HOST_IOMMU_CONTEXT(obj) \
> + OBJECT_CHECK(HostIOMMUContext, (obj), TYPE_HOST_IOMMU_CONTEXT)
> +#define HOST_IOMMU_CONTEXT_GET_CLASS(obj) \
> + OBJECT_GET_CLASS(HostIOMMUContextClass, (obj), \
> + TYPE_HOST_IOMMU_CONTEXT)
> +
> +typedef struct HostIOMMUContext HostIOMMUContext;
> +
> +typedef struct HostIOMMUContextClass {
> + /* private */
> + ObjectClass parent_class;
> +
> + /* Allocate pasid from HostIOMMUContext (a.k.a. host software) */
Request the host to allocate a PASID?
"from HostIOMMUContext (a.k.a. host software)" is a bit cryptic to me.
Actually at this stage I do not understand what this HostIOMMUContext
abstracts. Is it an object associated to one guest FL context entry
(attached to one PASID). Meaning for just vIOMMU/VFIO using nested
paging (single PASID) I would use a single of such context per IOMMU MR?
I think David also felt difficult to understand the abstraction behind
this object.
> + int (*pasid_alloc)(HostIOMMUContext *iommu_ctx,
> + uint32_t min,
> + uint32_t max,
> + uint32_t *pasid);
> + /* Reclaim pasid from HostIOMMUContext (a.k.a. host software) */
> + int (*pasid_free)(HostIOMMUContext *iommu_ctx,
> + uint32_t pasid);
> +} HostIOMMUContextClass;
> +
> +/*
> + * This is an abstraction of host IOMMU with dual-stage capability
> + */
> +struct HostIOMMUContext {
> + Object parent_obj;
> +#define HOST_IOMMU_PASID_REQUEST (1ULL << 0)
> + uint64_t flags;
> + bool initialized;
what's the purpose of the initialized flag?
> +};
> +
> +int host_iommu_ctx_pasid_alloc(HostIOMMUContext *iommu_ctx, uint32_t min,
> + uint32_t max, uint32_t *pasid);
> +int host_iommu_ctx_pasid_free(HostIOMMUContext *iommu_ctx, uint32_t pasid);
> +
> +void host_iommu_ctx_init(void *_iommu_ctx, size_t instance_size,
> + const char *mrtypename,
> + uint64_t flags);
> +void host_iommu_ctx_destroy(HostIOMMUContext *iommu_ctx);
leftover from V1?
> +
> +#endif
>
Thanks
Eric
next prev parent reply other threads:[~2020-03-30 17:24 UTC|newest]
Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-30 4:24 [PATCH v2 00/22] intel_iommu: expose Shared Virtual Addressing to VMs Liu Yi L
2020-03-30 4:24 ` [PATCH v2 01/22] scripts/update-linux-headers: Import iommu.h Liu Yi L
2020-03-30 4:24 ` [PATCH v2 02/22] header file update VFIO/IOMMU vSVA APIs Liu Yi L
2020-03-30 4:24 ` [PATCH v2 03/22] vfio: check VFIO_TYPE1_NESTING_IOMMU support Liu Yi L
2020-03-30 9:36 ` Auger Eric
2020-03-31 6:08 ` Liu, Yi L
2020-03-30 4:24 ` [PATCH v2 04/22] hw/iommu: introduce HostIOMMUContext Liu Yi L
2020-03-30 17:22 ` Auger Eric [this message]
2020-03-31 4:10 ` Liu, Yi L
2020-03-31 7:47 ` Auger Eric
2020-03-31 12:43 ` Liu, Yi L
2020-04-06 8:04 ` Liu, Yi L
2020-04-06 10:30 ` Auger Eric
2020-03-30 4:24 ` [PATCH v2 05/22] hw/pci: modify pci_setup_iommu() to set PCIIOMMUOps Liu Yi L
2020-03-30 11:02 ` Auger Eric
2020-04-02 8:52 ` Liu, Yi L
2020-04-02 12:41 ` Auger Eric
2020-04-02 13:37 ` Liu, Yi L
2020-04-02 13:49 ` Auger Eric
2020-04-06 6:27 ` Liu, Yi L
2020-04-06 10:04 ` Auger Eric
2020-03-30 4:24 ` [PATCH v2 06/22] hw/pci: introduce pci_device_set/unset_iommu_context() Liu Yi L
2020-03-30 17:30 ` Auger Eric
2020-03-31 12:14 ` Liu, Yi L
2020-03-30 4:24 ` [PATCH v2 07/22] intel_iommu: add set/unset_iommu_context callback Liu Yi L
2020-03-30 20:23 ` Auger Eric
2020-03-31 12:25 ` Liu, Yi L
2020-03-31 12:57 ` Auger Eric
2020-03-30 4:24 ` [PATCH v2 08/22] vfio/common: provide PASID alloc/free hooks Liu Yi L
2020-03-31 10:47 ` Auger Eric
2020-03-31 10:59 ` Liu, Yi L
2020-03-31 11:15 ` Auger Eric
2020-03-31 12:54 ` Liu, Yi L
2020-03-30 4:24 ` [PATCH v2 09/22] vfio/common: init HostIOMMUContext per-container Liu Yi L
2020-04-01 7:50 ` Auger Eric
2020-04-06 7:12 ` Liu, Yi L
2020-04-06 10:20 ` Auger Eric
2020-04-07 11:59 ` Liu, Yi L
2020-03-30 4:24 ` [PATCH v2 10/22] vfio/pci: set host iommu context to vIOMMU Liu Yi L
2020-03-31 14:30 ` Auger Eric
2020-04-01 3:20 ` Liu, Yi L
2020-03-30 4:24 ` [PATCH v2 11/22] intel_iommu: add virtual command capability support Liu Yi L
2020-03-30 4:24 ` [PATCH v2 12/22] intel_iommu: process PASID cache invalidation Liu Yi L
2020-03-30 4:24 ` [PATCH v2 13/22] intel_iommu: add PASID cache management infrastructure Liu Yi L
2020-04-02 0:02 ` Peter Xu
2020-04-02 6:46 ` Liu, Yi L
2020-04-02 13:44 ` Peter Xu
2020-04-03 15:05 ` Liu, Yi L
2020-04-03 16:19 ` Peter Xu
2020-04-04 11:39 ` Liu, Yi L
2020-03-30 4:24 ` [PATCH v2 14/22] vfio: add bind stage-1 page table support Liu Yi L
2020-03-30 4:24 ` [PATCH v2 15/22] intel_iommu: bind/unbind guest page table to host Liu Yi L
2020-04-02 18:09 ` Peter Xu
2020-04-03 14:29 ` Liu, Yi L
2020-03-30 4:24 ` [PATCH v2 16/22] intel_iommu: replay pasid binds after context cache invalidation Liu Yi L
2020-04-03 14:45 ` Peter Xu
2020-04-03 15:21 ` Liu, Yi L
2020-04-03 16:11 ` Peter Xu
2020-04-04 12:00 ` Liu, Yi L
2020-04-06 19:48 ` Peter Xu
2020-03-30 4:24 ` [PATCH v2 17/22] intel_iommu: do not pass down pasid bind for PASID #0 Liu Yi L
2020-03-30 4:24 ` [PATCH v2 18/22] vfio: add support for flush iommu stage-1 cache Liu Yi L
2020-03-30 4:24 ` [PATCH v2 19/22] intel_iommu: process PASID-based iotlb invalidation Liu Yi L
2020-04-03 14:47 ` Peter Xu
2020-04-03 15:21 ` Liu, Yi L
2020-03-30 4:24 ` [PATCH v2 20/22] intel_iommu: propagate PASID-based iotlb invalidation to host Liu Yi L
2020-03-30 4:25 ` [PATCH v2 21/22] intel_iommu: process PASID-based Device-TLB invalidation Liu Yi L
2020-03-30 4:25 ` [PATCH v2 22/22] intel_iommu: modify x-scalable-mode to be string option Liu Yi L
2020-04-03 14:49 ` Peter Xu
2020-04-03 15:22 ` Liu, Yi L
2020-03-30 5:40 ` [PATCH v2 00/22] intel_iommu: expose Shared Virtual Addressing to VMs no-reply
2020-03-30 10:36 ` Auger Eric
2020-03-30 14:46 ` Peter Xu
2020-03-31 6:53 ` Liu, Yi L
2020-04-02 8:33 ` Jason Wang
2020-04-02 13:46 ` Peter Xu
2020-04-03 1:38 ` Jason Wang
2020-04-03 14:20 ` Liu, Yi L
2020-04-02 18:12 ` Peter Xu
2020-04-03 14:32 ` Liu, Yi L
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=aa1bfbd5-e6de-6475-809e-a6ca46089aaa@redhat.com \
--to=eric.auger@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=hao.wu@intel.com \
--cc=jacob.jun.pan@linux.intel.com \
--cc=jean-philippe@linaro.org \
--cc=jun.j.tian@intel.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=yi.l.liu@intel.com \
--cc=yi.y.sun@intel.com \
--cc=yi.y.sun@linux.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).