[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[PATCH 00/11] 1:1 direct-map memory map


  • To: <xen-devel@xxxxxxxxxxxxxxxxxxxx>, <sstabellini@xxxxxxxxxx>, <julien@xxxxxxx>
  • From: Penny Zheng <penny.zheng@xxxxxxx>
  • Date: Thu, 23 Sep 2021 03:11:04 +0000
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 40.67.248.234) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=none (message not signed); arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UAeAMVF5g6MVjQKqmQi4d01qiiA0tPwK6j/l9Ubz7bc=; b=l4jZ0ylVLBSshdnKzuOk+6a8MEEYor4TK7hkByV6kZhPEPFqSMcVjezyX0dK0kMxiSfvGTsveQw9DNDXS17y4/bPc4G7jzQjgzUmg893VH5MibSg5w/k6a37E9gsNA/gagZbavNBuogGaVRVBIRjB3dFg/Al2TsimVMp3mLeTcTiLZ3ZtVxN1VeAteSV3Yt/cwucwQ1fD70a3VdkdpBbIaeaZXIFhBAJkEGfhAkQcCYHFK2VzcEtJXcmXlQY86eWxTIKE53bmkAzxCtVqanijMFrcdp1h5QbIOu9x+V+L+IHu4NPUvyMOwCoWkYx3JGpn4hZRWrS1PymXsa2Jca//g==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gnWi49FVyhZfhVGKqJN6eObkVj2pjqinxpwZuQhMi+lzt+HZ7Kxa5NHmMcKatxOQaNQCRJ5RKdKmOwC6R538ZiD6+h0vVbFBpQvXCvP8J6pdyEWMAWle9faqzJ2g56y4rDPVqeJHL2TbTkJ9n5iPFABU5SmcN+0/vHKElxA5mwvFIFxSu7k10dy31a3wx2D5Q4vQnnPmLBkiSyZtXt24GZ22eZOxcci9a9s+A6ONE0ILdSwKW6ZW4fWdry9LUF+afPiSM68ngW4YYMRc+EtY1xwnvbMSnTLSap3X6OJ5zBPtkZg/1t91YbFg/jnbjW9Y1JmancymEoqtF/UYUG1CmA==
  • Cc: <Bertrand.Marquis@xxxxxxx>, <Penny.Zheng@xxxxxxx>, <Wei.Chen@xxxxxxx>
  • Delivery-date: Thu, 23 Sep 2021 03:11:53 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true

Cases where domU needs 1:1 direct-map memory map:
  * IOMMU not present in the system.
  * IOMMU disabled if it doesn't cover a specific device and all the guests
are trusted. Thinking a mixed scenario, where a few devices with IOMMU and
a few without, then guest DMA security still could not be totally guaranteed.
So users may want to disable the IOMMU, to at least gain some performance
improvement from IOMMU disabled.
  * IOMMU disabled as a workaround when it doesn't have enough bandwidth.
To be specific, in a few extreme situation, when multiple devices do DMA
concurrently, these requests may exceed IOMMU's transmission capacity.
  * IOMMU disabled when it adds too much latency on DMA. For example,
TLB may be missing in some IOMMU hardware, which may bring latency in DMA
progress, so users may want to disable it in some realtime scenario.

*WARNING:
Users should be aware that it is not always secure to assign a device without
IOMMU protection.
When the device is not protected by the IOMMU, the administrator should make
sure that:
 1. The device is assigned to a trusted guest.
 2. Users have additional security mechanism on the platform.

Requesting 1:1 memory mapping for the domain, when IOMMU is absent from the
system or it is disabled (status = "disabled" in device tree). In which
case, "direct-map" property is added under the appropriate domain node.

Right now, 1:1 direct-map is only supported when domain on Static Allocation,
that is, "xen,static-mem" is also necessary in the domain configuration.

Looking into related [design link](
https://lists.xenproject.org/archives/html/xen-devel/2021-05/msg00882.html)
for more details.

The whole design is about Static Allocation and 1:1 direct-map, and this
Patch Serie only covers parts of it, which are 1:1 direct-map memory map.
Other features will be delievered through different patch series.

See https://lists.xenproject.org/archives/html/xen-devel/2021-09/msg00855.html
for Domain on Static Allocation.

Penny Zheng (1):
  xen/arm: device assignment on 1:1 direct-map domain

Stefano Stabellini (10):
  xen: reserve flags for internal usage in xen_domctl_createdomain
  xen/arm: introduce XEN_DOMCTL_INTERNAL_directmap
  xen/arm: introduce 1:1 direct-map for domUs
  xen/arm: introduce accessors for vgic dist, cpu, and rdist base
    addresses
  xen/arm: vgic: introduce vgic.cbase
  xen/arm: new vgic: update vgic_cpu_base
  xen/arm: if 1:1 direct-map domain use native addresses for GICv2
  xen/arm: if 1:1 direct-map domain use native addresses for GICv3
  xen/arm: if 1:1 direct-map domain use native UART address and IRQ
    number for vPL011
  xen/docs: add a document to explain how to do passthrough without
    IOMMU

 docs/misc/arm/device-tree/booting.txt |   9 ++
 docs/misc/arm/passthrough-noiommu.txt |  54 +++++++
 xen/arch/arm/domain.c                 |   3 +-
 xen/arch/arm/domain_build.c           | 219 ++++++++++++++++++--------
 xen/arch/arm/vgic-v2.c                |  26 ++-
 xen/arch/arm/vgic-v3.c                |  10 +-
 xen/arch/arm/vgic/vgic-v2.c           |  27 +++-
 xen/arch/arm/vpl011.c                 |  34 +++-
 xen/arch/x86/setup.c                  |   4 +-
 xen/common/domain.c                   |  19 ++-
 xen/common/domctl.c                   |   3 +-
 xen/common/sched/core.c               |   2 +-
 xen/include/asm-arm/domain.h          |   9 +-
 xen/include/asm-arm/new_vgic.h        |  24 +++
 xen/include/asm-arm/vgic.h            |  42 +++++
 xen/include/asm-arm/vpl011.h          |   2 +
 xen/include/public/domctl.h           |   3 +
 xen/include/xen/domain.h              |   8 +
 xen/include/xen/sched.h               |   3 +-
 19 files changed, 394 insertions(+), 107 deletions(-)
 create mode 100644 docs/misc/arm/passthrough-noiommu.txt

-- 
2.25.1




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.