Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Wei Liu <wei.liu@kernel.org>
To:     Linux on Hyper-V List <linux-hyperv@vger.kernel.org>
Cc:     virtualization@lists.linux-foundation.org,
        Linux Kernel List <linux-kernel@vger.kernel.org>,
        Michael Kelley <mikelley@microsoft.com>,
        Vineeth Pillai <viremana@linux.microsoft.com>,
        Sunil Muthuswamy <sunilmut@microsoft.com>,
        Nuno Das Neves <nunodasneves@linux.microsoft.com>,
        kumarpraveen@linux.microsoft.com, pasha.tatashin@soleen.com,
        Wei Liu <wei.liu@kernel.org>
Subject: [RFC v1 0/8] MSHV: add PV-IOMMU driver
Date:   Fri,  9 Jul 2021 11:43:31 +0000
Message-Id: <20210709114339.3467637-1-wei.liu@kernel.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

Hi all

Device passthrough is a critial feature for a virtualization stack. When
designing this feature for MSHV support on Linux, one important
considration is to not deviate from Linux's default VFIO stack. VFIO
relies on an IOMMU or IOMMUs in the system to manipulate DMA mappings.

In this series an IOMMU driver is implemented using a set of hypercall
interfaces provided by the Microsoft Hypervisor. At this stage only DMA
remapping is implemented. Interrupt remapping will come later.

With this series I'm able to passthrough an NVMe drive to a guest with VFIO on
a modified version of Cloud Hypervisor. From users' point of view, nothing
needs changing. Cloud Hypervisor and Rust-VMM changes, which depend on the new
kernel UAPIs from this series, will be upstreamed too.

This series is built on top of Nuno and Vineeth's patches [0][1].

The meat is in the patch named "mshv: add paravirtualized IOMMU
support".

The in-kernel device framework and the VFIO bridge device are heavily
inspired by KVM's code. I pondered whether it would be worth refactoring
the code in KVM but decided against that route for two reasons: 1. it
allowed faster prototyping and 2. I was not sure if that's something KVM
community would agree to.

For the VT-D changes, what we're after is to build the RMRR regions list
so that reserved regions are respected. Instead of doing a bad job
myself, I decided to piggy-back on Intel's own code. AMD support is to
be added until we have an AMD system.

Comments are welcome.

Thanks,
Wei.

[0] https://lore.kernel.org/linux-hyperv/1622241819-21155-1-git-send-email-nunodasneves@linux.microsoft.com/
[1] https://lore.kernel.org/linux-hyperv/cover.1622654100.git.viremana@linux.microsoft.com/

Wei Liu (8):
  x86/hyperv: export hv_build_pci_dev_id
  asm-generic/hyperv: add device domain definitions
  intel/vt-d: make DMAR table parsing code more flexible
  intel/vt-d: export intel_iommu_get_resv_regions
  mshv: add paravirtualized IOMMU support
  mshv: command line option to skip devices in PV-IOMMU
  mshv: implement in-kernel device framework
  mshv: add vfio bridge device

 Documentation/virt/mshv/api.rst     |  12 +
 arch/x86/hyperv/irqdomain.c         |   3 +-
 arch/x86/include/asm/mshyperv.h     |   1 +
 drivers/hv/Kconfig                  |   4 +
 drivers/hv/Makefile                 |   2 +-
 drivers/hv/mshv_main.c              | 186 ++++++++
 drivers/hv/vfio.c                   | 244 ++++++++++
 drivers/hv/vfio.h                   |  18 +
 drivers/iommu/Kconfig               |  14 +
 drivers/iommu/hyperv-iommu.c        | 673 ++++++++++++++++++++++++++++
 drivers/iommu/intel/dmar.c          |  38 +-
 drivers/iommu/intel/iommu.c         |   7 +-
 drivers/iommu/intel/irq_remapping.c |   2 +-
 include/asm-generic/hyperv-tlfs.h   | 144 ++++++
 include/linux/dmar.h                |   2 +-
 include/linux/intel-iommu.h         |   4 +
 include/linux/mshv.h                |  57 +++
 include/uapi/linux/mshv.h           |  36 ++
 18 files changed, 1429 insertions(+), 18 deletions(-)
 create mode 100644 drivers/hv/vfio.c
 create mode 100644 drivers/hv/vfio.h

-- 
2.30.2