* [PATCH V4 0/8] virtio: Solution to restrict memory access under Xen using xen-grant DMA-mapping layer
@ 2022-06-02 19:23 ` Oleksandr Tyshchenko
0 siblings, 0 replies; 30+ messages in thread
From: Oleksandr Tyshchenko @ 2022-06-02 19:23 UTC (permalink / raw)
To: xen-devel, linux-kernel, linux-arm-kernel, virtualization, x86
Cc: Oleksandr Tyshchenko, Michael S. Tsirkin, Christoph Hellwig,
Stefano Stabellini, Boris Ostrovsky, Juergen Gross, Julien Grall,
Bertrand Marquis, Wei Chen, Henry Wang, Kaly Xin, Jiamei Xie,
Alex Bennée
From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Hello all.
The purpose of this patch series is to add support for restricting memory access under Xen using specific
grant table [1] based DMA-mapping layer. Patch series is based on Juergen Gross’ initial work [2] which implies
using grant references instead of raw guest physical addresses (GPA) for the virtio communications (some
kind of the software IOMMU).
You can find RFC-V3 patch series (and previous discussions) at [3].
!!! Please note, the only diff between V3 and V4 is in commit #5, also I have collected the acks (commits ##4-7).
The high level idea is to create new Xen’s grant table based DMA-mapping layer for the guest Linux whose main
purpose is to provide a special 64-bit DMA address which is formed by using the grant reference (for a page
to be shared with the backend) with offset and setting the highest address bit (this is for the backend to
be able to distinguish grant ref based DMA address from normal GPA). For this to work we need the ability
to allocate contiguous (consecutive) grant references for multi-page allocations. And the backend then needs
to offer VIRTIO_F_ACCESS_PLATFORM and VIRTIO_F_VERSION_1 feature bits (it must support virtio-mmio modern
transport for 64-bit addresses in the virtqueue).
Xen's grant mapping mechanism is the secure and safe solution to share pages between domains which proven
to work and works for years (in the context of traditional Xen PV drivers for example). So far, the foreign
mapping is used for the virtio backend to map and access guest memory. With the foreign mapping, the backend
is able to map arbitrary pages from the guest memory (or even from Dom0 memory). And as the result, the malicious
backend which runs in a non-trusted domain can take advantage of this. Instead, with the grant mapping
the backend is only allowed to map pages which were explicitly granted by the guest before and nothing else.
According to the discussions in various mainline threads this solution would likely be welcome because it
perfectly fits in the security model Xen provides.
What is more, the grant table based solution requires zero changes to the Xen hypervisor itself at least
with virtio-mmio and DT (in comparison, for example, with "foreign mapping + virtio-iommu" solution which would
require the whole new complex emulator in hypervisor in addition to new functionality/hypercall to pass IOVA
from the virtio backend running elsewhere to the hypervisor and translate it to the GPA before mapping into
P2M or denying the foreign mapping request if no corresponding IOVA-GPA mapping present in the IOMMU page table
for that particular device). We only need to update toolstack to insert "xen,grant-dma" IOMMU node (to be referred
by the virtio-mmio device using "iommus" property) when creating a guest device-tree (this is an indicator for
the guest to use Xen grant mappings scheme for that device with the endpoint ID being used as ID of Xen domain
where the corresponding backend is running, the backend domid is used as an argument to the grant mapping APIs).
It worth mentioning that toolstack patch is based on non upstreamed yet “Virtio support for toolstack on Arm”
series which is on review now [4].
Please note the following:
- Patch series only covers Arm and virtio-mmio (device-tree) for now. To enable the restricted memory access
feature on Arm the following option should be set:
CONFIG_XEN_VIRTIO=y
- Patch series is based on "kernel: add new infrastructure for platform_has() support" patch series which
is on review now [5]
- Xen should be built with the following options:
CONFIG_IOREQ_SERVER=y
CONFIG_EXPERT=y
Patch series is rebased on "for-linus-5.19" branch [1] with "platform_has()" series applied and tested on Renesas
Salvator-X board + H3 ES3.0 SoC (Arm64) with standalone userspace (non-Qemu) virtio-mmio based virtio-disk backend
running in Driver domain and Linux guest running on existing virtio-blk driver (frontend). No issues were observed.
Guest domain 'reboot/destroy' use-cases work properly.
I have also tested other use-cases such as assigning several virtio block devices or a mix of virtio and Xen PV block
devices to the guest. Patch series was build-tested on Arm32 and x86.
1. Xen changes located at (last patch):
https://github.com/otyshchenko1/xen/commits/libxl_virtio_next2_1
2. Linux changes located at (last 8 patches):
https://github.com/otyshchenko1/linux/commits/virtio_grant9
3. virtio-disk changes located at:
https://github.com/otyshchenko1/virtio-disk/commits/virtio_grant
Any feedback/help would be highly appreciated.
[1] https://xenbits.xenproject.org/docs/4.16-testing/misc/grant-tables.txt
[2] https://www.youtube.com/watch?v=IrlEdaIUDPk
[3] https://lore.kernel.org/xen-devel/1649963973-22879-1-git-send-email-olekstysh@gmail.com/
https://lore.kernel.org/xen-devel/1650646263-22047-1-git-send-email-olekstysh@gmail.com/
https://lore.kernel.org/xen-devel/1651947548-4055-1-git-send-email-olekstysh@gmail.com/
https://lore.kernel.org/xen-devel/1653944417-17168-1-git-send-email-olekstysh@gmail.com/
[4] https://lore.kernel.org/xen-devel/1654106261-28044-1-git-send-email-olekstysh@gmail.com/
https://lore.kernel.org/xen-devel/1653944813-17970-1-git-send-email-olekstysh@gmail.com/
[5] https://lore.kernel.org/xen-devel/20220504155703.13336-1-jgross@suse.com/
[6] https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git/log/?h=for-linus-5.19
Juergen Gross (3):
xen/grants: support allocating consecutive grants
xen/grant-dma-ops: Add option to restrict memory access under Xen
xen/virtio: Enable restricted memory access using Xen grant mappings
Oleksandr Tyshchenko (5):
arm/xen: Introduce xen_setup_dma_ops()
dt-bindings: Add xen,grant-dma IOMMU description for xen-grant DMA ops
xen/grant-dma-iommu: Introduce stub IOMMU driver
xen/grant-dma-ops: Retrieve the ID of backend's domain for DT devices
arm/xen: Assign xen-grant DMA ops for xen-grant DMA devices
.../devicetree/bindings/iommu/xen,grant-dma.yaml | 39 +++
arch/arm/include/asm/xen/xen-ops.h | 2 +
arch/arm/mm/dma-mapping.c | 7 +-
arch/arm/xen/enlighten.c | 2 +
arch/arm64/include/asm/xen/xen-ops.h | 2 +
arch/arm64/mm/dma-mapping.c | 7 +-
arch/x86/xen/enlighten_hvm.c | 2 +
arch/x86/xen/enlighten_pv.c | 2 +
drivers/xen/Kconfig | 20 ++
drivers/xen/Makefile | 2 +
drivers/xen/grant-dma-iommu.c | 78 +++++
drivers/xen/grant-dma-ops.c | 345 +++++++++++++++++++++
drivers/xen/grant-table.c | 251 ++++++++++++---
include/xen/arm/xen-ops.h | 18 ++
include/xen/grant_table.h | 4 +
include/xen/xen-ops.h | 13 +
include/xen/xen.h | 8 +
17 files changed, 756 insertions(+), 46 deletions(-)
create mode 100644 Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml
create mode 100644 arch/arm/include/asm/xen/xen-ops.h
create mode 100644 arch/arm64/include/asm/xen/xen-ops.h
create mode 100644 drivers/xen/grant-dma-iommu.c
create mode 100644 drivers/xen/grant-dma-ops.c
create mode 100644 include/xen/arm/xen-ops.h
--
2.7.4
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH V4 0/8] virtio: Solution to restrict memory access under Xen using xen-grant DMA-mapping layer
@ 2022-06-02 19:23 ` Oleksandr Tyshchenko
0 siblings, 0 replies; 30+ messages in thread
From: Oleksandr Tyshchenko @ 2022-06-02 19:23 UTC (permalink / raw)
To: xen-devel, linux-kernel, linux-arm-kernel, virtualization, x86
Cc: Oleksandr Tyshchenko, Michael S. Tsirkin, Christoph Hellwig,
Stefano Stabellini, Boris Ostrovsky, Juergen Gross, Julien Grall,
Bertrand Marquis, Wei Chen, Henry Wang, Kaly Xin, Jiamei Xie,
Alex Bennée
From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Hello all.
The purpose of this patch series is to add support for restricting memory access under Xen using specific
grant table [1] based DMA-mapping layer. Patch series is based on Juergen Gross’ initial work [2] which implies
using grant references instead of raw guest physical addresses (GPA) for the virtio communications (some
kind of the software IOMMU).
You can find RFC-V3 patch series (and previous discussions) at [3].
!!! Please note, the only diff between V3 and V4 is in commit #5, also I have collected the acks (commits ##4-7).
The high level idea is to create new Xen’s grant table based DMA-mapping layer for the guest Linux whose main
purpose is to provide a special 64-bit DMA address which is formed by using the grant reference (for a page
to be shared with the backend) with offset and setting the highest address bit (this is for the backend to
be able to distinguish grant ref based DMA address from normal GPA). For this to work we need the ability
to allocate contiguous (consecutive) grant references for multi-page allocations. And the backend then needs
to offer VIRTIO_F_ACCESS_PLATFORM and VIRTIO_F_VERSION_1 feature bits (it must support virtio-mmio modern
transport for 64-bit addresses in the virtqueue).
Xen's grant mapping mechanism is the secure and safe solution to share pages between domains which proven
to work and works for years (in the context of traditional Xen PV drivers for example). So far, the foreign
mapping is used for the virtio backend to map and access guest memory. With the foreign mapping, the backend
is able to map arbitrary pages from the guest memory (or even from Dom0 memory). And as the result, the malicious
backend which runs in a non-trusted domain can take advantage of this. Instead, with the grant mapping
the backend is only allowed to map pages which were explicitly granted by the guest before and nothing else.
According to the discussions in various mainline threads this solution would likely be welcome because it
perfectly fits in the security model Xen provides.
What is more, the grant table based solution requires zero changes to the Xen hypervisor itself at least
with virtio-mmio and DT (in comparison, for example, with "foreign mapping + virtio-iommu" solution which would
require the whole new complex emulator in hypervisor in addition to new functionality/hypercall to pass IOVA
from the virtio backend running elsewhere to the hypervisor and translate it to the GPA before mapping into
P2M or denying the foreign mapping request if no corresponding IOVA-GPA mapping present in the IOMMU page table
for that particular device). We only need to update toolstack to insert "xen,grant-dma" IOMMU node (to be referred
by the virtio-mmio device using "iommus" property) when creating a guest device-tree (this is an indicator for
the guest to use Xen grant mappings scheme for that device with the endpoint ID being used as ID of Xen domain
where the corresponding backend is running, the backend domid is used as an argument to the grant mapping APIs).
It worth mentioning that toolstack patch is based on non upstreamed yet “Virtio support for toolstack on Arm”
series which is on review now [4].
Please note the following:
- Patch series only covers Arm and virtio-mmio (device-tree) for now. To enable the restricted memory access
feature on Arm the following option should be set:
CONFIG_XEN_VIRTIO=y
- Patch series is based on "kernel: add new infrastructure for platform_has() support" patch series which
is on review now [5]
- Xen should be built with the following options:
CONFIG_IOREQ_SERVER=y
CONFIG_EXPERT=y
Patch series is rebased on "for-linus-5.19" branch [1] with "platform_has()" series applied and tested on Renesas
Salvator-X board + H3 ES3.0 SoC (Arm64) with standalone userspace (non-Qemu) virtio-mmio based virtio-disk backend
running in Driver domain and Linux guest running on existing virtio-blk driver (frontend). No issues were observed.
Guest domain 'reboot/destroy' use-cases work properly.
I have also tested other use-cases such as assigning several virtio block devices or a mix of virtio and Xen PV block
devices to the guest. Patch series was build-tested on Arm32 and x86.
1. Xen changes located at (last patch):
https://github.com/otyshchenko1/xen/commits/libxl_virtio_next2_1
2. Linux changes located at (last 8 patches):
https://github.com/otyshchenko1/linux/commits/virtio_grant9
3. virtio-disk changes located at:
https://github.com/otyshchenko1/virtio-disk/commits/virtio_grant
Any feedback/help would be highly appreciated.
[1] https://xenbits.xenproject.org/docs/4.16-testing/misc/grant-tables.txt
[2] https://www.youtube.com/watch?v=IrlEdaIUDPk
[3] https://lore.kernel.org/xen-devel/1649963973-22879-1-git-send-email-olekstysh@gmail.com/
https://lore.kernel.org/xen-devel/1650646263-22047-1-git-send-email-olekstysh@gmail.com/
https://lore.kernel.org/xen-devel/1651947548-4055-1-git-send-email-olekstysh@gmail.com/
https://lore.kernel.org/xen-devel/1653944417-17168-1-git-send-email-olekstysh@gmail.com/
[4] https://lore.kernel.org/xen-devel/1654106261-28044-1-git-send-email-olekstysh@gmail.com/
https://lore.kernel.org/xen-devel/1653944813-17970-1-git-send-email-olekstysh@gmail.com/
[5] https://lore.kernel.org/xen-devel/20220504155703.13336-1-jgross@suse.com/
[6] https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git/log/?h=for-linus-5.19
Juergen Gross (3):
xen/grants: support allocating consecutive grants
xen/grant-dma-ops: Add option to restrict memory access under Xen
xen/virtio: Enable restricted memory access using Xen grant mappings
Oleksandr Tyshchenko (5):
arm/xen: Introduce xen_setup_dma_ops()
dt-bindings: Add xen,grant-dma IOMMU description for xen-grant DMA ops
xen/grant-dma-iommu: Introduce stub IOMMU driver
xen/grant-dma-ops: Retrieve the ID of backend's domain for DT devices
arm/xen: Assign xen-grant DMA ops for xen-grant DMA devices
.../devicetree/bindings/iommu/xen,grant-dma.yaml | 39 +++
arch/arm/include/asm/xen/xen-ops.h | 2 +
arch/arm/mm/dma-mapping.c | 7 +-
arch/arm/xen/enlighten.c | 2 +
arch/arm64/include/asm/xen/xen-ops.h | 2 +
arch/arm64/mm/dma-mapping.c | 7 +-
arch/x86/xen/enlighten_hvm.c | 2 +
arch/x86/xen/enlighten_pv.c | 2 +
drivers/xen/Kconfig | 20 ++
drivers/xen/Makefile | 2 +
drivers/xen/grant-dma-iommu.c | 78 +++++
drivers/xen/grant-dma-ops.c | 345 +++++++++++++++++++++
drivers/xen/grant-table.c | 251 ++++++++++++---
include/xen/arm/xen-ops.h | 18 ++
include/xen/grant_table.h | 4 +
include/xen/xen-ops.h | 13 +
include/xen/xen.h | 8 +
17 files changed, 756 insertions(+), 46 deletions(-)
create mode 100644 Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml
create mode 100644 arch/arm/include/asm/xen/xen-ops.h
create mode 100644 arch/arm64/include/asm/xen/xen-ops.h
create mode 100644 drivers/xen/grant-dma-iommu.c
create mode 100644 drivers/xen/grant-dma-ops.c
create mode 100644 include/xen/arm/xen-ops.h
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH V4 1/8] arm/xen: Introduce xen_setup_dma_ops()
2022-06-02 19:23 ` Oleksandr Tyshchenko
@ 2022-06-02 19:23 ` Oleksandr Tyshchenko
-1 siblings, 0 replies; 30+ messages in thread
From: Oleksandr Tyshchenko @ 2022-06-02 19:23 UTC (permalink / raw)
To: xen-devel, linux-kernel, linux-arm-kernel
Cc: Oleksandr Tyshchenko, Stefano Stabellini, Russell King,
Catalin Marinas, Will Deacon, Boris Ostrovsky, Juergen Gross,
Julien Grall, Michael S. Tsirkin, Christoph Hellwig
From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
This patch introduces new helper and places it in new header.
The helper's purpose is to assign any Xen specific DMA ops in
a single place. For now, we deal with xen-swiotlb DMA ops only.
The one of the subsequent commits in current series will add
xen-grant DMA ops case.
Also re-use the xen_swiotlb_detect() check on Arm32.
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
[For arm64]
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
---
Changes RFC -> V1:
- update commit description
- move commit to the beginning of the series
- move #ifdef CONFIG_XEN from dma-mapping.c to xen-ops.h
Changes V1 -> V2:
- add Stefano's R-b
- add missing SPDX-License-Identifier to xen-ops.h
Changes V2 -> V3:
- add Catalin's A-b
Changes V3 -> V4:
- no changes
---
arch/arm/include/asm/xen/xen-ops.h | 2 ++
arch/arm/mm/dma-mapping.c | 7 ++-----
arch/arm64/include/asm/xen/xen-ops.h | 2 ++
arch/arm64/mm/dma-mapping.c | 7 ++-----
include/xen/arm/xen-ops.h | 15 +++++++++++++++
5 files changed, 23 insertions(+), 10 deletions(-)
create mode 100644 arch/arm/include/asm/xen/xen-ops.h
create mode 100644 arch/arm64/include/asm/xen/xen-ops.h
create mode 100644 include/xen/arm/xen-ops.h
diff --git a/arch/arm/include/asm/xen/xen-ops.h b/arch/arm/include/asm/xen/xen-ops.h
new file mode 100644
index 00000000..7ebb7eb
--- /dev/null
+++ b/arch/arm/include/asm/xen/xen-ops.h
@@ -0,0 +1,2 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#include <xen/arm/xen-ops.h>
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 82ffac6..059cce0 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -33,7 +33,7 @@
#include <asm/dma-iommu.h>
#include <asm/mach/map.h>
#include <asm/system_info.h>
-#include <xen/swiotlb-xen.h>
+#include <asm/xen/xen-ops.h>
#include "dma.h"
#include "mm.h"
@@ -2287,10 +2287,7 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
set_dma_ops(dev, dma_ops);
-#ifdef CONFIG_XEN
- if (xen_initial_domain())
- dev->dma_ops = &xen_swiotlb_dma_ops;
-#endif
+ xen_setup_dma_ops(dev);
dev->archdata.dma_ops_setup = true;
}
diff --git a/arch/arm64/include/asm/xen/xen-ops.h b/arch/arm64/include/asm/xen/xen-ops.h
new file mode 100644
index 00000000..7ebb7eb
--- /dev/null
+++ b/arch/arm64/include/asm/xen/xen-ops.h
@@ -0,0 +1,2 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#include <xen/arm/xen-ops.h>
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 6719f9e..6099c81 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -9,9 +9,9 @@
#include <linux/dma-map-ops.h>
#include <linux/dma-iommu.h>
#include <xen/xen.h>
-#include <xen/swiotlb-xen.h>
#include <asm/cacheflush.h>
+#include <asm/xen/xen-ops.h>
void arch_sync_dma_for_device(phys_addr_t paddr, size_t size,
enum dma_data_direction dir)
@@ -52,8 +52,5 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
if (iommu)
iommu_setup_dma_ops(dev, dma_base, dma_base + size - 1);
-#ifdef CONFIG_XEN
- if (xen_swiotlb_detect())
- dev->dma_ops = &xen_swiotlb_dma_ops;
-#endif
+ xen_setup_dma_ops(dev);
}
diff --git a/include/xen/arm/xen-ops.h b/include/xen/arm/xen-ops.h
new file mode 100644
index 00000000..288deb1
--- /dev/null
+++ b/include/xen/arm/xen-ops.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_ARM_XEN_OPS_H
+#define _ASM_ARM_XEN_OPS_H
+
+#include <xen/swiotlb-xen.h>
+
+static inline void xen_setup_dma_ops(struct device *dev)
+{
+#ifdef CONFIG_XEN
+ if (xen_swiotlb_detect())
+ dev->dma_ops = &xen_swiotlb_dma_ops;
+#endif
+}
+
+#endif /* _ASM_ARM_XEN_OPS_H */
--
2.7.4
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH V4 1/8] arm/xen: Introduce xen_setup_dma_ops()
@ 2022-06-02 19:23 ` Oleksandr Tyshchenko
0 siblings, 0 replies; 30+ messages in thread
From: Oleksandr Tyshchenko @ 2022-06-02 19:23 UTC (permalink / raw)
To: xen-devel, linux-kernel, linux-arm-kernel
Cc: Oleksandr Tyshchenko, Stefano Stabellini, Russell King,
Catalin Marinas, Will Deacon, Boris Ostrovsky, Juergen Gross,
Julien Grall, Michael S. Tsirkin, Christoph Hellwig
From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
This patch introduces new helper and places it in new header.
The helper's purpose is to assign any Xen specific DMA ops in
a single place. For now, we deal with xen-swiotlb DMA ops only.
The one of the subsequent commits in current series will add
xen-grant DMA ops case.
Also re-use the xen_swiotlb_detect() check on Arm32.
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
[For arm64]
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
---
Changes RFC -> V1:
- update commit description
- move commit to the beginning of the series
- move #ifdef CONFIG_XEN from dma-mapping.c to xen-ops.h
Changes V1 -> V2:
- add Stefano's R-b
- add missing SPDX-License-Identifier to xen-ops.h
Changes V2 -> V3:
- add Catalin's A-b
Changes V3 -> V4:
- no changes
---
arch/arm/include/asm/xen/xen-ops.h | 2 ++
arch/arm/mm/dma-mapping.c | 7 ++-----
arch/arm64/include/asm/xen/xen-ops.h | 2 ++
arch/arm64/mm/dma-mapping.c | 7 ++-----
include/xen/arm/xen-ops.h | 15 +++++++++++++++
5 files changed, 23 insertions(+), 10 deletions(-)
create mode 100644 arch/arm/include/asm/xen/xen-ops.h
create mode 100644 arch/arm64/include/asm/xen/xen-ops.h
create mode 100644 include/xen/arm/xen-ops.h
diff --git a/arch/arm/include/asm/xen/xen-ops.h b/arch/arm/include/asm/xen/xen-ops.h
new file mode 100644
index 00000000..7ebb7eb
--- /dev/null
+++ b/arch/arm/include/asm/xen/xen-ops.h
@@ -0,0 +1,2 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#include <xen/arm/xen-ops.h>
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 82ffac6..059cce0 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -33,7 +33,7 @@
#include <asm/dma-iommu.h>
#include <asm/mach/map.h>
#include <asm/system_info.h>
-#include <xen/swiotlb-xen.h>
+#include <asm/xen/xen-ops.h>
#include "dma.h"
#include "mm.h"
@@ -2287,10 +2287,7 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
set_dma_ops(dev, dma_ops);
-#ifdef CONFIG_XEN
- if (xen_initial_domain())
- dev->dma_ops = &xen_swiotlb_dma_ops;
-#endif
+ xen_setup_dma_ops(dev);
dev->archdata.dma_ops_setup = true;
}
diff --git a/arch/arm64/include/asm/xen/xen-ops.h b/arch/arm64/include/asm/xen/xen-ops.h
new file mode 100644
index 00000000..7ebb7eb
--- /dev/null
+++ b/arch/arm64/include/asm/xen/xen-ops.h
@@ -0,0 +1,2 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#include <xen/arm/xen-ops.h>
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 6719f9e..6099c81 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -9,9 +9,9 @@
#include <linux/dma-map-ops.h>
#include <linux/dma-iommu.h>
#include <xen/xen.h>
-#include <xen/swiotlb-xen.h>
#include <asm/cacheflush.h>
+#include <asm/xen/xen-ops.h>
void arch_sync_dma_for_device(phys_addr_t paddr, size_t size,
enum dma_data_direction dir)
@@ -52,8 +52,5 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
if (iommu)
iommu_setup_dma_ops(dev, dma_base, dma_base + size - 1);
-#ifdef CONFIG_XEN
- if (xen_swiotlb_detect())
- dev->dma_ops = &xen_swiotlb_dma_ops;
-#endif
+ xen_setup_dma_ops(dev);
}
diff --git a/include/xen/arm/xen-ops.h b/include/xen/arm/xen-ops.h
new file mode 100644
index 00000000..288deb1
--- /dev/null
+++ b/include/xen/arm/xen-ops.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_ARM_XEN_OPS_H
+#define _ASM_ARM_XEN_OPS_H
+
+#include <xen/swiotlb-xen.h>
+
+static inline void xen_setup_dma_ops(struct device *dev)
+{
+#ifdef CONFIG_XEN
+ if (xen_swiotlb_detect())
+ dev->dma_ops = &xen_swiotlb_dma_ops;
+#endif
+}
+
+#endif /* _ASM_ARM_XEN_OPS_H */
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH V4 2/8] xen/grants: support allocating consecutive grants
2022-06-02 19:23 ` Oleksandr Tyshchenko
@ 2022-06-02 19:23 ` Oleksandr Tyshchenko
-1 siblings, 0 replies; 30+ messages in thread
From: Oleksandr Tyshchenko @ 2022-06-02 19:23 UTC (permalink / raw)
To: xen-devel, linux-kernel, linux-arm-kernel
Cc: Juergen Gross, Boris Ostrovsky, Stefano Stabellini, Julien Grall,
Oleksandr Tyshchenko, Michael S. Tsirkin, Christoph Hellwig
From: Juergen Gross <jgross@suse.com>
For support of virtio via grant mappings in rare cases larger mappings
using consecutive grants are needed. Support those by adding a bitmap
of free grants.
As consecutive grants will be needed only in very rare cases (e.g. when
configuring a virtio device with a multi-page ring), optimize for the
normal case of non-consecutive allocations.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
Changes RFC -> V1:
- no changes
Changes V1 -> V2:
- no changes
Changes V2 -> V3:
- rebase, move "if (unlikely(ref < GNTTAB_NR_RESERVED_ENTRIES))"
to put_free_entry_locked()
- do not overwrite "i" in gnttab_init(), introduce local max_nr_grefs
- add a comment on top of "while (from < to)" in get_free_seq()
- add Boris' R-b
Changes V3 -> V4:
- no changes
---
drivers/xen/grant-table.c | 251 +++++++++++++++++++++++++++++++++++++++-------
include/xen/grant_table.h | 4 +
2 files changed, 219 insertions(+), 36 deletions(-)
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 7a18292..738029d 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -33,6 +33,7 @@
#define pr_fmt(fmt) "xen:" KBUILD_MODNAME ": " fmt
+#include <linux/bitmap.h>
#include <linux/memblock.h>
#include <linux/sched.h>
#include <linux/mm.h>
@@ -70,9 +71,32 @@
static grant_ref_t **gnttab_list;
static unsigned int nr_grant_frames;
+
+/*
+ * Handling of free grants:
+ *
+ * Free grants are in a simple list anchored in gnttab_free_head. They are
+ * linked by grant ref, the last element contains GNTTAB_LIST_END. The number
+ * of free entries is stored in gnttab_free_count.
+ * Additionally there is a bitmap of free entries anchored in
+ * gnttab_free_bitmap. This is being used for simplifying allocation of
+ * multiple consecutive grants, which is needed e.g. for support of virtio.
+ * gnttab_last_free is used to add free entries of new frames at the end of
+ * the free list.
+ * gnttab_free_tail_ptr specifies the variable which references the start
+ * of consecutive free grants ending with gnttab_last_free. This pointer is
+ * updated in a rather defensive way, in order to avoid performance hits in
+ * hot paths.
+ * All those variables are protected by gnttab_list_lock.
+ */
static int gnttab_free_count;
-static grant_ref_t gnttab_free_head;
+static unsigned int gnttab_size;
+static grant_ref_t gnttab_free_head = GNTTAB_LIST_END;
+static grant_ref_t gnttab_last_free = GNTTAB_LIST_END;
+static grant_ref_t *gnttab_free_tail_ptr;
+static unsigned long *gnttab_free_bitmap;
static DEFINE_SPINLOCK(gnttab_list_lock);
+
struct grant_frames xen_auto_xlat_grant_frames;
static unsigned int xen_gnttab_version;
module_param_named(version, xen_gnttab_version, uint, 0);
@@ -168,16 +192,116 @@ static int get_free_entries(unsigned count)
ref = head = gnttab_free_head;
gnttab_free_count -= count;
- while (count-- > 1)
- head = gnttab_entry(head);
+ while (count--) {
+ bitmap_clear(gnttab_free_bitmap, head, 1);
+ if (gnttab_free_tail_ptr == __gnttab_entry(head))
+ gnttab_free_tail_ptr = &gnttab_free_head;
+ if (count)
+ head = gnttab_entry(head);
+ }
gnttab_free_head = gnttab_entry(head);
gnttab_entry(head) = GNTTAB_LIST_END;
+ if (!gnttab_free_count) {
+ gnttab_last_free = GNTTAB_LIST_END;
+ gnttab_free_tail_ptr = NULL;
+ }
+
spin_unlock_irqrestore(&gnttab_list_lock, flags);
return ref;
}
+static int get_seq_entry_count(void)
+{
+ if (gnttab_last_free == GNTTAB_LIST_END || !gnttab_free_tail_ptr ||
+ *gnttab_free_tail_ptr == GNTTAB_LIST_END)
+ return 0;
+
+ return gnttab_last_free - *gnttab_free_tail_ptr + 1;
+}
+
+/* Rebuilds the free grant list and tries to find count consecutive entries. */
+static int get_free_seq(unsigned int count)
+{
+ int ret = -ENOSPC;
+ unsigned int from, to;
+ grant_ref_t *last;
+
+ gnttab_free_tail_ptr = &gnttab_free_head;
+ last = &gnttab_free_head;
+
+ for (from = find_first_bit(gnttab_free_bitmap, gnttab_size);
+ from < gnttab_size;
+ from = find_next_bit(gnttab_free_bitmap, gnttab_size, to + 1)) {
+ to = find_next_zero_bit(gnttab_free_bitmap, gnttab_size,
+ from + 1);
+ if (ret < 0 && to - from >= count) {
+ ret = from;
+ bitmap_clear(gnttab_free_bitmap, ret, count);
+ from += count;
+ gnttab_free_count -= count;
+ if (from == to)
+ continue;
+ }
+
+ /*
+ * Recreate the free list in order to have it properly sorted.
+ * This is needed to make sure that the free tail has the maximum
+ * possible size.
+ */
+ while (from < to) {
+ *last = from;
+ last = __gnttab_entry(from);
+ gnttab_last_free = from;
+ from++;
+ }
+ if (to < gnttab_size)
+ gnttab_free_tail_ptr = __gnttab_entry(to - 1);
+ }
+
+ *last = GNTTAB_LIST_END;
+ if (gnttab_last_free != gnttab_size - 1)
+ gnttab_free_tail_ptr = NULL;
+
+ return ret;
+}
+
+static int get_free_entries_seq(unsigned int count)
+{
+ unsigned long flags;
+ int ret = 0;
+
+ spin_lock_irqsave(&gnttab_list_lock, flags);
+
+ if (gnttab_free_count < count) {
+ ret = gnttab_expand(count - gnttab_free_count);
+ if (ret < 0)
+ goto out;
+ }
+
+ if (get_seq_entry_count() < count) {
+ ret = get_free_seq(count);
+ if (ret >= 0)
+ goto out;
+ ret = gnttab_expand(count - get_seq_entry_count());
+ if (ret < 0)
+ goto out;
+ }
+
+ ret = *gnttab_free_tail_ptr;
+ *gnttab_free_tail_ptr = gnttab_entry(ret + count - 1);
+ gnttab_free_count -= count;
+ if (!gnttab_free_count)
+ gnttab_free_tail_ptr = NULL;
+ bitmap_clear(gnttab_free_bitmap, ret, count);
+
+ out:
+ spin_unlock_irqrestore(&gnttab_list_lock, flags);
+
+ return ret;
+}
+
static void do_free_callbacks(void)
{
struct gnttab_free_callback *callback, *next;
@@ -204,21 +328,51 @@ static inline void check_free_callbacks(void)
do_free_callbacks();
}
-static void put_free_entry(grant_ref_t ref)
+static void put_free_entry_locked(grant_ref_t ref)
{
- unsigned long flags;
-
if (unlikely(ref < GNTTAB_NR_RESERVED_ENTRIES))
return;
- spin_lock_irqsave(&gnttab_list_lock, flags);
gnttab_entry(ref) = gnttab_free_head;
gnttab_free_head = ref;
+ if (!gnttab_free_count)
+ gnttab_last_free = ref;
+ if (gnttab_free_tail_ptr == &gnttab_free_head)
+ gnttab_free_tail_ptr = __gnttab_entry(ref);
gnttab_free_count++;
+ bitmap_set(gnttab_free_bitmap, ref, 1);
+}
+
+static void put_free_entry(grant_ref_t ref)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&gnttab_list_lock, flags);
+ put_free_entry_locked(ref);
check_free_callbacks();
spin_unlock_irqrestore(&gnttab_list_lock, flags);
}
+static void gnttab_set_free(unsigned int start, unsigned int n)
+{
+ unsigned int i;
+
+ for (i = start; i < start + n - 1; i++)
+ gnttab_entry(i) = i + 1;
+
+ gnttab_entry(i) = GNTTAB_LIST_END;
+ if (!gnttab_free_count) {
+ gnttab_free_head = start;
+ gnttab_free_tail_ptr = &gnttab_free_head;
+ } else {
+ gnttab_entry(gnttab_last_free) = start;
+ }
+ gnttab_free_count += n;
+ gnttab_last_free = i;
+
+ bitmap_set(gnttab_free_bitmap, start, n);
+}
+
/*
* Following applies to gnttab_update_entry_v1 and gnttab_update_entry_v2.
* Introducing a valid entry into the grant table:
@@ -450,23 +604,31 @@ void gnttab_free_grant_references(grant_ref_t head)
{
grant_ref_t ref;
unsigned long flags;
- int count = 1;
- if (head == GNTTAB_LIST_END)
- return;
+
spin_lock_irqsave(&gnttab_list_lock, flags);
- ref = head;
- while (gnttab_entry(ref) != GNTTAB_LIST_END) {
- ref = gnttab_entry(ref);
- count++;
+ while (head != GNTTAB_LIST_END) {
+ ref = gnttab_entry(head);
+ put_free_entry_locked(head);
+ head = ref;
}
- gnttab_entry(ref) = gnttab_free_head;
- gnttab_free_head = head;
- gnttab_free_count += count;
check_free_callbacks();
spin_unlock_irqrestore(&gnttab_list_lock, flags);
}
EXPORT_SYMBOL_GPL(gnttab_free_grant_references);
+void gnttab_free_grant_reference_seq(grant_ref_t head, unsigned int count)
+{
+ unsigned long flags;
+ unsigned int i;
+
+ spin_lock_irqsave(&gnttab_list_lock, flags);
+ for (i = count; i > 0; i--)
+ put_free_entry_locked(head + i - 1);
+ check_free_callbacks();
+ spin_unlock_irqrestore(&gnttab_list_lock, flags);
+}
+EXPORT_SYMBOL_GPL(gnttab_free_grant_reference_seq);
+
int gnttab_alloc_grant_references(u16 count, grant_ref_t *head)
{
int h = get_free_entries(count);
@@ -480,6 +642,24 @@ int gnttab_alloc_grant_references(u16 count, grant_ref_t *head)
}
EXPORT_SYMBOL_GPL(gnttab_alloc_grant_references);
+int gnttab_alloc_grant_reference_seq(unsigned int count, grant_ref_t *first)
+{
+ int h;
+
+ if (count == 1)
+ h = get_free_entries(1);
+ else
+ h = get_free_entries_seq(count);
+
+ if (h < 0)
+ return -ENOSPC;
+
+ *first = h;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(gnttab_alloc_grant_reference_seq);
+
int gnttab_empty_grant_references(const grant_ref_t *private_head)
{
return (*private_head == GNTTAB_LIST_END);
@@ -572,16 +752,13 @@ static int grow_gnttab_list(unsigned int more_frames)
goto grow_nomem;
}
+ gnttab_set_free(gnttab_size, extra_entries);
- for (i = grefs_per_frame * nr_grant_frames;
- i < grefs_per_frame * new_nr_grant_frames - 1; i++)
- gnttab_entry(i) = i + 1;
-
- gnttab_entry(i) = gnttab_free_head;
- gnttab_free_head = grefs_per_frame * nr_grant_frames;
- gnttab_free_count += extra_entries;
+ if (!gnttab_free_tail_ptr)
+ gnttab_free_tail_ptr = __gnttab_entry(gnttab_size);
nr_grant_frames = new_nr_grant_frames;
+ gnttab_size += extra_entries;
check_free_callbacks();
@@ -1424,20 +1601,20 @@ static int gnttab_expand(unsigned int req_entries)
int gnttab_init(void)
{
int i;
- unsigned long max_nr_grant_frames;
+ unsigned long max_nr_grant_frames, max_nr_grefs;
unsigned int max_nr_glist_frames, nr_glist_frames;
- unsigned int nr_init_grefs;
int ret;
gnttab_request_version();
max_nr_grant_frames = gnttab_max_grant_frames();
+ max_nr_grefs = max_nr_grant_frames *
+ gnttab_interface->grefs_per_grant_frame;
nr_grant_frames = 1;
/* Determine the maximum number of frames required for the
* grant reference free list on the current hypervisor.
*/
- max_nr_glist_frames = (max_nr_grant_frames *
- gnttab_interface->grefs_per_grant_frame / RPP);
+ max_nr_glist_frames = max_nr_grefs / RPP;
gnttab_list = kmalloc_array(max_nr_glist_frames,
sizeof(grant_ref_t *),
@@ -1454,6 +1631,12 @@ int gnttab_init(void)
}
}
+ gnttab_free_bitmap = bitmap_zalloc(max_nr_grefs, GFP_KERNEL);
+ if (!gnttab_free_bitmap) {
+ ret = -ENOMEM;
+ goto ini_nomem;
+ }
+
ret = arch_gnttab_init(max_nr_grant_frames,
nr_status_frames(max_nr_grant_frames));
if (ret < 0)
@@ -1464,15 +1647,10 @@ int gnttab_init(void)
goto ini_nomem;
}
- nr_init_grefs = nr_grant_frames *
- gnttab_interface->grefs_per_grant_frame;
-
- for (i = GNTTAB_NR_RESERVED_ENTRIES; i < nr_init_grefs - 1; i++)
- gnttab_entry(i) = i + 1;
+ gnttab_size = nr_grant_frames * gnttab_interface->grefs_per_grant_frame;
- gnttab_entry(nr_init_grefs - 1) = GNTTAB_LIST_END;
- gnttab_free_count = nr_init_grefs - GNTTAB_NR_RESERVED_ENTRIES;
- gnttab_free_head = GNTTAB_NR_RESERVED_ENTRIES;
+ gnttab_set_free(GNTTAB_NR_RESERVED_ENTRIES,
+ gnttab_size - GNTTAB_NR_RESERVED_ENTRIES);
printk("Grant table initialized\n");
return 0;
@@ -1481,6 +1659,7 @@ int gnttab_init(void)
for (i--; i >= 0; i--)
free_page((unsigned long)gnttab_list[i]);
kfree(gnttab_list);
+ bitmap_free(gnttab_free_bitmap);
return ret;
}
EXPORT_SYMBOL_GPL(gnttab_init);
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index 527c990..e279be3 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -127,10 +127,14 @@ int gnttab_try_end_foreign_access(grant_ref_t ref);
*/
int gnttab_alloc_grant_references(u16 count, grant_ref_t *pprivate_head);
+int gnttab_alloc_grant_reference_seq(unsigned int count, grant_ref_t *first);
+
void gnttab_free_grant_reference(grant_ref_t ref);
void gnttab_free_grant_references(grant_ref_t head);
+void gnttab_free_grant_reference_seq(grant_ref_t head, unsigned int count);
+
int gnttab_empty_grant_references(const grant_ref_t *pprivate_head);
int gnttab_claim_grant_reference(grant_ref_t *pprivate_head);
--
2.7.4
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH V4 2/8] xen/grants: support allocating consecutive grants
@ 2022-06-02 19:23 ` Oleksandr Tyshchenko
0 siblings, 0 replies; 30+ messages in thread
From: Oleksandr Tyshchenko @ 2022-06-02 19:23 UTC (permalink / raw)
To: xen-devel, linux-kernel, linux-arm-kernel
Cc: Juergen Gross, Boris Ostrovsky, Stefano Stabellini, Julien Grall,
Oleksandr Tyshchenko, Michael S. Tsirkin, Christoph Hellwig
From: Juergen Gross <jgross@suse.com>
For support of virtio via grant mappings in rare cases larger mappings
using consecutive grants are needed. Support those by adding a bitmap
of free grants.
As consecutive grants will be needed only in very rare cases (e.g. when
configuring a virtio device with a multi-page ring), optimize for the
normal case of non-consecutive allocations.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
Changes RFC -> V1:
- no changes
Changes V1 -> V2:
- no changes
Changes V2 -> V3:
- rebase, move "if (unlikely(ref < GNTTAB_NR_RESERVED_ENTRIES))"
to put_free_entry_locked()
- do not overwrite "i" in gnttab_init(), introduce local max_nr_grefs
- add a comment on top of "while (from < to)" in get_free_seq()
- add Boris' R-b
Changes V3 -> V4:
- no changes
---
drivers/xen/grant-table.c | 251 +++++++++++++++++++++++++++++++++++++++-------
include/xen/grant_table.h | 4 +
2 files changed, 219 insertions(+), 36 deletions(-)
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 7a18292..738029d 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -33,6 +33,7 @@
#define pr_fmt(fmt) "xen:" KBUILD_MODNAME ": " fmt
+#include <linux/bitmap.h>
#include <linux/memblock.h>
#include <linux/sched.h>
#include <linux/mm.h>
@@ -70,9 +71,32 @@
static grant_ref_t **gnttab_list;
static unsigned int nr_grant_frames;
+
+/*
+ * Handling of free grants:
+ *
+ * Free grants are in a simple list anchored in gnttab_free_head. They are
+ * linked by grant ref, the last element contains GNTTAB_LIST_END. The number
+ * of free entries is stored in gnttab_free_count.
+ * Additionally there is a bitmap of free entries anchored in
+ * gnttab_free_bitmap. This is being used for simplifying allocation of
+ * multiple consecutive grants, which is needed e.g. for support of virtio.
+ * gnttab_last_free is used to add free entries of new frames at the end of
+ * the free list.
+ * gnttab_free_tail_ptr specifies the variable which references the start
+ * of consecutive free grants ending with gnttab_last_free. This pointer is
+ * updated in a rather defensive way, in order to avoid performance hits in
+ * hot paths.
+ * All those variables are protected by gnttab_list_lock.
+ */
static int gnttab_free_count;
-static grant_ref_t gnttab_free_head;
+static unsigned int gnttab_size;
+static grant_ref_t gnttab_free_head = GNTTAB_LIST_END;
+static grant_ref_t gnttab_last_free = GNTTAB_LIST_END;
+static grant_ref_t *gnttab_free_tail_ptr;
+static unsigned long *gnttab_free_bitmap;
static DEFINE_SPINLOCK(gnttab_list_lock);
+
struct grant_frames xen_auto_xlat_grant_frames;
static unsigned int xen_gnttab_version;
module_param_named(version, xen_gnttab_version, uint, 0);
@@ -168,16 +192,116 @@ static int get_free_entries(unsigned count)
ref = head = gnttab_free_head;
gnttab_free_count -= count;
- while (count-- > 1)
- head = gnttab_entry(head);
+ while (count--) {
+ bitmap_clear(gnttab_free_bitmap, head, 1);
+ if (gnttab_free_tail_ptr == __gnttab_entry(head))
+ gnttab_free_tail_ptr = &gnttab_free_head;
+ if (count)
+ head = gnttab_entry(head);
+ }
gnttab_free_head = gnttab_entry(head);
gnttab_entry(head) = GNTTAB_LIST_END;
+ if (!gnttab_free_count) {
+ gnttab_last_free = GNTTAB_LIST_END;
+ gnttab_free_tail_ptr = NULL;
+ }
+
spin_unlock_irqrestore(&gnttab_list_lock, flags);
return ref;
}
+static int get_seq_entry_count(void)
+{
+ if (gnttab_last_free == GNTTAB_LIST_END || !gnttab_free_tail_ptr ||
+ *gnttab_free_tail_ptr == GNTTAB_LIST_END)
+ return 0;
+
+ return gnttab_last_free - *gnttab_free_tail_ptr + 1;
+}
+
+/* Rebuilds the free grant list and tries to find count consecutive entries. */
+static int get_free_seq(unsigned int count)
+{
+ int ret = -ENOSPC;
+ unsigned int from, to;
+ grant_ref_t *last;
+
+ gnttab_free_tail_ptr = &gnttab_free_head;
+ last = &gnttab_free_head;
+
+ for (from = find_first_bit(gnttab_free_bitmap, gnttab_size);
+ from < gnttab_size;
+ from = find_next_bit(gnttab_free_bitmap, gnttab_size, to + 1)) {
+ to = find_next_zero_bit(gnttab_free_bitmap, gnttab_size,
+ from + 1);
+ if (ret < 0 && to - from >= count) {
+ ret = from;
+ bitmap_clear(gnttab_free_bitmap, ret, count);
+ from += count;
+ gnttab_free_count -= count;
+ if (from == to)
+ continue;
+ }
+
+ /*
+ * Recreate the free list in order to have it properly sorted.
+ * This is needed to make sure that the free tail has the maximum
+ * possible size.
+ */
+ while (from < to) {
+ *last = from;
+ last = __gnttab_entry(from);
+ gnttab_last_free = from;
+ from++;
+ }
+ if (to < gnttab_size)
+ gnttab_free_tail_ptr = __gnttab_entry(to - 1);
+ }
+
+ *last = GNTTAB_LIST_END;
+ if (gnttab_last_free != gnttab_size - 1)
+ gnttab_free_tail_ptr = NULL;
+
+ return ret;
+}
+
+static int get_free_entries_seq(unsigned int count)
+{
+ unsigned long flags;
+ int ret = 0;
+
+ spin_lock_irqsave(&gnttab_list_lock, flags);
+
+ if (gnttab_free_count < count) {
+ ret = gnttab_expand(count - gnttab_free_count);
+ if (ret < 0)
+ goto out;
+ }
+
+ if (get_seq_entry_count() < count) {
+ ret = get_free_seq(count);
+ if (ret >= 0)
+ goto out;
+ ret = gnttab_expand(count - get_seq_entry_count());
+ if (ret < 0)
+ goto out;
+ }
+
+ ret = *gnttab_free_tail_ptr;
+ *gnttab_free_tail_ptr = gnttab_entry(ret + count - 1);
+ gnttab_free_count -= count;
+ if (!gnttab_free_count)
+ gnttab_free_tail_ptr = NULL;
+ bitmap_clear(gnttab_free_bitmap, ret, count);
+
+ out:
+ spin_unlock_irqrestore(&gnttab_list_lock, flags);
+
+ return ret;
+}
+
static void do_free_callbacks(void)
{
struct gnttab_free_callback *callback, *next;
@@ -204,21 +328,51 @@ static inline void check_free_callbacks(void)
do_free_callbacks();
}
-static void put_free_entry(grant_ref_t ref)
+static void put_free_entry_locked(grant_ref_t ref)
{
- unsigned long flags;
-
if (unlikely(ref < GNTTAB_NR_RESERVED_ENTRIES))
return;
- spin_lock_irqsave(&gnttab_list_lock, flags);
gnttab_entry(ref) = gnttab_free_head;
gnttab_free_head = ref;
+ if (!gnttab_free_count)
+ gnttab_last_free = ref;
+ if (gnttab_free_tail_ptr == &gnttab_free_head)
+ gnttab_free_tail_ptr = __gnttab_entry(ref);
gnttab_free_count++;
+ bitmap_set(gnttab_free_bitmap, ref, 1);
+}
+
+static void put_free_entry(grant_ref_t ref)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&gnttab_list_lock, flags);
+ put_free_entry_locked(ref);
check_free_callbacks();
spin_unlock_irqrestore(&gnttab_list_lock, flags);
}
+static void gnttab_set_free(unsigned int start, unsigned int n)
+{
+ unsigned int i;
+
+ for (i = start; i < start + n - 1; i++)
+ gnttab_entry(i) = i + 1;
+
+ gnttab_entry(i) = GNTTAB_LIST_END;
+ if (!gnttab_free_count) {
+ gnttab_free_head = start;
+ gnttab_free_tail_ptr = &gnttab_free_head;
+ } else {
+ gnttab_entry(gnttab_last_free) = start;
+ }
+ gnttab_free_count += n;
+ gnttab_last_free = i;
+
+ bitmap_set(gnttab_free_bitmap, start, n);
+}
+
/*
* Following applies to gnttab_update_entry_v1 and gnttab_update_entry_v2.
* Introducing a valid entry into the grant table:
@@ -450,23 +604,31 @@ void gnttab_free_grant_references(grant_ref_t head)
{
grant_ref_t ref;
unsigned long flags;
- int count = 1;
- if (head == GNTTAB_LIST_END)
- return;
+
spin_lock_irqsave(&gnttab_list_lock, flags);
- ref = head;
- while (gnttab_entry(ref) != GNTTAB_LIST_END) {
- ref = gnttab_entry(ref);
- count++;
+ while (head != GNTTAB_LIST_END) {
+ ref = gnttab_entry(head);
+ put_free_entry_locked(head);
+ head = ref;
}
- gnttab_entry(ref) = gnttab_free_head;
- gnttab_free_head = head;
- gnttab_free_count += count;
check_free_callbacks();
spin_unlock_irqrestore(&gnttab_list_lock, flags);
}
EXPORT_SYMBOL_GPL(gnttab_free_grant_references);
+void gnttab_free_grant_reference_seq(grant_ref_t head, unsigned int count)
+{
+ unsigned long flags;
+ unsigned int i;
+
+ spin_lock_irqsave(&gnttab_list_lock, flags);
+ for (i = count; i > 0; i--)
+ put_free_entry_locked(head + i - 1);
+ check_free_callbacks();
+ spin_unlock_irqrestore(&gnttab_list_lock, flags);
+}
+EXPORT_SYMBOL_GPL(gnttab_free_grant_reference_seq);
+
int gnttab_alloc_grant_references(u16 count, grant_ref_t *head)
{
int h = get_free_entries(count);
@@ -480,6 +642,24 @@ int gnttab_alloc_grant_references(u16 count, grant_ref_t *head)
}
EXPORT_SYMBOL_GPL(gnttab_alloc_grant_references);
+int gnttab_alloc_grant_reference_seq(unsigned int count, grant_ref_t *first)
+{
+ int h;
+
+ if (count == 1)
+ h = get_free_entries(1);
+ else
+ h = get_free_entries_seq(count);
+
+ if (h < 0)
+ return -ENOSPC;
+
+ *first = h;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(gnttab_alloc_grant_reference_seq);
+
int gnttab_empty_grant_references(const grant_ref_t *private_head)
{
return (*private_head == GNTTAB_LIST_END);
@@ -572,16 +752,13 @@ static int grow_gnttab_list(unsigned int more_frames)
goto grow_nomem;
}
+ gnttab_set_free(gnttab_size, extra_entries);
- for (i = grefs_per_frame * nr_grant_frames;
- i < grefs_per_frame * new_nr_grant_frames - 1; i++)
- gnttab_entry(i) = i + 1;
-
- gnttab_entry(i) = gnttab_free_head;
- gnttab_free_head = grefs_per_frame * nr_grant_frames;
- gnttab_free_count += extra_entries;
+ if (!gnttab_free_tail_ptr)
+ gnttab_free_tail_ptr = __gnttab_entry(gnttab_size);
nr_grant_frames = new_nr_grant_frames;
+ gnttab_size += extra_entries;
check_free_callbacks();
@@ -1424,20 +1601,20 @@ static int gnttab_expand(unsigned int req_entries)
int gnttab_init(void)
{
int i;
- unsigned long max_nr_grant_frames;
+ unsigned long max_nr_grant_frames, max_nr_grefs;
unsigned int max_nr_glist_frames, nr_glist_frames;
- unsigned int nr_init_grefs;
int ret;
gnttab_request_version();
max_nr_grant_frames = gnttab_max_grant_frames();
+ max_nr_grefs = max_nr_grant_frames *
+ gnttab_interface->grefs_per_grant_frame;
nr_grant_frames = 1;
/* Determine the maximum number of frames required for the
* grant reference free list on the current hypervisor.
*/
- max_nr_glist_frames = (max_nr_grant_frames *
- gnttab_interface->grefs_per_grant_frame / RPP);
+ max_nr_glist_frames = max_nr_grefs / RPP;
gnttab_list = kmalloc_array(max_nr_glist_frames,
sizeof(grant_ref_t *),
@@ -1454,6 +1631,12 @@ int gnttab_init(void)
}
}
+ gnttab_free_bitmap = bitmap_zalloc(max_nr_grefs, GFP_KERNEL);
+ if (!gnttab_free_bitmap) {
+ ret = -ENOMEM;
+ goto ini_nomem;
+ }
+
ret = arch_gnttab_init(max_nr_grant_frames,
nr_status_frames(max_nr_grant_frames));
if (ret < 0)
@@ -1464,15 +1647,10 @@ int gnttab_init(void)
goto ini_nomem;
}
- nr_init_grefs = nr_grant_frames *
- gnttab_interface->grefs_per_grant_frame;
-
- for (i = GNTTAB_NR_RESERVED_ENTRIES; i < nr_init_grefs - 1; i++)
- gnttab_entry(i) = i + 1;
+ gnttab_size = nr_grant_frames * gnttab_interface->grefs_per_grant_frame;
- gnttab_entry(nr_init_grefs - 1) = GNTTAB_LIST_END;
- gnttab_free_count = nr_init_grefs - GNTTAB_NR_RESERVED_ENTRIES;
- gnttab_free_head = GNTTAB_NR_RESERVED_ENTRIES;
+ gnttab_set_free(GNTTAB_NR_RESERVED_ENTRIES,
+ gnttab_size - GNTTAB_NR_RESERVED_ENTRIES);
printk("Grant table initialized\n");
return 0;
@@ -1481,6 +1659,7 @@ int gnttab_init(void)
for (i--; i >= 0; i--)
free_page((unsigned long)gnttab_list[i]);
kfree(gnttab_list);
+ bitmap_free(gnttab_free_bitmap);
return ret;
}
EXPORT_SYMBOL_GPL(gnttab_init);
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index 527c990..e279be3 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -127,10 +127,14 @@ int gnttab_try_end_foreign_access(grant_ref_t ref);
*/
int gnttab_alloc_grant_references(u16 count, grant_ref_t *pprivate_head);
+int gnttab_alloc_grant_reference_seq(unsigned int count, grant_ref_t *first);
+
void gnttab_free_grant_reference(grant_ref_t ref);
void gnttab_free_grant_references(grant_ref_t head);
+void gnttab_free_grant_reference_seq(grant_ref_t head, unsigned int count);
+
int gnttab_empty_grant_references(const grant_ref_t *pprivate_head);
int gnttab_claim_grant_reference(grant_ref_t *pprivate_head);
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH V4 3/8] xen/grant-dma-ops: Add option to restrict memory access under Xen
2022-06-02 19:23 ` Oleksandr Tyshchenko
@ 2022-06-02 19:23 ` Oleksandr Tyshchenko
-1 siblings, 0 replies; 30+ messages in thread
From: Oleksandr Tyshchenko @ 2022-06-02 19:23 UTC (permalink / raw)
To: xen-devel, linux-kernel, linux-arm-kernel
Cc: Juergen Gross, Boris Ostrovsky, Stefano Stabellini, Julien Grall,
Oleksandr Tyshchenko, Michael S. Tsirkin, Christoph Hellwig
From: Juergen Gross <jgross@suse.com>
Introduce Xen grant DMA-mapping layer which contains special DMA-mapping
routines for providing grant references as DMA addresses to be used by
frontends (e.g. virtio) in Xen guests.
Add the needed functionality by providing a special set of DMA ops
handling the needed grant operations for the I/O pages.
The subsequent commit will introduce the use case for xen-grant DMA ops
layer to enable using virtio devices in Xen guests in a safe manner.
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
---
Changes RFC -> V1:
- squash with almost all changes from commit (except handling "xen,dev-domid"
property):
"[PATCH 4/6] virtio: Various updates to xen-virtio DMA ops layer"
- update commit subject/description and comments in code
- leave only single Kconfig option XEN_VIRTIO and remove architectural
dependencies
- introduce common xen_has_restricted_virtio_memory_access() in xen.h
and update arch_has_restricted_virtio_memory_access() for both
Arm and x86 to call new helper
- use (1ULL << 63) instead of 0x8000000000000000ULL for XEN_GRANT_ADDR_OFF
- implement xen_virtio_dma_map(unmap)_sg() using example in swiotlb-xen.c
- optimize padding by moving "broken" field in struct xen_virtio_data
- remove unneeded per-device spinlock
- remove the inclusion of virtio_config.h
- remane everything according to the new naming scheme:
s/virtio/grant_dma
- add new hidden config option XEN_GRANT_DMA_OPS
Changes V1 -> V2:
- fix checkpatch.pl warnings
- remove the inclusion of linux/pci.h
- rework to use xarray for data context
- remove EXPORT_SYMBOL_GPL(xen_grant_setup_dma_ops);
- remove the line of * after SPDX-License-Identifier
- split changes into grant-dma-ops.c and arch_has_restricted_virtio_memory_access()
and update commit subject/description accordingly
- remove "default n" for config XEN_VIRTIO
- implement xen_grant_dma_alloc(free)_pages()
Changes V2 -> V3:
- Stefano already gave his Reviewed-by, I dropped it due to the changes (minor)
- remane field "dev_domid" in struct xen_grant_dma_data to "backend_domid"
- remove local variable "domid" in xen_grant_setup_dma_ops()
Changes V3 -> V4:
- add Stefano's R-b
---
---
drivers/xen/Kconfig | 4 +
drivers/xen/Makefile | 1 +
drivers/xen/grant-dma-ops.c | 311 ++++++++++++++++++++++++++++++++++++++++++++
include/xen/xen-ops.h | 8 ++
4 files changed, 324 insertions(+)
create mode 100644 drivers/xen/grant-dma-ops.c
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 120d32f..313a9127 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -335,4 +335,8 @@ config XEN_UNPOPULATED_ALLOC
having to balloon out RAM regions in order to obtain physical memory
space to create such mappings.
+config XEN_GRANT_DMA_OPS
+ bool
+ select DMA_OPS
+
endmenu
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 5aae66e..1a23cb0 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -39,3 +39,4 @@ xen-gntalloc-y := gntalloc.o
xen-privcmd-y := privcmd.o privcmd-buf.o
obj-$(CONFIG_XEN_FRONT_PGDIR_SHBUF) += xen-front-pgdir-shbuf.o
obj-$(CONFIG_XEN_UNPOPULATED_ALLOC) += unpopulated-alloc.o
+obj-$(CONFIG_XEN_GRANT_DMA_OPS) += grant-dma-ops.o
diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c
new file mode 100644
index 00000000..44659f4
--- /dev/null
+++ b/drivers/xen/grant-dma-ops.c
@@ -0,0 +1,311 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Xen grant DMA-mapping layer - contains special DMA-mapping routines
+ * for providing grant references as DMA addresses to be used by frontends
+ * (e.g. virtio) in Xen guests
+ *
+ * Copyright (c) 2021, Juergen Gross <jgross@suse.com>
+ */
+
+#include <linux/module.h>
+#include <linux/dma-map-ops.h>
+#include <linux/of.h>
+#include <linux/pfn.h>
+#include <linux/xarray.h>
+#include <xen/xen.h>
+#include <xen/grant_table.h>
+
+struct xen_grant_dma_data {
+ /* The ID of backend domain */
+ domid_t backend_domid;
+ /* Is device behaving sane? */
+ bool broken;
+};
+
+static DEFINE_XARRAY(xen_grant_dma_devices);
+
+#define XEN_GRANT_DMA_ADDR_OFF (1ULL << 63)
+
+static inline dma_addr_t grant_to_dma(grant_ref_t grant)
+{
+ return XEN_GRANT_DMA_ADDR_OFF | ((dma_addr_t)grant << PAGE_SHIFT);
+}
+
+static inline grant_ref_t dma_to_grant(dma_addr_t dma)
+{
+ return (grant_ref_t)((dma & ~XEN_GRANT_DMA_ADDR_OFF) >> PAGE_SHIFT);
+}
+
+static struct xen_grant_dma_data *find_xen_grant_dma_data(struct device *dev)
+{
+ struct xen_grant_dma_data *data;
+
+ xa_lock(&xen_grant_dma_devices);
+ data = xa_load(&xen_grant_dma_devices, (unsigned long)dev);
+ xa_unlock(&xen_grant_dma_devices);
+
+ return data;
+}
+
+/*
+ * DMA ops for Xen frontends (e.g. virtio).
+ *
+ * Used to act as a kind of software IOMMU for Xen guests by using grants as
+ * DMA addresses.
+ * Such a DMA address is formed by using the grant reference as a frame
+ * number and setting the highest address bit (this bit is for the backend
+ * to be able to distinguish it from e.g. a mmio address).
+ *
+ * Note that for now we hard wire dom0 to be the backend domain. In order
+ * to support any domain as backend we'd need to add a way to communicate
+ * the domid of this backend, e.g. via Xenstore, via the PCI-device's
+ * config space or DT/ACPI.
+ */
+static void *xen_grant_dma_alloc(struct device *dev, size_t size,
+ dma_addr_t *dma_handle, gfp_t gfp,
+ unsigned long attrs)
+{
+ struct xen_grant_dma_data *data;
+ unsigned int i, n_pages = PFN_UP(size);
+ unsigned long pfn;
+ grant_ref_t grant;
+ void *ret;
+
+ data = find_xen_grant_dma_data(dev);
+ if (!data)
+ return NULL;
+
+ if (unlikely(data->broken))
+ return NULL;
+
+ ret = alloc_pages_exact(n_pages * PAGE_SIZE, gfp);
+ if (!ret)
+ return NULL;
+
+ pfn = virt_to_pfn(ret);
+
+ if (gnttab_alloc_grant_reference_seq(n_pages, &grant)) {
+ free_pages_exact(ret, n_pages * PAGE_SIZE);
+ return NULL;
+ }
+
+ for (i = 0; i < n_pages; i++) {
+ gnttab_grant_foreign_access_ref(grant + i, data->backend_domid,
+ pfn_to_gfn(pfn + i), 0);
+ }
+
+ *dma_handle = grant_to_dma(grant);
+
+ return ret;
+}
+
+static void xen_grant_dma_free(struct device *dev, size_t size, void *vaddr,
+ dma_addr_t dma_handle, unsigned long attrs)
+{
+ struct xen_grant_dma_data *data;
+ unsigned int i, n_pages = PFN_UP(size);
+ grant_ref_t grant;
+
+ data = find_xen_grant_dma_data(dev);
+ if (!data)
+ return;
+
+ if (unlikely(data->broken))
+ return;
+
+ grant = dma_to_grant(dma_handle);
+
+ for (i = 0; i < n_pages; i++) {
+ if (unlikely(!gnttab_end_foreign_access_ref(grant + i))) {
+ dev_alert(dev, "Grant still in use by backend domain, disabled for further use\n");
+ data->broken = true;
+ return;
+ }
+ }
+
+ gnttab_free_grant_reference_seq(grant, n_pages);
+
+ free_pages_exact(vaddr, n_pages * PAGE_SIZE);
+}
+
+static struct page *xen_grant_dma_alloc_pages(struct device *dev, size_t size,
+ dma_addr_t *dma_handle,
+ enum dma_data_direction dir,
+ gfp_t gfp)
+{
+ void *vaddr;
+
+ vaddr = xen_grant_dma_alloc(dev, size, dma_handle, gfp, 0);
+ if (!vaddr)
+ return NULL;
+
+ return virt_to_page(vaddr);
+}
+
+static void xen_grant_dma_free_pages(struct device *dev, size_t size,
+ struct page *vaddr, dma_addr_t dma_handle,
+ enum dma_data_direction dir)
+{
+ xen_grant_dma_free(dev, size, page_to_virt(vaddr), dma_handle, 0);
+}
+
+static dma_addr_t xen_grant_dma_map_page(struct device *dev, struct page *page,
+ unsigned long offset, size_t size,
+ enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ struct xen_grant_dma_data *data;
+ unsigned int i, n_pages = PFN_UP(size);
+ grant_ref_t grant;
+ dma_addr_t dma_handle;
+
+ if (WARN_ON(dir == DMA_NONE))
+ return DMA_MAPPING_ERROR;
+
+ data = find_xen_grant_dma_data(dev);
+ if (!data)
+ return DMA_MAPPING_ERROR;
+
+ if (unlikely(data->broken))
+ return DMA_MAPPING_ERROR;
+
+ if (gnttab_alloc_grant_reference_seq(n_pages, &grant))
+ return DMA_MAPPING_ERROR;
+
+ for (i = 0; i < n_pages; i++) {
+ gnttab_grant_foreign_access_ref(grant + i, data->backend_domid,
+ xen_page_to_gfn(page) + i, dir == DMA_TO_DEVICE);
+ }
+
+ dma_handle = grant_to_dma(grant) + offset;
+
+ return dma_handle;
+}
+
+static void xen_grant_dma_unmap_page(struct device *dev, dma_addr_t dma_handle,
+ size_t size, enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ struct xen_grant_dma_data *data;
+ unsigned int i, n_pages = PFN_UP(size);
+ grant_ref_t grant;
+
+ if (WARN_ON(dir == DMA_NONE))
+ return;
+
+ data = find_xen_grant_dma_data(dev);
+ if (!data)
+ return;
+
+ if (unlikely(data->broken))
+ return;
+
+ grant = dma_to_grant(dma_handle);
+
+ for (i = 0; i < n_pages; i++) {
+ if (unlikely(!gnttab_end_foreign_access_ref(grant + i))) {
+ dev_alert(dev, "Grant still in use by backend domain, disabled for further use\n");
+ data->broken = true;
+ return;
+ }
+ }
+
+ gnttab_free_grant_reference_seq(grant, n_pages);
+}
+
+static void xen_grant_dma_unmap_sg(struct device *dev, struct scatterlist *sg,
+ int nents, enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ struct scatterlist *s;
+ unsigned int i;
+
+ if (WARN_ON(dir == DMA_NONE))
+ return;
+
+ for_each_sg(sg, s, nents, i)
+ xen_grant_dma_unmap_page(dev, s->dma_address, sg_dma_len(s), dir,
+ attrs);
+}
+
+static int xen_grant_dma_map_sg(struct device *dev, struct scatterlist *sg,
+ int nents, enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ struct scatterlist *s;
+ unsigned int i;
+
+ if (WARN_ON(dir == DMA_NONE))
+ return -EINVAL;
+
+ for_each_sg(sg, s, nents, i) {
+ s->dma_address = xen_grant_dma_map_page(dev, sg_page(s), s->offset,
+ s->length, dir, attrs);
+ if (s->dma_address == DMA_MAPPING_ERROR)
+ goto out;
+
+ sg_dma_len(s) = s->length;
+ }
+
+ return nents;
+
+out:
+ xen_grant_dma_unmap_sg(dev, sg, i, dir, attrs | DMA_ATTR_SKIP_CPU_SYNC);
+ sg_dma_len(sg) = 0;
+
+ return -EIO;
+}
+
+static int xen_grant_dma_supported(struct device *dev, u64 mask)
+{
+ return mask == DMA_BIT_MASK(64);
+}
+
+static const struct dma_map_ops xen_grant_dma_ops = {
+ .alloc = xen_grant_dma_alloc,
+ .free = xen_grant_dma_free,
+ .alloc_pages = xen_grant_dma_alloc_pages,
+ .free_pages = xen_grant_dma_free_pages,
+ .mmap = dma_common_mmap,
+ .get_sgtable = dma_common_get_sgtable,
+ .map_page = xen_grant_dma_map_page,
+ .unmap_page = xen_grant_dma_unmap_page,
+ .map_sg = xen_grant_dma_map_sg,
+ .unmap_sg = xen_grant_dma_unmap_sg,
+ .dma_supported = xen_grant_dma_supported,
+};
+
+void xen_grant_setup_dma_ops(struct device *dev)
+{
+ struct xen_grant_dma_data *data;
+
+ data = find_xen_grant_dma_data(dev);
+ if (data) {
+ dev_err(dev, "Xen grant DMA data is already created\n");
+ return;
+ }
+
+ data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ goto err;
+
+ /* XXX The dom0 is hardcoded as the backend domain for now */
+ data->backend_domid = 0;
+
+ if (xa_err(xa_store(&xen_grant_dma_devices, (unsigned long)dev, data,
+ GFP_KERNEL))) {
+ dev_err(dev, "Cannot store Xen grant DMA data\n");
+ goto err;
+ }
+
+ dev->dma_ops = &xen_grant_dma_ops;
+
+ return;
+
+err:
+ dev_err(dev, "Cannot set up Xen grant DMA ops, retain platform DMA ops\n");
+}
+
+MODULE_DESCRIPTION("Xen grant DMA-mapping layer");
+MODULE_AUTHOR("Juergen Gross <jgross@suse.com>");
+MODULE_LICENSE("GPL");
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index a3584a3..4f9fad5 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -221,4 +221,12 @@ static inline void xen_preemptible_hcall_end(void) { }
#endif /* CONFIG_XEN_PV && !CONFIG_PREEMPTION */
+#ifdef CONFIG_XEN_GRANT_DMA_OPS
+void xen_grant_setup_dma_ops(struct device *dev);
+#else
+static inline void xen_grant_setup_dma_ops(struct device *dev)
+{
+}
+#endif /* CONFIG_XEN_GRANT_DMA_OPS */
+
#endif /* INCLUDE_XEN_OPS_H */
--
2.7.4
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH V4 3/8] xen/grant-dma-ops: Add option to restrict memory access under Xen
@ 2022-06-02 19:23 ` Oleksandr Tyshchenko
0 siblings, 0 replies; 30+ messages in thread
From: Oleksandr Tyshchenko @ 2022-06-02 19:23 UTC (permalink / raw)
To: xen-devel, linux-kernel, linux-arm-kernel
Cc: Juergen Gross, Boris Ostrovsky, Stefano Stabellini, Julien Grall,
Oleksandr Tyshchenko, Michael S. Tsirkin, Christoph Hellwig
From: Juergen Gross <jgross@suse.com>
Introduce Xen grant DMA-mapping layer which contains special DMA-mapping
routines for providing grant references as DMA addresses to be used by
frontends (e.g. virtio) in Xen guests.
Add the needed functionality by providing a special set of DMA ops
handling the needed grant operations for the I/O pages.
The subsequent commit will introduce the use case for xen-grant DMA ops
layer to enable using virtio devices in Xen guests in a safe manner.
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
---
Changes RFC -> V1:
- squash with almost all changes from commit (except handling "xen,dev-domid"
property):
"[PATCH 4/6] virtio: Various updates to xen-virtio DMA ops layer"
- update commit subject/description and comments in code
- leave only single Kconfig option XEN_VIRTIO and remove architectural
dependencies
- introduce common xen_has_restricted_virtio_memory_access() in xen.h
and update arch_has_restricted_virtio_memory_access() for both
Arm and x86 to call new helper
- use (1ULL << 63) instead of 0x8000000000000000ULL for XEN_GRANT_ADDR_OFF
- implement xen_virtio_dma_map(unmap)_sg() using example in swiotlb-xen.c
- optimize padding by moving "broken" field in struct xen_virtio_data
- remove unneeded per-device spinlock
- remove the inclusion of virtio_config.h
- remane everything according to the new naming scheme:
s/virtio/grant_dma
- add new hidden config option XEN_GRANT_DMA_OPS
Changes V1 -> V2:
- fix checkpatch.pl warnings
- remove the inclusion of linux/pci.h
- rework to use xarray for data context
- remove EXPORT_SYMBOL_GPL(xen_grant_setup_dma_ops);
- remove the line of * after SPDX-License-Identifier
- split changes into grant-dma-ops.c and arch_has_restricted_virtio_memory_access()
and update commit subject/description accordingly
- remove "default n" for config XEN_VIRTIO
- implement xen_grant_dma_alloc(free)_pages()
Changes V2 -> V3:
- Stefano already gave his Reviewed-by, I dropped it due to the changes (minor)
- remane field "dev_domid" in struct xen_grant_dma_data to "backend_domid"
- remove local variable "domid" in xen_grant_setup_dma_ops()
Changes V3 -> V4:
- add Stefano's R-b
---
---
drivers/xen/Kconfig | 4 +
drivers/xen/Makefile | 1 +
drivers/xen/grant-dma-ops.c | 311 ++++++++++++++++++++++++++++++++++++++++++++
include/xen/xen-ops.h | 8 ++
4 files changed, 324 insertions(+)
create mode 100644 drivers/xen/grant-dma-ops.c
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 120d32f..313a9127 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -335,4 +335,8 @@ config XEN_UNPOPULATED_ALLOC
having to balloon out RAM regions in order to obtain physical memory
space to create such mappings.
+config XEN_GRANT_DMA_OPS
+ bool
+ select DMA_OPS
+
endmenu
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 5aae66e..1a23cb0 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -39,3 +39,4 @@ xen-gntalloc-y := gntalloc.o
xen-privcmd-y := privcmd.o privcmd-buf.o
obj-$(CONFIG_XEN_FRONT_PGDIR_SHBUF) += xen-front-pgdir-shbuf.o
obj-$(CONFIG_XEN_UNPOPULATED_ALLOC) += unpopulated-alloc.o
+obj-$(CONFIG_XEN_GRANT_DMA_OPS) += grant-dma-ops.o
diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c
new file mode 100644
index 00000000..44659f4
--- /dev/null
+++ b/drivers/xen/grant-dma-ops.c
@@ -0,0 +1,311 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Xen grant DMA-mapping layer - contains special DMA-mapping routines
+ * for providing grant references as DMA addresses to be used by frontends
+ * (e.g. virtio) in Xen guests
+ *
+ * Copyright (c) 2021, Juergen Gross <jgross@suse.com>
+ */
+
+#include <linux/module.h>
+#include <linux/dma-map-ops.h>
+#include <linux/of.h>
+#include <linux/pfn.h>
+#include <linux/xarray.h>
+#include <xen/xen.h>
+#include <xen/grant_table.h>
+
+struct xen_grant_dma_data {
+ /* The ID of backend domain */
+ domid_t backend_domid;
+ /* Is device behaving sane? */
+ bool broken;
+};
+
+static DEFINE_XARRAY(xen_grant_dma_devices);
+
+#define XEN_GRANT_DMA_ADDR_OFF (1ULL << 63)
+
+static inline dma_addr_t grant_to_dma(grant_ref_t grant)
+{
+ return XEN_GRANT_DMA_ADDR_OFF | ((dma_addr_t)grant << PAGE_SHIFT);
+}
+
+static inline grant_ref_t dma_to_grant(dma_addr_t dma)
+{
+ return (grant_ref_t)((dma & ~XEN_GRANT_DMA_ADDR_OFF) >> PAGE_SHIFT);
+}
+
+static struct xen_grant_dma_data *find_xen_grant_dma_data(struct device *dev)
+{
+ struct xen_grant_dma_data *data;
+
+ xa_lock(&xen_grant_dma_devices);
+ data = xa_load(&xen_grant_dma_devices, (unsigned long)dev);
+ xa_unlock(&xen_grant_dma_devices);
+
+ return data;
+}
+
+/*
+ * DMA ops for Xen frontends (e.g. virtio).
+ *
+ * Used to act as a kind of software IOMMU for Xen guests by using grants as
+ * DMA addresses.
+ * Such a DMA address is formed by using the grant reference as a frame
+ * number and setting the highest address bit (this bit is for the backend
+ * to be able to distinguish it from e.g. a mmio address).
+ *
+ * Note that for now we hard wire dom0 to be the backend domain. In order
+ * to support any domain as backend we'd need to add a way to communicate
+ * the domid of this backend, e.g. via Xenstore, via the PCI-device's
+ * config space or DT/ACPI.
+ */
+static void *xen_grant_dma_alloc(struct device *dev, size_t size,
+ dma_addr_t *dma_handle, gfp_t gfp,
+ unsigned long attrs)
+{
+ struct xen_grant_dma_data *data;
+ unsigned int i, n_pages = PFN_UP(size);
+ unsigned long pfn;
+ grant_ref_t grant;
+ void *ret;
+
+ data = find_xen_grant_dma_data(dev);
+ if (!data)
+ return NULL;
+
+ if (unlikely(data->broken))
+ return NULL;
+
+ ret = alloc_pages_exact(n_pages * PAGE_SIZE, gfp);
+ if (!ret)
+ return NULL;
+
+ pfn = virt_to_pfn(ret);
+
+ if (gnttab_alloc_grant_reference_seq(n_pages, &grant)) {
+ free_pages_exact(ret, n_pages * PAGE_SIZE);
+ return NULL;
+ }
+
+ for (i = 0; i < n_pages; i++) {
+ gnttab_grant_foreign_access_ref(grant + i, data->backend_domid,
+ pfn_to_gfn(pfn + i), 0);
+ }
+
+ *dma_handle = grant_to_dma(grant);
+
+ return ret;
+}
+
+static void xen_grant_dma_free(struct device *dev, size_t size, void *vaddr,
+ dma_addr_t dma_handle, unsigned long attrs)
+{
+ struct xen_grant_dma_data *data;
+ unsigned int i, n_pages = PFN_UP(size);
+ grant_ref_t grant;
+
+ data = find_xen_grant_dma_data(dev);
+ if (!data)
+ return;
+
+ if (unlikely(data->broken))
+ return;
+
+ grant = dma_to_grant(dma_handle);
+
+ for (i = 0; i < n_pages; i++) {
+ if (unlikely(!gnttab_end_foreign_access_ref(grant + i))) {
+ dev_alert(dev, "Grant still in use by backend domain, disabled for further use\n");
+ data->broken = true;
+ return;
+ }
+ }
+
+ gnttab_free_grant_reference_seq(grant, n_pages);
+
+ free_pages_exact(vaddr, n_pages * PAGE_SIZE);
+}
+
+static struct page *xen_grant_dma_alloc_pages(struct device *dev, size_t size,
+ dma_addr_t *dma_handle,
+ enum dma_data_direction dir,
+ gfp_t gfp)
+{
+ void *vaddr;
+
+ vaddr = xen_grant_dma_alloc(dev, size, dma_handle, gfp, 0);
+ if (!vaddr)
+ return NULL;
+
+ return virt_to_page(vaddr);
+}
+
+static void xen_grant_dma_free_pages(struct device *dev, size_t size,
+ struct page *vaddr, dma_addr_t dma_handle,
+ enum dma_data_direction dir)
+{
+ xen_grant_dma_free(dev, size, page_to_virt(vaddr), dma_handle, 0);
+}
+
+static dma_addr_t xen_grant_dma_map_page(struct device *dev, struct page *page,
+ unsigned long offset, size_t size,
+ enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ struct xen_grant_dma_data *data;
+ unsigned int i, n_pages = PFN_UP(size);
+ grant_ref_t grant;
+ dma_addr_t dma_handle;
+
+ if (WARN_ON(dir == DMA_NONE))
+ return DMA_MAPPING_ERROR;
+
+ data = find_xen_grant_dma_data(dev);
+ if (!data)
+ return DMA_MAPPING_ERROR;
+
+ if (unlikely(data->broken))
+ return DMA_MAPPING_ERROR;
+
+ if (gnttab_alloc_grant_reference_seq(n_pages, &grant))
+ return DMA_MAPPING_ERROR;
+
+ for (i = 0; i < n_pages; i++) {
+ gnttab_grant_foreign_access_ref(grant + i, data->backend_domid,
+ xen_page_to_gfn(page) + i, dir == DMA_TO_DEVICE);
+ }
+
+ dma_handle = grant_to_dma(grant) + offset;
+
+ return dma_handle;
+}
+
+static void xen_grant_dma_unmap_page(struct device *dev, dma_addr_t dma_handle,
+ size_t size, enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ struct xen_grant_dma_data *data;
+ unsigned int i, n_pages = PFN_UP(size);
+ grant_ref_t grant;
+
+ if (WARN_ON(dir == DMA_NONE))
+ return;
+
+ data = find_xen_grant_dma_data(dev);
+ if (!data)
+ return;
+
+ if (unlikely(data->broken))
+ return;
+
+ grant = dma_to_grant(dma_handle);
+
+ for (i = 0; i < n_pages; i++) {
+ if (unlikely(!gnttab_end_foreign_access_ref(grant + i))) {
+ dev_alert(dev, "Grant still in use by backend domain, disabled for further use\n");
+ data->broken = true;
+ return;
+ }
+ }
+
+ gnttab_free_grant_reference_seq(grant, n_pages);
+}
+
+static void xen_grant_dma_unmap_sg(struct device *dev, struct scatterlist *sg,
+ int nents, enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ struct scatterlist *s;
+ unsigned int i;
+
+ if (WARN_ON(dir == DMA_NONE))
+ return;
+
+ for_each_sg(sg, s, nents, i)
+ xen_grant_dma_unmap_page(dev, s->dma_address, sg_dma_len(s), dir,
+ attrs);
+}
+
+static int xen_grant_dma_map_sg(struct device *dev, struct scatterlist *sg,
+ int nents, enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ struct scatterlist *s;
+ unsigned int i;
+
+ if (WARN_ON(dir == DMA_NONE))
+ return -EINVAL;
+
+ for_each_sg(sg, s, nents, i) {
+ s->dma_address = xen_grant_dma_map_page(dev, sg_page(s), s->offset,
+ s->length, dir, attrs);
+ if (s->dma_address == DMA_MAPPING_ERROR)
+ goto out;
+
+ sg_dma_len(s) = s->length;
+ }
+
+ return nents;
+
+out:
+ xen_grant_dma_unmap_sg(dev, sg, i, dir, attrs | DMA_ATTR_SKIP_CPU_SYNC);
+ sg_dma_len(sg) = 0;
+
+ return -EIO;
+}
+
+static int xen_grant_dma_supported(struct device *dev, u64 mask)
+{
+ return mask == DMA_BIT_MASK(64);
+}
+
+static const struct dma_map_ops xen_grant_dma_ops = {
+ .alloc = xen_grant_dma_alloc,
+ .free = xen_grant_dma_free,
+ .alloc_pages = xen_grant_dma_alloc_pages,
+ .free_pages = xen_grant_dma_free_pages,
+ .mmap = dma_common_mmap,
+ .get_sgtable = dma_common_get_sgtable,
+ .map_page = xen_grant_dma_map_page,
+ .unmap_page = xen_grant_dma_unmap_page,
+ .map_sg = xen_grant_dma_map_sg,
+ .unmap_sg = xen_grant_dma_unmap_sg,
+ .dma_supported = xen_grant_dma_supported,
+};
+
+void xen_grant_setup_dma_ops(struct device *dev)
+{
+ struct xen_grant_dma_data *data;
+
+ data = find_xen_grant_dma_data(dev);
+ if (data) {
+ dev_err(dev, "Xen grant DMA data is already created\n");
+ return;
+ }
+
+ data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ goto err;
+
+ /* XXX The dom0 is hardcoded as the backend domain for now */
+ data->backend_domid = 0;
+
+ if (xa_err(xa_store(&xen_grant_dma_devices, (unsigned long)dev, data,
+ GFP_KERNEL))) {
+ dev_err(dev, "Cannot store Xen grant DMA data\n");
+ goto err;
+ }
+
+ dev->dma_ops = &xen_grant_dma_ops;
+
+ return;
+
+err:
+ dev_err(dev, "Cannot set up Xen grant DMA ops, retain platform DMA ops\n");
+}
+
+MODULE_DESCRIPTION("Xen grant DMA-mapping layer");
+MODULE_AUTHOR("Juergen Gross <jgross@suse.com>");
+MODULE_LICENSE("GPL");
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index a3584a3..4f9fad5 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -221,4 +221,12 @@ static inline void xen_preemptible_hcall_end(void) { }
#endif /* CONFIG_XEN_PV && !CONFIG_PREEMPTION */
+#ifdef CONFIG_XEN_GRANT_DMA_OPS
+void xen_grant_setup_dma_ops(struct device *dev);
+#else
+static inline void xen_grant_setup_dma_ops(struct device *dev)
+{
+}
+#endif /* CONFIG_XEN_GRANT_DMA_OPS */
+
#endif /* INCLUDE_XEN_OPS_H */
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH V4 4/8] xen/virtio: Enable restricted memory access using Xen grant mappings
2022-06-02 19:23 ` Oleksandr Tyshchenko
@ 2022-06-02 19:23 ` Oleksandr Tyshchenko
-1 siblings, 0 replies; 30+ messages in thread
From: Oleksandr Tyshchenko @ 2022-06-02 19:23 UTC (permalink / raw)
To: xen-devel, x86, linux-arm-kernel, linux-kernel
Cc: Juergen Gross, Oleksandr Tyshchenko, Stefano Stabellini,
Russell King, Boris Ostrovsky, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, H. Peter Anvin, Julien Grall,
Michael S. Tsirkin, Christoph Hellwig
From: Juergen Gross <jgross@suse.com>
In order to support virtio in Xen guests add a config option XEN_VIRTIO
enabling the user to specify whether in all Xen guests virtio should
be able to access memory via Xen grant mappings only on the host side.
Also set PLATFORM_VIRTIO_RESTRICTED_MEM_ACCESS feature from the guest
initialization code on Arm and x86 if CONFIG_XEN_VIRTIO is enabled.
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
Changes V1 -> V2:
- new patch, split required changes from commit:
"[PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen"
- rework according to new platform_has() infrastructure
Changes V2 -> V3:
- add Stefano's R-b
Changes V3 -> V4:
- add Boris' R-b
---
arch/arm/xen/enlighten.c | 2 ++
arch/x86/xen/enlighten_hvm.c | 2 ++
arch/x86/xen/enlighten_pv.c | 2 ++
drivers/xen/Kconfig | 11 +++++++++++
include/xen/xen.h | 8 ++++++++
5 files changed, 25 insertions(+)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 07eb69f..1f9c3ba 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -443,6 +443,8 @@ static int __init xen_guest_init(void)
if (!xen_domain())
return 0;
+ xen_set_restricted_virtio_memory_access();
+
if (!acpi_disabled)
xen_acpi_guest_init();
else
diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
index 517a9d8..8b71b1d 100644
--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -195,6 +195,8 @@ static void __init xen_hvm_guest_init(void)
if (xen_pv_domain())
return;
+ xen_set_restricted_virtio_memory_access();
+
init_hvm_pv_info();
reserve_shared_info();
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index ca85d14..30d24fe 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -108,6 +108,8 @@ static DEFINE_PER_CPU(struct tls_descs, shadow_tls_desc);
static void __init xen_pv_init_platform(void)
{
+ xen_set_restricted_virtio_memory_access();
+
populate_extra_pte(fix_to_virt(FIX_PARAVIRT_BOOTMAP));
set_fixmap(FIX_PARAVIRT_BOOTMAP, xen_start_info->shared_info);
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 313a9127..a7bd8ce 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -339,4 +339,15 @@ config XEN_GRANT_DMA_OPS
bool
select DMA_OPS
+config XEN_VIRTIO
+ bool "Xen virtio support"
+ depends on VIRTIO
+ select XEN_GRANT_DMA_OPS
+ help
+ Enable virtio support for running as Xen guest. Depending on the
+ guest type this will require special support on the backend side
+ (qemu or kernel, depending on the virtio device types used).
+
+ If in doubt, say n.
+
endmenu
diff --git a/include/xen/xen.h b/include/xen/xen.h
index a99bab8..0780a81 100644
--- a/include/xen/xen.h
+++ b/include/xen/xen.h
@@ -52,6 +52,14 @@ bool xen_biovec_phys_mergeable(const struct bio_vec *vec1,
extern u64 xen_saved_max_mem_size;
#endif
+#include <linux/platform-feature.h>
+
+static inline void xen_set_restricted_virtio_memory_access(void)
+{
+ if (IS_ENABLED(CONFIG_XEN_VIRTIO) && xen_domain())
+ platform_set(PLATFORM_VIRTIO_RESTRICTED_MEM_ACCESS);
+}
+
#ifdef CONFIG_XEN_UNPOPULATED_ALLOC
int xen_alloc_unpopulated_pages(unsigned int nr_pages, struct page **pages);
void xen_free_unpopulated_pages(unsigned int nr_pages, struct page **pages);
--
2.7.4
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH V4 4/8] xen/virtio: Enable restricted memory access using Xen grant mappings
@ 2022-06-02 19:23 ` Oleksandr Tyshchenko
0 siblings, 0 replies; 30+ messages in thread
From: Oleksandr Tyshchenko @ 2022-06-02 19:23 UTC (permalink / raw)
To: xen-devel, x86, linux-arm-kernel, linux-kernel
Cc: Juergen Gross, Oleksandr Tyshchenko, Stefano Stabellini,
Russell King, Boris Ostrovsky, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, H. Peter Anvin, Julien Grall,
Michael S. Tsirkin, Christoph Hellwig
From: Juergen Gross <jgross@suse.com>
In order to support virtio in Xen guests add a config option XEN_VIRTIO
enabling the user to specify whether in all Xen guests virtio should
be able to access memory via Xen grant mappings only on the host side.
Also set PLATFORM_VIRTIO_RESTRICTED_MEM_ACCESS feature from the guest
initialization code on Arm and x86 if CONFIG_XEN_VIRTIO is enabled.
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
Changes V1 -> V2:
- new patch, split required changes from commit:
"[PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen"
- rework according to new platform_has() infrastructure
Changes V2 -> V3:
- add Stefano's R-b
Changes V3 -> V4:
- add Boris' R-b
---
arch/arm/xen/enlighten.c | 2 ++
arch/x86/xen/enlighten_hvm.c | 2 ++
arch/x86/xen/enlighten_pv.c | 2 ++
drivers/xen/Kconfig | 11 +++++++++++
include/xen/xen.h | 8 ++++++++
5 files changed, 25 insertions(+)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 07eb69f..1f9c3ba 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -443,6 +443,8 @@ static int __init xen_guest_init(void)
if (!xen_domain())
return 0;
+ xen_set_restricted_virtio_memory_access();
+
if (!acpi_disabled)
xen_acpi_guest_init();
else
diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
index 517a9d8..8b71b1d 100644
--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -195,6 +195,8 @@ static void __init xen_hvm_guest_init(void)
if (xen_pv_domain())
return;
+ xen_set_restricted_virtio_memory_access();
+
init_hvm_pv_info();
reserve_shared_info();
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index ca85d14..30d24fe 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -108,6 +108,8 @@ static DEFINE_PER_CPU(struct tls_descs, shadow_tls_desc);
static void __init xen_pv_init_platform(void)
{
+ xen_set_restricted_virtio_memory_access();
+
populate_extra_pte(fix_to_virt(FIX_PARAVIRT_BOOTMAP));
set_fixmap(FIX_PARAVIRT_BOOTMAP, xen_start_info->shared_info);
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 313a9127..a7bd8ce 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -339,4 +339,15 @@ config XEN_GRANT_DMA_OPS
bool
select DMA_OPS
+config XEN_VIRTIO
+ bool "Xen virtio support"
+ depends on VIRTIO
+ select XEN_GRANT_DMA_OPS
+ help
+ Enable virtio support for running as Xen guest. Depending on the
+ guest type this will require special support on the backend side
+ (qemu or kernel, depending on the virtio device types used).
+
+ If in doubt, say n.
+
endmenu
diff --git a/include/xen/xen.h b/include/xen/xen.h
index a99bab8..0780a81 100644
--- a/include/xen/xen.h
+++ b/include/xen/xen.h
@@ -52,6 +52,14 @@ bool xen_biovec_phys_mergeable(const struct bio_vec *vec1,
extern u64 xen_saved_max_mem_size;
#endif
+#include <linux/platform-feature.h>
+
+static inline void xen_set_restricted_virtio_memory_access(void)
+{
+ if (IS_ENABLED(CONFIG_XEN_VIRTIO) && xen_domain())
+ platform_set(PLATFORM_VIRTIO_RESTRICTED_MEM_ACCESS);
+}
+
#ifdef CONFIG_XEN_UNPOPULATED_ALLOC
int xen_alloc_unpopulated_pages(unsigned int nr_pages, struct page **pages);
void xen_free_unpopulated_pages(unsigned int nr_pages, struct page **pages);
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH V4 5/8] dt-bindings: Add xen,grant-dma IOMMU description for xen-grant DMA ops
2022-06-02 19:23 ` Oleksandr Tyshchenko
(?)
@ 2022-06-02 19:23 ` Oleksandr Tyshchenko
-1 siblings, 0 replies; 30+ messages in thread
From: Oleksandr Tyshchenko @ 2022-06-02 19:23 UTC (permalink / raw)
To: xen-devel, devicetree, linux-kernel, linux-arm-kernel, iommu
Cc: Oleksandr Tyshchenko, Rob Herring, Joerg Roedel, Will Deacon,
Krzysztof Kozlowski, Julien Grall, Juergen Gross,
Stefano Stabellini, Michael S. Tsirkin, Christoph Hellwig,
Arnd Bergmann
From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
The main purpose of this binding is to communicate Xen specific
information using generic IOMMU device tree bindings (which is
a good fit here) rather than introducing a custom property.
Introduce Xen specific IOMMU for the virtualized device (e.g. virtio)
to be used by Xen grant DMA-mapping layer in the subsequent commit.
The reference to Xen specific IOMMU node using "iommus" property
indicates that Xen grant mappings need to be enabled for the device,
and it specifies the ID of the domain where the corresponding backend
resides. The domid (domain ID) is used as an argument to the Xen grant
mapping APIs.
This is needed for the option to restrict memory access using Xen grant
mappings to work which primary goal is to enable using virtio devices
in Xen guests.
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
---
Changes RFC -> V1:
- update commit subject/description and text in description
- move to devicetree/bindings/arm/
Changes V1 -> V2:
- update text in description
- change the maintainer of the binding
- fix validation issue
- reference xen,dev-domid.yaml schema from virtio/mmio.yaml
Change V2 -> V3:
- Stefano already gave his Reviewed-by, I dropped it due to the changes (significant)
- use generic IOMMU device tree bindings instead of custom property
"xen,dev-domid"
- change commit subject and description, was
"dt-bindings: Add xen,dev-domid property description for xen-grant DMA ops"
Changes V3 -> V4:
- add Stefano's R-b
- remove underscore in iommu node name
- remove consumer example virtio@3000
- update text for two descriptions
---
.../devicetree/bindings/iommu/xen,grant-dma.yaml | 39 ++++++++++++++++++++++
1 file changed, 39 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml
diff --git a/Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml b/Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml
new file mode 100644
index 00000000..be1539d
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iommu/xen,grant-dma.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xen specific IOMMU for virtualized devices (e.g. virtio)
+
+maintainers:
+ - Stefano Stabellini <sstabellini@kernel.org>
+
+description:
+ The Xen IOMMU represents the Xen grant table interface. Grant mappings
+ are to be used with devices connected to the Xen IOMMU using the "iommus"
+ property, which also specifies the ID of the backend domain.
+ The binding is required to restrict memory access using Xen grant mappings.
+
+properties:
+ compatible:
+ const: xen,grant-dma
+
+ '#iommu-cells':
+ const: 1
+ description:
+ The single cell is the domid (domain ID) of the domain where the backend
+ is running.
+
+required:
+ - compatible
+ - "#iommu-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ iommu {
+ compatible = "xen,grant-dma";
+ #iommu-cells = <1>;
+ };
--
2.7.4
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH V4 5/8] dt-bindings: Add xen, grant-dma IOMMU description for xen-grant DMA ops
@ 2022-06-02 19:23 ` Oleksandr Tyshchenko
0 siblings, 0 replies; 30+ messages in thread
From: Oleksandr Tyshchenko @ 2022-06-02 19:23 UTC (permalink / raw)
To: xen-devel, devicetree, linux-kernel, linux-arm-kernel, iommu
Cc: Juergen Gross, Stefano Stabellini, Julien Grall, Arnd Bergmann,
Michael S. Tsirkin, Christoph Hellwig, Oleksandr Tyshchenko,
Rob Herring, Krzysztof Kozlowski, Will Deacon
From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
The main purpose of this binding is to communicate Xen specific
information using generic IOMMU device tree bindings (which is
a good fit here) rather than introducing a custom property.
Introduce Xen specific IOMMU for the virtualized device (e.g. virtio)
to be used by Xen grant DMA-mapping layer in the subsequent commit.
The reference to Xen specific IOMMU node using "iommus" property
indicates that Xen grant mappings need to be enabled for the device,
and it specifies the ID of the domain where the corresponding backend
resides. The domid (domain ID) is used as an argument to the Xen grant
mapping APIs.
This is needed for the option to restrict memory access using Xen grant
mappings to work which primary goal is to enable using virtio devices
in Xen guests.
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
---
Changes RFC -> V1:
- update commit subject/description and text in description
- move to devicetree/bindings/arm/
Changes V1 -> V2:
- update text in description
- change the maintainer of the binding
- fix validation issue
- reference xen,dev-domid.yaml schema from virtio/mmio.yaml
Change V2 -> V3:
- Stefano already gave his Reviewed-by, I dropped it due to the changes (significant)
- use generic IOMMU device tree bindings instead of custom property
"xen,dev-domid"
- change commit subject and description, was
"dt-bindings: Add xen,dev-domid property description for xen-grant DMA ops"
Changes V3 -> V4:
- add Stefano's R-b
- remove underscore in iommu node name
- remove consumer example virtio@3000
- update text for two descriptions
---
.../devicetree/bindings/iommu/xen,grant-dma.yaml | 39 ++++++++++++++++++++++
1 file changed, 39 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml
diff --git a/Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml b/Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml
new file mode 100644
index 00000000..be1539d
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iommu/xen,grant-dma.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xen specific IOMMU for virtualized devices (e.g. virtio)
+
+maintainers:
+ - Stefano Stabellini <sstabellini@kernel.org>
+
+description:
+ The Xen IOMMU represents the Xen grant table interface. Grant mappings
+ are to be used with devices connected to the Xen IOMMU using the "iommus"
+ property, which also specifies the ID of the backend domain.
+ The binding is required to restrict memory access using Xen grant mappings.
+
+properties:
+ compatible:
+ const: xen,grant-dma
+
+ '#iommu-cells':
+ const: 1
+ description:
+ The single cell is the domid (domain ID) of the domain where the backend
+ is running.
+
+required:
+ - compatible
+ - "#iommu-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ iommu {
+ compatible = "xen,grant-dma";
+ #iommu-cells = <1>;
+ };
--
2.7.4
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH V4 5/8] dt-bindings: Add xen,grant-dma IOMMU description for xen-grant DMA ops
@ 2022-06-02 19:23 ` Oleksandr Tyshchenko
0 siblings, 0 replies; 30+ messages in thread
From: Oleksandr Tyshchenko @ 2022-06-02 19:23 UTC (permalink / raw)
To: xen-devel, devicetree, linux-kernel, linux-arm-kernel, iommu
Cc: Oleksandr Tyshchenko, Rob Herring, Joerg Roedel, Will Deacon,
Krzysztof Kozlowski, Julien Grall, Juergen Gross,
Stefano Stabellini, Michael S. Tsirkin, Christoph Hellwig,
Arnd Bergmann
From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
The main purpose of this binding is to communicate Xen specific
information using generic IOMMU device tree bindings (which is
a good fit here) rather than introducing a custom property.
Introduce Xen specific IOMMU for the virtualized device (e.g. virtio)
to be used by Xen grant DMA-mapping layer in the subsequent commit.
The reference to Xen specific IOMMU node using "iommus" property
indicates that Xen grant mappings need to be enabled for the device,
and it specifies the ID of the domain where the corresponding backend
resides. The domid (domain ID) is used as an argument to the Xen grant
mapping APIs.
This is needed for the option to restrict memory access using Xen grant
mappings to work which primary goal is to enable using virtio devices
in Xen guests.
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
---
Changes RFC -> V1:
- update commit subject/description and text in description
- move to devicetree/bindings/arm/
Changes V1 -> V2:
- update text in description
- change the maintainer of the binding
- fix validation issue
- reference xen,dev-domid.yaml schema from virtio/mmio.yaml
Change V2 -> V3:
- Stefano already gave his Reviewed-by, I dropped it due to the changes (significant)
- use generic IOMMU device tree bindings instead of custom property
"xen,dev-domid"
- change commit subject and description, was
"dt-bindings: Add xen,dev-domid property description for xen-grant DMA ops"
Changes V3 -> V4:
- add Stefano's R-b
- remove underscore in iommu node name
- remove consumer example virtio@3000
- update text for two descriptions
---
.../devicetree/bindings/iommu/xen,grant-dma.yaml | 39 ++++++++++++++++++++++
1 file changed, 39 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml
diff --git a/Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml b/Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml
new file mode 100644
index 00000000..be1539d
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iommu/xen,grant-dma.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xen specific IOMMU for virtualized devices (e.g. virtio)
+
+maintainers:
+ - Stefano Stabellini <sstabellini@kernel.org>
+
+description:
+ The Xen IOMMU represents the Xen grant table interface. Grant mappings
+ are to be used with devices connected to the Xen IOMMU using the "iommus"
+ property, which also specifies the ID of the backend domain.
+ The binding is required to restrict memory access using Xen grant mappings.
+
+properties:
+ compatible:
+ const: xen,grant-dma
+
+ '#iommu-cells':
+ const: 1
+ description:
+ The single cell is the domid (domain ID) of the domain where the backend
+ is running.
+
+required:
+ - compatible
+ - "#iommu-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ iommu {
+ compatible = "xen,grant-dma";
+ #iommu-cells = <1>;
+ };
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH V4 6/8] xen/grant-dma-iommu: Introduce stub IOMMU driver
2022-06-02 19:23 ` Oleksandr Tyshchenko
@ 2022-06-02 19:23 ` Oleksandr Tyshchenko
-1 siblings, 0 replies; 30+ messages in thread
From: Oleksandr Tyshchenko @ 2022-06-02 19:23 UTC (permalink / raw)
To: xen-devel, linux-kernel, linux-arm-kernel
Cc: Oleksandr Tyshchenko, Stefano Stabellini, Boris Ostrovsky,
Juergen Gross, Julien Grall, Michael S. Tsirkin,
Christoph Hellwig
From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
In order to reuse generic IOMMU device tree bindings by Xen grant
DMA-mapping layer we need to add this stub driver from a fw_devlink
perspective (grant-dma-ops cannot be converted into the proper
IOMMU driver).
Otherwise, just reusing IOMMU bindings (without having a corresponding
driver) leads to the deferred probe timeout afterwards, because
the IOMMU device never becomes available.
This stub driver does nothing except registering empty iommu_ops,
the upper layer "of_iommu" will treat this as NO_IOMMU condition
and won't return -EPROBE_DEFER.
As this driver is quite different from the most hardware IOMMU
implementations and only needed in Xen guests, place it in drivers/xen
directory. The subsequent commit will make use of it.
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
---
According to the discussion at:
https://lore.kernel.org/xen-devel/c0f78aab-e723-fe00-a310-9fe52ec75e48@gmail.com/
Change V2 -> V3:
- new patch
Changes V3 -> V4:
- add Stefano's R-b
---
drivers/xen/Kconfig | 4 +++
drivers/xen/Makefile | 1 +
drivers/xen/grant-dma-iommu.c | 78 +++++++++++++++++++++++++++++++++++++++++++
3 files changed, 83 insertions(+)
create mode 100644 drivers/xen/grant-dma-iommu.c
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index a7bd8ce..35d20d9 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -335,6 +335,10 @@ config XEN_UNPOPULATED_ALLOC
having to balloon out RAM regions in order to obtain physical memory
space to create such mappings.
+config XEN_GRANT_DMA_IOMMU
+ bool
+ select IOMMU_API
+
config XEN_GRANT_DMA_OPS
bool
select DMA_OPS
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 1a23cb0..c0503f1 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -40,3 +40,4 @@ xen-privcmd-y := privcmd.o privcmd-buf.o
obj-$(CONFIG_XEN_FRONT_PGDIR_SHBUF) += xen-front-pgdir-shbuf.o
obj-$(CONFIG_XEN_UNPOPULATED_ALLOC) += unpopulated-alloc.o
obj-$(CONFIG_XEN_GRANT_DMA_OPS) += grant-dma-ops.o
+obj-$(CONFIG_XEN_GRANT_DMA_IOMMU) += grant-dma-iommu.o
diff --git a/drivers/xen/grant-dma-iommu.c b/drivers/xen/grant-dma-iommu.c
new file mode 100644
index 00000000..16b8bc0
--- /dev/null
+++ b/drivers/xen/grant-dma-iommu.c
@@ -0,0 +1,78 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Stub IOMMU driver which does nothing.
+ * The main purpose of it being present is to reuse generic IOMMU device tree
+ * bindings by Xen grant DMA-mapping layer.
+ *
+ * Copyright (C) 2022 EPAM Systems Inc.
+ */
+
+#include <linux/iommu.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+
+struct grant_dma_iommu_device {
+ struct device *dev;
+ struct iommu_device iommu;
+};
+
+/* Nothing is really needed here */
+static const struct iommu_ops grant_dma_iommu_ops;
+
+static const struct of_device_id grant_dma_iommu_of_match[] = {
+ { .compatible = "xen,grant-dma" },
+ { },
+};
+
+static int grant_dma_iommu_probe(struct platform_device *pdev)
+{
+ struct grant_dma_iommu_device *mmu;
+ int ret;
+
+ mmu = devm_kzalloc(&pdev->dev, sizeof(*mmu), GFP_KERNEL);
+ if (!mmu)
+ return -ENOMEM;
+
+ mmu->dev = &pdev->dev;
+
+ ret = iommu_device_register(&mmu->iommu, &grant_dma_iommu_ops, &pdev->dev);
+ if (ret)
+ return ret;
+
+ platform_set_drvdata(pdev, mmu);
+
+ return 0;
+}
+
+static int grant_dma_iommu_remove(struct platform_device *pdev)
+{
+ struct grant_dma_iommu_device *mmu = platform_get_drvdata(pdev);
+
+ platform_set_drvdata(pdev, NULL);
+ iommu_device_unregister(&mmu->iommu);
+
+ return 0;
+}
+
+static struct platform_driver grant_dma_iommu_driver = {
+ .driver = {
+ .name = "grant-dma-iommu",
+ .of_match_table = grant_dma_iommu_of_match,
+ },
+ .probe = grant_dma_iommu_probe,
+ .remove = grant_dma_iommu_remove,
+};
+
+static int __init grant_dma_iommu_init(void)
+{
+ struct device_node *iommu_np;
+
+ iommu_np = of_find_matching_node(NULL, grant_dma_iommu_of_match);
+ if (!iommu_np)
+ return 0;
+
+ of_node_put(iommu_np);
+
+ return platform_driver_register(&grant_dma_iommu_driver);
+}
+subsys_initcall(grant_dma_iommu_init);
--
2.7.4
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH V4 6/8] xen/grant-dma-iommu: Introduce stub IOMMU driver
@ 2022-06-02 19:23 ` Oleksandr Tyshchenko
0 siblings, 0 replies; 30+ messages in thread
From: Oleksandr Tyshchenko @ 2022-06-02 19:23 UTC (permalink / raw)
To: xen-devel, linux-kernel, linux-arm-kernel
Cc: Oleksandr Tyshchenko, Stefano Stabellini, Boris Ostrovsky,
Juergen Gross, Julien Grall, Michael S. Tsirkin,
Christoph Hellwig
From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
In order to reuse generic IOMMU device tree bindings by Xen grant
DMA-mapping layer we need to add this stub driver from a fw_devlink
perspective (grant-dma-ops cannot be converted into the proper
IOMMU driver).
Otherwise, just reusing IOMMU bindings (without having a corresponding
driver) leads to the deferred probe timeout afterwards, because
the IOMMU device never becomes available.
This stub driver does nothing except registering empty iommu_ops,
the upper layer "of_iommu" will treat this as NO_IOMMU condition
and won't return -EPROBE_DEFER.
As this driver is quite different from the most hardware IOMMU
implementations and only needed in Xen guests, place it in drivers/xen
directory. The subsequent commit will make use of it.
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
---
According to the discussion at:
https://lore.kernel.org/xen-devel/c0f78aab-e723-fe00-a310-9fe52ec75e48@gmail.com/
Change V2 -> V3:
- new patch
Changes V3 -> V4:
- add Stefano's R-b
---
drivers/xen/Kconfig | 4 +++
drivers/xen/Makefile | 1 +
drivers/xen/grant-dma-iommu.c | 78 +++++++++++++++++++++++++++++++++++++++++++
3 files changed, 83 insertions(+)
create mode 100644 drivers/xen/grant-dma-iommu.c
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index a7bd8ce..35d20d9 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -335,6 +335,10 @@ config XEN_UNPOPULATED_ALLOC
having to balloon out RAM regions in order to obtain physical memory
space to create such mappings.
+config XEN_GRANT_DMA_IOMMU
+ bool
+ select IOMMU_API
+
config XEN_GRANT_DMA_OPS
bool
select DMA_OPS
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 1a23cb0..c0503f1 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -40,3 +40,4 @@ xen-privcmd-y := privcmd.o privcmd-buf.o
obj-$(CONFIG_XEN_FRONT_PGDIR_SHBUF) += xen-front-pgdir-shbuf.o
obj-$(CONFIG_XEN_UNPOPULATED_ALLOC) += unpopulated-alloc.o
obj-$(CONFIG_XEN_GRANT_DMA_OPS) += grant-dma-ops.o
+obj-$(CONFIG_XEN_GRANT_DMA_IOMMU) += grant-dma-iommu.o
diff --git a/drivers/xen/grant-dma-iommu.c b/drivers/xen/grant-dma-iommu.c
new file mode 100644
index 00000000..16b8bc0
--- /dev/null
+++ b/drivers/xen/grant-dma-iommu.c
@@ -0,0 +1,78 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Stub IOMMU driver which does nothing.
+ * The main purpose of it being present is to reuse generic IOMMU device tree
+ * bindings by Xen grant DMA-mapping layer.
+ *
+ * Copyright (C) 2022 EPAM Systems Inc.
+ */
+
+#include <linux/iommu.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+
+struct grant_dma_iommu_device {
+ struct device *dev;
+ struct iommu_device iommu;
+};
+
+/* Nothing is really needed here */
+static const struct iommu_ops grant_dma_iommu_ops;
+
+static const struct of_device_id grant_dma_iommu_of_match[] = {
+ { .compatible = "xen,grant-dma" },
+ { },
+};
+
+static int grant_dma_iommu_probe(struct platform_device *pdev)
+{
+ struct grant_dma_iommu_device *mmu;
+ int ret;
+
+ mmu = devm_kzalloc(&pdev->dev, sizeof(*mmu), GFP_KERNEL);
+ if (!mmu)
+ return -ENOMEM;
+
+ mmu->dev = &pdev->dev;
+
+ ret = iommu_device_register(&mmu->iommu, &grant_dma_iommu_ops, &pdev->dev);
+ if (ret)
+ return ret;
+
+ platform_set_drvdata(pdev, mmu);
+
+ return 0;
+}
+
+static int grant_dma_iommu_remove(struct platform_device *pdev)
+{
+ struct grant_dma_iommu_device *mmu = platform_get_drvdata(pdev);
+
+ platform_set_drvdata(pdev, NULL);
+ iommu_device_unregister(&mmu->iommu);
+
+ return 0;
+}
+
+static struct platform_driver grant_dma_iommu_driver = {
+ .driver = {
+ .name = "grant-dma-iommu",
+ .of_match_table = grant_dma_iommu_of_match,
+ },
+ .probe = grant_dma_iommu_probe,
+ .remove = grant_dma_iommu_remove,
+};
+
+static int __init grant_dma_iommu_init(void)
+{
+ struct device_node *iommu_np;
+
+ iommu_np = of_find_matching_node(NULL, grant_dma_iommu_of_match);
+ if (!iommu_np)
+ return 0;
+
+ of_node_put(iommu_np);
+
+ return platform_driver_register(&grant_dma_iommu_driver);
+}
+subsys_initcall(grant_dma_iommu_init);
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH V4 7/8] xen/grant-dma-ops: Retrieve the ID of backend's domain for DT devices
2022-06-02 19:23 ` Oleksandr Tyshchenko
@ 2022-06-02 19:23 ` Oleksandr Tyshchenko
-1 siblings, 0 replies; 30+ messages in thread
From: Oleksandr Tyshchenko @ 2022-06-02 19:23 UTC (permalink / raw)
To: xen-devel, linux-kernel, linux-arm-kernel
Cc: Oleksandr Tyshchenko, Stefano Stabellini, Boris Ostrovsky,
Juergen Gross, Julien Grall, Michael S. Tsirkin,
Christoph Hellwig
From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Use the presence of "iommus" property pointed to the IOMMU node with
recently introduced "xen,grant-dma" compatible as a clear indicator
of enabling Xen grant mappings scheme for that device and read the ID
of Xen domain where the corresponding backend is running. The domid
(domain ID) is used as an argument to the Xen grant mapping APIs.
To avoid the deferred probe timeout which takes place after reusing
generic IOMMU device tree bindings (because the IOMMU device never
becomes available) enable recently introduced stub IOMMU driver by
selecting XEN_GRANT_DMA_IOMMU.
Also introduce xen_is_grant_dma_device() to check whether xen-grant
DMA ops need to be set for a passed device.
Remove the hardcoded domid 0 in xen_grant_setup_dma_ops().
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
---
Changes RFC -> V1:
- new patch, split required changes from commit:
"[PATCH 4/6] virtio: Various updates to xen-virtio DMA ops layer"
- update checks in xen_virtio_setup_dma_ops() to only support
DT devices for now
- remove the "virtio,mmio" check from xen_is_virtio_device()
- remane everything according to the new naming scheme:
s/virtio/grant_dma
Changes V1 -> V2:
- remove dev_is_pci() check in xen_grant_setup_dma_ops()
- remove EXPORT_SYMBOL_GPL(xen_is_grant_dma_device);
Changes V2 -> V3:
- Stefano already gave his Reviewed-by, I dropped it due to the changes (significant)
- update commit description
- reuse generic IOMMU device tree bindings, select XEN_GRANT_DMA_IOMMU
to avoid the deferred probe timeout
Changes V3 -> V4:
- add Stefano's R-b
---
drivers/xen/Kconfig | 1 +
drivers/xen/grant-dma-ops.c | 48 ++++++++++++++++++++++++++++++++++++++-------
include/xen/xen-ops.h | 5 +++++
3 files changed, 47 insertions(+), 7 deletions(-)
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 35d20d9..bfd5f4f 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -347,6 +347,7 @@ config XEN_VIRTIO
bool "Xen virtio support"
depends on VIRTIO
select XEN_GRANT_DMA_OPS
+ select XEN_GRANT_DMA_IOMMU if OF
help
Enable virtio support for running as Xen guest. Depending on the
guest type this will require special support on the backend side
diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c
index 44659f4..6586152 100644
--- a/drivers/xen/grant-dma-ops.c
+++ b/drivers/xen/grant-dma-ops.c
@@ -55,11 +55,6 @@ static struct xen_grant_dma_data *find_xen_grant_dma_data(struct device *dev)
* Such a DMA address is formed by using the grant reference as a frame
* number and setting the highest address bit (this bit is for the backend
* to be able to distinguish it from e.g. a mmio address).
- *
- * Note that for now we hard wire dom0 to be the backend domain. In order
- * to support any domain as backend we'd need to add a way to communicate
- * the domid of this backend, e.g. via Xenstore, via the PCI-device's
- * config space or DT/ACPI.
*/
static void *xen_grant_dma_alloc(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t gfp,
@@ -275,9 +270,26 @@ static const struct dma_map_ops xen_grant_dma_ops = {
.dma_supported = xen_grant_dma_supported,
};
+bool xen_is_grant_dma_device(struct device *dev)
+{
+ struct device_node *iommu_np;
+ bool has_iommu;
+
+ /* XXX Handle only DT devices for now */
+ if (!dev->of_node)
+ return false;
+
+ iommu_np = of_parse_phandle(dev->of_node, "iommus", 0);
+ has_iommu = iommu_np && of_device_is_compatible(iommu_np, "xen,grant-dma");
+ of_node_put(iommu_np);
+
+ return has_iommu;
+}
+
void xen_grant_setup_dma_ops(struct device *dev)
{
struct xen_grant_dma_data *data;
+ struct of_phandle_args iommu_spec;
data = find_xen_grant_dma_data(dev);
if (data) {
@@ -285,12 +297,34 @@ void xen_grant_setup_dma_ops(struct device *dev)
return;
}
+ /* XXX ACPI device unsupported for now */
+ if (!dev->of_node)
+ goto err;
+
+ if (of_parse_phandle_with_args(dev->of_node, "iommus", "#iommu-cells",
+ 0, &iommu_spec)) {
+ dev_err(dev, "Cannot parse iommus property\n");
+ goto err;
+ }
+
+ if (!of_device_is_compatible(iommu_spec.np, "xen,grant-dma") ||
+ iommu_spec.args_count != 1) {
+ dev_err(dev, "Incompatible IOMMU node\n");
+ of_node_put(iommu_spec.np);
+ goto err;
+ }
+
+ of_node_put(iommu_spec.np);
+
data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
if (!data)
goto err;
- /* XXX The dom0 is hardcoded as the backend domain for now */
- data->backend_domid = 0;
+ /*
+ * The endpoint ID here means the ID of the domain where the corresponding
+ * backend is running
+ */
+ data->backend_domid = iommu_spec.args[0];
if (xa_err(xa_store(&xen_grant_dma_devices, (unsigned long)dev, data,
GFP_KERNEL))) {
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 4f9fad5..62be9dc 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -223,10 +223,15 @@ static inline void xen_preemptible_hcall_end(void) { }
#ifdef CONFIG_XEN_GRANT_DMA_OPS
void xen_grant_setup_dma_ops(struct device *dev);
+bool xen_is_grant_dma_device(struct device *dev);
#else
static inline void xen_grant_setup_dma_ops(struct device *dev)
{
}
+static inline bool xen_is_grant_dma_device(struct device *dev)
+{
+ return false;
+}
#endif /* CONFIG_XEN_GRANT_DMA_OPS */
#endif /* INCLUDE_XEN_OPS_H */
--
2.7.4
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH V4 7/8] xen/grant-dma-ops: Retrieve the ID of backend's domain for DT devices
@ 2022-06-02 19:23 ` Oleksandr Tyshchenko
0 siblings, 0 replies; 30+ messages in thread
From: Oleksandr Tyshchenko @ 2022-06-02 19:23 UTC (permalink / raw)
To: xen-devel, linux-kernel, linux-arm-kernel
Cc: Oleksandr Tyshchenko, Stefano Stabellini, Boris Ostrovsky,
Juergen Gross, Julien Grall, Michael S. Tsirkin,
Christoph Hellwig
From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Use the presence of "iommus" property pointed to the IOMMU node with
recently introduced "xen,grant-dma" compatible as a clear indicator
of enabling Xen grant mappings scheme for that device and read the ID
of Xen domain where the corresponding backend is running. The domid
(domain ID) is used as an argument to the Xen grant mapping APIs.
To avoid the deferred probe timeout which takes place after reusing
generic IOMMU device tree bindings (because the IOMMU device never
becomes available) enable recently introduced stub IOMMU driver by
selecting XEN_GRANT_DMA_IOMMU.
Also introduce xen_is_grant_dma_device() to check whether xen-grant
DMA ops need to be set for a passed device.
Remove the hardcoded domid 0 in xen_grant_setup_dma_ops().
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
---
Changes RFC -> V1:
- new patch, split required changes from commit:
"[PATCH 4/6] virtio: Various updates to xen-virtio DMA ops layer"
- update checks in xen_virtio_setup_dma_ops() to only support
DT devices for now
- remove the "virtio,mmio" check from xen_is_virtio_device()
- remane everything according to the new naming scheme:
s/virtio/grant_dma
Changes V1 -> V2:
- remove dev_is_pci() check in xen_grant_setup_dma_ops()
- remove EXPORT_SYMBOL_GPL(xen_is_grant_dma_device);
Changes V2 -> V3:
- Stefano already gave his Reviewed-by, I dropped it due to the changes (significant)
- update commit description
- reuse generic IOMMU device tree bindings, select XEN_GRANT_DMA_IOMMU
to avoid the deferred probe timeout
Changes V3 -> V4:
- add Stefano's R-b
---
drivers/xen/Kconfig | 1 +
drivers/xen/grant-dma-ops.c | 48 ++++++++++++++++++++++++++++++++++++++-------
include/xen/xen-ops.h | 5 +++++
3 files changed, 47 insertions(+), 7 deletions(-)
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 35d20d9..bfd5f4f 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -347,6 +347,7 @@ config XEN_VIRTIO
bool "Xen virtio support"
depends on VIRTIO
select XEN_GRANT_DMA_OPS
+ select XEN_GRANT_DMA_IOMMU if OF
help
Enable virtio support for running as Xen guest. Depending on the
guest type this will require special support on the backend side
diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c
index 44659f4..6586152 100644
--- a/drivers/xen/grant-dma-ops.c
+++ b/drivers/xen/grant-dma-ops.c
@@ -55,11 +55,6 @@ static struct xen_grant_dma_data *find_xen_grant_dma_data(struct device *dev)
* Such a DMA address is formed by using the grant reference as a frame
* number and setting the highest address bit (this bit is for the backend
* to be able to distinguish it from e.g. a mmio address).
- *
- * Note that for now we hard wire dom0 to be the backend domain. In order
- * to support any domain as backend we'd need to add a way to communicate
- * the domid of this backend, e.g. via Xenstore, via the PCI-device's
- * config space or DT/ACPI.
*/
static void *xen_grant_dma_alloc(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t gfp,
@@ -275,9 +270,26 @@ static const struct dma_map_ops xen_grant_dma_ops = {
.dma_supported = xen_grant_dma_supported,
};
+bool xen_is_grant_dma_device(struct device *dev)
+{
+ struct device_node *iommu_np;
+ bool has_iommu;
+
+ /* XXX Handle only DT devices for now */
+ if (!dev->of_node)
+ return false;
+
+ iommu_np = of_parse_phandle(dev->of_node, "iommus", 0);
+ has_iommu = iommu_np && of_device_is_compatible(iommu_np, "xen,grant-dma");
+ of_node_put(iommu_np);
+
+ return has_iommu;
+}
+
void xen_grant_setup_dma_ops(struct device *dev)
{
struct xen_grant_dma_data *data;
+ struct of_phandle_args iommu_spec;
data = find_xen_grant_dma_data(dev);
if (data) {
@@ -285,12 +297,34 @@ void xen_grant_setup_dma_ops(struct device *dev)
return;
}
+ /* XXX ACPI device unsupported for now */
+ if (!dev->of_node)
+ goto err;
+
+ if (of_parse_phandle_with_args(dev->of_node, "iommus", "#iommu-cells",
+ 0, &iommu_spec)) {
+ dev_err(dev, "Cannot parse iommus property\n");
+ goto err;
+ }
+
+ if (!of_device_is_compatible(iommu_spec.np, "xen,grant-dma") ||
+ iommu_spec.args_count != 1) {
+ dev_err(dev, "Incompatible IOMMU node\n");
+ of_node_put(iommu_spec.np);
+ goto err;
+ }
+
+ of_node_put(iommu_spec.np);
+
data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
if (!data)
goto err;
- /* XXX The dom0 is hardcoded as the backend domain for now */
- data->backend_domid = 0;
+ /*
+ * The endpoint ID here means the ID of the domain where the corresponding
+ * backend is running
+ */
+ data->backend_domid = iommu_spec.args[0];
if (xa_err(xa_store(&xen_grant_dma_devices, (unsigned long)dev, data,
GFP_KERNEL))) {
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 4f9fad5..62be9dc 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -223,10 +223,15 @@ static inline void xen_preemptible_hcall_end(void) { }
#ifdef CONFIG_XEN_GRANT_DMA_OPS
void xen_grant_setup_dma_ops(struct device *dev);
+bool xen_is_grant_dma_device(struct device *dev);
#else
static inline void xen_grant_setup_dma_ops(struct device *dev)
{
}
+static inline bool xen_is_grant_dma_device(struct device *dev)
+{
+ return false;
+}
#endif /* CONFIG_XEN_GRANT_DMA_OPS */
#endif /* INCLUDE_XEN_OPS_H */
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH V4 8/8] arm/xen: Assign xen-grant DMA ops for xen-grant DMA devices
2022-06-02 19:23 ` Oleksandr Tyshchenko
@ 2022-06-02 19:23 ` Oleksandr Tyshchenko
-1 siblings, 0 replies; 30+ messages in thread
From: Oleksandr Tyshchenko @ 2022-06-02 19:23 UTC (permalink / raw)
To: xen-devel, linux-kernel, linux-arm-kernel
Cc: Oleksandr Tyshchenko, Boris Ostrovsky, Juergen Gross,
Stefano Stabellini, Julien Grall, Michael S. Tsirkin,
Christoph Hellwig
From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
By assigning xen-grant DMA ops we will restrict memory access for
passed device using Xen grant mappings. This is needed for using any
virtualized device (e.g. virtio) in Xen guests in a safe manner.
Please note, for the virtio devices the XEN_VIRTIO config should
be enabled (it forces ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS).
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
---
Changes RFC -> V1:
- update commit subject/description
- remove #ifdef CONFIG_XEN_VIRTIO
- re-organize the check taking into the account that
swiotlb and virtio cases are mutually exclusive
- update according to the new naming scheme:
s/virtio/grant_dma
Changes V1 -> V2:
- add Stefano's R-b
- remove arch_has_restricted_virtio_memory_access() check
- update commit description
- remove the inclusion of virtio_config.h
Changes V2 -> V3:
- no changes
Changes V3 -> V4:
- no changes
---
include/xen/arm/xen-ops.h | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/xen/arm/xen-ops.h b/include/xen/arm/xen-ops.h
index 288deb1..b0766a6 100644
--- a/include/xen/arm/xen-ops.h
+++ b/include/xen/arm/xen-ops.h
@@ -3,11 +3,14 @@
#define _ASM_ARM_XEN_OPS_H
#include <xen/swiotlb-xen.h>
+#include <xen/xen-ops.h>
static inline void xen_setup_dma_ops(struct device *dev)
{
#ifdef CONFIG_XEN
- if (xen_swiotlb_detect())
+ if (xen_is_grant_dma_device(dev))
+ xen_grant_setup_dma_ops(dev);
+ else if (xen_swiotlb_detect())
dev->dma_ops = &xen_swiotlb_dma_ops;
#endif
}
--
2.7.4
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH V4 8/8] arm/xen: Assign xen-grant DMA ops for xen-grant DMA devices
@ 2022-06-02 19:23 ` Oleksandr Tyshchenko
0 siblings, 0 replies; 30+ messages in thread
From: Oleksandr Tyshchenko @ 2022-06-02 19:23 UTC (permalink / raw)
To: xen-devel, linux-kernel, linux-arm-kernel
Cc: Oleksandr Tyshchenko, Boris Ostrovsky, Juergen Gross,
Stefano Stabellini, Julien Grall, Michael S. Tsirkin,
Christoph Hellwig
From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
By assigning xen-grant DMA ops we will restrict memory access for
passed device using Xen grant mappings. This is needed for using any
virtualized device (e.g. virtio) in Xen guests in a safe manner.
Please note, for the virtio devices the XEN_VIRTIO config should
be enabled (it forces ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS).
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
---
Changes RFC -> V1:
- update commit subject/description
- remove #ifdef CONFIG_XEN_VIRTIO
- re-organize the check taking into the account that
swiotlb and virtio cases are mutually exclusive
- update according to the new naming scheme:
s/virtio/grant_dma
Changes V1 -> V2:
- add Stefano's R-b
- remove arch_has_restricted_virtio_memory_access() check
- update commit description
- remove the inclusion of virtio_config.h
Changes V2 -> V3:
- no changes
Changes V3 -> V4:
- no changes
---
include/xen/arm/xen-ops.h | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/xen/arm/xen-ops.h b/include/xen/arm/xen-ops.h
index 288deb1..b0766a6 100644
--- a/include/xen/arm/xen-ops.h
+++ b/include/xen/arm/xen-ops.h
@@ -3,11 +3,14 @@
#define _ASM_ARM_XEN_OPS_H
#include <xen/swiotlb-xen.h>
+#include <xen/xen-ops.h>
static inline void xen_setup_dma_ops(struct device *dev)
{
#ifdef CONFIG_XEN
- if (xen_swiotlb_detect())
+ if (xen_is_grant_dma_device(dev))
+ xen_grant_setup_dma_ops(dev);
+ else if (xen_swiotlb_detect())
dev->dma_ops = &xen_swiotlb_dma_ops;
#endif
}
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: [PATCH V4 5/8] dt-bindings: Add xen,grant-dma IOMMU description for xen-grant DMA ops
2022-06-02 19:23 ` [PATCH V4 5/8] dt-bindings: Add xen, grant-dma " Oleksandr Tyshchenko
(?)
@ 2022-06-05 22:45 ` Rob Herring
-1 siblings, 0 replies; 30+ messages in thread
From: Rob Herring @ 2022-06-05 22:45 UTC (permalink / raw)
To: Oleksandr Tyshchenko
Cc: linux-kernel, iommu, Joerg Roedel, Michael S. Tsirkin,
Julien Grall, xen-devel, devicetree, Will Deacon, Juergen Gross,
Arnd Bergmann, Stefano Stabellini, Oleksandr Tyshchenko,
Krzysztof Kozlowski, linux-arm-kernel, Christoph Hellwig,
Rob Herring
On Thu, 02 Jun 2022 22:23:50 +0300, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>
> The main purpose of this binding is to communicate Xen specific
> information using generic IOMMU device tree bindings (which is
> a good fit here) rather than introducing a custom property.
>
> Introduce Xen specific IOMMU for the virtualized device (e.g. virtio)
> to be used by Xen grant DMA-mapping layer in the subsequent commit.
>
> The reference to Xen specific IOMMU node using "iommus" property
> indicates that Xen grant mappings need to be enabled for the device,
> and it specifies the ID of the domain where the corresponding backend
> resides. The domid (domain ID) is used as an argument to the Xen grant
> mapping APIs.
>
> This is needed for the option to restrict memory access using Xen grant
> mappings to work which primary goal is to enable using virtio devices
> in Xen guests.
>
> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
> ---
> Changes RFC -> V1:
> - update commit subject/description and text in description
> - move to devicetree/bindings/arm/
>
> Changes V1 -> V2:
> - update text in description
> - change the maintainer of the binding
> - fix validation issue
> - reference xen,dev-domid.yaml schema from virtio/mmio.yaml
>
> Change V2 -> V3:
> - Stefano already gave his Reviewed-by, I dropped it due to the changes (significant)
> - use generic IOMMU device tree bindings instead of custom property
> "xen,dev-domid"
> - change commit subject and description, was
> "dt-bindings: Add xen,dev-domid property description for xen-grant DMA ops"
>
> Changes V3 -> V4:
> - add Stefano's R-b
> - remove underscore in iommu node name
> - remove consumer example virtio@3000
> - update text for two descriptions
> ---
> .../devicetree/bindings/iommu/xen,grant-dma.yaml | 39 ++++++++++++++++++++++
> 1 file changed, 39 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH V4 5/8] dt-bindings: Add xen,grant-dma IOMMU description for xen-grant DMA ops
@ 2022-06-05 22:45 ` Rob Herring
0 siblings, 0 replies; 30+ messages in thread
From: Rob Herring @ 2022-06-05 22:45 UTC (permalink / raw)
To: Oleksandr Tyshchenko
Cc: Juergen Gross, devicetree, Stefano Stabellini, Julien Grall,
Arnd Bergmann, Michael S. Tsirkin, linux-kernel,
Christoph Hellwig, Oleksandr Tyshchenko, iommu, Rob Herring,
Krzysztof Kozlowski, xen-devel, Will Deacon, linux-arm-kernel
On Thu, 02 Jun 2022 22:23:50 +0300, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>
> The main purpose of this binding is to communicate Xen specific
> information using generic IOMMU device tree bindings (which is
> a good fit here) rather than introducing a custom property.
>
> Introduce Xen specific IOMMU for the virtualized device (e.g. virtio)
> to be used by Xen grant DMA-mapping layer in the subsequent commit.
>
> The reference to Xen specific IOMMU node using "iommus" property
> indicates that Xen grant mappings need to be enabled for the device,
> and it specifies the ID of the domain where the corresponding backend
> resides. The domid (domain ID) is used as an argument to the Xen grant
> mapping APIs.
>
> This is needed for the option to restrict memory access using Xen grant
> mappings to work which primary goal is to enable using virtio devices
> in Xen guests.
>
> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
> ---
> Changes RFC -> V1:
> - update commit subject/description and text in description
> - move to devicetree/bindings/arm/
>
> Changes V1 -> V2:
> - update text in description
> - change the maintainer of the binding
> - fix validation issue
> - reference xen,dev-domid.yaml schema from virtio/mmio.yaml
>
> Change V2 -> V3:
> - Stefano already gave his Reviewed-by, I dropped it due to the changes (significant)
> - use generic IOMMU device tree bindings instead of custom property
> "xen,dev-domid"
> - change commit subject and description, was
> "dt-bindings: Add xen,dev-domid property description for xen-grant DMA ops"
>
> Changes V3 -> V4:
> - add Stefano's R-b
> - remove underscore in iommu node name
> - remove consumer example virtio@3000
> - update text for two descriptions
> ---
> .../devicetree/bindings/iommu/xen,grant-dma.yaml | 39 ++++++++++++++++++++++
> 1 file changed, 39 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH V4 5/8] dt-bindings: Add xen,grant-dma IOMMU description for xen-grant DMA ops
@ 2022-06-05 22:45 ` Rob Herring
0 siblings, 0 replies; 30+ messages in thread
From: Rob Herring @ 2022-06-05 22:45 UTC (permalink / raw)
To: Oleksandr Tyshchenko
Cc: linux-kernel, iommu, Joerg Roedel, Michael S. Tsirkin,
Julien Grall, xen-devel, devicetree, Will Deacon, Juergen Gross,
Arnd Bergmann, Stefano Stabellini, Oleksandr Tyshchenko,
Krzysztof Kozlowski, linux-arm-kernel, Christoph Hellwig,
Rob Herring
On Thu, 02 Jun 2022 22:23:50 +0300, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>
> The main purpose of this binding is to communicate Xen specific
> information using generic IOMMU device tree bindings (which is
> a good fit here) rather than introducing a custom property.
>
> Introduce Xen specific IOMMU for the virtualized device (e.g. virtio)
> to be used by Xen grant DMA-mapping layer in the subsequent commit.
>
> The reference to Xen specific IOMMU node using "iommus" property
> indicates that Xen grant mappings need to be enabled for the device,
> and it specifies the ID of the domain where the corresponding backend
> resides. The domid (domain ID) is used as an argument to the Xen grant
> mapping APIs.
>
> This is needed for the option to restrict memory access using Xen grant
> mappings to work which primary goal is to enable using virtio devices
> in Xen guests.
>
> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
> ---
> Changes RFC -> V1:
> - update commit subject/description and text in description
> - move to devicetree/bindings/arm/
>
> Changes V1 -> V2:
> - update text in description
> - change the maintainer of the binding
> - fix validation issue
> - reference xen,dev-domid.yaml schema from virtio/mmio.yaml
>
> Change V2 -> V3:
> - Stefano already gave his Reviewed-by, I dropped it due to the changes (significant)
> - use generic IOMMU device tree bindings instead of custom property
> "xen,dev-domid"
> - change commit subject and description, was
> "dt-bindings: Add xen,dev-domid property description for xen-grant DMA ops"
>
> Changes V3 -> V4:
> - add Stefano's R-b
> - remove underscore in iommu node name
> - remove consumer example virtio@3000
> - update text for two descriptions
> ---
> .../devicetree/bindings/iommu/xen,grant-dma.yaml | 39 ++++++++++++++++++++++
> 1 file changed, 39 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH V4 0/8] virtio: Solution to restrict memory access under Xen using xen-grant DMA-mapping layer
2022-06-02 19:23 ` Oleksandr Tyshchenko
(?)
@ 2022-06-08 5:36 ` Juergen Gross
-1 siblings, 0 replies; 30+ messages in thread
From: Juergen Gross via Virtualization @ 2022-06-08 5:36 UTC (permalink / raw)
To: Oleksandr Tyshchenko, xen-devel, linux-kernel, linux-arm-kernel,
virtualization, x86
Cc: Henry Wang, Stefano Stabellini, Julien Grall, Wei Chen,
Michael S. Tsirkin, Bertrand Marquis, Christoph Hellwig,
Oleksandr Tyshchenko, Jiamei Xie, Kaly Xin, Boris Ostrovsky
[-- Attachment #1.1.1.1: Type: text/plain, Size: 7979 bytes --]
On 02.06.22 21:23, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>
> Hello all.
>
> The purpose of this patch series is to add support for restricting memory access under Xen using specific
> grant table [1] based DMA-mapping layer. Patch series is based on Juergen Gross’ initial work [2] which implies
> using grant references instead of raw guest physical addresses (GPA) for the virtio communications (some
> kind of the software IOMMU).
>
> You can find RFC-V3 patch series (and previous discussions) at [3].
>
> !!! Please note, the only diff between V3 and V4 is in commit #5, also I have collected the acks (commits ##4-7).
>
> The high level idea is to create new Xen’s grant table based DMA-mapping layer for the guest Linux whose main
> purpose is to provide a special 64-bit DMA address which is formed by using the grant reference (for a page
> to be shared with the backend) with offset and setting the highest address bit (this is for the backend to
> be able to distinguish grant ref based DMA address from normal GPA). For this to work we need the ability
> to allocate contiguous (consecutive) grant references for multi-page allocations. And the backend then needs
> to offer VIRTIO_F_ACCESS_PLATFORM and VIRTIO_F_VERSION_1 feature bits (it must support virtio-mmio modern
> transport for 64-bit addresses in the virtqueue).
>
> Xen's grant mapping mechanism is the secure and safe solution to share pages between domains which proven
> to work and works for years (in the context of traditional Xen PV drivers for example). So far, the foreign
> mapping is used for the virtio backend to map and access guest memory. With the foreign mapping, the backend
> is able to map arbitrary pages from the guest memory (or even from Dom0 memory). And as the result, the malicious
> backend which runs in a non-trusted domain can take advantage of this. Instead, with the grant mapping
> the backend is only allowed to map pages which were explicitly granted by the guest before and nothing else.
> According to the discussions in various mainline threads this solution would likely be welcome because it
> perfectly fits in the security model Xen provides.
>
> What is more, the grant table based solution requires zero changes to the Xen hypervisor itself at least
> with virtio-mmio and DT (in comparison, for example, with "foreign mapping + virtio-iommu" solution which would
> require the whole new complex emulator in hypervisor in addition to new functionality/hypercall to pass IOVA
> from the virtio backend running elsewhere to the hypervisor and translate it to the GPA before mapping into
> P2M or denying the foreign mapping request if no corresponding IOVA-GPA mapping present in the IOMMU page table
> for that particular device). We only need to update toolstack to insert "xen,grant-dma" IOMMU node (to be referred
> by the virtio-mmio device using "iommus" property) when creating a guest device-tree (this is an indicator for
> the guest to use Xen grant mappings scheme for that device with the endpoint ID being used as ID of Xen domain
> where the corresponding backend is running, the backend domid is used as an argument to the grant mapping APIs).
> It worth mentioning that toolstack patch is based on non upstreamed yet “Virtio support for toolstack on Arm”
> series which is on review now [4].
>
> Please note the following:
> - Patch series only covers Arm and virtio-mmio (device-tree) for now. To enable the restricted memory access
> feature on Arm the following option should be set:
> CONFIG_XEN_VIRTIO=y
> - Patch series is based on "kernel: add new infrastructure for platform_has() support" patch series which
> is on review now [5]
> - Xen should be built with the following options:
> CONFIG_IOREQ_SERVER=y
> CONFIG_EXPERT=y
>
> Patch series is rebased on "for-linus-5.19" branch [1] with "platform_has()" series applied and tested on Renesas
> Salvator-X board + H3 ES3.0 SoC (Arm64) with standalone userspace (non-Qemu) virtio-mmio based virtio-disk backend
> running in Driver domain and Linux guest running on existing virtio-blk driver (frontend). No issues were observed.
> Guest domain 'reboot/destroy' use-cases work properly.
> I have also tested other use-cases such as assigning several virtio block devices or a mix of virtio and Xen PV block
> devices to the guest. Patch series was build-tested on Arm32 and x86.
>
> 1. Xen changes located at (last patch):
> https://github.com/otyshchenko1/xen/commits/libxl_virtio_next2_1
> 2. Linux changes located at (last 8 patches):
> https://github.com/otyshchenko1/linux/commits/virtio_grant9
> 3. virtio-disk changes located at:
> https://github.com/otyshchenko1/virtio-disk/commits/virtio_grant
>
> Any feedback/help would be highly appreciated.
>
> [1] https://xenbits.xenproject.org/docs/4.16-testing/misc/grant-tables.txt
> [2] https://www.youtube.com/watch?v=IrlEdaIUDPk
> [3] https://lore.kernel.org/xen-devel/1649963973-22879-1-git-send-email-olekstysh@gmail.com/
> https://lore.kernel.org/xen-devel/1650646263-22047-1-git-send-email-olekstysh@gmail.com/
> https://lore.kernel.org/xen-devel/1651947548-4055-1-git-send-email-olekstysh@gmail.com/
> https://lore.kernel.org/xen-devel/1653944417-17168-1-git-send-email-olekstysh@gmail.com/
> [4] https://lore.kernel.org/xen-devel/1654106261-28044-1-git-send-email-olekstysh@gmail.com/
> https://lore.kernel.org/xen-devel/1653944813-17970-1-git-send-email-olekstysh@gmail.com/
> [5] https://lore.kernel.org/xen-devel/20220504155703.13336-1-jgross@suse.com/
> [6] https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git/log/?h=for-linus-5.19
>
> Juergen Gross (3):
> xen/grants: support allocating consecutive grants
> xen/grant-dma-ops: Add option to restrict memory access under Xen
> xen/virtio: Enable restricted memory access using Xen grant mappings
>
> Oleksandr Tyshchenko (5):
> arm/xen: Introduce xen_setup_dma_ops()
> dt-bindings: Add xen,grant-dma IOMMU description for xen-grant DMA ops
> xen/grant-dma-iommu: Introduce stub IOMMU driver
> xen/grant-dma-ops: Retrieve the ID of backend's domain for DT devices
> arm/xen: Assign xen-grant DMA ops for xen-grant DMA devices
>
> .../devicetree/bindings/iommu/xen,grant-dma.yaml | 39 +++
> arch/arm/include/asm/xen/xen-ops.h | 2 +
> arch/arm/mm/dma-mapping.c | 7 +-
> arch/arm/xen/enlighten.c | 2 +
> arch/arm64/include/asm/xen/xen-ops.h | 2 +
> arch/arm64/mm/dma-mapping.c | 7 +-
> arch/x86/xen/enlighten_hvm.c | 2 +
> arch/x86/xen/enlighten_pv.c | 2 +
> drivers/xen/Kconfig | 20 ++
> drivers/xen/Makefile | 2 +
> drivers/xen/grant-dma-iommu.c | 78 +++++
> drivers/xen/grant-dma-ops.c | 345 +++++++++++++++++++++
> drivers/xen/grant-table.c | 251 ++++++++++++---
> include/xen/arm/xen-ops.h | 18 ++
> include/xen/grant_table.h | 4 +
> include/xen/xen-ops.h | 13 +
> include/xen/xen.h | 8 +
> 17 files changed, 756 insertions(+), 46 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml
> create mode 100644 arch/arm/include/asm/xen/xen-ops.h
> create mode 100644 arch/arm64/include/asm/xen/xen-ops.h
> create mode 100644 drivers/xen/grant-dma-iommu.c
> create mode 100644 drivers/xen/grant-dma-ops.c
> create mode 100644 include/xen/arm/xen-ops.h
>
Series pushed to xen/tip.git for-linus-5.19a
Juergen
[-- Attachment #1.1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3149 bytes --]
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH V4 0/8] virtio: Solution to restrict memory access under Xen using xen-grant DMA-mapping layer
@ 2022-06-08 5:36 ` Juergen Gross
0 siblings, 0 replies; 30+ messages in thread
From: Juergen Gross @ 2022-06-08 5:36 UTC (permalink / raw)
To: Oleksandr Tyshchenko, xen-devel, linux-kernel, linux-arm-kernel,
virtualization, x86
Cc: Oleksandr Tyshchenko, Michael S. Tsirkin, Christoph Hellwig,
Stefano Stabellini, Boris Ostrovsky, Julien Grall,
Bertrand Marquis, Wei Chen, Henry Wang, Kaly Xin, Jiamei Xie,
Alex Bennée
[-- Attachment #1.1.1: Type: text/plain, Size: 7979 bytes --]
On 02.06.22 21:23, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>
> Hello all.
>
> The purpose of this patch series is to add support for restricting memory access under Xen using specific
> grant table [1] based DMA-mapping layer. Patch series is based on Juergen Gross’ initial work [2] which implies
> using grant references instead of raw guest physical addresses (GPA) for the virtio communications (some
> kind of the software IOMMU).
>
> You can find RFC-V3 patch series (and previous discussions) at [3].
>
> !!! Please note, the only diff between V3 and V4 is in commit #5, also I have collected the acks (commits ##4-7).
>
> The high level idea is to create new Xen’s grant table based DMA-mapping layer for the guest Linux whose main
> purpose is to provide a special 64-bit DMA address which is formed by using the grant reference (for a page
> to be shared with the backend) with offset and setting the highest address bit (this is for the backend to
> be able to distinguish grant ref based DMA address from normal GPA). For this to work we need the ability
> to allocate contiguous (consecutive) grant references for multi-page allocations. And the backend then needs
> to offer VIRTIO_F_ACCESS_PLATFORM and VIRTIO_F_VERSION_1 feature bits (it must support virtio-mmio modern
> transport for 64-bit addresses in the virtqueue).
>
> Xen's grant mapping mechanism is the secure and safe solution to share pages between domains which proven
> to work and works for years (in the context of traditional Xen PV drivers for example). So far, the foreign
> mapping is used for the virtio backend to map and access guest memory. With the foreign mapping, the backend
> is able to map arbitrary pages from the guest memory (or even from Dom0 memory). And as the result, the malicious
> backend which runs in a non-trusted domain can take advantage of this. Instead, with the grant mapping
> the backend is only allowed to map pages which were explicitly granted by the guest before and nothing else.
> According to the discussions in various mainline threads this solution would likely be welcome because it
> perfectly fits in the security model Xen provides.
>
> What is more, the grant table based solution requires zero changes to the Xen hypervisor itself at least
> with virtio-mmio and DT (in comparison, for example, with "foreign mapping + virtio-iommu" solution which would
> require the whole new complex emulator in hypervisor in addition to new functionality/hypercall to pass IOVA
> from the virtio backend running elsewhere to the hypervisor and translate it to the GPA before mapping into
> P2M or denying the foreign mapping request if no corresponding IOVA-GPA mapping present in the IOMMU page table
> for that particular device). We only need to update toolstack to insert "xen,grant-dma" IOMMU node (to be referred
> by the virtio-mmio device using "iommus" property) when creating a guest device-tree (this is an indicator for
> the guest to use Xen grant mappings scheme for that device with the endpoint ID being used as ID of Xen domain
> where the corresponding backend is running, the backend domid is used as an argument to the grant mapping APIs).
> It worth mentioning that toolstack patch is based on non upstreamed yet “Virtio support for toolstack on Arm”
> series which is on review now [4].
>
> Please note the following:
> - Patch series only covers Arm and virtio-mmio (device-tree) for now. To enable the restricted memory access
> feature on Arm the following option should be set:
> CONFIG_XEN_VIRTIO=y
> - Patch series is based on "kernel: add new infrastructure for platform_has() support" patch series which
> is on review now [5]
> - Xen should be built with the following options:
> CONFIG_IOREQ_SERVER=y
> CONFIG_EXPERT=y
>
> Patch series is rebased on "for-linus-5.19" branch [1] with "platform_has()" series applied and tested on Renesas
> Salvator-X board + H3 ES3.0 SoC (Arm64) with standalone userspace (non-Qemu) virtio-mmio based virtio-disk backend
> running in Driver domain and Linux guest running on existing virtio-blk driver (frontend). No issues were observed.
> Guest domain 'reboot/destroy' use-cases work properly.
> I have also tested other use-cases such as assigning several virtio block devices or a mix of virtio and Xen PV block
> devices to the guest. Patch series was build-tested on Arm32 and x86.
>
> 1. Xen changes located at (last patch):
> https://github.com/otyshchenko1/xen/commits/libxl_virtio_next2_1
> 2. Linux changes located at (last 8 patches):
> https://github.com/otyshchenko1/linux/commits/virtio_grant9
> 3. virtio-disk changes located at:
> https://github.com/otyshchenko1/virtio-disk/commits/virtio_grant
>
> Any feedback/help would be highly appreciated.
>
> [1] https://xenbits.xenproject.org/docs/4.16-testing/misc/grant-tables.txt
> [2] https://www.youtube.com/watch?v=IrlEdaIUDPk
> [3] https://lore.kernel.org/xen-devel/1649963973-22879-1-git-send-email-olekstysh@gmail.com/
> https://lore.kernel.org/xen-devel/1650646263-22047-1-git-send-email-olekstysh@gmail.com/
> https://lore.kernel.org/xen-devel/1651947548-4055-1-git-send-email-olekstysh@gmail.com/
> https://lore.kernel.org/xen-devel/1653944417-17168-1-git-send-email-olekstysh@gmail.com/
> [4] https://lore.kernel.org/xen-devel/1654106261-28044-1-git-send-email-olekstysh@gmail.com/
> https://lore.kernel.org/xen-devel/1653944813-17970-1-git-send-email-olekstysh@gmail.com/
> [5] https://lore.kernel.org/xen-devel/20220504155703.13336-1-jgross@suse.com/
> [6] https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git/log/?h=for-linus-5.19
>
> Juergen Gross (3):
> xen/grants: support allocating consecutive grants
> xen/grant-dma-ops: Add option to restrict memory access under Xen
> xen/virtio: Enable restricted memory access using Xen grant mappings
>
> Oleksandr Tyshchenko (5):
> arm/xen: Introduce xen_setup_dma_ops()
> dt-bindings: Add xen,grant-dma IOMMU description for xen-grant DMA ops
> xen/grant-dma-iommu: Introduce stub IOMMU driver
> xen/grant-dma-ops: Retrieve the ID of backend's domain for DT devices
> arm/xen: Assign xen-grant DMA ops for xen-grant DMA devices
>
> .../devicetree/bindings/iommu/xen,grant-dma.yaml | 39 +++
> arch/arm/include/asm/xen/xen-ops.h | 2 +
> arch/arm/mm/dma-mapping.c | 7 +-
> arch/arm/xen/enlighten.c | 2 +
> arch/arm64/include/asm/xen/xen-ops.h | 2 +
> arch/arm64/mm/dma-mapping.c | 7 +-
> arch/x86/xen/enlighten_hvm.c | 2 +
> arch/x86/xen/enlighten_pv.c | 2 +
> drivers/xen/Kconfig | 20 ++
> drivers/xen/Makefile | 2 +
> drivers/xen/grant-dma-iommu.c | 78 +++++
> drivers/xen/grant-dma-ops.c | 345 +++++++++++++++++++++
> drivers/xen/grant-table.c | 251 ++++++++++++---
> include/xen/arm/xen-ops.h | 18 ++
> include/xen/grant_table.h | 4 +
> include/xen/xen-ops.h | 13 +
> include/xen/xen.h | 8 +
> 17 files changed, 756 insertions(+), 46 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml
> create mode 100644 arch/arm/include/asm/xen/xen-ops.h
> create mode 100644 arch/arm64/include/asm/xen/xen-ops.h
> create mode 100644 drivers/xen/grant-dma-iommu.c
> create mode 100644 drivers/xen/grant-dma-ops.c
> create mode 100644 include/xen/arm/xen-ops.h
>
Series pushed to xen/tip.git for-linus-5.19a
Juergen
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3149 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH V4 0/8] virtio: Solution to restrict memory access under Xen using xen-grant DMA-mapping layer
@ 2022-06-08 5:36 ` Juergen Gross
0 siblings, 0 replies; 30+ messages in thread
From: Juergen Gross @ 2022-06-08 5:36 UTC (permalink / raw)
To: Oleksandr Tyshchenko, xen-devel, linux-kernel, linux-arm-kernel,
virtualization, x86
Cc: Oleksandr Tyshchenko, Michael S. Tsirkin, Christoph Hellwig,
Stefano Stabellini, Boris Ostrovsky, Julien Grall,
Bertrand Marquis, Wei Chen, Henry Wang, Kaly Xin, Jiamei Xie,
Alex Bennée
[-- Attachment #1.1.1.1: Type: text/plain, Size: 7979 bytes --]
On 02.06.22 21:23, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>
> Hello all.
>
> The purpose of this patch series is to add support for restricting memory access under Xen using specific
> grant table [1] based DMA-mapping layer. Patch series is based on Juergen Gross’ initial work [2] which implies
> using grant references instead of raw guest physical addresses (GPA) for the virtio communications (some
> kind of the software IOMMU).
>
> You can find RFC-V3 patch series (and previous discussions) at [3].
>
> !!! Please note, the only diff between V3 and V4 is in commit #5, also I have collected the acks (commits ##4-7).
>
> The high level idea is to create new Xen’s grant table based DMA-mapping layer for the guest Linux whose main
> purpose is to provide a special 64-bit DMA address which is formed by using the grant reference (for a page
> to be shared with the backend) with offset and setting the highest address bit (this is for the backend to
> be able to distinguish grant ref based DMA address from normal GPA). For this to work we need the ability
> to allocate contiguous (consecutive) grant references for multi-page allocations. And the backend then needs
> to offer VIRTIO_F_ACCESS_PLATFORM and VIRTIO_F_VERSION_1 feature bits (it must support virtio-mmio modern
> transport for 64-bit addresses in the virtqueue).
>
> Xen's grant mapping mechanism is the secure and safe solution to share pages between domains which proven
> to work and works for years (in the context of traditional Xen PV drivers for example). So far, the foreign
> mapping is used for the virtio backend to map and access guest memory. With the foreign mapping, the backend
> is able to map arbitrary pages from the guest memory (or even from Dom0 memory). And as the result, the malicious
> backend which runs in a non-trusted domain can take advantage of this. Instead, with the grant mapping
> the backend is only allowed to map pages which were explicitly granted by the guest before and nothing else.
> According to the discussions in various mainline threads this solution would likely be welcome because it
> perfectly fits in the security model Xen provides.
>
> What is more, the grant table based solution requires zero changes to the Xen hypervisor itself at least
> with virtio-mmio and DT (in comparison, for example, with "foreign mapping + virtio-iommu" solution which would
> require the whole new complex emulator in hypervisor in addition to new functionality/hypercall to pass IOVA
> from the virtio backend running elsewhere to the hypervisor and translate it to the GPA before mapping into
> P2M or denying the foreign mapping request if no corresponding IOVA-GPA mapping present in the IOMMU page table
> for that particular device). We only need to update toolstack to insert "xen,grant-dma" IOMMU node (to be referred
> by the virtio-mmio device using "iommus" property) when creating a guest device-tree (this is an indicator for
> the guest to use Xen grant mappings scheme for that device with the endpoint ID being used as ID of Xen domain
> where the corresponding backend is running, the backend domid is used as an argument to the grant mapping APIs).
> It worth mentioning that toolstack patch is based on non upstreamed yet “Virtio support for toolstack on Arm”
> series which is on review now [4].
>
> Please note the following:
> - Patch series only covers Arm and virtio-mmio (device-tree) for now. To enable the restricted memory access
> feature on Arm the following option should be set:
> CONFIG_XEN_VIRTIO=y
> - Patch series is based on "kernel: add new infrastructure for platform_has() support" patch series which
> is on review now [5]
> - Xen should be built with the following options:
> CONFIG_IOREQ_SERVER=y
> CONFIG_EXPERT=y
>
> Patch series is rebased on "for-linus-5.19" branch [1] with "platform_has()" series applied and tested on Renesas
> Salvator-X board + H3 ES3.0 SoC (Arm64) with standalone userspace (non-Qemu) virtio-mmio based virtio-disk backend
> running in Driver domain and Linux guest running on existing virtio-blk driver (frontend). No issues were observed.
> Guest domain 'reboot/destroy' use-cases work properly.
> I have also tested other use-cases such as assigning several virtio block devices or a mix of virtio and Xen PV block
> devices to the guest. Patch series was build-tested on Arm32 and x86.
>
> 1. Xen changes located at (last patch):
> https://github.com/otyshchenko1/xen/commits/libxl_virtio_next2_1
> 2. Linux changes located at (last 8 patches):
> https://github.com/otyshchenko1/linux/commits/virtio_grant9
> 3. virtio-disk changes located at:
> https://github.com/otyshchenko1/virtio-disk/commits/virtio_grant
>
> Any feedback/help would be highly appreciated.
>
> [1] https://xenbits.xenproject.org/docs/4.16-testing/misc/grant-tables.txt
> [2] https://www.youtube.com/watch?v=IrlEdaIUDPk
> [3] https://lore.kernel.org/xen-devel/1649963973-22879-1-git-send-email-olekstysh@gmail.com/
> https://lore.kernel.org/xen-devel/1650646263-22047-1-git-send-email-olekstysh@gmail.com/
> https://lore.kernel.org/xen-devel/1651947548-4055-1-git-send-email-olekstysh@gmail.com/
> https://lore.kernel.org/xen-devel/1653944417-17168-1-git-send-email-olekstysh@gmail.com/
> [4] https://lore.kernel.org/xen-devel/1654106261-28044-1-git-send-email-olekstysh@gmail.com/
> https://lore.kernel.org/xen-devel/1653944813-17970-1-git-send-email-olekstysh@gmail.com/
> [5] https://lore.kernel.org/xen-devel/20220504155703.13336-1-jgross@suse.com/
> [6] https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git/log/?h=for-linus-5.19
>
> Juergen Gross (3):
> xen/grants: support allocating consecutive grants
> xen/grant-dma-ops: Add option to restrict memory access under Xen
> xen/virtio: Enable restricted memory access using Xen grant mappings
>
> Oleksandr Tyshchenko (5):
> arm/xen: Introduce xen_setup_dma_ops()
> dt-bindings: Add xen,grant-dma IOMMU description for xen-grant DMA ops
> xen/grant-dma-iommu: Introduce stub IOMMU driver
> xen/grant-dma-ops: Retrieve the ID of backend's domain for DT devices
> arm/xen: Assign xen-grant DMA ops for xen-grant DMA devices
>
> .../devicetree/bindings/iommu/xen,grant-dma.yaml | 39 +++
> arch/arm/include/asm/xen/xen-ops.h | 2 +
> arch/arm/mm/dma-mapping.c | 7 +-
> arch/arm/xen/enlighten.c | 2 +
> arch/arm64/include/asm/xen/xen-ops.h | 2 +
> arch/arm64/mm/dma-mapping.c | 7 +-
> arch/x86/xen/enlighten_hvm.c | 2 +
> arch/x86/xen/enlighten_pv.c | 2 +
> drivers/xen/Kconfig | 20 ++
> drivers/xen/Makefile | 2 +
> drivers/xen/grant-dma-iommu.c | 78 +++++
> drivers/xen/grant-dma-ops.c | 345 +++++++++++++++++++++
> drivers/xen/grant-table.c | 251 ++++++++++++---
> include/xen/arm/xen-ops.h | 18 ++
> include/xen/grant_table.h | 4 +
> include/xen/xen-ops.h | 13 +
> include/xen/xen.h | 8 +
> 17 files changed, 756 insertions(+), 46 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml
> create mode 100644 arch/arm/include/asm/xen/xen-ops.h
> create mode 100644 arch/arm64/include/asm/xen/xen-ops.h
> create mode 100644 drivers/xen/grant-dma-iommu.c
> create mode 100644 drivers/xen/grant-dma-ops.c
> create mode 100644 include/xen/arm/xen-ops.h
>
Series pushed to xen/tip.git for-linus-5.19a
Juergen
[-- Attachment #1.1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3149 bytes --]
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH V4 0/8] virtio: Solution to restrict memory access under Xen using xen-grant DMA-mapping layer
2022-06-02 19:23 ` Oleksandr Tyshchenko
(?)
@ 2022-06-15 6:23 ` Viresh Kumar
-1 siblings, 0 replies; 30+ messages in thread
From: Viresh Kumar @ 2022-06-15 6:23 UTC (permalink / raw)
To: Oleksandr Tyshchenko
Cc: xen-devel, Linux Kernel Mailing List, Linux ARM, virtualization,
x86, Oleksandr Tyshchenko, Michael S. Tsirkin, Christoph Hellwig,
Stefano Stabellini, Boris Ostrovsky, Juergen Gross, Julien Grall,
Bertrand Marquis, Wei Chen, Henry Wang, Kaly Xin, Jiamei Xie,
Alex Bennée, Vincent Guittot, Mathieu Poirier
Hi Oleksandr,
On Mon, Jun 6, 2022 at 10:16 AM Oleksandr Tyshchenko
<olekstysh@gmail.com> wrote:
> The high level idea is to create new Xen’s grant table based DMA-mapping layer for the guest Linux whose main
> purpose is to provide a special 64-bit DMA address which is formed by using the grant reference (for a page
> to be shared with the backend) with offset and setting the highest address bit (this is for the backend to
> be able to distinguish grant ref based DMA address from normal GPA). For this to work we need the ability
> to allocate contiguous (consecutive) grant references for multi-page allocations. And the backend then needs
> to offer VIRTIO_F_ACCESS_PLATFORM and VIRTIO_F_VERSION_1 feature bits (it must support virtio-mmio modern
> transport for 64-bit addresses in the virtqueue).
I was trying your series, from Linus's tree now and started seeing
boot failures,
failed to mount rootfs. And the reason probably is these messages:
[ 1.222498] virtio_scsi virtio1: device must provide VIRTIO_F_ACCESS_PLATFORM
[ 1.316334] virtio_net virtio0: device must provide VIRTIO_F_ACCESS_PLATFORM
I understand from your email that the backends need to offer
VIRTIO_F_ACCESS_PLATFORM flag now, but should this requirement be a
bit soft ? I mean shouldn't we allow both types of backends to run with the same
kernel, ones that offer this feature and others that don't ? The ones that don't
offer the feature, should continue to work like they used to, i.e.
without the restricted
memory access feature.
I am testing Xen currently with help of Qemu over my x86 desktop and
these backends
(scsi and net) are part of QEMU itself I think, and I don't really
want to go and make the
change there.
Thanks.
--
Viresh
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH V4 0/8] virtio: Solution to restrict memory access under Xen using xen-grant DMA-mapping layer
@ 2022-06-15 6:23 ` Viresh Kumar
0 siblings, 0 replies; 30+ messages in thread
From: Viresh Kumar @ 2022-06-15 6:23 UTC (permalink / raw)
To: Oleksandr Tyshchenko
Cc: Juergen Gross, Henry Wang, Stefano Stabellini, Julien Grall,
Mathieu Poirier, Wei Chen, Michael S. Tsirkin, x86,
Linux Kernel Mailing List, virtualization, Christoph Hellwig,
Oleksandr Tyshchenko, Jiamei Xie, Vincent Guittot, Kaly Xin,
xen-devel, Boris Ostrovsky, Bertrand Marquis, Linux ARM
Hi Oleksandr,
On Mon, Jun 6, 2022 at 10:16 AM Oleksandr Tyshchenko
<olekstysh@gmail.com> wrote:
> The high level idea is to create new Xen’s grant table based DMA-mapping layer for the guest Linux whose main
> purpose is to provide a special 64-bit DMA address which is formed by using the grant reference (for a page
> to be shared with the backend) with offset and setting the highest address bit (this is for the backend to
> be able to distinguish grant ref based DMA address from normal GPA). For this to work we need the ability
> to allocate contiguous (consecutive) grant references for multi-page allocations. And the backend then needs
> to offer VIRTIO_F_ACCESS_PLATFORM and VIRTIO_F_VERSION_1 feature bits (it must support virtio-mmio modern
> transport for 64-bit addresses in the virtqueue).
I was trying your series, from Linus's tree now and started seeing
boot failures,
failed to mount rootfs. And the reason probably is these messages:
[ 1.222498] virtio_scsi virtio1: device must provide VIRTIO_F_ACCESS_PLATFORM
[ 1.316334] virtio_net virtio0: device must provide VIRTIO_F_ACCESS_PLATFORM
I understand from your email that the backends need to offer
VIRTIO_F_ACCESS_PLATFORM flag now, but should this requirement be a
bit soft ? I mean shouldn't we allow both types of backends to run with the same
kernel, ones that offer this feature and others that don't ? The ones that don't
offer the feature, should continue to work like they used to, i.e.
without the restricted
memory access feature.
I am testing Xen currently with help of Qemu over my x86 desktop and
these backends
(scsi and net) are part of QEMU itself I think, and I don't really
want to go and make the
change there.
Thanks.
--
Viresh
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH V4 0/8] virtio: Solution to restrict memory access under Xen using xen-grant DMA-mapping layer
@ 2022-06-15 6:23 ` Viresh Kumar
0 siblings, 0 replies; 30+ messages in thread
From: Viresh Kumar @ 2022-06-15 6:23 UTC (permalink / raw)
To: Oleksandr Tyshchenko
Cc: xen-devel, Linux Kernel Mailing List, Linux ARM, virtualization,
x86, Oleksandr Tyshchenko, Michael S. Tsirkin, Christoph Hellwig,
Stefano Stabellini, Boris Ostrovsky, Juergen Gross, Julien Grall,
Bertrand Marquis, Wei Chen, Henry Wang, Kaly Xin, Jiamei Xie,
Alex Bennée, Vincent Guittot, Mathieu Poirier
Hi Oleksandr,
On Mon, Jun 6, 2022 at 10:16 AM Oleksandr Tyshchenko
<olekstysh@gmail.com> wrote:
> The high level idea is to create new Xen’s grant table based DMA-mapping layer for the guest Linux whose main
> purpose is to provide a special 64-bit DMA address which is formed by using the grant reference (for a page
> to be shared with the backend) with offset and setting the highest address bit (this is for the backend to
> be able to distinguish grant ref based DMA address from normal GPA). For this to work we need the ability
> to allocate contiguous (consecutive) grant references for multi-page allocations. And the backend then needs
> to offer VIRTIO_F_ACCESS_PLATFORM and VIRTIO_F_VERSION_1 feature bits (it must support virtio-mmio modern
> transport for 64-bit addresses in the virtqueue).
I was trying your series, from Linus's tree now and started seeing
boot failures,
failed to mount rootfs. And the reason probably is these messages:
[ 1.222498] virtio_scsi virtio1: device must provide VIRTIO_F_ACCESS_PLATFORM
[ 1.316334] virtio_net virtio0: device must provide VIRTIO_F_ACCESS_PLATFORM
I understand from your email that the backends need to offer
VIRTIO_F_ACCESS_PLATFORM flag now, but should this requirement be a
bit soft ? I mean shouldn't we allow both types of backends to run with the same
kernel, ones that offer this feature and others that don't ? The ones that don't
offer the feature, should continue to work like they used to, i.e.
without the restricted
memory access feature.
I am testing Xen currently with help of Qemu over my x86 desktop and
these backends
(scsi and net) are part of QEMU itself I think, and I don't really
want to go and make the
change there.
Thanks.
--
Viresh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH V4 0/8] virtio: Solution to restrict memory access under Xen using xen-grant DMA-mapping layer
2022-06-15 6:23 ` Viresh Kumar
@ 2022-06-15 12:41 ` Oleksandr
-1 siblings, 0 replies; 30+ messages in thread
From: Oleksandr @ 2022-06-15 12:41 UTC (permalink / raw)
To: Viresh Kumar
Cc: xen-devel, Linux Kernel Mailing List, Linux ARM, virtualization,
x86, Oleksandr Tyshchenko, Michael S. Tsirkin, Christoph Hellwig,
Stefano Stabellini, Boris Ostrovsky, Juergen Gross, Julien Grall,
Bertrand Marquis, Wei Chen, Henry Wang, Kaly Xin, Jiamei Xie,
Alex Bennée, Vincent Guittot, Mathieu Poirier
On 15.06.22 09:23, Viresh Kumar wrote:
> Hi Oleksandr,
Hello Viresh
>
> On Mon, Jun 6, 2022 at 10:16 AM Oleksandr Tyshchenko
> <olekstysh@gmail.com> wrote:
>> The high level idea is to create new Xen’s grant table based DMA-mapping layer for the guest Linux whose main
>> purpose is to provide a special 64-bit DMA address which is formed by using the grant reference (for a page
>> to be shared with the backend) with offset and setting the highest address bit (this is for the backend to
>> be able to distinguish grant ref based DMA address from normal GPA). For this to work we need the ability
>> to allocate contiguous (consecutive) grant references for multi-page allocations. And the backend then needs
>> to offer VIRTIO_F_ACCESS_PLATFORM and VIRTIO_F_VERSION_1 feature bits (it must support virtio-mmio modern
>> transport for 64-bit addresses in the virtqueue).
> I was trying your series, from Linus's tree now and started seeing
> boot failures,
> failed to mount rootfs. And the reason probably is these messages:
>
> [ 1.222498] virtio_scsi virtio1: device must provide VIRTIO_F_ACCESS_PLATFORM
> [ 1.316334] virtio_net virtio0: device must provide VIRTIO_F_ACCESS_PLATFORM
>
> I understand from your email that the backends need to offer
> VIRTIO_F_ACCESS_PLATFORM flag now, but should this requirement be a
> bit soft ? I mean shouldn't we allow both types of backends to run with the same
> kernel, ones that offer this feature and others that don't ? The ones that don't
> offer the feature, should continue to work like they used to, i.e.
> without the restricted
> memory access feature.
> I am testing Xen currently with help of Qemu over my x86 desktop and
> these backends
> (scsi and net) are part of QEMU itself I think, and I don't really
> want to go and make the
> change there.
Thank you for testing on x86.
I assume your guest type in HVM. Within current series the
PLATFORM_VIRTIO_RESTRICTED_MEM_ACCESS is set for *all* type of Xen
guests if CONFIG_XEN_VIRTIO is enabled.
I have to admit that from the very beginning it could be possible to
configure for PV and HVM guests separately [1] because the usage of
grant mappings for virtio is mandatory for paravirtualized guest, but
not strictly necessary for the fully virtualized guests (if the backends
are in Dom0). But it was decided to drop these extra options (including
XEN_HVM_VIRTIO_GRANT) and leave only single one CONFIG_XEN_VIRTIO.
I see that Juergen has already pushed a fix.
Sorry for the inconvenience.
[1]
https://lore.kernel.org/xen-devel/1649963973-22879-3-git-send-email-olekstysh@gmail.com/
>
> Thanks.
>
> --
> Viresh
--
Regards,
Oleksandr Tyshchenko
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH V4 0/8] virtio: Solution to restrict memory access under Xen using xen-grant DMA-mapping layer
@ 2022-06-15 12:41 ` Oleksandr
0 siblings, 0 replies; 30+ messages in thread
From: Oleksandr @ 2022-06-15 12:41 UTC (permalink / raw)
To: Viresh Kumar
Cc: xen-devel, Linux Kernel Mailing List, Linux ARM, virtualization,
x86, Oleksandr Tyshchenko, Michael S. Tsirkin, Christoph Hellwig,
Stefano Stabellini, Boris Ostrovsky, Juergen Gross, Julien Grall,
Bertrand Marquis, Wei Chen, Henry Wang, Kaly Xin, Jiamei Xie,
Alex Bennée, Vincent Guittot, Mathieu Poirier
On 15.06.22 09:23, Viresh Kumar wrote:
> Hi Oleksandr,
Hello Viresh
>
> On Mon, Jun 6, 2022 at 10:16 AM Oleksandr Tyshchenko
> <olekstysh@gmail.com> wrote:
>> The high level idea is to create new Xen’s grant table based DMA-mapping layer for the guest Linux whose main
>> purpose is to provide a special 64-bit DMA address which is formed by using the grant reference (for a page
>> to be shared with the backend) with offset and setting the highest address bit (this is for the backend to
>> be able to distinguish grant ref based DMA address from normal GPA). For this to work we need the ability
>> to allocate contiguous (consecutive) grant references for multi-page allocations. And the backend then needs
>> to offer VIRTIO_F_ACCESS_PLATFORM and VIRTIO_F_VERSION_1 feature bits (it must support virtio-mmio modern
>> transport for 64-bit addresses in the virtqueue).
> I was trying your series, from Linus's tree now and started seeing
> boot failures,
> failed to mount rootfs. And the reason probably is these messages:
>
> [ 1.222498] virtio_scsi virtio1: device must provide VIRTIO_F_ACCESS_PLATFORM
> [ 1.316334] virtio_net virtio0: device must provide VIRTIO_F_ACCESS_PLATFORM
>
> I understand from your email that the backends need to offer
> VIRTIO_F_ACCESS_PLATFORM flag now, but should this requirement be a
> bit soft ? I mean shouldn't we allow both types of backends to run with the same
> kernel, ones that offer this feature and others that don't ? The ones that don't
> offer the feature, should continue to work like they used to, i.e.
> without the restricted
> memory access feature.
> I am testing Xen currently with help of Qemu over my x86 desktop and
> these backends
> (scsi and net) are part of QEMU itself I think, and I don't really
> want to go and make the
> change there.
Thank you for testing on x86.
I assume your guest type in HVM. Within current series the
PLATFORM_VIRTIO_RESTRICTED_MEM_ACCESS is set for *all* type of Xen
guests if CONFIG_XEN_VIRTIO is enabled.
I have to admit that from the very beginning it could be possible to
configure for PV and HVM guests separately [1] because the usage of
grant mappings for virtio is mandatory for paravirtualized guest, but
not strictly necessary for the fully virtualized guests (if the backends
are in Dom0). But it was decided to drop these extra options (including
XEN_HVM_VIRTIO_GRANT) and leave only single one CONFIG_XEN_VIRTIO.
I see that Juergen has already pushed a fix.
Sorry for the inconvenience.
[1]
https://lore.kernel.org/xen-devel/1649963973-22879-3-git-send-email-olekstysh@gmail.com/
>
> Thanks.
>
> --
> Viresh
--
Regards,
Oleksandr Tyshchenko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2022-06-15 12:42 UTC | newest]
Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-02 19:23 [PATCH V4 0/8] virtio: Solution to restrict memory access under Xen using xen-grant DMA-mapping layer Oleksandr Tyshchenko
2022-06-02 19:23 ` Oleksandr Tyshchenko
2022-06-02 19:23 ` [PATCH V4 1/8] arm/xen: Introduce xen_setup_dma_ops() Oleksandr Tyshchenko
2022-06-02 19:23 ` Oleksandr Tyshchenko
2022-06-02 19:23 ` [PATCH V4 2/8] xen/grants: support allocating consecutive grants Oleksandr Tyshchenko
2022-06-02 19:23 ` Oleksandr Tyshchenko
2022-06-02 19:23 ` [PATCH V4 3/8] xen/grant-dma-ops: Add option to restrict memory access under Xen Oleksandr Tyshchenko
2022-06-02 19:23 ` Oleksandr Tyshchenko
2022-06-02 19:23 ` [PATCH V4 4/8] xen/virtio: Enable restricted memory access using Xen grant mappings Oleksandr Tyshchenko
2022-06-02 19:23 ` Oleksandr Tyshchenko
2022-06-02 19:23 ` [PATCH V4 5/8] dt-bindings: Add xen,grant-dma IOMMU description for xen-grant DMA ops Oleksandr Tyshchenko
2022-06-02 19:23 ` Oleksandr Tyshchenko
2022-06-02 19:23 ` [PATCH V4 5/8] dt-bindings: Add xen, grant-dma " Oleksandr Tyshchenko
2022-06-05 22:45 ` [PATCH V4 5/8] dt-bindings: Add xen,grant-dma " Rob Herring
2022-06-05 22:45 ` Rob Herring
2022-06-05 22:45 ` Rob Herring
2022-06-02 19:23 ` [PATCH V4 6/8] xen/grant-dma-iommu: Introduce stub IOMMU driver Oleksandr Tyshchenko
2022-06-02 19:23 ` Oleksandr Tyshchenko
2022-06-02 19:23 ` [PATCH V4 7/8] xen/grant-dma-ops: Retrieve the ID of backend's domain for DT devices Oleksandr Tyshchenko
2022-06-02 19:23 ` Oleksandr Tyshchenko
2022-06-02 19:23 ` [PATCH V4 8/8] arm/xen: Assign xen-grant DMA ops for xen-grant DMA devices Oleksandr Tyshchenko
2022-06-02 19:23 ` Oleksandr Tyshchenko
2022-06-08 5:36 ` [PATCH V4 0/8] virtio: Solution to restrict memory access under Xen using xen-grant DMA-mapping layer Juergen Gross via Virtualization
2022-06-08 5:36 ` Juergen Gross
2022-06-08 5:36 ` Juergen Gross
2022-06-15 6:23 ` Viresh Kumar
2022-06-15 6:23 ` Viresh Kumar
2022-06-15 6:23 ` Viresh Kumar
2022-06-15 12:41 ` Oleksandr
2022-06-15 12:41 ` Oleksandr
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.