* [PATCH V1 0/6] virtio: Solution to restrict memory access under Xen using xen-grant DMA-mapping layer
@ 2022-04-22 16:50 ` Oleksandr Tyshchenko
0 siblings, 0 replies; 79+ messages in thread
From: Oleksandr Tyshchenko @ 2022-04-22 16:50 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 patch series (and previous discussions) at [3].
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 a new "xen,dev-domid" property to
the virtio-mmio device node when creating a guest device-tree (this is an indicator for the guest to use grants
and the ID of Xen domain where the corresponding backend resides, it 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
- Some callbacks in xen-grant DMA-mapping layer (alloc_pages/free_pages, etc) are not implemented yet as they
are not needed/used in the first prototype
- Xen should be built with the following options:
CONFIG_IOREQ_SERVER=y
CONFIG_EXPERT=y
Patch series is rebased on Linux 5.18-rc2 tag 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_next
2. Linux changes located at:
https://github.com/otyshchenko1/linux/commits/virtio_grant6
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/
[4] https://lore.kernel.org/xen-devel/1649442065-8332-1-git-send-email-olekstysh@gmail.com/
Juergen Gross (2):
xen/grants: support allocating consecutive grants
xen/virtio: Add option to restrict memory access under Xen
Oleksandr Tyshchenko (4):
arm/xen: Introduce xen_setup_dma_ops()
dt-bindings: Add xen,dev-domid property description for xen-grant DMA
ops
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/arm/xen,dev-domid.yaml | 37 +++
arch/arm/include/asm/xen/xen-ops.h | 1 +
arch/arm/mm/dma-mapping.c | 7 +-
arch/arm/xen/enlighten.c | 8 +
arch/arm64/include/asm/xen/xen-ops.h | 1 +
arch/arm64/mm/dma-mapping.c | 7 +-
arch/x86/mm/init.c | 11 +
arch/x86/mm/mem_encrypt.c | 5 -
drivers/xen/Kconfig | 15 +
drivers/xen/Makefile | 1 +
drivers/xen/grant-dma-ops.c | 328 +++++++++++++++++++++
drivers/xen/grant-table.c | 238 +++++++++++++--
include/xen/arm/xen-ops.h | 20 ++
include/xen/grant_table.h | 4 +
include/xen/xen-ops.h | 13 +
include/xen/xen.h | 5 +
16 files changed, 654 insertions(+), 47 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/xen,dev-domid.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-ops.c
create mode 100644 include/xen/arm/xen-ops.h
--
2.7.4
^ permalink raw reply [flat|nested] 79+ messages in thread
* [PATCH V1 0/6] virtio: Solution to restrict memory access under Xen using xen-grant DMA-mapping layer
@ 2022-04-22 16:50 ` Oleksandr Tyshchenko
0 siblings, 0 replies; 79+ messages in thread
From: Oleksandr Tyshchenko @ 2022-04-22 16:50 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 patch series (and previous discussions) at [3].
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 a new "xen,dev-domid" property to
the virtio-mmio device node when creating a guest device-tree (this is an indicator for the guest to use grants
and the ID of Xen domain where the corresponding backend resides, it 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
- Some callbacks in xen-grant DMA-mapping layer (alloc_pages/free_pages, etc) are not implemented yet as they
are not needed/used in the first prototype
- Xen should be built with the following options:
CONFIG_IOREQ_SERVER=y
CONFIG_EXPERT=y
Patch series is rebased on Linux 5.18-rc2 tag 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_next
2. Linux changes located at:
https://github.com/otyshchenko1/linux/commits/virtio_grant6
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/
[4] https://lore.kernel.org/xen-devel/1649442065-8332-1-git-send-email-olekstysh@gmail.com/
Juergen Gross (2):
xen/grants: support allocating consecutive grants
xen/virtio: Add option to restrict memory access under Xen
Oleksandr Tyshchenko (4):
arm/xen: Introduce xen_setup_dma_ops()
dt-bindings: Add xen,dev-domid property description for xen-grant DMA
ops
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/arm/xen,dev-domid.yaml | 37 +++
arch/arm/include/asm/xen/xen-ops.h | 1 +
arch/arm/mm/dma-mapping.c | 7 +-
arch/arm/xen/enlighten.c | 8 +
arch/arm64/include/asm/xen/xen-ops.h | 1 +
arch/arm64/mm/dma-mapping.c | 7 +-
arch/x86/mm/init.c | 11 +
arch/x86/mm/mem_encrypt.c | 5 -
drivers/xen/Kconfig | 15 +
drivers/xen/Makefile | 1 +
drivers/xen/grant-dma-ops.c | 328 +++++++++++++++++++++
drivers/xen/grant-table.c | 238 +++++++++++++--
include/xen/arm/xen-ops.h | 20 ++
include/xen/grant_table.h | 4 +
include/xen/xen-ops.h | 13 +
include/xen/xen.h | 5 +
16 files changed, 654 insertions(+), 47 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/xen,dev-domid.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-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] 79+ messages in thread
* [PATCH V1 1/6] arm/xen: Introduce xen_setup_dma_ops()
2022-04-22 16:50 ` Oleksandr Tyshchenko
@ 2022-04-22 16:50 ` Oleksandr Tyshchenko
-1 siblings, 0 replies; 79+ messages in thread
From: Oleksandr Tyshchenko @ 2022-04-22 16:50 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,
Logan Gunthorpe, David Hildenbrand, Martin Oliveira, Kees Cook,
Jean-Philippe Brucker, 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>
---
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
---
arch/arm/include/asm/xen/xen-ops.h | 1 +
arch/arm/mm/dma-mapping.c | 7 ++-----
arch/arm64/include/asm/xen/xen-ops.h | 1 +
arch/arm64/mm/dma-mapping.c | 7 ++-----
include/xen/arm/xen-ops.h | 15 +++++++++++++++
5 files changed, 21 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..8d2fa24
--- /dev/null
+++ b/arch/arm/include/asm/xen/xen-ops.h
@@ -0,0 +1 @@
+#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..8d2fa24
--- /dev/null
+++ b/arch/arm64/include/asm/xen/xen-ops.h
@@ -0,0 +1 @@
+#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] 79+ messages in thread
* [PATCH V1 1/6] arm/xen: Introduce xen_setup_dma_ops()
@ 2022-04-22 16:50 ` Oleksandr Tyshchenko
0 siblings, 0 replies; 79+ messages in thread
From: Oleksandr Tyshchenko @ 2022-04-22 16:50 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,
Logan Gunthorpe, David Hildenbrand, Martin Oliveira, Kees Cook,
Jean-Philippe Brucker, 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>
---
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
---
arch/arm/include/asm/xen/xen-ops.h | 1 +
arch/arm/mm/dma-mapping.c | 7 ++-----
arch/arm64/include/asm/xen/xen-ops.h | 1 +
arch/arm64/mm/dma-mapping.c | 7 ++-----
include/xen/arm/xen-ops.h | 15 +++++++++++++++
5 files changed, 21 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..8d2fa24
--- /dev/null
+++ b/arch/arm/include/asm/xen/xen-ops.h
@@ -0,0 +1 @@
+#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..8d2fa24
--- /dev/null
+++ b/arch/arm64/include/asm/xen/xen-ops.h
@@ -0,0 +1 @@
+#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] 79+ messages in thread
* [PATCH V1 2/6] xen/grants: support allocating consecutive grants
2022-04-22 16:50 ` Oleksandr Tyshchenko
@ 2022-04-22 16:50 ` Oleksandr Tyshchenko
-1 siblings, 0 replies; 79+ messages in thread
From: Oleksandr Tyshchenko @ 2022-04-22 16:50 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>
---
Changes RFC -> V1:
- no changes
---
drivers/xen/grant-table.c | 238 +++++++++++++++++++++++++++++++++++++++-------
include/xen/grant_table.h | 4 +
2 files changed, 210 insertions(+), 32 deletions(-)
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 8ccccac..1b458c0 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>
@@ -72,9 +73,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);
@@ -170,16 +194,111 @@ 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;
+ }
+
+ 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;
@@ -206,17 +325,48 @@ 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;
- 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:
@@ -448,23 +598,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);
@@ -478,6 +636,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);
@@ -570,16 +746,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,7 +1597,6 @@ int gnttab_init(void)
int i;
unsigned long max_nr_grant_frames;
unsigned int max_nr_glist_frames, nr_glist_frames;
- unsigned int nr_init_grefs;
int ret;
gnttab_request_version();
@@ -1452,6 +1624,13 @@ int gnttab_init(void)
}
}
+ i = gnttab_interface->grefs_per_grant_frame * max_nr_grant_frames;
+ gnttab_free_bitmap = bitmap_zalloc(i, 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)
@@ -1462,15 +1641,9 @@ int gnttab_init(void)
goto ini_nomem;
}
- nr_init_grefs = nr_grant_frames *
- gnttab_interface->grefs_per_grant_frame;
-
- for (i = 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 - NR_RESERVED_ENTRIES;
- gnttab_free_head = NR_RESERVED_ENTRIES;
+ gnttab_set_free(NR_RESERVED_ENTRIES, gnttab_size - NR_RESERVED_ENTRIES);
printk("Grant table initialized\n");
return 0;
@@ -1479,6 +1652,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 dfd5bf3..d815e1d 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -129,10 +129,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] 79+ messages in thread
* [PATCH V1 2/6] xen/grants: support allocating consecutive grants
@ 2022-04-22 16:50 ` Oleksandr Tyshchenko
0 siblings, 0 replies; 79+ messages in thread
From: Oleksandr Tyshchenko @ 2022-04-22 16:50 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>
---
Changes RFC -> V1:
- no changes
---
drivers/xen/grant-table.c | 238 +++++++++++++++++++++++++++++++++++++++-------
include/xen/grant_table.h | 4 +
2 files changed, 210 insertions(+), 32 deletions(-)
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 8ccccac..1b458c0 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>
@@ -72,9 +73,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);
@@ -170,16 +194,111 @@ 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;
+ }
+
+ 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;
@@ -206,17 +325,48 @@ 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;
- 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:
@@ -448,23 +598,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);
@@ -478,6 +636,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);
@@ -570,16 +746,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,7 +1597,6 @@ int gnttab_init(void)
int i;
unsigned long max_nr_grant_frames;
unsigned int max_nr_glist_frames, nr_glist_frames;
- unsigned int nr_init_grefs;
int ret;
gnttab_request_version();
@@ -1452,6 +1624,13 @@ int gnttab_init(void)
}
}
+ i = gnttab_interface->grefs_per_grant_frame * max_nr_grant_frames;
+ gnttab_free_bitmap = bitmap_zalloc(i, 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)
@@ -1462,15 +1641,9 @@ int gnttab_init(void)
goto ini_nomem;
}
- nr_init_grefs = nr_grant_frames *
- gnttab_interface->grefs_per_grant_frame;
-
- for (i = 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 - NR_RESERVED_ENTRIES;
- gnttab_free_head = NR_RESERVED_ENTRIES;
+ gnttab_set_free(NR_RESERVED_ENTRIES, gnttab_size - NR_RESERVED_ENTRIES);
printk("Grant table initialized\n");
return 0;
@@ -1479,6 +1652,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 dfd5bf3..d815e1d 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -129,10 +129,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] 79+ messages in thread
* [PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen
2022-04-22 16:50 ` Oleksandr Tyshchenko
@ 2022-04-22 16:51 ` Oleksandr Tyshchenko
-1 siblings, 0 replies; 79+ messages in thread
From: Oleksandr Tyshchenko @ 2022-04-22 16:51 UTC (permalink / raw)
To: xen-devel, x86, linux-kernel, linux-arm-kernel
Cc: Juergen Gross, Dave Hansen, Andy Lutomirski, Peter Zijlstra,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin,
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.
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.
As this also requires providing arch_has_restricted_virtio_memory_access
implementation, switch from a pure stub to a real function on Arm
and combine with existing implementation for the SEV guests on x86.
Add the needed functionality by providing a special set of DMA ops
handling the needed grant operations for the I/O pages.
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
---
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
---
arch/arm/xen/enlighten.c | 8 ++
arch/x86/mm/init.c | 11 ++
arch/x86/mm/mem_encrypt.c | 5 -
drivers/xen/Kconfig | 15 +++
drivers/xen/Makefile | 1 +
drivers/xen/grant-dma-ops.c | 317 ++++++++++++++++++++++++++++++++++++++++++++
include/xen/xen-ops.h | 8 ++
include/xen/xen.h | 5 +
8 files changed, 365 insertions(+), 5 deletions(-)
create mode 100644 drivers/xen/grant-dma-ops.c
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index ec5b082..49af493 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -409,6 +409,14 @@ int __init arch_xen_unpopulated_init(struct resource **res)
}
#endif
+#ifdef CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS
+int arch_has_restricted_virtio_memory_access(void)
+{
+ return xen_has_restricted_virtio_memory_access();
+}
+EXPORT_SYMBOL_GPL(arch_has_restricted_virtio_memory_access);
+#endif
+
static void __init xen_dt_guest_init(void)
{
struct device_node *xen_node;
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index d8cfce2..fe84a3e 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -8,6 +8,8 @@
#include <linux/kmemleak.h>
#include <linux/sched/task.h>
+#include <xen/xen.h>
+
#include <asm/set_memory.h>
#include <asm/e820/api.h>
#include <asm/init.h>
@@ -1065,3 +1067,12 @@ unsigned long max_swapfile_size(void)
return pages;
}
#endif
+
+#ifdef CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS
+int arch_has_restricted_virtio_memory_access(void)
+{
+ return (xen_has_restricted_virtio_memory_access() ||
+ cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT));
+}
+EXPORT_SYMBOL_GPL(arch_has_restricted_virtio_memory_access);
+#endif
diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
index 50d2099..dda020f 100644
--- a/arch/x86/mm/mem_encrypt.c
+++ b/arch/x86/mm/mem_encrypt.c
@@ -77,8 +77,3 @@ void __init mem_encrypt_init(void)
print_mem_encrypt_feature_info();
}
-int arch_has_restricted_virtio_memory_access(void)
-{
- return cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT);
-}
-EXPORT_SYMBOL_GPL(arch_has_restricted_virtio_memory_access);
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 120d32f..b95581f 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -335,4 +335,19 @@ 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
+
+config XEN_VIRTIO
+ bool "Xen virtio support"
+ default n
+ depends on VIRTIO
+ select ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS
+ 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).
+
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..0e69aa8
--- /dev/null
+++ b/drivers/xen/grant-dma-ops.c
@@ -0,0 +1,317 @@
+// 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/pci.h>
+#include <linux/pfn.h>
+#include <xen/xen.h>
+#include <xen/grant_table.h>
+
+struct xen_grant_dma_data {
+ /* The ID of backend domain */
+ domid_t dev_domid;
+ /* Is device behaving sane? */
+ bool broken;
+ struct device *dev;
+ struct list_head list;
+};
+
+static LIST_HEAD(xen_grant_dma_devices);
+static DEFINE_SPINLOCK(xen_grant_dma_lock);
+
+#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 = NULL;
+ bool found = false;
+
+ spin_lock(&xen_grant_dma_lock);
+
+ list_for_each_entry(data, &xen_grant_dma_devices, list) {
+ if (data->dev == dev) {
+ found = true;
+ break;
+ }
+ }
+
+ spin_unlock(&xen_grant_dma_lock);
+
+ return found ? data : NULL;
+}
+
+/*
+ * 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->dev_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)
+{
+ WARN_ONCE(1, "xen_grant_dma_alloc_pages size %zu\n", size);
+ return NULL;
+}
+
+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)
+{
+ WARN_ONCE(1, "xen_grant_dma_free_pages size %zu\n", size);
+}
+
+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;
+
+ BUG_ON(dir == DMA_NONE);
+
+ 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->dev_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;
+
+ BUG_ON(dir == DMA_NONE);
+
+ 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;
+
+ BUG_ON(dir == DMA_NONE);
+
+ 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;
+
+ BUG_ON(dir == DMA_NONE);
+
+ 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;
+ uint32_t dev_domid;
+
+ data = find_xen_grant_dma_data(dev);
+ if (data) {
+ dev_err(dev, "Xen grant DMA data is already created\n");
+ return;
+ }
+
+ /* XXX The dom0 is hardcoded as the backend domain for now */
+ dev_domid = 0;
+
+ data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+ if (!data) {
+ dev_err(dev, "Сannot allocate Xen grant DMA data\n");
+ goto err;
+ }
+ data->dev_domid = dev_domid;
+ data->dev = dev;
+
+ spin_lock(&xen_grant_dma_lock);
+ list_add(&data->list, &xen_grant_dma_devices);
+ spin_unlock(&xen_grant_dma_lock);
+
+ dev->dma_ops = &xen_grant_dma_ops;
+
+ return;
+
+err:
+ dev_err(dev, "Сannot set up Xen grant DMA ops, retain platform DMA ops\n");
+}
+EXPORT_SYMBOL_GPL(xen_grant_setup_dma_ops);
+
+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 */
diff --git a/include/xen/xen.h b/include/xen/xen.h
index a99bab8..fe6e6bb 100644
--- a/include/xen/xen.h
+++ b/include/xen/xen.h
@@ -52,6 +52,11 @@ bool xen_biovec_phys_mergeable(const struct bio_vec *vec1,
extern u64 xen_saved_max_mem_size;
#endif
+static inline int xen_has_restricted_virtio_memory_access(void)
+{
+ return IS_ENABLED(CONFIG_XEN_VIRTIO) && xen_domain();
+}
+
#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] 79+ messages in thread
* [PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen
@ 2022-04-22 16:51 ` Oleksandr Tyshchenko
0 siblings, 0 replies; 79+ messages in thread
From: Oleksandr Tyshchenko @ 2022-04-22 16:51 UTC (permalink / raw)
To: xen-devel, x86, linux-kernel, linux-arm-kernel
Cc: Juergen Gross, Dave Hansen, Andy Lutomirski, Peter Zijlstra,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin,
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.
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.
As this also requires providing arch_has_restricted_virtio_memory_access
implementation, switch from a pure stub to a real function on Arm
and combine with existing implementation for the SEV guests on x86.
Add the needed functionality by providing a special set of DMA ops
handling the needed grant operations for the I/O pages.
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
---
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
---
arch/arm/xen/enlighten.c | 8 ++
arch/x86/mm/init.c | 11 ++
arch/x86/mm/mem_encrypt.c | 5 -
drivers/xen/Kconfig | 15 +++
drivers/xen/Makefile | 1 +
drivers/xen/grant-dma-ops.c | 317 ++++++++++++++++++++++++++++++++++++++++++++
include/xen/xen-ops.h | 8 ++
include/xen/xen.h | 5 +
8 files changed, 365 insertions(+), 5 deletions(-)
create mode 100644 drivers/xen/grant-dma-ops.c
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index ec5b082..49af493 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -409,6 +409,14 @@ int __init arch_xen_unpopulated_init(struct resource **res)
}
#endif
+#ifdef CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS
+int arch_has_restricted_virtio_memory_access(void)
+{
+ return xen_has_restricted_virtio_memory_access();
+}
+EXPORT_SYMBOL_GPL(arch_has_restricted_virtio_memory_access);
+#endif
+
static void __init xen_dt_guest_init(void)
{
struct device_node *xen_node;
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index d8cfce2..fe84a3e 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -8,6 +8,8 @@
#include <linux/kmemleak.h>
#include <linux/sched/task.h>
+#include <xen/xen.h>
+
#include <asm/set_memory.h>
#include <asm/e820/api.h>
#include <asm/init.h>
@@ -1065,3 +1067,12 @@ unsigned long max_swapfile_size(void)
return pages;
}
#endif
+
+#ifdef CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS
+int arch_has_restricted_virtio_memory_access(void)
+{
+ return (xen_has_restricted_virtio_memory_access() ||
+ cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT));
+}
+EXPORT_SYMBOL_GPL(arch_has_restricted_virtio_memory_access);
+#endif
diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
index 50d2099..dda020f 100644
--- a/arch/x86/mm/mem_encrypt.c
+++ b/arch/x86/mm/mem_encrypt.c
@@ -77,8 +77,3 @@ void __init mem_encrypt_init(void)
print_mem_encrypt_feature_info();
}
-int arch_has_restricted_virtio_memory_access(void)
-{
- return cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT);
-}
-EXPORT_SYMBOL_GPL(arch_has_restricted_virtio_memory_access);
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 120d32f..b95581f 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -335,4 +335,19 @@ 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
+
+config XEN_VIRTIO
+ bool "Xen virtio support"
+ default n
+ depends on VIRTIO
+ select ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS
+ 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).
+
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..0e69aa8
--- /dev/null
+++ b/drivers/xen/grant-dma-ops.c
@@ -0,0 +1,317 @@
+// 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/pci.h>
+#include <linux/pfn.h>
+#include <xen/xen.h>
+#include <xen/grant_table.h>
+
+struct xen_grant_dma_data {
+ /* The ID of backend domain */
+ domid_t dev_domid;
+ /* Is device behaving sane? */
+ bool broken;
+ struct device *dev;
+ struct list_head list;
+};
+
+static LIST_HEAD(xen_grant_dma_devices);
+static DEFINE_SPINLOCK(xen_grant_dma_lock);
+
+#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 = NULL;
+ bool found = false;
+
+ spin_lock(&xen_grant_dma_lock);
+
+ list_for_each_entry(data, &xen_grant_dma_devices, list) {
+ if (data->dev == dev) {
+ found = true;
+ break;
+ }
+ }
+
+ spin_unlock(&xen_grant_dma_lock);
+
+ return found ? data : NULL;
+}
+
+/*
+ * 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->dev_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)
+{
+ WARN_ONCE(1, "xen_grant_dma_alloc_pages size %zu\n", size);
+ return NULL;
+}
+
+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)
+{
+ WARN_ONCE(1, "xen_grant_dma_free_pages size %zu\n", size);
+}
+
+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;
+
+ BUG_ON(dir == DMA_NONE);
+
+ 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->dev_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;
+
+ BUG_ON(dir == DMA_NONE);
+
+ 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;
+
+ BUG_ON(dir == DMA_NONE);
+
+ 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;
+
+ BUG_ON(dir == DMA_NONE);
+
+ 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;
+ uint32_t dev_domid;
+
+ data = find_xen_grant_dma_data(dev);
+ if (data) {
+ dev_err(dev, "Xen grant DMA data is already created\n");
+ return;
+ }
+
+ /* XXX The dom0 is hardcoded as the backend domain for now */
+ dev_domid = 0;
+
+ data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+ if (!data) {
+ dev_err(dev, "Сannot allocate Xen grant DMA data\n");
+ goto err;
+ }
+ data->dev_domid = dev_domid;
+ data->dev = dev;
+
+ spin_lock(&xen_grant_dma_lock);
+ list_add(&data->list, &xen_grant_dma_devices);
+ spin_unlock(&xen_grant_dma_lock);
+
+ dev->dma_ops = &xen_grant_dma_ops;
+
+ return;
+
+err:
+ dev_err(dev, "Сannot set up Xen grant DMA ops, retain platform DMA ops\n");
+}
+EXPORT_SYMBOL_GPL(xen_grant_setup_dma_ops);
+
+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 */
diff --git a/include/xen/xen.h b/include/xen/xen.h
index a99bab8..fe6e6bb 100644
--- a/include/xen/xen.h
+++ b/include/xen/xen.h
@@ -52,6 +52,11 @@ bool xen_biovec_phys_mergeable(const struct bio_vec *vec1,
extern u64 xen_saved_max_mem_size;
#endif
+static inline int xen_has_restricted_virtio_memory_access(void)
+{
+ return IS_ENABLED(CONFIG_XEN_VIRTIO) && xen_domain();
+}
+
#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] 79+ messages in thread
* [PATCH V1 4/6] dt-bindings: Add xen,dev-domid property description for xen-grant DMA ops
2022-04-22 16:50 ` Oleksandr Tyshchenko
@ 2022-04-22 16:51 ` Oleksandr Tyshchenko
-1 siblings, 0 replies; 79+ messages in thread
From: Oleksandr Tyshchenko @ 2022-04-22 16:51 UTC (permalink / raw)
To: xen-devel, virtualization, devicetree, linux-kernel, linux-arm-kernel
Cc: Oleksandr Tyshchenko, Jason Wang, Rob Herring,
Krzysztof Kozlowski, Julien Grall, Juergen Gross,
Stefano Stabellini, Michael S. Tsirkin, Christoph Hellwig
From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Introduce Xen specific binding for the virtualized device (e.g. virtio)
to be used by Xen grant DMA-mapping layer in the subsequent commit.
This binding indicates that Xen grant mappings scheme needs to be
enabled for the device which DT node contains that property and specifies
the ID of Xen domain where the corresponding backend resides. The ID
(domid) is used as an argument to the 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>
---
Changes RFC -> V1:
- update commit subject/description and text in description
- move to devicetree/bindings/arm/
---
.../devicetree/bindings/arm/xen,dev-domid.yaml | 37 ++++++++++++++++++++++
1 file changed, 37 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
diff --git a/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
new file mode 100644
index 00000000..ef0f747
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/xen,dev-domid.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xen specific binding for the virtualized device (e.g. virtio)
+
+maintainers:
+ - Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
+
+select: true
+
+description:
+ This binding indicates that Xen grant mappings scheme needs to be enabled
+ for that device and specifies the ID of Xen domain where the corresponding
+ device (backend) resides. This is needed for the option to restrict memory
+ access using Xen grant mappings to work.
+
+properties:
+ xen,dev-domid:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ The domid (domain ID) of the domain where the device (backend) is running.
+
+additionalProperties: true
+
+examples:
+ - |
+ virtio_block@3000 {
+ compatible = "virtio,mmio";
+ reg = <0x3000 0x100>;
+ interrupts = <41>;
+
+ /* The device is located in Xen domain with ID 1 */
+ xen,dev-domid = <1>;
+ };
--
2.7.4
^ permalink raw reply related [flat|nested] 79+ messages in thread
* [PATCH V1 4/6] dt-bindings: Add xen, dev-domid property description for xen-grant DMA ops
@ 2022-04-22 16:51 ` Oleksandr Tyshchenko
0 siblings, 0 replies; 79+ messages in thread
From: Oleksandr Tyshchenko @ 2022-04-22 16:51 UTC (permalink / raw)
To: xen-devel, virtualization, devicetree, linux-kernel, linux-arm-kernel
Cc: Oleksandr Tyshchenko, Jason Wang, Rob Herring,
Krzysztof Kozlowski, Julien Grall, Juergen Gross,
Stefano Stabellini, Michael S. Tsirkin, Christoph Hellwig
From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Introduce Xen specific binding for the virtualized device (e.g. virtio)
to be used by Xen grant DMA-mapping layer in the subsequent commit.
This binding indicates that Xen grant mappings scheme needs to be
enabled for the device which DT node contains that property and specifies
the ID of Xen domain where the corresponding backend resides. The ID
(domid) is used as an argument to the 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>
---
Changes RFC -> V1:
- update commit subject/description and text in description
- move to devicetree/bindings/arm/
---
.../devicetree/bindings/arm/xen,dev-domid.yaml | 37 ++++++++++++++++++++++
1 file changed, 37 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
diff --git a/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
new file mode 100644
index 00000000..ef0f747
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/xen,dev-domid.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xen specific binding for the virtualized device (e.g. virtio)
+
+maintainers:
+ - Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
+
+select: true
+
+description:
+ This binding indicates that Xen grant mappings scheme needs to be enabled
+ for that device and specifies the ID of Xen domain where the corresponding
+ device (backend) resides. This is needed for the option to restrict memory
+ access using Xen grant mappings to work.
+
+properties:
+ xen,dev-domid:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ The domid (domain ID) of the domain where the device (backend) is running.
+
+additionalProperties: true
+
+examples:
+ - |
+ virtio_block@3000 {
+ compatible = "virtio,mmio";
+ reg = <0x3000 0x100>;
+ interrupts = <41>;
+
+ /* The device is located in Xen domain with ID 1 */
+ xen,dev-domid = <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] 79+ messages in thread
* [PATCH V1 5/6] xen/grant-dma-ops: Retrieve the ID of backend's domain for DT devices
2022-04-22 16:50 ` Oleksandr Tyshchenko
@ 2022-04-22 16:51 ` Oleksandr Tyshchenko
-1 siblings, 0 replies; 79+ messages in thread
From: Oleksandr Tyshchenko @ 2022-04-22 16:51 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 recently introduced "xen,dev-domid" property
in the device node as a clear indicator of enabling Xen grant
mappings scheme for that device and read the ID of Xen domain where
the corresponding backend resides. The ID (domid) is used as
an argument to the Xen grant mapping APIs.
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>
---
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
---
drivers/xen/grant-dma-ops.c | 25 ++++++++++++++++++-------
include/xen/xen-ops.h | 5 +++++
2 files changed, 23 insertions(+), 7 deletions(-)
diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c
index 0e69aa8..70d5d77 100644
--- a/drivers/xen/grant-dma-ops.c
+++ b/drivers/xen/grant-dma-ops.c
@@ -66,11 +66,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,
@@ -277,6 +272,16 @@ 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)
+{
+ /* XXX Handle only DT devices for now */
+ if (!dev->of_node)
+ return false;
+
+ return of_property_read_bool(dev->of_node, "xen,dev-domid");
+}
+EXPORT_SYMBOL_GPL(xen_is_grant_dma_device);
+
void xen_grant_setup_dma_ops(struct device *dev)
{
struct xen_grant_dma_data *data;
@@ -288,8 +293,14 @@ void xen_grant_setup_dma_ops(struct device *dev)
return;
}
- /* XXX The dom0 is hardcoded as the backend domain for now */
- dev_domid = 0;
+ /* XXX ACPI and PCI devices unsupported for now */
+ if (dev_is_pci(dev) || !dev->of_node)
+ goto err;
+
+ if (of_property_read_u32(dev->of_node, "xen,dev-domid", &dev_domid)) {
+ dev_err(dev, "xen,dev-domid property is not present\n");
+ goto err;
+ }
data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
if (!data) {
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] 79+ messages in thread
* [PATCH V1 5/6] xen/grant-dma-ops: Retrieve the ID of backend's domain for DT devices
@ 2022-04-22 16:51 ` Oleksandr Tyshchenko
0 siblings, 0 replies; 79+ messages in thread
From: Oleksandr Tyshchenko @ 2022-04-22 16:51 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 recently introduced "xen,dev-domid" property
in the device node as a clear indicator of enabling Xen grant
mappings scheme for that device and read the ID of Xen domain where
the corresponding backend resides. The ID (domid) is used as
an argument to the Xen grant mapping APIs.
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>
---
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
---
drivers/xen/grant-dma-ops.c | 25 ++++++++++++++++++-------
include/xen/xen-ops.h | 5 +++++
2 files changed, 23 insertions(+), 7 deletions(-)
diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c
index 0e69aa8..70d5d77 100644
--- a/drivers/xen/grant-dma-ops.c
+++ b/drivers/xen/grant-dma-ops.c
@@ -66,11 +66,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,
@@ -277,6 +272,16 @@ 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)
+{
+ /* XXX Handle only DT devices for now */
+ if (!dev->of_node)
+ return false;
+
+ return of_property_read_bool(dev->of_node, "xen,dev-domid");
+}
+EXPORT_SYMBOL_GPL(xen_is_grant_dma_device);
+
void xen_grant_setup_dma_ops(struct device *dev)
{
struct xen_grant_dma_data *data;
@@ -288,8 +293,14 @@ void xen_grant_setup_dma_ops(struct device *dev)
return;
}
- /* XXX The dom0 is hardcoded as the backend domain for now */
- dev_domid = 0;
+ /* XXX ACPI and PCI devices unsupported for now */
+ if (dev_is_pci(dev) || !dev->of_node)
+ goto err;
+
+ if (of_property_read_u32(dev->of_node, "xen,dev-domid", &dev_domid)) {
+ dev_err(dev, "xen,dev-domid property is not present\n");
+ goto err;
+ }
data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
if (!data) {
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] 79+ messages in thread
* [PATCH V1 6/6] arm/xen: Assign xen-grant DMA ops for xen-grant DMA devices
2022-04-22 16:50 ` Oleksandr Tyshchenko
@ 2022-04-22 16:51 ` Oleksandr Tyshchenko
-1 siblings, 0 replies; 79+ messages in thread
From: Oleksandr Tyshchenko @ 2022-04-22 16:51 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>
As the main (and single at the moment) purpose of xen-grant
DMA devices is to enable using virtio devices in Xen guests
in a safe manner, assign xen-grant DMA ops only if restricted
access to the guest memory is enabled.
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
---
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
---
include/xen/arm/xen-ops.h | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/include/xen/arm/xen-ops.h b/include/xen/arm/xen-ops.h
index 288deb1..26954e5 100644
--- a/include/xen/arm/xen-ops.h
+++ b/include/xen/arm/xen-ops.h
@@ -2,12 +2,17 @@
#ifndef _ASM_ARM_XEN_OPS_H
#define _ASM_ARM_XEN_OPS_H
+#include <linux/virtio_config.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 (arch_has_restricted_virtio_memory_access() &&
+ 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] 79+ messages in thread
* [PATCH V1 6/6] arm/xen: Assign xen-grant DMA ops for xen-grant DMA devices
@ 2022-04-22 16:51 ` Oleksandr Tyshchenko
0 siblings, 0 replies; 79+ messages in thread
From: Oleksandr Tyshchenko @ 2022-04-22 16:51 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>
As the main (and single at the moment) purpose of xen-grant
DMA devices is to enable using virtio devices in Xen guests
in a safe manner, assign xen-grant DMA ops only if restricted
access to the guest memory is enabled.
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
---
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
---
include/xen/arm/xen-ops.h | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/include/xen/arm/xen-ops.h b/include/xen/arm/xen-ops.h
index 288deb1..26954e5 100644
--- a/include/xen/arm/xen-ops.h
+++ b/include/xen/arm/xen-ops.h
@@ -2,12 +2,17 @@
#ifndef _ASM_ARM_XEN_OPS_H
#define _ASM_ARM_XEN_OPS_H
+#include <linux/virtio_config.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 (arch_has_restricted_virtio_memory_access() &&
+ 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] 79+ messages in thread
* Re: [PATCH V1 1/6] arm/xen: Introduce xen_setup_dma_ops()
2022-04-22 16:50 ` Oleksandr Tyshchenko
@ 2022-04-22 22:59 ` Stefano Stabellini
-1 siblings, 0 replies; 79+ messages in thread
From: Stefano Stabellini @ 2022-04-22 22:59 UTC (permalink / raw)
To: Oleksandr Tyshchenko
Cc: xen-devel, linux-kernel, linux-arm-kernel, Oleksandr Tyshchenko,
Stefano Stabellini, Russell King, Catalin Marinas, Will Deacon,
Boris Ostrovsky, Juergen Gross, Logan Gunthorpe,
David Hildenbrand, Martin Oliveira, Kees Cook,
Jean-Philippe Brucker, Julien Grall, Michael S. Tsirkin,
Christoph Hellwig
On Fri, 22 Apr 2022, Oleksandr Tyshchenko wrote:
> 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>
> ---
> 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
> ---
> arch/arm/include/asm/xen/xen-ops.h | 1 +
> arch/arm/mm/dma-mapping.c | 7 ++-----
> arch/arm64/include/asm/xen/xen-ops.h | 1 +
> arch/arm64/mm/dma-mapping.c | 7 ++-----
> include/xen/arm/xen-ops.h | 15 +++++++++++++++
> 5 files changed, 21 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..8d2fa24
> --- /dev/null
> +++ b/arch/arm/include/asm/xen/xen-ops.h
> @@ -0,0 +1 @@
> +#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..8d2fa24
> --- /dev/null
> +++ b/arch/arm64/include/asm/xen/xen-ops.h
> @@ -0,0 +1 @@
> +#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 [flat|nested] 79+ messages in thread
* Re: [PATCH V1 1/6] arm/xen: Introduce xen_setup_dma_ops()
@ 2022-04-22 22:59 ` Stefano Stabellini
0 siblings, 0 replies; 79+ messages in thread
From: Stefano Stabellini @ 2022-04-22 22:59 UTC (permalink / raw)
To: Oleksandr Tyshchenko
Cc: xen-devel, linux-kernel, linux-arm-kernel, Oleksandr Tyshchenko,
Stefano Stabellini, Russell King, Catalin Marinas, Will Deacon,
Boris Ostrovsky, Juergen Gross, Logan Gunthorpe,
David Hildenbrand, Martin Oliveira, Kees Cook,
Jean-Philippe Brucker, Julien Grall, Michael S. Tsirkin,
Christoph Hellwig
On Fri, 22 Apr 2022, Oleksandr Tyshchenko wrote:
> 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>
> ---
> 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
> ---
> arch/arm/include/asm/xen/xen-ops.h | 1 +
> arch/arm/mm/dma-mapping.c | 7 ++-----
> arch/arm64/include/asm/xen/xen-ops.h | 1 +
> arch/arm64/mm/dma-mapping.c | 7 ++-----
> include/xen/arm/xen-ops.h | 15 +++++++++++++++
> 5 files changed, 21 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..8d2fa24
> --- /dev/null
> +++ b/arch/arm/include/asm/xen/xen-ops.h
> @@ -0,0 +1 @@
> +#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..8d2fa24
> --- /dev/null
> +++ b/arch/arm64/include/asm/xen/xen-ops.h
> @@ -0,0 +1 @@
> +#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
>
_______________________________________________
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] 79+ messages in thread
* Re: [PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen
2022-04-22 16:51 ` Oleksandr Tyshchenko
@ 2022-04-22 23:00 ` Stefano Stabellini
-1 siblings, 0 replies; 79+ messages in thread
From: Stefano Stabellini @ 2022-04-22 23:00 UTC (permalink / raw)
To: Oleksandr Tyshchenko
Cc: xen-devel, x86, linux-kernel, linux-arm-kernel, Juergen Gross,
Dave Hansen, Andy Lutomirski, Peter Zijlstra, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H. Peter Anvin, Boris Ostrovsky,
Stefano Stabellini, Julien Grall, Oleksandr Tyshchenko,
Michael S. Tsirkin, Christoph Hellwig
[-- Attachment #1: Type: text/plain, Size: 15965 bytes --]
On Fri, 22 Apr 2022, Oleksandr Tyshchenko wrote:
> 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.
>
> 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.
>
> As this also requires providing arch_has_restricted_virtio_memory_access
> implementation, switch from a pure stub to a real function on Arm
> and combine with existing implementation for the SEV guests on x86.
>
> Add the needed functionality by providing a special set of DMA ops
> handling the needed grant operations for the I/O pages.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
There are a couple of minor things that checkpatch.pl reports, but aside
from those the patch looks fine to me.
> ---
> 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
> ---
> arch/arm/xen/enlighten.c | 8 ++
> arch/x86/mm/init.c | 11 ++
> arch/x86/mm/mem_encrypt.c | 5 -
> drivers/xen/Kconfig | 15 +++
> drivers/xen/Makefile | 1 +
> drivers/xen/grant-dma-ops.c | 317 ++++++++++++++++++++++++++++++++++++++++++++
> include/xen/xen-ops.h | 8 ++
> include/xen/xen.h | 5 +
> 8 files changed, 365 insertions(+), 5 deletions(-)
> create mode 100644 drivers/xen/grant-dma-ops.c
>
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index ec5b082..49af493 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -409,6 +409,14 @@ int __init arch_xen_unpopulated_init(struct resource **res)
> }
> #endif
>
> +#ifdef CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS
> +int arch_has_restricted_virtio_memory_access(void)
> +{
> + return xen_has_restricted_virtio_memory_access();
> +}
> +EXPORT_SYMBOL_GPL(arch_has_restricted_virtio_memory_access);
> +#endif
> +
> static void __init xen_dt_guest_init(void)
> {
> struct device_node *xen_node;
> diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
> index d8cfce2..fe84a3e 100644
> --- a/arch/x86/mm/init.c
> +++ b/arch/x86/mm/init.c
> @@ -8,6 +8,8 @@
> #include <linux/kmemleak.h>
> #include <linux/sched/task.h>
>
> +#include <xen/xen.h>
> +
> #include <asm/set_memory.h>
> #include <asm/e820/api.h>
> #include <asm/init.h>
> @@ -1065,3 +1067,12 @@ unsigned long max_swapfile_size(void)
> return pages;
> }
> #endif
> +
> +#ifdef CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS
> +int arch_has_restricted_virtio_memory_access(void)
> +{
> + return (xen_has_restricted_virtio_memory_access() ||
> + cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT));
> +}
> +EXPORT_SYMBOL_GPL(arch_has_restricted_virtio_memory_access);
> +#endif
> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
> index 50d2099..dda020f 100644
> --- a/arch/x86/mm/mem_encrypt.c
> +++ b/arch/x86/mm/mem_encrypt.c
> @@ -77,8 +77,3 @@ void __init mem_encrypt_init(void)
> print_mem_encrypt_feature_info();
> }
>
> -int arch_has_restricted_virtio_memory_access(void)
> -{
> - return cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT);
> -}
> -EXPORT_SYMBOL_GPL(arch_has_restricted_virtio_memory_access);
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index 120d32f..b95581f 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -335,4 +335,19 @@ 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
> +
> +config XEN_VIRTIO
> + bool "Xen virtio support"
> + default n
> + depends on VIRTIO
> + select ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS
> + 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).
> +
> 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..0e69aa8
> --- /dev/null
> +++ b/drivers/xen/grant-dma-ops.c
> @@ -0,0 +1,317 @@
> +// 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/pci.h>
> +#include <linux/pfn.h>
> +#include <xen/xen.h>
> +#include <xen/grant_table.h>
> +
> +struct xen_grant_dma_data {
> + /* The ID of backend domain */
> + domid_t dev_domid;
> + /* Is device behaving sane? */
> + bool broken;
> + struct device *dev;
> + struct list_head list;
> +};
> +
> +static LIST_HEAD(xen_grant_dma_devices);
> +static DEFINE_SPINLOCK(xen_grant_dma_lock);
> +
> +#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 = NULL;
> + bool found = false;
> +
> + spin_lock(&xen_grant_dma_lock);
> +
> + list_for_each_entry(data, &xen_grant_dma_devices, list) {
> + if (data->dev == dev) {
> + found = true;
> + break;
> + }
> + }
> +
> + spin_unlock(&xen_grant_dma_lock);
> +
> + return found ? data : NULL;
> +}
> +
> +/*
> + * 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->dev_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)
> +{
> + WARN_ONCE(1, "xen_grant_dma_alloc_pages size %zu\n", size);
> + return NULL;
> +}
> +
> +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)
> +{
> + WARN_ONCE(1, "xen_grant_dma_free_pages size %zu\n", size);
> +}
> +
> +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;
> +
> + BUG_ON(dir == DMA_NONE);
> +
> + 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->dev_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;
> +
> + BUG_ON(dir == DMA_NONE);
> +
> + 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;
> +
> + BUG_ON(dir == DMA_NONE);
> +
> + 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;
> +
> + BUG_ON(dir == DMA_NONE);
> +
> + 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;
> + uint32_t dev_domid;
> +
> + data = find_xen_grant_dma_data(dev);
> + if (data) {
> + dev_err(dev, "Xen grant DMA data is already created\n");
> + return;
> + }
> +
> + /* XXX The dom0 is hardcoded as the backend domain for now */
> + dev_domid = 0;
> +
> + data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> + if (!data) {
> + dev_err(dev, "Сannot allocate Xen grant DMA data\n");
> + goto err;
> + }
> + data->dev_domid = dev_domid;
> + data->dev = dev;
> +
> + spin_lock(&xen_grant_dma_lock);
> + list_add(&data->list, &xen_grant_dma_devices);
> + spin_unlock(&xen_grant_dma_lock);
> +
> + dev->dma_ops = &xen_grant_dma_ops;
> +
> + return;
> +
> +err:
> + dev_err(dev, "Сannot set up Xen grant DMA ops, retain platform DMA ops\n");
> +}
> +EXPORT_SYMBOL_GPL(xen_grant_setup_dma_ops);
> +
> +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 */
> diff --git a/include/xen/xen.h b/include/xen/xen.h
> index a99bab8..fe6e6bb 100644
> --- a/include/xen/xen.h
> +++ b/include/xen/xen.h
> @@ -52,6 +52,11 @@ bool xen_biovec_phys_mergeable(const struct bio_vec *vec1,
> extern u64 xen_saved_max_mem_size;
> #endif
>
> +static inline int xen_has_restricted_virtio_memory_access(void)
> +{
> + return IS_ENABLED(CONFIG_XEN_VIRTIO) && xen_domain();
> +}
> +
> #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 [flat|nested] 79+ messages in thread
* Re: [PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen
@ 2022-04-22 23:00 ` Stefano Stabellini
0 siblings, 0 replies; 79+ messages in thread
From: Stefano Stabellini @ 2022-04-22 23:00 UTC (permalink / raw)
To: Oleksandr Tyshchenko
Cc: xen-devel, x86, linux-kernel, linux-arm-kernel, Juergen Gross,
Dave Hansen, Andy Lutomirski, Peter Zijlstra, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H. Peter Anvin, Boris Ostrovsky,
Stefano Stabellini, Julien Grall, Oleksandr Tyshchenko,
Michael S. Tsirkin, Christoph Hellwig
[-- Attachment #1: Type: text/plain, Size: 15965 bytes --]
On Fri, 22 Apr 2022, Oleksandr Tyshchenko wrote:
> 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.
>
> 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.
>
> As this also requires providing arch_has_restricted_virtio_memory_access
> implementation, switch from a pure stub to a real function on Arm
> and combine with existing implementation for the SEV guests on x86.
>
> Add the needed functionality by providing a special set of DMA ops
> handling the needed grant operations for the I/O pages.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
There are a couple of minor things that checkpatch.pl reports, but aside
from those the patch looks fine to me.
> ---
> 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
> ---
> arch/arm/xen/enlighten.c | 8 ++
> arch/x86/mm/init.c | 11 ++
> arch/x86/mm/mem_encrypt.c | 5 -
> drivers/xen/Kconfig | 15 +++
> drivers/xen/Makefile | 1 +
> drivers/xen/grant-dma-ops.c | 317 ++++++++++++++++++++++++++++++++++++++++++++
> include/xen/xen-ops.h | 8 ++
> include/xen/xen.h | 5 +
> 8 files changed, 365 insertions(+), 5 deletions(-)
> create mode 100644 drivers/xen/grant-dma-ops.c
>
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index ec5b082..49af493 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -409,6 +409,14 @@ int __init arch_xen_unpopulated_init(struct resource **res)
> }
> #endif
>
> +#ifdef CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS
> +int arch_has_restricted_virtio_memory_access(void)
> +{
> + return xen_has_restricted_virtio_memory_access();
> +}
> +EXPORT_SYMBOL_GPL(arch_has_restricted_virtio_memory_access);
> +#endif
> +
> static void __init xen_dt_guest_init(void)
> {
> struct device_node *xen_node;
> diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
> index d8cfce2..fe84a3e 100644
> --- a/arch/x86/mm/init.c
> +++ b/arch/x86/mm/init.c
> @@ -8,6 +8,8 @@
> #include <linux/kmemleak.h>
> #include <linux/sched/task.h>
>
> +#include <xen/xen.h>
> +
> #include <asm/set_memory.h>
> #include <asm/e820/api.h>
> #include <asm/init.h>
> @@ -1065,3 +1067,12 @@ unsigned long max_swapfile_size(void)
> return pages;
> }
> #endif
> +
> +#ifdef CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS
> +int arch_has_restricted_virtio_memory_access(void)
> +{
> + return (xen_has_restricted_virtio_memory_access() ||
> + cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT));
> +}
> +EXPORT_SYMBOL_GPL(arch_has_restricted_virtio_memory_access);
> +#endif
> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
> index 50d2099..dda020f 100644
> --- a/arch/x86/mm/mem_encrypt.c
> +++ b/arch/x86/mm/mem_encrypt.c
> @@ -77,8 +77,3 @@ void __init mem_encrypt_init(void)
> print_mem_encrypt_feature_info();
> }
>
> -int arch_has_restricted_virtio_memory_access(void)
> -{
> - return cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT);
> -}
> -EXPORT_SYMBOL_GPL(arch_has_restricted_virtio_memory_access);
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index 120d32f..b95581f 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -335,4 +335,19 @@ 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
> +
> +config XEN_VIRTIO
> + bool "Xen virtio support"
> + default n
> + depends on VIRTIO
> + select ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS
> + 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).
> +
> 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..0e69aa8
> --- /dev/null
> +++ b/drivers/xen/grant-dma-ops.c
> @@ -0,0 +1,317 @@
> +// 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/pci.h>
> +#include <linux/pfn.h>
> +#include <xen/xen.h>
> +#include <xen/grant_table.h>
> +
> +struct xen_grant_dma_data {
> + /* The ID of backend domain */
> + domid_t dev_domid;
> + /* Is device behaving sane? */
> + bool broken;
> + struct device *dev;
> + struct list_head list;
> +};
> +
> +static LIST_HEAD(xen_grant_dma_devices);
> +static DEFINE_SPINLOCK(xen_grant_dma_lock);
> +
> +#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 = NULL;
> + bool found = false;
> +
> + spin_lock(&xen_grant_dma_lock);
> +
> + list_for_each_entry(data, &xen_grant_dma_devices, list) {
> + if (data->dev == dev) {
> + found = true;
> + break;
> + }
> + }
> +
> + spin_unlock(&xen_grant_dma_lock);
> +
> + return found ? data : NULL;
> +}
> +
> +/*
> + * 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->dev_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)
> +{
> + WARN_ONCE(1, "xen_grant_dma_alloc_pages size %zu\n", size);
> + return NULL;
> +}
> +
> +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)
> +{
> + WARN_ONCE(1, "xen_grant_dma_free_pages size %zu\n", size);
> +}
> +
> +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;
> +
> + BUG_ON(dir == DMA_NONE);
> +
> + 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->dev_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;
> +
> + BUG_ON(dir == DMA_NONE);
> +
> + 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;
> +
> + BUG_ON(dir == DMA_NONE);
> +
> + 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;
> +
> + BUG_ON(dir == DMA_NONE);
> +
> + 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;
> + uint32_t dev_domid;
> +
> + data = find_xen_grant_dma_data(dev);
> + if (data) {
> + dev_err(dev, "Xen grant DMA data is already created\n");
> + return;
> + }
> +
> + /* XXX The dom0 is hardcoded as the backend domain for now */
> + dev_domid = 0;
> +
> + data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> + if (!data) {
> + dev_err(dev, "Сannot allocate Xen grant DMA data\n");
> + goto err;
> + }
> + data->dev_domid = dev_domid;
> + data->dev = dev;
> +
> + spin_lock(&xen_grant_dma_lock);
> + list_add(&data->list, &xen_grant_dma_devices);
> + spin_unlock(&xen_grant_dma_lock);
> +
> + dev->dma_ops = &xen_grant_dma_ops;
> +
> + return;
> +
> +err:
> + dev_err(dev, "Сannot set up Xen grant DMA ops, retain platform DMA ops\n");
> +}
> +EXPORT_SYMBOL_GPL(xen_grant_setup_dma_ops);
> +
> +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 */
> diff --git a/include/xen/xen.h b/include/xen/xen.h
> index a99bab8..fe6e6bb 100644
> --- a/include/xen/xen.h
> +++ b/include/xen/xen.h
> @@ -52,6 +52,11 @@ bool xen_biovec_phys_mergeable(const struct bio_vec *vec1,
> extern u64 xen_saved_max_mem_size;
> #endif
>
> +static inline int xen_has_restricted_virtio_memory_access(void)
> +{
> + return IS_ENABLED(CONFIG_XEN_VIRTIO) && xen_domain();
> +}
> +
> #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
>
[-- 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] 79+ messages in thread
* Re: [PATCH V1 4/6] dt-bindings: Add xen, dev-domid property description for xen-grant DMA ops
2022-04-22 16:51 ` [PATCH V1 4/6] dt-bindings: Add xen, dev-domid " Oleksandr Tyshchenko
(?)
@ 2022-04-22 23:00 ` Stefano Stabellini
-1 siblings, 0 replies; 79+ messages in thread
From: Stefano Stabellini @ 2022-04-22 23:00 UTC (permalink / raw)
To: Oleksandr Tyshchenko
Cc: Juergen Gross, devicetree, Stefano Stabellini, Julien Grall,
Michael S. Tsirkin, linux-kernel, virtualization,
Christoph Hellwig, Oleksandr Tyshchenko, Rob Herring, xen-devel,
Krzysztof Kozlowski, linux-arm-kernel
On Fri, 22 Apr 2022, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>
> Introduce Xen specific binding for the virtualized device (e.g. virtio)
> to be used by Xen grant DMA-mapping layer in the subsequent commit.
>
> This binding indicates that Xen grant mappings scheme needs to be
> enabled for the device which DT node contains that property and specifies
> the ID of Xen domain where the corresponding backend resides. The ID
> (domid) is used as an argument to the 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>
Looks OK to me. Just a couple of grammar improvements below. Aside from
those, I have no further comments.
> ---
> Changes RFC -> V1:
> - update commit subject/description and text in description
> - move to devicetree/bindings/arm/
> ---
> .../devicetree/bindings/arm/xen,dev-domid.yaml | 37 ++++++++++++++++++++++
> 1 file changed, 37 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
>
> diff --git a/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
> new file mode 100644
> index 00000000..ef0f747
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
> @@ -0,0 +1,37 @@
> +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/xen,dev-domid.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Xen specific binding for the virtualized device (e.g. virtio)
NIT: Xen specific binding for virtualized devices (e.g. virtio)
> +maintainers:
> + - Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
> +
> +select: true
> +
> +description:
> + This binding indicates that Xen grant mappings scheme needs to be enabled
> + for that device and specifies the ID of Xen domain where the corresponding
> + device (backend) resides. This is needed for the option to restrict memory
> + access using Xen grant mappings to work.
NIT:
This binding indicates that Xen grant mappings need to be enabled for
the device, and it specifies the ID of the domain where the
corresponding device (backend) resides. The property is required to
restrict memory access using Xen grant mappings.
> +properties:
> + xen,dev-domid:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + The domid (domain ID) of the domain where the device (backend) is running.
> +
> +additionalProperties: true
> +
> +examples:
> + - |
> + virtio_block@3000 {
> + compatible = "virtio,mmio";
> + reg = <0x3000 0x100>;
> + interrupts = <41>;
> +
> + /* The device is located in Xen domain with ID 1 */
> + xen,dev-domid = <1>;
> + };
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [PATCH V1 4/6] dt-bindings: Add xen, dev-domid property description for xen-grant DMA ops
@ 2022-04-22 23:00 ` Stefano Stabellini
0 siblings, 0 replies; 79+ messages in thread
From: Stefano Stabellini @ 2022-04-22 23:00 UTC (permalink / raw)
To: Oleksandr Tyshchenko
Cc: xen-devel, virtualization, devicetree, linux-kernel,
linux-arm-kernel, Oleksandr Tyshchenko, Jason Wang, Rob Herring,
Krzysztof Kozlowski, Julien Grall, Juergen Gross,
Stefano Stabellini, Michael S. Tsirkin, Christoph Hellwig
On Fri, 22 Apr 2022, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>
> Introduce Xen specific binding for the virtualized device (e.g. virtio)
> to be used by Xen grant DMA-mapping layer in the subsequent commit.
>
> This binding indicates that Xen grant mappings scheme needs to be
> enabled for the device which DT node contains that property and specifies
> the ID of Xen domain where the corresponding backend resides. The ID
> (domid) is used as an argument to the 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>
Looks OK to me. Just a couple of grammar improvements below. Aside from
those, I have no further comments.
> ---
> Changes RFC -> V1:
> - update commit subject/description and text in description
> - move to devicetree/bindings/arm/
> ---
> .../devicetree/bindings/arm/xen,dev-domid.yaml | 37 ++++++++++++++++++++++
> 1 file changed, 37 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
>
> diff --git a/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
> new file mode 100644
> index 00000000..ef0f747
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
> @@ -0,0 +1,37 @@
> +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/xen,dev-domid.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Xen specific binding for the virtualized device (e.g. virtio)
NIT: Xen specific binding for virtualized devices (e.g. virtio)
> +maintainers:
> + - Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
> +
> +select: true
> +
> +description:
> + This binding indicates that Xen grant mappings scheme needs to be enabled
> + for that device and specifies the ID of Xen domain where the corresponding
> + device (backend) resides. This is needed for the option to restrict memory
> + access using Xen grant mappings to work.
NIT:
This binding indicates that Xen grant mappings need to be enabled for
the device, and it specifies the ID of the domain where the
corresponding device (backend) resides. The property is required to
restrict memory access using Xen grant mappings.
> +properties:
> + xen,dev-domid:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + The domid (domain ID) of the domain where the device (backend) is running.
> +
> +additionalProperties: true
> +
> +examples:
> + - |
> + virtio_block@3000 {
> + compatible = "virtio,mmio";
> + reg = <0x3000 0x100>;
> + interrupts = <41>;
> +
> + /* The device is located in Xen domain with ID 1 */
> + xen,dev-domid = <1>;
> + };
^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [PATCH V1 4/6] dt-bindings: Add xen, dev-domid property description for xen-grant DMA ops
@ 2022-04-22 23:00 ` Stefano Stabellini
0 siblings, 0 replies; 79+ messages in thread
From: Stefano Stabellini @ 2022-04-22 23:00 UTC (permalink / raw)
To: Oleksandr Tyshchenko
Cc: xen-devel, virtualization, devicetree, linux-kernel,
linux-arm-kernel, Oleksandr Tyshchenko, Jason Wang, Rob Herring,
Krzysztof Kozlowski, Julien Grall, Juergen Gross,
Stefano Stabellini, Michael S. Tsirkin, Christoph Hellwig
On Fri, 22 Apr 2022, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>
> Introduce Xen specific binding for the virtualized device (e.g. virtio)
> to be used by Xen grant DMA-mapping layer in the subsequent commit.
>
> This binding indicates that Xen grant mappings scheme needs to be
> enabled for the device which DT node contains that property and specifies
> the ID of Xen domain where the corresponding backend resides. The ID
> (domid) is used as an argument to the 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>
Looks OK to me. Just a couple of grammar improvements below. Aside from
those, I have no further comments.
> ---
> Changes RFC -> V1:
> - update commit subject/description and text in description
> - move to devicetree/bindings/arm/
> ---
> .../devicetree/bindings/arm/xen,dev-domid.yaml | 37 ++++++++++++++++++++++
> 1 file changed, 37 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
>
> diff --git a/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
> new file mode 100644
> index 00000000..ef0f747
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
> @@ -0,0 +1,37 @@
> +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/xen,dev-domid.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Xen specific binding for the virtualized device (e.g. virtio)
NIT: Xen specific binding for virtualized devices (e.g. virtio)
> +maintainers:
> + - Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
> +
> +select: true
> +
> +description:
> + This binding indicates that Xen grant mappings scheme needs to be enabled
> + for that device and specifies the ID of Xen domain where the corresponding
> + device (backend) resides. This is needed for the option to restrict memory
> + access using Xen grant mappings to work.
NIT:
This binding indicates that Xen grant mappings need to be enabled for
the device, and it specifies the ID of the domain where the
corresponding device (backend) resides. The property is required to
restrict memory access using Xen grant mappings.
> +properties:
> + xen,dev-domid:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + The domid (domain ID) of the domain where the device (backend) is running.
> +
> +additionalProperties: true
> +
> +examples:
> + - |
> + virtio_block@3000 {
> + compatible = "virtio,mmio";
> + reg = <0x3000 0x100>;
> + interrupts = <41>;
> +
> + /* The device is located in Xen domain with ID 1 */
> + xen,dev-domid = <1>;
> + };
_______________________________________________
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] 79+ messages in thread
* Re: [PATCH V1 5/6] xen/grant-dma-ops: Retrieve the ID of backend's domain for DT devices
2022-04-22 16:51 ` Oleksandr Tyshchenko
@ 2022-04-22 23:00 ` Stefano Stabellini
-1 siblings, 0 replies; 79+ messages in thread
From: Stefano Stabellini @ 2022-04-22 23:00 UTC (permalink / raw)
To: Oleksandr Tyshchenko
Cc: xen-devel, linux-kernel, linux-arm-kernel, Oleksandr Tyshchenko,
Stefano Stabellini, Boris Ostrovsky, Juergen Gross, Julien Grall,
Michael S. Tsirkin, Christoph Hellwig
On Fri, 22 Apr 2022, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>
> Use the presence of recently introduced "xen,dev-domid" property
> in the device node as a clear indicator of enabling Xen grant
> mappings scheme for that device and read the ID of Xen domain where
> the corresponding backend resides. The ID (domid) is used as
> an argument to the Xen grant mapping APIs.
>
> 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>
> ---
> 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
> ---
> drivers/xen/grant-dma-ops.c | 25 ++++++++++++++++++-------
> include/xen/xen-ops.h | 5 +++++
> 2 files changed, 23 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c
> index 0e69aa8..70d5d77 100644
> --- a/drivers/xen/grant-dma-ops.c
> +++ b/drivers/xen/grant-dma-ops.c
> @@ -66,11 +66,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,
> @@ -277,6 +272,16 @@ 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)
> +{
> + /* XXX Handle only DT devices for now */
> + if (!dev->of_node)
> + return false;
> +
> + return of_property_read_bool(dev->of_node, "xen,dev-domid");
> +}
> +EXPORT_SYMBOL_GPL(xen_is_grant_dma_device);
> +
> void xen_grant_setup_dma_ops(struct device *dev)
> {
> struct xen_grant_dma_data *data;
> @@ -288,8 +293,14 @@ void xen_grant_setup_dma_ops(struct device *dev)
> return;
> }
>
> - /* XXX The dom0 is hardcoded as the backend domain for now */
> - dev_domid = 0;
> + /* XXX ACPI and PCI devices unsupported for now */
> + if (dev_is_pci(dev) || !dev->of_node)
> + goto err;
I think we can remove the "dev_is_pci" check, right?
> + if (of_property_read_u32(dev->of_node, "xen,dev-domid", &dev_domid)) {
> + dev_err(dev, "xen,dev-domid property is not present\n");
> + goto err;
> + }
>
> data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> if (!data) {
> 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 [flat|nested] 79+ messages in thread
* Re: [PATCH V1 5/6] xen/grant-dma-ops: Retrieve the ID of backend's domain for DT devices
@ 2022-04-22 23:00 ` Stefano Stabellini
0 siblings, 0 replies; 79+ messages in thread
From: Stefano Stabellini @ 2022-04-22 23:00 UTC (permalink / raw)
To: Oleksandr Tyshchenko
Cc: xen-devel, linux-kernel, linux-arm-kernel, Oleksandr Tyshchenko,
Stefano Stabellini, Boris Ostrovsky, Juergen Gross, Julien Grall,
Michael S. Tsirkin, Christoph Hellwig
On Fri, 22 Apr 2022, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>
> Use the presence of recently introduced "xen,dev-domid" property
> in the device node as a clear indicator of enabling Xen grant
> mappings scheme for that device and read the ID of Xen domain where
> the corresponding backend resides. The ID (domid) is used as
> an argument to the Xen grant mapping APIs.
>
> 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>
> ---
> 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
> ---
> drivers/xen/grant-dma-ops.c | 25 ++++++++++++++++++-------
> include/xen/xen-ops.h | 5 +++++
> 2 files changed, 23 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c
> index 0e69aa8..70d5d77 100644
> --- a/drivers/xen/grant-dma-ops.c
> +++ b/drivers/xen/grant-dma-ops.c
> @@ -66,11 +66,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,
> @@ -277,6 +272,16 @@ 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)
> +{
> + /* XXX Handle only DT devices for now */
> + if (!dev->of_node)
> + return false;
> +
> + return of_property_read_bool(dev->of_node, "xen,dev-domid");
> +}
> +EXPORT_SYMBOL_GPL(xen_is_grant_dma_device);
> +
> void xen_grant_setup_dma_ops(struct device *dev)
> {
> struct xen_grant_dma_data *data;
> @@ -288,8 +293,14 @@ void xen_grant_setup_dma_ops(struct device *dev)
> return;
> }
>
> - /* XXX The dom0 is hardcoded as the backend domain for now */
> - dev_domid = 0;
> + /* XXX ACPI and PCI devices unsupported for now */
> + if (dev_is_pci(dev) || !dev->of_node)
> + goto err;
I think we can remove the "dev_is_pci" check, right?
> + if (of_property_read_u32(dev->of_node, "xen,dev-domid", &dev_domid)) {
> + dev_err(dev, "xen,dev-domid property is not present\n");
> + goto err;
> + }
>
> data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> if (!data) {
> 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
>
_______________________________________________
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] 79+ messages in thread
* Re: [PATCH V1 6/6] arm/xen: Assign xen-grant DMA ops for xen-grant DMA devices
2022-04-22 16:51 ` Oleksandr Tyshchenko
@ 2022-04-22 23:00 ` Stefano Stabellini
-1 siblings, 0 replies; 79+ messages in thread
From: Stefano Stabellini @ 2022-04-22 23:00 UTC (permalink / raw)
To: Oleksandr Tyshchenko
Cc: xen-devel, linux-kernel, linux-arm-kernel, Oleksandr Tyshchenko,
Boris Ostrovsky, Juergen Gross, Stefano Stabellini, Julien Grall,
Michael S. Tsirkin, Christoph Hellwig
On Fri, 22 Apr 2022, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>
> As the main (and single at the moment) purpose of xen-grant
> DMA devices is to enable using virtio devices in Xen guests
> in a safe manner, assign xen-grant DMA ops only if restricted
> access to the guest memory is enabled.
>
> 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
> ---
> include/xen/arm/xen-ops.h | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/include/xen/arm/xen-ops.h b/include/xen/arm/xen-ops.h
> index 288deb1..26954e5 100644
> --- a/include/xen/arm/xen-ops.h
> +++ b/include/xen/arm/xen-ops.h
> @@ -2,12 +2,17 @@
> #ifndef _ASM_ARM_XEN_OPS_H
> #define _ASM_ARM_XEN_OPS_H
>
> +#include <linux/virtio_config.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 (arch_has_restricted_virtio_memory_access() &&
> + 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 [flat|nested] 79+ messages in thread
* Re: [PATCH V1 6/6] arm/xen: Assign xen-grant DMA ops for xen-grant DMA devices
@ 2022-04-22 23:00 ` Stefano Stabellini
0 siblings, 0 replies; 79+ messages in thread
From: Stefano Stabellini @ 2022-04-22 23:00 UTC (permalink / raw)
To: Oleksandr Tyshchenko
Cc: xen-devel, linux-kernel, linux-arm-kernel, Oleksandr Tyshchenko,
Boris Ostrovsky, Juergen Gross, Stefano Stabellini, Julien Grall,
Michael S. Tsirkin, Christoph Hellwig
On Fri, 22 Apr 2022, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>
> As the main (and single at the moment) purpose of xen-grant
> DMA devices is to enable using virtio devices in Xen guests
> in a safe manner, assign xen-grant DMA ops only if restricted
> access to the guest memory is enabled.
>
> 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
> ---
> include/xen/arm/xen-ops.h | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/include/xen/arm/xen-ops.h b/include/xen/arm/xen-ops.h
> index 288deb1..26954e5 100644
> --- a/include/xen/arm/xen-ops.h
> +++ b/include/xen/arm/xen-ops.h
> @@ -2,12 +2,17 @@
> #ifndef _ASM_ARM_XEN_OPS_H
> #define _ASM_ARM_XEN_OPS_H
>
> +#include <linux/virtio_config.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 (arch_has_restricted_virtio_memory_access() &&
> + 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
>
_______________________________________________
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] 79+ messages in thread
* Re: [PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen
2022-04-22 23:00 ` Stefano Stabellini
@ 2022-04-23 7:05 ` Oleksandr
-1 siblings, 0 replies; 79+ messages in thread
From: Oleksandr @ 2022-04-23 7:05 UTC (permalink / raw)
To: Stefano Stabellini
Cc: xen-devel, x86, linux-kernel, linux-arm-kernel, Juergen Gross,
Dave Hansen, Andy Lutomirski, Peter Zijlstra, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H. Peter Anvin, Boris Ostrovsky,
Julien Grall, Oleksandr Tyshchenko, Michael S. Tsirkin,
Christoph Hellwig
[-- Attachment #1: Type: text/plain, Size: 2013 bytes --]
On 23.04.22 02:00, Stefano Stabellini wrote:
Hello Stefano
> On Fri, 22 Apr 2022, Oleksandr Tyshchenko wrote:
>> 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.
>>
>> 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.
>>
>> As this also requires providing arch_has_restricted_virtio_memory_access
>> implementation, switch from a pure stub to a real function on Arm
>> and combine with existing implementation for the SEV guests on x86.
>>
>> Add the needed functionality by providing a special set of DMA ops
>> handling the needed grant operations for the I/O pages.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
> There are a couple of minor things that checkpatch.pl reports,
Thank you for pointing this out, my fault.
> but aside
> from those the patch looks fine to me.
good
The attached diff to be squashed for the new version. One thing remains:
checkpatch.pl says regarding drivers/xen/grant-dma-ops.c:
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#151:
new file mode 100644
Which, I assume, this is not an issue as new file falls under XEN
HYPERVISOR INTERFACE maintainership?
scripts/get_maintainer.pl -f drivers/xen/grant-dma-ops.c
Boris Ostrovsky <boris.ostrovsky@oracle.com> (supporter:XEN HYPERVISOR
INTERFACE)
Juergen Gross <jgross@suse.com> (supporter:XEN HYPERVISOR INTERFACE)
Stefano Stabellini <sstabellini@kernel.org> (reviewer:XEN HYPERVISOR
INTERFACE)
xen-devel@lists.xenproject.org (moderated list:XEN HYPERVISOR INTERFACE)
linux-kernel@vger.kernel.org (open list)
[snip]
--
Regards,
Oleksandr Tyshchenko
[-- Attachment #2: 0001-fixup.patch --]
[-- Type: text/x-patch, Size: 3123 bytes --]
From 8d36fc5a3604a69848c300a42f1a78f8ace41829 Mon Sep 17 00:00:00 2001
From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Date: Sat, 23 Apr 2022 09:23:04 +0300
Subject: [PATCH] fixup
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
---
drivers/xen/Kconfig | 2 ++
drivers/xen/grant-dma-ops.c | 21 ++++++++++++---------
2 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index b95581f..1727337 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -350,4 +350,6 @@ config XEN_VIRTIO
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/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c
index 70d5d77..b9d93d7 100644
--- a/drivers/xen/grant-dma-ops.c
+++ b/drivers/xen/grant-dma-ops.c
@@ -139,7 +139,7 @@ static struct page *xen_grant_dma_alloc_pages(struct device *dev, size_t size,
enum dma_data_direction dir,
gfp_t gfp)
{
- WARN_ONCE(1, "xen_grant_dma_alloc_pages size %zu\n", size);
+ WARN_ONCE(1, "%s: size %zu\n", __func__, size);
return NULL;
}
@@ -147,7 +147,7 @@ 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)
{
- WARN_ONCE(1, "xen_grant_dma_free_pages size %zu\n", size);
+ WARN_ONCE(1, "%s: size %zu\n", __func__, size);
}
static dma_addr_t xen_grant_dma_map_page(struct device *dev, struct page *page,
@@ -160,7 +160,8 @@ static dma_addr_t xen_grant_dma_map_page(struct device *dev, struct page *page,
grant_ref_t grant;
dma_addr_t dma_handle;
- BUG_ON(dir == DMA_NONE);
+ if (WARN_ON(dir == DMA_NONE))
+ return DMA_MAPPING_ERROR;
data = find_xen_grant_dma_data(dev);
if (!data)
@@ -190,7 +191,8 @@ static void xen_grant_dma_unmap_page(struct device *dev, dma_addr_t dma_handle,
unsigned int i, n_pages = PFN_UP(size);
grant_ref_t grant;
- BUG_ON(dir == DMA_NONE);
+ if (WARN_ON(dir == DMA_NONE))
+ return;
data = find_xen_grant_dma_data(dev);
if (!data)
@@ -219,7 +221,8 @@ static void xen_grant_dma_unmap_sg(struct device *dev, struct scatterlist *sg,
struct scatterlist *s;
unsigned int i;
- BUG_ON(dir == DMA_NONE);
+ 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,
@@ -233,7 +236,8 @@ static int xen_grant_dma_map_sg(struct device *dev, struct scatterlist *sg,
struct scatterlist *s;
unsigned int i;
- BUG_ON(dir == DMA_NONE);
+ 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,
@@ -303,10 +307,9 @@ void xen_grant_setup_dma_ops(struct device *dev)
}
data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
- if (!data) {
- dev_err(dev, "Сannot allocate Xen grant DMA data\n");
+ if (!data)
goto err;
- }
+
data->dev_domid = dev_domid;
data->dev = dev;
--
2.7.4
^ permalink raw reply related [flat|nested] 79+ messages in thread
* Re: [PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen
@ 2022-04-23 7:05 ` Oleksandr
0 siblings, 0 replies; 79+ messages in thread
From: Oleksandr @ 2022-04-23 7:05 UTC (permalink / raw)
To: Stefano Stabellini
Cc: xen-devel, x86, linux-kernel, linux-arm-kernel, Juergen Gross,
Dave Hansen, Andy Lutomirski, Peter Zijlstra, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H. Peter Anvin, Boris Ostrovsky,
Julien Grall, Oleksandr Tyshchenko, Michael S. Tsirkin,
Christoph Hellwig
[-- Attachment #1: Type: text/plain, Size: 2013 bytes --]
On 23.04.22 02:00, Stefano Stabellini wrote:
Hello Stefano
> On Fri, 22 Apr 2022, Oleksandr Tyshchenko wrote:
>> 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.
>>
>> 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.
>>
>> As this also requires providing arch_has_restricted_virtio_memory_access
>> implementation, switch from a pure stub to a real function on Arm
>> and combine with existing implementation for the SEV guests on x86.
>>
>> Add the needed functionality by providing a special set of DMA ops
>> handling the needed grant operations for the I/O pages.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
> There are a couple of minor things that checkpatch.pl reports,
Thank you for pointing this out, my fault.
> but aside
> from those the patch looks fine to me.
good
The attached diff to be squashed for the new version. One thing remains:
checkpatch.pl says regarding drivers/xen/grant-dma-ops.c:
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#151:
new file mode 100644
Which, I assume, this is not an issue as new file falls under XEN
HYPERVISOR INTERFACE maintainership?
scripts/get_maintainer.pl -f drivers/xen/grant-dma-ops.c
Boris Ostrovsky <boris.ostrovsky@oracle.com> (supporter:XEN HYPERVISOR
INTERFACE)
Juergen Gross <jgross@suse.com> (supporter:XEN HYPERVISOR INTERFACE)
Stefano Stabellini <sstabellini@kernel.org> (reviewer:XEN HYPERVISOR
INTERFACE)
xen-devel@lists.xenproject.org (moderated list:XEN HYPERVISOR INTERFACE)
linux-kernel@vger.kernel.org (open list)
[snip]
--
Regards,
Oleksandr Tyshchenko
[-- Attachment #2: 0001-fixup.patch --]
[-- Type: text/x-patch, Size: 3123 bytes --]
From 8d36fc5a3604a69848c300a42f1a78f8ace41829 Mon Sep 17 00:00:00 2001
From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Date: Sat, 23 Apr 2022 09:23:04 +0300
Subject: [PATCH] fixup
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
---
drivers/xen/Kconfig | 2 ++
drivers/xen/grant-dma-ops.c | 21 ++++++++++++---------
2 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index b95581f..1727337 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -350,4 +350,6 @@ config XEN_VIRTIO
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/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c
index 70d5d77..b9d93d7 100644
--- a/drivers/xen/grant-dma-ops.c
+++ b/drivers/xen/grant-dma-ops.c
@@ -139,7 +139,7 @@ static struct page *xen_grant_dma_alloc_pages(struct device *dev, size_t size,
enum dma_data_direction dir,
gfp_t gfp)
{
- WARN_ONCE(1, "xen_grant_dma_alloc_pages size %zu\n", size);
+ WARN_ONCE(1, "%s: size %zu\n", __func__, size);
return NULL;
}
@@ -147,7 +147,7 @@ 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)
{
- WARN_ONCE(1, "xen_grant_dma_free_pages size %zu\n", size);
+ WARN_ONCE(1, "%s: size %zu\n", __func__, size);
}
static dma_addr_t xen_grant_dma_map_page(struct device *dev, struct page *page,
@@ -160,7 +160,8 @@ static dma_addr_t xen_grant_dma_map_page(struct device *dev, struct page *page,
grant_ref_t grant;
dma_addr_t dma_handle;
- BUG_ON(dir == DMA_NONE);
+ if (WARN_ON(dir == DMA_NONE))
+ return DMA_MAPPING_ERROR;
data = find_xen_grant_dma_data(dev);
if (!data)
@@ -190,7 +191,8 @@ static void xen_grant_dma_unmap_page(struct device *dev, dma_addr_t dma_handle,
unsigned int i, n_pages = PFN_UP(size);
grant_ref_t grant;
- BUG_ON(dir == DMA_NONE);
+ if (WARN_ON(dir == DMA_NONE))
+ return;
data = find_xen_grant_dma_data(dev);
if (!data)
@@ -219,7 +221,8 @@ static void xen_grant_dma_unmap_sg(struct device *dev, struct scatterlist *sg,
struct scatterlist *s;
unsigned int i;
- BUG_ON(dir == DMA_NONE);
+ 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,
@@ -233,7 +236,8 @@ static int xen_grant_dma_map_sg(struct device *dev, struct scatterlist *sg,
struct scatterlist *s;
unsigned int i;
- BUG_ON(dir == DMA_NONE);
+ 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,
@@ -303,10 +307,9 @@ void xen_grant_setup_dma_ops(struct device *dev)
}
data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
- if (!data) {
- dev_err(dev, "Сannot allocate Xen grant DMA data\n");
+ if (!data)
goto err;
- }
+
data->dev_domid = dev_domid;
data->dev = dev;
--
2.7.4
[-- Attachment #3: 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 related [flat|nested] 79+ messages in thread
* Re: [PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen
2022-04-23 7:05 ` Oleksandr
@ 2022-04-23 9:10 ` Juergen Gross
-1 siblings, 0 replies; 79+ messages in thread
From: Juergen Gross @ 2022-04-23 9:10 UTC (permalink / raw)
To: Oleksandr, Stefano Stabellini
Cc: xen-devel, x86, linux-kernel, linux-arm-kernel, Dave Hansen,
Andy Lutomirski, Peter Zijlstra, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H. Peter Anvin, Boris Ostrovsky, Julien Grall,
Oleksandr Tyshchenko, Michael S. Tsirkin, Christoph Hellwig
[-- Attachment #1.1.1: Type: text/plain, Size: 1743 bytes --]
On 23.04.22 09:05, Oleksandr wrote:
>
> On 23.04.22 02:00, Stefano Stabellini wrote:
>
> Hello Stefano
>
>
>> On Fri, 22 Apr 2022, Oleksandr Tyshchenko wrote:
>>> 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.
>>>
>>> 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.
>>>
>>> As this also requires providing arch_has_restricted_virtio_memory_access
>>> implementation, switch from a pure stub to a real function on Arm
>>> and combine with existing implementation for the SEV guests on x86.
>>>
>>> Add the needed functionality by providing a special set of DMA ops
>>> handling the needed grant operations for the I/O pages.
>>>
>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>> There are a couple of minor things that checkpatch.pl reports,
>
> Thank you for pointing this out, my fault.
>
>
>> but aside
>> from those the patch looks fine to me.
>
> good
>
>
> The attached diff to be squashed for the new version. One thing remains:
>
> checkpatch.pl says regarding drivers/xen/grant-dma-ops.c:
>
> WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
> #151:
> new file mode 100644
>
>
> Which, I assume, this is not an issue as new file falls under XEN HYPERVISOR
> INTERFACE maintainership?
Yes.
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] 79+ messages in thread
* Re: [PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen
@ 2022-04-23 9:10 ` Juergen Gross
0 siblings, 0 replies; 79+ messages in thread
From: Juergen Gross @ 2022-04-23 9:10 UTC (permalink / raw)
To: Oleksandr, Stefano Stabellini
Cc: xen-devel, x86, linux-kernel, linux-arm-kernel, Dave Hansen,
Andy Lutomirski, Peter Zijlstra, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H. Peter Anvin, Boris Ostrovsky, Julien Grall,
Oleksandr Tyshchenko, Michael S. Tsirkin, Christoph Hellwig
[-- Attachment #1.1.1.1: Type: text/plain, Size: 1743 bytes --]
On 23.04.22 09:05, Oleksandr wrote:
>
> On 23.04.22 02:00, Stefano Stabellini wrote:
>
> Hello Stefano
>
>
>> On Fri, 22 Apr 2022, Oleksandr Tyshchenko wrote:
>>> 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.
>>>
>>> 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.
>>>
>>> As this also requires providing arch_has_restricted_virtio_memory_access
>>> implementation, switch from a pure stub to a real function on Arm
>>> and combine with existing implementation for the SEV guests on x86.
>>>
>>> Add the needed functionality by providing a special set of DMA ops
>>> handling the needed grant operations for the I/O pages.
>>>
>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>> There are a couple of minor things that checkpatch.pl reports,
>
> Thank you for pointing this out, my fault.
>
>
>> but aside
>> from those the patch looks fine to me.
>
> good
>
>
> The attached diff to be squashed for the new version. One thing remains:
>
> checkpatch.pl says regarding drivers/xen/grant-dma-ops.c:
>
> WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
> #151:
> new file mode 100644
>
>
> Which, I assume, this is not an issue as new file falls under XEN HYPERVISOR
> INTERFACE maintainership?
Yes.
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] 79+ messages in thread
* Re: [PATCH V1 1/6] arm/xen: Introduce xen_setup_dma_ops()
2022-04-22 22:59 ` Stefano Stabellini
@ 2022-04-23 14:35 ` Oleksandr
-1 siblings, 0 replies; 79+ messages in thread
From: Oleksandr @ 2022-04-23 14:35 UTC (permalink / raw)
To: Stefano Stabellini
Cc: xen-devel, linux-kernel, linux-arm-kernel, Oleksandr Tyshchenko,
Russell King, Catalin Marinas, Will Deacon, Boris Ostrovsky,
Juergen Gross, Logan Gunthorpe, David Hildenbrand,
Martin Oliveira, Kees Cook, Jean-Philippe Brucker, Julien Grall,
Michael S. Tsirkin, Christoph Hellwig
On 23.04.22 01:59, Stefano Stabellini wrote:
Hello Stefano
> On Fri, 22 Apr 2022, Oleksandr Tyshchenko wrote:
>> 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>
Thanks!
checkpatch.pl suggests adding missing SPDX-License-Identifier to
Arm/Arm64's xen-ops.h
I will retain your R-b tag after making this change. Please let me know
if you think otherwise.
>> ---
>> 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
>> ---
>> arch/arm/include/asm/xen/xen-ops.h | 1 +
>> arch/arm/mm/dma-mapping.c | 7 ++-----
>> arch/arm64/include/asm/xen/xen-ops.h | 1 +
>> arch/arm64/mm/dma-mapping.c | 7 ++-----
>> include/xen/arm/xen-ops.h | 15 +++++++++++++++
>> 5 files changed, 21 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..8d2fa24
>> --- /dev/null
>> +++ b/arch/arm/include/asm/xen/xen-ops.h
>> @@ -0,0 +1 @@
>> +#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..8d2fa24
>> --- /dev/null
>> +++ b/arch/arm64/include/asm/xen/xen-ops.h
>> @@ -0,0 +1 @@
>> +#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
>>
--
Regards,
Oleksandr Tyshchenko
^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [PATCH V1 1/6] arm/xen: Introduce xen_setup_dma_ops()
@ 2022-04-23 14:35 ` Oleksandr
0 siblings, 0 replies; 79+ messages in thread
From: Oleksandr @ 2022-04-23 14:35 UTC (permalink / raw)
To: Stefano Stabellini
Cc: xen-devel, linux-kernel, linux-arm-kernel, Oleksandr Tyshchenko,
Russell King, Catalin Marinas, Will Deacon, Boris Ostrovsky,
Juergen Gross, Logan Gunthorpe, David Hildenbrand,
Martin Oliveira, Kees Cook, Jean-Philippe Brucker, Julien Grall,
Michael S. Tsirkin, Christoph Hellwig
On 23.04.22 01:59, Stefano Stabellini wrote:
Hello Stefano
> On Fri, 22 Apr 2022, Oleksandr Tyshchenko wrote:
>> 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>
Thanks!
checkpatch.pl suggests adding missing SPDX-License-Identifier to
Arm/Arm64's xen-ops.h
I will retain your R-b tag after making this change. Please let me know
if you think otherwise.
>> ---
>> 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
>> ---
>> arch/arm/include/asm/xen/xen-ops.h | 1 +
>> arch/arm/mm/dma-mapping.c | 7 ++-----
>> arch/arm64/include/asm/xen/xen-ops.h | 1 +
>> arch/arm64/mm/dma-mapping.c | 7 ++-----
>> include/xen/arm/xen-ops.h | 15 +++++++++++++++
>> 5 files changed, 21 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..8d2fa24
>> --- /dev/null
>> +++ b/arch/arm/include/asm/xen/xen-ops.h
>> @@ -0,0 +1 @@
>> +#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..8d2fa24
>> --- /dev/null
>> +++ b/arch/arm64/include/asm/xen/xen-ops.h
>> @@ -0,0 +1 @@
>> +#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
>>
--
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] 79+ messages in thread
* Re: [PATCH V1 4/6] dt-bindings: Add xen, dev-domid property description for xen-grant DMA ops
2022-04-22 23:00 ` Stefano Stabellini
@ 2022-04-23 14:37 ` Oleksandr
-1 siblings, 0 replies; 79+ messages in thread
From: Oleksandr @ 2022-04-23 14:37 UTC (permalink / raw)
To: Stefano Stabellini
Cc: xen-devel, virtualization, devicetree, linux-kernel,
linux-arm-kernel, Oleksandr Tyshchenko, Jason Wang, Rob Herring,
Krzysztof Kozlowski, Julien Grall, Juergen Gross,
Michael S. Tsirkin, Christoph Hellwig
On 23.04.22 02:00, Stefano Stabellini wrote:
Hello Stefano
> On Fri, 22 Apr 2022, Oleksandr Tyshchenko wrote:
>> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>
>> Introduce Xen specific binding for the virtualized device (e.g. virtio)
>> to be used by Xen grant DMA-mapping layer in the subsequent commit.
>>
>> This binding indicates that Xen grant mappings scheme needs to be
>> enabled for the device which DT node contains that property and specifies
>> the ID of Xen domain where the corresponding backend resides. The ID
>> (domid) is used as an argument to the 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>
> Looks OK to me. Just a couple of grammar improvements below. Aside from
> those, I have no further comments.
thank you, I agree with proposed comments, will update
>
>
>> ---
>> Changes RFC -> V1:
>> - update commit subject/description and text in description
>> - move to devicetree/bindings/arm/
>> ---
>> .../devicetree/bindings/arm/xen,dev-domid.yaml | 37 ++++++++++++++++++++++
>> 1 file changed, 37 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
>> new file mode 100644
>> index 00000000..ef0f747
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
>> @@ -0,0 +1,37 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/arm/xen,dev-domid.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Xen specific binding for the virtualized device (e.g. virtio)
> NIT: Xen specific binding for virtualized devices (e.g. virtio)
>
>
>> +maintainers:
>> + - Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>> +
>> +select: true
>> +
>> +description:
>> + This binding indicates that Xen grant mappings scheme needs to be enabled
>> + for that device and specifies the ID of Xen domain where the corresponding
>> + device (backend) resides. This is needed for the option to restrict memory
>> + access using Xen grant mappings to work.
> NIT:
>
> This binding indicates that Xen grant mappings need to be enabled for
> the device, and it specifies the ID of the domain where the
> corresponding device (backend) resides. The property is required to
> restrict memory access using Xen grant mappings.
>
>
>> +properties:
>> + xen,dev-domid:
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> + description:
>> + The domid (domain ID) of the domain where the device (backend) is running.
>> +
>> +additionalProperties: true
>> +
>> +examples:
>> + - |
>> + virtio_block@3000 {
>> + compatible = "virtio,mmio";
>> + reg = <0x3000 0x100>;
>> + interrupts = <41>;
>> +
>> + /* The device is located in Xen domain with ID 1 */
>> + xen,dev-domid = <1>;
>> + };
--
Regards,
Oleksandr Tyshchenko
^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [PATCH V1 4/6] dt-bindings: Add xen, dev-domid property description for xen-grant DMA ops
@ 2022-04-23 14:37 ` Oleksandr
0 siblings, 0 replies; 79+ messages in thread
From: Oleksandr @ 2022-04-23 14:37 UTC (permalink / raw)
To: Stefano Stabellini
Cc: xen-devel, virtualization, devicetree, linux-kernel,
linux-arm-kernel, Oleksandr Tyshchenko, Jason Wang, Rob Herring,
Krzysztof Kozlowski, Julien Grall, Juergen Gross,
Michael S. Tsirkin, Christoph Hellwig
On 23.04.22 02:00, Stefano Stabellini wrote:
Hello Stefano
> On Fri, 22 Apr 2022, Oleksandr Tyshchenko wrote:
>> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>
>> Introduce Xen specific binding for the virtualized device (e.g. virtio)
>> to be used by Xen grant DMA-mapping layer in the subsequent commit.
>>
>> This binding indicates that Xen grant mappings scheme needs to be
>> enabled for the device which DT node contains that property and specifies
>> the ID of Xen domain where the corresponding backend resides. The ID
>> (domid) is used as an argument to the 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>
> Looks OK to me. Just a couple of grammar improvements below. Aside from
> those, I have no further comments.
thank you, I agree with proposed comments, will update
>
>
>> ---
>> Changes RFC -> V1:
>> - update commit subject/description and text in description
>> - move to devicetree/bindings/arm/
>> ---
>> .../devicetree/bindings/arm/xen,dev-domid.yaml | 37 ++++++++++++++++++++++
>> 1 file changed, 37 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
>> new file mode 100644
>> index 00000000..ef0f747
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
>> @@ -0,0 +1,37 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/arm/xen,dev-domid.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Xen specific binding for the virtualized device (e.g. virtio)
> NIT: Xen specific binding for virtualized devices (e.g. virtio)
>
>
>> +maintainers:
>> + - Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>> +
>> +select: true
>> +
>> +description:
>> + This binding indicates that Xen grant mappings scheme needs to be enabled
>> + for that device and specifies the ID of Xen domain where the corresponding
>> + device (backend) resides. This is needed for the option to restrict memory
>> + access using Xen grant mappings to work.
> NIT:
>
> This binding indicates that Xen grant mappings need to be enabled for
> the device, and it specifies the ID of the domain where the
> corresponding device (backend) resides. The property is required to
> restrict memory access using Xen grant mappings.
>
>
>> +properties:
>> + xen,dev-domid:
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> + description:
>> + The domid (domain ID) of the domain where the device (backend) is running.
>> +
>> +additionalProperties: true
>> +
>> +examples:
>> + - |
>> + virtio_block@3000 {
>> + compatible = "virtio,mmio";
>> + reg = <0x3000 0x100>;
>> + interrupts = <41>;
>> +
>> + /* The device is located in Xen domain with ID 1 */
>> + xen,dev-domid = <1>;
>> + };
--
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] 79+ messages in thread
* Re: [PATCH V1 5/6] xen/grant-dma-ops: Retrieve the ID of backend's domain for DT devices
2022-04-22 23:00 ` Stefano Stabellini
@ 2022-04-23 15:23 ` Oleksandr
-1 siblings, 0 replies; 79+ messages in thread
From: Oleksandr @ 2022-04-23 15:23 UTC (permalink / raw)
To: Stefano Stabellini
Cc: xen-devel, linux-kernel, linux-arm-kernel, Oleksandr Tyshchenko,
Boris Ostrovsky, Juergen Gross, Julien Grall, Michael S. Tsirkin,
Christoph Hellwig
On 23.04.22 02:00, Stefano Stabellini wrote:
Hello Stefano
> On Fri, 22 Apr 2022, Oleksandr Tyshchenko wrote:
>> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>
>> Use the presence of recently introduced "xen,dev-domid" property
>> in the device node as a clear indicator of enabling Xen grant
>> mappings scheme for that device and read the ID of Xen domain where
>> the corresponding backend resides. The ID (domid) is used as
>> an argument to the Xen grant mapping APIs.
>>
>> 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>
>> ---
>> 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
>> ---
>> drivers/xen/grant-dma-ops.c | 25 ++++++++++++++++++-------
>> include/xen/xen-ops.h | 5 +++++
>> 2 files changed, 23 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c
>> index 0e69aa8..70d5d77 100644
>> --- a/drivers/xen/grant-dma-ops.c
>> +++ b/drivers/xen/grant-dma-ops.c
>> @@ -66,11 +66,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,
>> @@ -277,6 +272,16 @@ 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)
>> +{
>> + /* XXX Handle only DT devices for now */
>> + if (!dev->of_node)
>> + return false;
>> +
>> + return of_property_read_bool(dev->of_node, "xen,dev-domid");
>> +}
>> +EXPORT_SYMBOL_GPL(xen_is_grant_dma_device);
>> +
>> void xen_grant_setup_dma_ops(struct device *dev)
>> {
>> struct xen_grant_dma_data *data;
>> @@ -288,8 +293,14 @@ void xen_grant_setup_dma_ops(struct device *dev)
>> return;
>> }
>>
>> - /* XXX The dom0 is hardcoded as the backend domain for now */
>> - dev_domid = 0;
>> + /* XXX ACPI and PCI devices unsupported for now */
>> + if (dev_is_pci(dev) || !dev->of_node)
>> + goto err;
> I think we can remove the "dev_is_pci" check, right?
I think, yes (at least for now). I will remove the inclusion of #include
<linux/pci.h> as well.
>
>
>> + if (of_property_read_u32(dev->of_node, "xen,dev-domid", &dev_domid)) {
>> + dev_err(dev, "xen,dev-domid property is not present\n");
>> + goto err;
>> + }
>>
>> data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
>> if (!data) {
>> 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
>>
--
Regards,
Oleksandr Tyshchenko
^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [PATCH V1 5/6] xen/grant-dma-ops: Retrieve the ID of backend's domain for DT devices
@ 2022-04-23 15:23 ` Oleksandr
0 siblings, 0 replies; 79+ messages in thread
From: Oleksandr @ 2022-04-23 15:23 UTC (permalink / raw)
To: Stefano Stabellini
Cc: xen-devel, linux-kernel, linux-arm-kernel, Oleksandr Tyshchenko,
Boris Ostrovsky, Juergen Gross, Julien Grall, Michael S. Tsirkin,
Christoph Hellwig
On 23.04.22 02:00, Stefano Stabellini wrote:
Hello Stefano
> On Fri, 22 Apr 2022, Oleksandr Tyshchenko wrote:
>> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>
>> Use the presence of recently introduced "xen,dev-domid" property
>> in the device node as a clear indicator of enabling Xen grant
>> mappings scheme for that device and read the ID of Xen domain where
>> the corresponding backend resides. The ID (domid) is used as
>> an argument to the Xen grant mapping APIs.
>>
>> 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>
>> ---
>> 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
>> ---
>> drivers/xen/grant-dma-ops.c | 25 ++++++++++++++++++-------
>> include/xen/xen-ops.h | 5 +++++
>> 2 files changed, 23 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c
>> index 0e69aa8..70d5d77 100644
>> --- a/drivers/xen/grant-dma-ops.c
>> +++ b/drivers/xen/grant-dma-ops.c
>> @@ -66,11 +66,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,
>> @@ -277,6 +272,16 @@ 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)
>> +{
>> + /* XXX Handle only DT devices for now */
>> + if (!dev->of_node)
>> + return false;
>> +
>> + return of_property_read_bool(dev->of_node, "xen,dev-domid");
>> +}
>> +EXPORT_SYMBOL_GPL(xen_is_grant_dma_device);
>> +
>> void xen_grant_setup_dma_ops(struct device *dev)
>> {
>> struct xen_grant_dma_data *data;
>> @@ -288,8 +293,14 @@ void xen_grant_setup_dma_ops(struct device *dev)
>> return;
>> }
>>
>> - /* XXX The dom0 is hardcoded as the backend domain for now */
>> - dev_domid = 0;
>> + /* XXX ACPI and PCI devices unsupported for now */
>> + if (dev_is_pci(dev) || !dev->of_node)
>> + goto err;
> I think we can remove the "dev_is_pci" check, right?
I think, yes (at least for now). I will remove the inclusion of #include
<linux/pci.h> as well.
>
>
>> + if (of_property_read_u32(dev->of_node, "xen,dev-domid", &dev_domid)) {
>> + dev_err(dev, "xen,dev-domid property is not present\n");
>> + goto err;
>> + }
>>
>> data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
>> if (!data) {
>> 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
>>
--
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] 79+ messages in thread
* Re: [PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen
2022-04-23 9:10 ` Juergen Gross
@ 2022-04-23 15:25 ` Oleksandr
-1 siblings, 0 replies; 79+ messages in thread
From: Oleksandr @ 2022-04-23 15:25 UTC (permalink / raw)
To: Juergen Gross
Cc: Stefano Stabellini, xen-devel, x86, linux-kernel,
linux-arm-kernel, Dave Hansen, Andy Lutomirski, Peter Zijlstra,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin,
Boris Ostrovsky, Julien Grall, Oleksandr Tyshchenko,
Michael S. Tsirkin, Christoph Hellwig
On 23.04.22 12:10, Juergen Gross wrote:
Hello Juergen
> On 23.04.22 09:05, Oleksandr wrote:
>>
>> On 23.04.22 02:00, Stefano Stabellini wrote:
>>
>> Hello Stefano
>>
>>
>>> On Fri, 22 Apr 2022, Oleksandr Tyshchenko wrote:
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> As this also requires providing
>>>> arch_has_restricted_virtio_memory_access
>>>> implementation, switch from a pure stub to a real function on Arm
>>>> and combine with existing implementation for the SEV guests on x86.
>>>>
>>>> Add the needed functionality by providing a special set of DMA ops
>>>> handling the needed grant operations for the I/O pages.
>>>>
>>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>>> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>> There are a couple of minor things that checkpatch.pl reports,
>>
>> Thank you for pointing this out, my fault.
>>
>>
>>> but aside
>>> from those the patch looks fine to me.
>>
>> good
>>
>>
>> The attached diff to be squashed for the new version. One thing remains:
>>
>> checkpatch.pl says regarding drivers/xen/grant-dma-ops.c:
>>
>> WARNING: added, moved or deleted file(s), does MAINTAINERS need
>> updating?
>> #151:
>> new file mode 100644
>>
>>
>> Which, I assume, this is not an issue as new file falls under XEN
>> HYPERVISOR INTERFACE maintainership?
>
> Yes.
ok, thank you for the confirmation.
>
>
> Juergen
--
Regards,
Oleksandr Tyshchenko
^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen
@ 2022-04-23 15:25 ` Oleksandr
0 siblings, 0 replies; 79+ messages in thread
From: Oleksandr @ 2022-04-23 15:25 UTC (permalink / raw)
To: Juergen Gross
Cc: Stefano Stabellini, xen-devel, x86, linux-kernel,
linux-arm-kernel, Dave Hansen, Andy Lutomirski, Peter Zijlstra,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin,
Boris Ostrovsky, Julien Grall, Oleksandr Tyshchenko,
Michael S. Tsirkin, Christoph Hellwig
On 23.04.22 12:10, Juergen Gross wrote:
Hello Juergen
> On 23.04.22 09:05, Oleksandr wrote:
>>
>> On 23.04.22 02:00, Stefano Stabellini wrote:
>>
>> Hello Stefano
>>
>>
>>> On Fri, 22 Apr 2022, Oleksandr Tyshchenko wrote:
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> As this also requires providing
>>>> arch_has_restricted_virtio_memory_access
>>>> implementation, switch from a pure stub to a real function on Arm
>>>> and combine with existing implementation for the SEV guests on x86.
>>>>
>>>> Add the needed functionality by providing a special set of DMA ops
>>>> handling the needed grant operations for the I/O pages.
>>>>
>>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>>> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>> There are a couple of minor things that checkpatch.pl reports,
>>
>> Thank you for pointing this out, my fault.
>>
>>
>>> but aside
>>> from those the patch looks fine to me.
>>
>> good
>>
>>
>> The attached diff to be squashed for the new version. One thing remains:
>>
>> checkpatch.pl says regarding drivers/xen/grant-dma-ops.c:
>>
>> WARNING: added, moved or deleted file(s), does MAINTAINERS need
>> updating?
>> #151:
>> new file mode 100644
>>
>>
>> Which, I assume, this is not an issue as new file falls under XEN
>> HYPERVISOR INTERFACE maintainership?
>
> Yes.
ok, thank you for the confirmation.
>
>
> Juergen
--
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] 79+ messages in thread
* Re: [PATCH V1 1/6] arm/xen: Introduce xen_setup_dma_ops()
2022-04-22 16:50 ` Oleksandr Tyshchenko
@ 2022-04-23 16:32 ` Christoph Hellwig
-1 siblings, 0 replies; 79+ messages in thread
From: Christoph Hellwig @ 2022-04-23 16:32 UTC (permalink / raw)
To: Oleksandr Tyshchenko
Cc: xen-devel, linux-kernel, linux-arm-kernel, Oleksandr Tyshchenko,
Stefano Stabellini, Russell King, Catalin Marinas, Will Deacon,
Boris Ostrovsky, Juergen Gross, Logan Gunthorpe,
David Hildenbrand, Martin Oliveira, Kees Cook,
Jean-Philippe Brucker, Julien Grall, Michael S. Tsirkin,
Christoph Hellwig
On Fri, Apr 22, 2022 at 07:50:58PM +0300, Oleksandr Tyshchenko wrote:
> +#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
Maybe create a proper !CONFIG_XEN stub for xen_swiotlb_detect instead
of the ifdef here, but otherwise this looks good to me.
^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [PATCH V1 1/6] arm/xen: Introduce xen_setup_dma_ops()
@ 2022-04-23 16:32 ` Christoph Hellwig
0 siblings, 0 replies; 79+ messages in thread
From: Christoph Hellwig @ 2022-04-23 16:32 UTC (permalink / raw)
To: Oleksandr Tyshchenko
Cc: xen-devel, linux-kernel, linux-arm-kernel, Oleksandr Tyshchenko,
Stefano Stabellini, Russell King, Catalin Marinas, Will Deacon,
Boris Ostrovsky, Juergen Gross, Logan Gunthorpe,
David Hildenbrand, Martin Oliveira, Kees Cook,
Jean-Philippe Brucker, Julien Grall, Michael S. Tsirkin,
Christoph Hellwig
On Fri, Apr 22, 2022 at 07:50:58PM +0300, Oleksandr Tyshchenko wrote:
> +#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
Maybe create a proper !CONFIG_XEN stub for xen_swiotlb_detect instead
of the ifdef here, but otherwise this looks good to me.
_______________________________________________
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] 79+ messages in thread
* Re: [PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen
2022-04-22 16:51 ` Oleksandr Tyshchenko
@ 2022-04-23 16:40 ` Christoph Hellwig
-1 siblings, 0 replies; 79+ messages in thread
From: Christoph Hellwig @ 2022-04-23 16:40 UTC (permalink / raw)
To: Oleksandr Tyshchenko
Cc: xen-devel, x86, linux-kernel, linux-arm-kernel, Juergen Gross,
Dave Hansen, Andy Lutomirski, Peter Zijlstra, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H. Peter Anvin, Boris Ostrovsky,
Stefano Stabellini, Julien Grall, Oleksandr Tyshchenko,
Michael S. Tsirkin, Christoph Hellwig
Please split this into one patch that creates grant-dma-ops, and another
that sets up the virtio restricted access helpers.
> +
> +#ifdef CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS
> +int arch_has_restricted_virtio_memory_access(void)
> +{
> + return (xen_has_restricted_virtio_memory_access() ||
> + cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT));
> +}
So instead of hardcoding Xen here, this seems like a candidate for
another cc_platform_has flag.
> +config XEN_VIRTIO
> + bool "Xen virtio support"
> + default n
n is the default default, so no need to specify it.
> +// SPDX-License-Identifier: GPL-2.0-only
> +/******************************************************************************
The all * line is not the usual kernel style, I'd suggest to drop it.
> +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)
> +{
> + WARN_ONCE(1, "xen_grant_dma_alloc_pages size %zu\n", size);
> + return NULL;
> +}
> +
> +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)
> +{
> + WARN_ONCE(1, "xen_grant_dma_free_pages size %zu\n", size);
> +}
Please just wire this up to the same implementation as .alloc and .free.
> + spin_lock(&xen_grant_dma_lock);
> + list_add(&data->list, &xen_grant_dma_devices);
> + spin_unlock(&xen_grant_dma_lock);
Hmm, having to do this device lookup for every DMA operation is going
to suck. It might make sense to add a private field (e.g. as a union
with the iommu field) in struct device instead.
But if not you probably want to switch to a more efficient data
structure like the xarray at least.
> +EXPORT_SYMBOL_GPL(xen_grant_setup_dma_ops);
I don't think this has any modular users, or did I miss something?
^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen
@ 2022-04-23 16:40 ` Christoph Hellwig
0 siblings, 0 replies; 79+ messages in thread
From: Christoph Hellwig @ 2022-04-23 16:40 UTC (permalink / raw)
To: Oleksandr Tyshchenko
Cc: xen-devel, x86, linux-kernel, linux-arm-kernel, Juergen Gross,
Dave Hansen, Andy Lutomirski, Peter Zijlstra, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H. Peter Anvin, Boris Ostrovsky,
Stefano Stabellini, Julien Grall, Oleksandr Tyshchenko,
Michael S. Tsirkin, Christoph Hellwig
Please split this into one patch that creates grant-dma-ops, and another
that sets up the virtio restricted access helpers.
> +
> +#ifdef CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS
> +int arch_has_restricted_virtio_memory_access(void)
> +{
> + return (xen_has_restricted_virtio_memory_access() ||
> + cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT));
> +}
So instead of hardcoding Xen here, this seems like a candidate for
another cc_platform_has flag.
> +config XEN_VIRTIO
> + bool "Xen virtio support"
> + default n
n is the default default, so no need to specify it.
> +// SPDX-License-Identifier: GPL-2.0-only
> +/******************************************************************************
The all * line is not the usual kernel style, I'd suggest to drop it.
> +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)
> +{
> + WARN_ONCE(1, "xen_grant_dma_alloc_pages size %zu\n", size);
> + return NULL;
> +}
> +
> +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)
> +{
> + WARN_ONCE(1, "xen_grant_dma_free_pages size %zu\n", size);
> +}
Please just wire this up to the same implementation as .alloc and .free.
> + spin_lock(&xen_grant_dma_lock);
> + list_add(&data->list, &xen_grant_dma_devices);
> + spin_unlock(&xen_grant_dma_lock);
Hmm, having to do this device lookup for every DMA operation is going
to suck. It might make sense to add a private field (e.g. as a union
with the iommu field) in struct device instead.
But if not you probably want to switch to a more efficient data
structure like the xarray at least.
> +EXPORT_SYMBOL_GPL(xen_grant_setup_dma_ops);
I don't think this has any modular users, or did I miss something?
_______________________________________________
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] 79+ messages in thread
* Re: [PATCH V1 6/6] arm/xen: Assign xen-grant DMA ops for xen-grant DMA devices
2022-04-22 16:51 ` Oleksandr Tyshchenko
@ 2022-04-23 16:42 ` Christoph Hellwig
-1 siblings, 0 replies; 79+ messages in thread
From: Christoph Hellwig @ 2022-04-23 16:42 UTC (permalink / raw)
To: Oleksandr Tyshchenko
Cc: xen-devel, linux-kernel, linux-arm-kernel, Oleksandr Tyshchenko,
Boris Ostrovsky, Juergen Gross, Stefano Stabellini, Julien Grall,
Michael S. Tsirkin, Christoph Hellwig
On Fri, Apr 22, 2022 at 07:51:03PM +0300, Oleksandr Tyshchenko wrote:
> static inline void xen_setup_dma_ops(struct device *dev)
> {
> #ifdef CONFIG_XEN
> - if (xen_swiotlb_detect())
> + if (arch_has_restricted_virtio_memory_access() &&
> + xen_is_grant_dma_device(dev))
> + xen_grant_setup_dma_ops(dev);
> + else if (xen_swiotlb_detect())
I don't think that arch_has_restricted_virtio_memory_access
check should be there as it still is a bit of a layering violation.
^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [PATCH V1 6/6] arm/xen: Assign xen-grant DMA ops for xen-grant DMA devices
@ 2022-04-23 16:42 ` Christoph Hellwig
0 siblings, 0 replies; 79+ messages in thread
From: Christoph Hellwig @ 2022-04-23 16:42 UTC (permalink / raw)
To: Oleksandr Tyshchenko
Cc: xen-devel, linux-kernel, linux-arm-kernel, Oleksandr Tyshchenko,
Boris Ostrovsky, Juergen Gross, Stefano Stabellini, Julien Grall,
Michael S. Tsirkin, Christoph Hellwig
On Fri, Apr 22, 2022 at 07:51:03PM +0300, Oleksandr Tyshchenko wrote:
> static inline void xen_setup_dma_ops(struct device *dev)
> {
> #ifdef CONFIG_XEN
> - if (xen_swiotlb_detect())
> + if (arch_has_restricted_virtio_memory_access() &&
> + xen_is_grant_dma_device(dev))
> + xen_grant_setup_dma_ops(dev);
> + else if (xen_swiotlb_detect())
I don't think that arch_has_restricted_virtio_memory_access
check should be there as it still is a bit of a layering violation.
_______________________________________________
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] 79+ messages in thread
* Re: [PATCH V1 6/6] arm/xen: Assign xen-grant DMA ops for xen-grant DMA devices
2022-04-23 16:42 ` Christoph Hellwig
@ 2022-04-24 16:07 ` Oleksandr
-1 siblings, 0 replies; 79+ messages in thread
From: Oleksandr @ 2022-04-24 16:07 UTC (permalink / raw)
To: Christoph Hellwig
Cc: xen-devel, linux-kernel, linux-arm-kernel, Oleksandr Tyshchenko,
Boris Ostrovsky, Juergen Gross, Stefano Stabellini, Julien Grall,
Michael S. Tsirkin
On 23.04.22 19:42, Christoph Hellwig wrote:
Hello Christoph
> On Fri, Apr 22, 2022 at 07:51:03PM +0300, Oleksandr Tyshchenko wrote:
>> static inline void xen_setup_dma_ops(struct device *dev)
>> {
>> #ifdef CONFIG_XEN
>> - if (xen_swiotlb_detect())
>> + if (arch_has_restricted_virtio_memory_access() &&
>> + xen_is_grant_dma_device(dev))
>> + xen_grant_setup_dma_ops(dev);
>> + else if (xen_swiotlb_detect())
> I don't think that arch_has_restricted_virtio_memory_access
> check should be there as it still is a bit of a layering violation.
Well, I will remove it then (and update commit description).
For virtualized but non-virtio devices, it is not needed at all. For the
virtio devices, this check is already present at
virtio.c:virtio_features_ok()
>
--
Regards,
Oleksandr Tyshchenko
^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [PATCH V1 6/6] arm/xen: Assign xen-grant DMA ops for xen-grant DMA devices
@ 2022-04-24 16:07 ` Oleksandr
0 siblings, 0 replies; 79+ messages in thread
From: Oleksandr @ 2022-04-24 16:07 UTC (permalink / raw)
To: Christoph Hellwig
Cc: xen-devel, linux-kernel, linux-arm-kernel, Oleksandr Tyshchenko,
Boris Ostrovsky, Juergen Gross, Stefano Stabellini, Julien Grall,
Michael S. Tsirkin
On 23.04.22 19:42, Christoph Hellwig wrote:
Hello Christoph
> On Fri, Apr 22, 2022 at 07:51:03PM +0300, Oleksandr Tyshchenko wrote:
>> static inline void xen_setup_dma_ops(struct device *dev)
>> {
>> #ifdef CONFIG_XEN
>> - if (xen_swiotlb_detect())
>> + if (arch_has_restricted_virtio_memory_access() &&
>> + xen_is_grant_dma_device(dev))
>> + xen_grant_setup_dma_ops(dev);
>> + else if (xen_swiotlb_detect())
> I don't think that arch_has_restricted_virtio_memory_access
> check should be there as it still is a bit of a layering violation.
Well, I will remove it then (and update commit description).
For virtualized but non-virtio devices, it is not needed at all. For the
virtio devices, this check is already present at
virtio.c:virtio_features_ok()
>
--
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] 79+ messages in thread
* Re: [PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen
2022-04-23 16:40 ` Christoph Hellwig
@ 2022-04-24 16:53 ` Oleksandr
-1 siblings, 0 replies; 79+ messages in thread
From: Oleksandr @ 2022-04-24 16:53 UTC (permalink / raw)
To: Christoph Hellwig
Cc: xen-devel, x86, linux-kernel, linux-arm-kernel, Juergen Gross,
Dave Hansen, Andy Lutomirski, Peter Zijlstra, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H. Peter Anvin, Boris Ostrovsky,
Stefano Stabellini, Julien Grall, Oleksandr Tyshchenko,
Michael S. Tsirkin
On 23.04.22 19:40, Christoph Hellwig wrote:
Hello Christoph
> Please split this into one patch that creates grant-dma-ops, and another
> that sets up the virtio restricted access helpers.
Sounds reasonable, will do:
1. grant-dma-ops.c with config XEN_GRANT_DMA_OPS
2. arch_has_restricted_virtio_memory_access() with config XEN_VIRTIO
>
>> +
>> +#ifdef CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS
>> +int arch_has_restricted_virtio_memory_access(void)
>> +{
>> + return (xen_has_restricted_virtio_memory_access() ||
>> + cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT));
>> +}
> So instead of hardcoding Xen here, this seems like a candidate for
> another cc_platform_has flag.
I have a limited knowledge of x86 and Xen on x86.
Would the Xen specific bits fit into Confidential Computing Platform
checks? I will let Juergen/Boris comment on this.
>
>> +config XEN_VIRTIO
>> + bool "Xen virtio support"
>> + default n
> n is the default default, so no need to specify it.
ok, will drop
>
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/******************************************************************************
> The all * line is not the usual kernel style, I'd suggest to drop it.
ok, will drop
>
>> +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)
>> +{
>> + WARN_ONCE(1, "xen_grant_dma_alloc_pages size %zu\n", size);
>> + return NULL;
>> +}
>> +
>> +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)
>> +{
>> + WARN_ONCE(1, "xen_grant_dma_free_pages size %zu\n", size);
>> +}
> Please just wire this up to the same implementation as .alloc and .free.
I got it, will implement
>
>> + spin_lock(&xen_grant_dma_lock);
>> + list_add(&data->list, &xen_grant_dma_devices);
>> + spin_unlock(&xen_grant_dma_lock);
> Hmm, having to do this device lookup for every DMA operation is going
> to suck. It might make sense to add a private field (e.g. as a union
> with the iommu field) in struct device instead.
I was thinking about it, but decided to not alter common struct device
for adding Xen specific field, but haven't managed to think of a better
idea than just using that brute lookup ...
>
> But if not you probably want to switch to a more efficient data
> structure like the xarray at least.
... I think, this is good point, thank you. I have no idea how faster it
is going to be, but the resulting code looks simple (if of course I
correctly understood the usage of xarray)
diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c
index a512c0a..7ecc0b0 100644
--- a/drivers/xen/grant-dma-ops.c
+++ b/drivers/xen/grant-dma-ops.c
@@ -11,6 +11,7 @@
#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>
@@ -19,12 +20,9 @@ struct xen_grant_dma_data {
domid_t dev_domid;
/* Is device behaving sane? */
bool broken;
- struct device *dev;
- struct list_head list;
};
-static LIST_HEAD(xen_grant_dma_devices);
-static DEFINE_SPINLOCK(xen_grant_dma_lock);
+static DEFINE_XARRAY(xen_grant_dma_devices);
#define XEN_GRANT_DMA_ADDR_OFF (1ULL << 63)
@@ -40,21 +38,13 @@ static inline grant_ref_t dma_to_grant(dma_addr_t dma)
static struct xen_grant_dma_data *find_xen_grant_dma_data(struct
device *dev)
{
- struct xen_grant_dma_data *data = NULL;
- bool found = false;
-
- spin_lock(&xen_grant_dma_lock);
-
- list_for_each_entry(data, &xen_grant_dma_devices, list) {
- if (data->dev == dev) {
- found = true;
- break;
- }
- }
+ struct xen_grant_dma_data *data;
- spin_unlock(&xen_grant_dma_lock);
+ xa_lock(&xen_grant_dma_devices);
+ data = xa_load(&xen_grant_dma_devices, (unsigned long)dev);
+ xa_unlock(&xen_grant_dma_devices);
- return found ? data : NULL;
+ return data;
}
/*
@@ -310,11 +300,12 @@ void xen_grant_setup_dma_ops(struct device *dev)
goto err;
data->dev_domid = dev_domid;
- data->dev = dev;
- spin_lock(&xen_grant_dma_lock);
- list_add(&data->list, &xen_grant_dma_devices);
- spin_unlock(&xen_grant_dma_lock);
+ 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;
>
>> +EXPORT_SYMBOL_GPL(xen_grant_setup_dma_ops);
> I don't think this has any modular users, or did I miss something?
No, you didn't. Will drop here and in the next patch for
xen_is_grant_dma_device() as well.
--
Regards,
Oleksandr Tyshchenko
^ permalink raw reply related [flat|nested] 79+ messages in thread
* Re: [PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen
@ 2022-04-24 16:53 ` Oleksandr
0 siblings, 0 replies; 79+ messages in thread
From: Oleksandr @ 2022-04-24 16:53 UTC (permalink / raw)
To: Christoph Hellwig
Cc: xen-devel, x86, linux-kernel, linux-arm-kernel, Juergen Gross,
Dave Hansen, Andy Lutomirski, Peter Zijlstra, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H. Peter Anvin, Boris Ostrovsky,
Stefano Stabellini, Julien Grall, Oleksandr Tyshchenko,
Michael S. Tsirkin
On 23.04.22 19:40, Christoph Hellwig wrote:
Hello Christoph
> Please split this into one patch that creates grant-dma-ops, and another
> that sets up the virtio restricted access helpers.
Sounds reasonable, will do:
1. grant-dma-ops.c with config XEN_GRANT_DMA_OPS
2. arch_has_restricted_virtio_memory_access() with config XEN_VIRTIO
>
>> +
>> +#ifdef CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS
>> +int arch_has_restricted_virtio_memory_access(void)
>> +{
>> + return (xen_has_restricted_virtio_memory_access() ||
>> + cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT));
>> +}
> So instead of hardcoding Xen here, this seems like a candidate for
> another cc_platform_has flag.
I have a limited knowledge of x86 and Xen on x86.
Would the Xen specific bits fit into Confidential Computing Platform
checks? I will let Juergen/Boris comment on this.
>
>> +config XEN_VIRTIO
>> + bool "Xen virtio support"
>> + default n
> n is the default default, so no need to specify it.
ok, will drop
>
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/******************************************************************************
> The all * line is not the usual kernel style, I'd suggest to drop it.
ok, will drop
>
>> +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)
>> +{
>> + WARN_ONCE(1, "xen_grant_dma_alloc_pages size %zu\n", size);
>> + return NULL;
>> +}
>> +
>> +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)
>> +{
>> + WARN_ONCE(1, "xen_grant_dma_free_pages size %zu\n", size);
>> +}
> Please just wire this up to the same implementation as .alloc and .free.
I got it, will implement
>
>> + spin_lock(&xen_grant_dma_lock);
>> + list_add(&data->list, &xen_grant_dma_devices);
>> + spin_unlock(&xen_grant_dma_lock);
> Hmm, having to do this device lookup for every DMA operation is going
> to suck. It might make sense to add a private field (e.g. as a union
> with the iommu field) in struct device instead.
I was thinking about it, but decided to not alter common struct device
for adding Xen specific field, but haven't managed to think of a better
idea than just using that brute lookup ...
>
> But if not you probably want to switch to a more efficient data
> structure like the xarray at least.
... I think, this is good point, thank you. I have no idea how faster it
is going to be, but the resulting code looks simple (if of course I
correctly understood the usage of xarray)
diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c
index a512c0a..7ecc0b0 100644
--- a/drivers/xen/grant-dma-ops.c
+++ b/drivers/xen/grant-dma-ops.c
@@ -11,6 +11,7 @@
#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>
@@ -19,12 +20,9 @@ struct xen_grant_dma_data {
domid_t dev_domid;
/* Is device behaving sane? */
bool broken;
- struct device *dev;
- struct list_head list;
};
-static LIST_HEAD(xen_grant_dma_devices);
-static DEFINE_SPINLOCK(xen_grant_dma_lock);
+static DEFINE_XARRAY(xen_grant_dma_devices);
#define XEN_GRANT_DMA_ADDR_OFF (1ULL << 63)
@@ -40,21 +38,13 @@ static inline grant_ref_t dma_to_grant(dma_addr_t dma)
static struct xen_grant_dma_data *find_xen_grant_dma_data(struct
device *dev)
{
- struct xen_grant_dma_data *data = NULL;
- bool found = false;
-
- spin_lock(&xen_grant_dma_lock);
-
- list_for_each_entry(data, &xen_grant_dma_devices, list) {
- if (data->dev == dev) {
- found = true;
- break;
- }
- }
+ struct xen_grant_dma_data *data;
- spin_unlock(&xen_grant_dma_lock);
+ xa_lock(&xen_grant_dma_devices);
+ data = xa_load(&xen_grant_dma_devices, (unsigned long)dev);
+ xa_unlock(&xen_grant_dma_devices);
- return found ? data : NULL;
+ return data;
}
/*
@@ -310,11 +300,12 @@ void xen_grant_setup_dma_ops(struct device *dev)
goto err;
data->dev_domid = dev_domid;
- data->dev = dev;
- spin_lock(&xen_grant_dma_lock);
- list_add(&data->list, &xen_grant_dma_devices);
- spin_unlock(&xen_grant_dma_lock);
+ 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;
>
>> +EXPORT_SYMBOL_GPL(xen_grant_setup_dma_ops);
> I don't think this has any modular users, or did I miss something?
No, you didn't. Will drop here and in the next patch for
xen_is_grant_dma_device() as well.
--
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 related [flat|nested] 79+ messages in thread
* Re: [PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen
2022-04-24 16:53 ` Oleksandr
@ 2022-04-24 18:08 ` Boris Ostrovsky
-1 siblings, 0 replies; 79+ messages in thread
From: Boris Ostrovsky @ 2022-04-24 18:08 UTC (permalink / raw)
To: Oleksandr, Christoph Hellwig
Cc: xen-devel, x86, linux-kernel, linux-arm-kernel, Juergen Gross,
Dave Hansen, Andy Lutomirski, Peter Zijlstra, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H. Peter Anvin, Stefano Stabellini,
Julien Grall, Oleksandr Tyshchenko, Michael S. Tsirkin
On 4/24/22 12:53 PM, Oleksandr wrote:
>
> On 23.04.22 19:40, Christoph Hellwig wrote:
>
>
>
>
>>
>>> +
>>> +#ifdef CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS
>>> +int arch_has_restricted_virtio_memory_access(void)
>>> +{
>>> + return (xen_has_restricted_virtio_memory_access() ||
>>> + cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT));
>>> +}
>> So instead of hardcoding Xen here, this seems like a candidate for
>> another cc_platform_has flag.
>
>
> I have a limited knowledge of x86 and Xen on x86.
>
> Would the Xen specific bits fit into Confidential Computing Platform checks? I will let Juergen/Boris comment on this.
>
This is unrelated to confidential so I don't think we can add another CC_ flag.
Would arch/x86/kernel/cpu/hypervisor.c be a better home for this?
-boris
^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen
@ 2022-04-24 18:08 ` Boris Ostrovsky
0 siblings, 0 replies; 79+ messages in thread
From: Boris Ostrovsky @ 2022-04-24 18:08 UTC (permalink / raw)
To: Oleksandr, Christoph Hellwig
Cc: xen-devel, x86, linux-kernel, linux-arm-kernel, Juergen Gross,
Dave Hansen, Andy Lutomirski, Peter Zijlstra, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H. Peter Anvin, Stefano Stabellini,
Julien Grall, Oleksandr Tyshchenko, Michael S. Tsirkin
On 4/24/22 12:53 PM, Oleksandr wrote:
>
> On 23.04.22 19:40, Christoph Hellwig wrote:
>
>
>
>
>>
>>> +
>>> +#ifdef CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS
>>> +int arch_has_restricted_virtio_memory_access(void)
>>> +{
>>> + return (xen_has_restricted_virtio_memory_access() ||
>>> + cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT));
>>> +}
>> So instead of hardcoding Xen here, this seems like a candidate for
>> another cc_platform_has flag.
>
>
> I have a limited knowledge of x86 and Xen on x86.
>
> Would the Xen specific bits fit into Confidential Computing Platform checks? I will let Juergen/Boris comment on this.
>
This is unrelated to confidential so I don't think we can add another CC_ flag.
Would arch/x86/kernel/cpu/hypervisor.c be a better home for this?
-boris
_______________________________________________
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] 79+ messages in thread
* Re: [PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen
2022-04-24 16:53 ` Oleksandr
@ 2022-04-25 7:47 ` Juergen Gross
-1 siblings, 0 replies; 79+ messages in thread
From: Juergen Gross @ 2022-04-25 7:47 UTC (permalink / raw)
To: Oleksandr, Christoph Hellwig
Cc: xen-devel, x86, linux-kernel, linux-arm-kernel, Dave Hansen,
Andy Lutomirski, Peter Zijlstra, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H. Peter Anvin, Boris Ostrovsky,
Stefano Stabellini, Julien Grall, Oleksandr Tyshchenko,
Michael S. Tsirkin
[-- Attachment #1.1.1: Type: text/plain, Size: 1215 bytes --]
On 24.04.22 18:53, Oleksandr wrote:
>
> On 23.04.22 19:40, Christoph Hellwig wrote:
>
>
> Hello Christoph
>
>> Please split this into one patch that creates grant-dma-ops, and another
>> that sets up the virtio restricted access helpers.
>
>
> Sounds reasonable, will do:
>
> 1. grant-dma-ops.c with config XEN_GRANT_DMA_OPS
>
> 2. arch_has_restricted_virtio_memory_access() with config XEN_VIRTIO
>
>
>>
>>> +
>>> +#ifdef CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS
>>> +int arch_has_restricted_virtio_memory_access(void)
>>> +{
>>> + return (xen_has_restricted_virtio_memory_access() ||
>>> + cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT));
>>> +}
>> So instead of hardcoding Xen here, this seems like a candidate for
>> another cc_platform_has flag.
>
>
> I have a limited knowledge of x86 and Xen on x86.
>
> Would the Xen specific bits fit into Confidential Computing Platform checks? I
> will let Juergen/Boris comment on this.
I don't think cc_platform_has would be correct here. Xen certainly
provides more isolation between guests and dom0, but "Confidential
Computing" is basically orthogonal to that feature.
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] 79+ messages in thread
* Re: [PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen
@ 2022-04-25 7:47 ` Juergen Gross
0 siblings, 0 replies; 79+ messages in thread
From: Juergen Gross @ 2022-04-25 7:47 UTC (permalink / raw)
To: Oleksandr, Christoph Hellwig
Cc: xen-devel, x86, linux-kernel, linux-arm-kernel, Dave Hansen,
Andy Lutomirski, Peter Zijlstra, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H. Peter Anvin, Boris Ostrovsky,
Stefano Stabellini, Julien Grall, Oleksandr Tyshchenko,
Michael S. Tsirkin
[-- Attachment #1.1.1.1: Type: text/plain, Size: 1215 bytes --]
On 24.04.22 18:53, Oleksandr wrote:
>
> On 23.04.22 19:40, Christoph Hellwig wrote:
>
>
> Hello Christoph
>
>> Please split this into one patch that creates grant-dma-ops, and another
>> that sets up the virtio restricted access helpers.
>
>
> Sounds reasonable, will do:
>
> 1. grant-dma-ops.c with config XEN_GRANT_DMA_OPS
>
> 2. arch_has_restricted_virtio_memory_access() with config XEN_VIRTIO
>
>
>>
>>> +
>>> +#ifdef CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS
>>> +int arch_has_restricted_virtio_memory_access(void)
>>> +{
>>> + return (xen_has_restricted_virtio_memory_access() ||
>>> + cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT));
>>> +}
>> So instead of hardcoding Xen here, this seems like a candidate for
>> another cc_platform_has flag.
>
>
> I have a limited knowledge of x86 and Xen on x86.
>
> Would the Xen specific bits fit into Confidential Computing Platform checks? I
> will let Juergen/Boris comment on this.
I don't think cc_platform_has would be correct here. Xen certainly
provides more isolation between guests and dom0, but "Confidential
Computing" is basically orthogonal to that feature.
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] 79+ messages in thread
* Re: [PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen
2022-04-24 18:08 ` Boris Ostrovsky
@ 2022-04-25 7:53 ` Juergen Gross
-1 siblings, 0 replies; 79+ messages in thread
From: Juergen Gross @ 2022-04-25 7:53 UTC (permalink / raw)
To: Boris Ostrovsky, Oleksandr, Christoph Hellwig
Cc: xen-devel, x86, linux-kernel, linux-arm-kernel, Dave Hansen,
Andy Lutomirski, Peter Zijlstra, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H. Peter Anvin, Stefano Stabellini,
Julien Grall, Oleksandr Tyshchenko, Michael S. Tsirkin
[-- Attachment #1.1.1.1: Type: text/plain, Size: 990 bytes --]
On 24.04.22 20:08, Boris Ostrovsky wrote:
>
> On 4/24/22 12:53 PM, Oleksandr wrote:
>>
>> On 23.04.22 19:40, Christoph Hellwig wrote:
>>
>>
>>
>>
>>>
>>>> +
>>>> +#ifdef CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS
>>>> +int arch_has_restricted_virtio_memory_access(void)
>>>> +{
>>>> + return (xen_has_restricted_virtio_memory_access() ||
>>>> + cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT));
>>>> +}
>>> So instead of hardcoding Xen here, this seems like a candidate for
>>> another cc_platform_has flag.
>>
>>
>> I have a limited knowledge of x86 and Xen on x86.
>>
>> Would the Xen specific bits fit into Confidential Computing Platform checks? I
>> will let Juergen/Boris comment on this.
>>
>
> This is unrelated to confidential so I don't think we can add another CC_ flag.
>
>
> Would arch/x86/kernel/cpu/hypervisor.c be a better home for this?
Or a callback in struct struct x86_hyper_runtime maybe?
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] 79+ messages in thread
* Re: [PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen
@ 2022-04-25 7:53 ` Juergen Gross
0 siblings, 0 replies; 79+ messages in thread
From: Juergen Gross @ 2022-04-25 7:53 UTC (permalink / raw)
To: Boris Ostrovsky, Oleksandr, Christoph Hellwig
Cc: xen-devel, x86, linux-kernel, linux-arm-kernel, Dave Hansen,
Andy Lutomirski, Peter Zijlstra, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H. Peter Anvin, Stefano Stabellini,
Julien Grall, Oleksandr Tyshchenko, Michael S. Tsirkin
[-- Attachment #1.1.1: Type: text/plain, Size: 990 bytes --]
On 24.04.22 20:08, Boris Ostrovsky wrote:
>
> On 4/24/22 12:53 PM, Oleksandr wrote:
>>
>> On 23.04.22 19:40, Christoph Hellwig wrote:
>>
>>
>>
>>
>>>
>>>> +
>>>> +#ifdef CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS
>>>> +int arch_has_restricted_virtio_memory_access(void)
>>>> +{
>>>> + return (xen_has_restricted_virtio_memory_access() ||
>>>> + cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT));
>>>> +}
>>> So instead of hardcoding Xen here, this seems like a candidate for
>>> another cc_platform_has flag.
>>
>>
>> I have a limited knowledge of x86 and Xen on x86.
>>
>> Would the Xen specific bits fit into Confidential Computing Platform checks? I
>> will let Juergen/Boris comment on this.
>>
>
> This is unrelated to confidential so I don't think we can add another CC_ flag.
>
>
> Would arch/x86/kernel/cpu/hypervisor.c be a better home for this?
Or a callback in struct struct x86_hyper_runtime maybe?
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] 79+ messages in thread
* Re: [PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen
2022-04-25 7:47 ` Juergen Gross
@ 2022-04-25 7:58 ` Christoph Hellwig
-1 siblings, 0 replies; 79+ messages in thread
From: Christoph Hellwig @ 2022-04-25 7:58 UTC (permalink / raw)
To: Juergen Gross
Cc: Oleksandr, Christoph Hellwig, xen-devel, x86, linux-kernel,
linux-arm-kernel, Dave Hansen, Andy Lutomirski, Peter Zijlstra,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin,
Boris Ostrovsky, Stefano Stabellini, Julien Grall,
Oleksandr Tyshchenko, Michael S. Tsirkin, Tom Lendacky
On Mon, Apr 25, 2022 at 09:47:49AM +0200, Juergen Gross wrote:
> > Would the Xen specific bits fit into Confidential Computing Platform
> > checks? I will let Juergen/Boris comment on this.
>
> I don't think cc_platform_has would be correct here. Xen certainly
> provides more isolation between guests and dom0, but "Confidential
> Computing" is basically orthogonal to that feature.
The point of cc_platform_has is to remove all these open code checks.
If a Xen hypervisor / dom0 can't access arbitrary guest memory for
virtual I/O and we need special APIs for that it certainly false
into the scope of cc_platform_has, even if the confientiality is
rather limited.
^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen
@ 2022-04-25 7:58 ` Christoph Hellwig
0 siblings, 0 replies; 79+ messages in thread
From: Christoph Hellwig @ 2022-04-25 7:58 UTC (permalink / raw)
To: Juergen Gross
Cc: Oleksandr, Christoph Hellwig, xen-devel, x86, linux-kernel,
linux-arm-kernel, Dave Hansen, Andy Lutomirski, Peter Zijlstra,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin,
Boris Ostrovsky, Stefano Stabellini, Julien Grall,
Oleksandr Tyshchenko, Michael S. Tsirkin, Tom Lendacky
On Mon, Apr 25, 2022 at 09:47:49AM +0200, Juergen Gross wrote:
> > Would the Xen specific bits fit into Confidential Computing Platform
> > checks? I will let Juergen/Boris comment on this.
>
> I don't think cc_platform_has would be correct here. Xen certainly
> provides more isolation between guests and dom0, but "Confidential
> Computing" is basically orthogonal to that feature.
The point of cc_platform_has is to remove all these open code checks.
If a Xen hypervisor / dom0 can't access arbitrary guest memory for
virtual I/O and we need special APIs for that it certainly false
into the scope of cc_platform_has, even if the confientiality is
rather limited.
_______________________________________________
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] 79+ messages in thread
* Re: [PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen
2022-04-25 7:58 ` Christoph Hellwig
@ 2022-04-25 9:14 ` Juergen Gross
-1 siblings, 0 replies; 79+ messages in thread
From: Juergen Gross @ 2022-04-25 9:14 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Oleksandr, xen-devel, x86, linux-kernel, linux-arm-kernel,
Dave Hansen, Andy Lutomirski, Peter Zijlstra, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H. Peter Anvin, Boris Ostrovsky,
Stefano Stabellini, Julien Grall, Oleksandr Tyshchenko,
Michael S. Tsirkin, Tom Lendacky
[-- Attachment #1.1.1: Type: text/plain, Size: 823 bytes --]
On 25.04.22 09:58, Christoph Hellwig wrote:
> On Mon, Apr 25, 2022 at 09:47:49AM +0200, Juergen Gross wrote:
>>> Would the Xen specific bits fit into Confidential Computing Platform
>>> checks? I will let Juergen/Boris comment on this.
>>
>> I don't think cc_platform_has would be correct here. Xen certainly
>> provides more isolation between guests and dom0, but "Confidential
>> Computing" is basically orthogonal to that feature.
>
> The point of cc_platform_has is to remove all these open code checks.
> If a Xen hypervisor / dom0 can't access arbitrary guest memory for
> virtual I/O and we need special APIs for that it certainly false
> into the scope of cc_platform_has, even if the confientiality is
> rather limited.
In case the x86 maintainers are fine with that I won't oppose.
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] 79+ messages in thread
* Re: [PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen
@ 2022-04-25 9:14 ` Juergen Gross
0 siblings, 0 replies; 79+ messages in thread
From: Juergen Gross @ 2022-04-25 9:14 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Oleksandr, xen-devel, x86, linux-kernel, linux-arm-kernel,
Dave Hansen, Andy Lutomirski, Peter Zijlstra, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H. Peter Anvin, Boris Ostrovsky,
Stefano Stabellini, Julien Grall, Oleksandr Tyshchenko,
Michael S. Tsirkin, Tom Lendacky
[-- Attachment #1.1.1.1: Type: text/plain, Size: 823 bytes --]
On 25.04.22 09:58, Christoph Hellwig wrote:
> On Mon, Apr 25, 2022 at 09:47:49AM +0200, Juergen Gross wrote:
>>> Would the Xen specific bits fit into Confidential Computing Platform
>>> checks? I will let Juergen/Boris comment on this.
>>
>> I don't think cc_platform_has would be correct here. Xen certainly
>> provides more isolation between guests and dom0, but "Confidential
>> Computing" is basically orthogonal to that feature.
>
> The point of cc_platform_has is to remove all these open code checks.
> If a Xen hypervisor / dom0 can't access arbitrary guest memory for
> virtual I/O and we need special APIs for that it certainly false
> into the scope of cc_platform_has, even if the confientiality is
> rather limited.
In case the x86 maintainers are fine with that I won't oppose.
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] 79+ messages in thread
* Re: [PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen
2022-04-25 9:14 ` Juergen Gross
@ 2022-04-25 20:38 ` Oleksandr
-1 siblings, 0 replies; 79+ messages in thread
From: Oleksandr @ 2022-04-25 20:38 UTC (permalink / raw)
To: Juergen Gross, Christoph Hellwig, Boris Ostrovsky, Stefano Stabellini
Cc: xen-devel, x86, linux-kernel, linux-arm-kernel, Dave Hansen,
Andy Lutomirski, Peter Zijlstra, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H. Peter Anvin, Julien Grall,
Oleksandr Tyshchenko, Michael S. Tsirkin, Tom Lendacky
Hello all.
On 25.04.22 12:14, Juergen Gross wrote:
> On 25.04.22 09:58, Christoph Hellwig wrote:
>> On Mon, Apr 25, 2022 at 09:47:49AM +0200, Juergen Gross wrote:
>>>> Would the Xen specific bits fit into Confidential Computing Platform
>>>> checks? I will let Juergen/Boris comment on this.
>>>
>>> I don't think cc_platform_has would be correct here. Xen certainly
>>> provides more isolation between guests and dom0, but "Confidential
>>> Computing" is basically orthogonal to that feature.
>>
>> The point of cc_platform_has is to remove all these open code checks.
>> If a Xen hypervisor / dom0 can't access arbitrary guest memory for
>> virtual I/O and we need special APIs for that it certainly false
>> into the scope of cc_platform_has, even if the confientiality is
>> rather limited.
>
> In case the x86 maintainers are fine with that I won't oppose.
>
>
> Juergen
[I have discussed with Juergen on IRC about it.]
Well, if cc_platform_has() is a way to go (at least on x86), below some
thoughts about possible integration (if, of course, I got the idea and
code correctly).
1. We will need to introduce new attribute
CC_ATTR_GUEST_MEM_ACCESS_RESTRICTED
as we can't reuse CC_ATTR_GUEST_MEM_ENCRYPT (in case of Xen the Guest
memory is not encrypted). New attribute is automatically set if Guest
memory encryption is active (CC_ATTR_GUEST_MEM_ENCRYPT is set). Also new
attribute is set if restricted memory access using Xen grant mappings is
active. This will allow us to have a single check in
arch_has_restricted_virtio_memory_access() which covers both cases: Xen
and SEV
int arch_has_restricted_virtio_memory_access(void)
{
return cc_platform_has(CC_ATTR_GUEST_MEM_ACCESS_RESTRICTED);
}
2. We will need to introduce new vendor CC_VENDOR_XXX for our case (I
have chosen XEN, although I am not sure it is a good fit) which deals
with new attribute only.
3. Xen code then will call cc_set_vendor(CC_VENDOR_XEN) for different
modes (PV, HVM, etc) during initialization if restricted memory access
using Xen grant mappings is enabled.
Below the diff (not tested and without x86's PVH) how it could look like:
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index ec5b082..0284aa7 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -409,6 +409,14 @@ int __init arch_xen_unpopulated_init(struct
resource **res)
}
#endif
+#ifdef CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS
+int arch_has_restricted_virtio_memory_access(void)
+{
+ return IS_ENABLED(CONFIG_XEN_VIRTIO) && xen_domain();
+}
+EXPORT_SYMBOL_GPL(arch_has_restricted_virtio_memory_access);
+#endif
+
static void __init xen_dt_guest_init(void)
{
struct device_node *xen_node;
diff --git a/arch/x86/coco/core.c b/arch/x86/coco/core.c
index fc1365d..9020a60 100644
--- a/arch/x86/coco/core.c
+++ b/arch/x86/coco/core.c
@@ -44,6 +44,7 @@ static bool amd_cc_platform_has(enum cc_attr attr)
return sme_me_mask && !(sev_status &
MSR_AMD64_SEV_ENABLED);
case CC_ATTR_GUEST_MEM_ENCRYPT:
+ case CC_ATTR_GUEST_MEM_ACCESS_RESTRICTED:
return sev_status & MSR_AMD64_SEV_ENABLED;
case CC_ATTR_GUEST_STATE_ENCRYPT:
@@ -67,7 +68,19 @@ static bool amd_cc_platform_has(enum cc_attr attr)
static bool hyperv_cc_platform_has(enum cc_attr attr)
{
- return attr == CC_ATTR_GUEST_MEM_ENCRYPT;
+ switch (attr) {
+ case CC_ATTR_GUEST_MEM_ENCRYPT:
+ case CC_ATTR_GUEST_MEM_ACCESS_RESTRICTED:
+ return true;
+
+ default:
+ return false;
+ }
+}
+
+static bool xen_cc_platform_has(enum cc_attr attr)
+{
+ return attr == CC_ATTR_GUEST_MEM_ACCESS_RESTRICTED;
}
bool cc_platform_has(enum cc_attr attr)
@@ -79,6 +92,8 @@ bool cc_platform_has(enum cc_attr attr)
return intel_cc_platform_has(attr);
case CC_VENDOR_HYPERV:
return hyperv_cc_platform_has(attr);
+ case CC_VENDOR_XEN:
+ return xen_cc_platform_has(attr);
default:
return false;
}
@@ -115,3 +130,11 @@ __init void cc_set_mask(u64 mask)
{
cc_mask = mask;
}
+
+#ifdef CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS
+int arch_has_restricted_virtio_memory_access(void)
+{
+ return cc_platform_has(CC_ATTR_GUEST_MEM_ACCESS_RESTRICTED);
+}
+EXPORT_SYMBOL_GPL(arch_has_restricted_virtio_memory_access);
+#endif
diff --git a/arch/x86/include/asm/coco.h b/arch/x86/include/asm/coco.h
index 3d98c3a..6395ec1 100644
--- a/arch/x86/include/asm/coco.h
+++ b/arch/x86/include/asm/coco.h
@@ -9,6 +9,7 @@ enum cc_vendor {
CC_VENDOR_AMD,
CC_VENDOR_HYPERV,
CC_VENDOR_INTEL,
+ CC_VENDOR_XEN,
};
void cc_set_vendor(enum cc_vendor v);
diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
index 50d2099..dda020f 100644
--- a/arch/x86/mm/mem_encrypt.c
+++ b/arch/x86/mm/mem_encrypt.c
@@ -77,8 +77,3 @@ void __init mem_encrypt_init(void)
print_mem_encrypt_feature_info();
}
-int arch_has_restricted_virtio_memory_access(void)
-{
- return cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT);
-}
-EXPORT_SYMBOL_GPL(arch_has_restricted_virtio_memory_access);
diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 85246dd..79cb30f 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -8,6 +8,7 @@ config XEN
depends on PARAVIRT
select PARAVIRT_CLOCK
select X86_HV_CALLBACK_VECTOR
+ select ARCH_HAS_CC_PLATFORM
depends on X86_64 || (X86_32 && X86_PAE)
depends on X86_LOCAL_APIC && X86_TSC
help
diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
index 517a9d8..11c3f4e 100644
--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -195,6 +195,9 @@ static void __init xen_hvm_guest_init(void)
if (xen_pv_domain())
return;
+ if (IS_ENABLED(CONFIG_XEN_VIRTIO))
+ cc_set_vendor(CC_VENDOR_XEN);
+
init_hvm_pv_info();
reserve_shared_info();
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 5038edb..2fe5aaa 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -109,6 +109,9 @@ static DEFINE_PER_CPU(struct tls_descs,
shadow_tls_desc);
static void __init xen_pv_init_platform(void)
{
+ if (IS_ENABLED(CONFIG_XEN_VIRTIO))
+ cc_set_vendor(CC_VENDOR_XEN);
+
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..d3179f8 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -339,4 +339,16 @@ config XEN_GRANT_DMA_OPS
bool
select DMA_OPS
+config XEN_VIRTIO
+ bool "Xen virtio support"
+ depends on VIRTIO
+ select ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS
+ 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/linux/cc_platform.h b/include/linux/cc_platform.h
index efd8205..d06bc7a 100644
--- a/include/linux/cc_platform.h
+++ b/include/linux/cc_platform.h
@@ -72,6 +72,19 @@ enum cc_attr {
* Examples include TDX guest & SEV.
*/
CC_ATTR_GUEST_UNROLL_STRING_IO,
+
+ /**
+ * @CC_ATTR_GUEST_MEM_ACCESS_RESTRICTED: Restricted memory access to
+ * Guest memory is active
+ *
+ * The platform/OS is running as a guest/virtual machine and uses
+ * the restricted access to its memory. This attribute is set if
either
+ * Guest memory encryption or restricted memory access using Xen
grant
+ * mappings is active.
+ *
+ * Examples include Xen guest and SEV.
+ */
+ CC_ATTR_GUEST_MEM_ACCESS_RESTRICTED,
};
#ifdef CONFIG_ARCH_HAS_CC_PLATFORM
(END)
On Arm I left simple variant simply because of no users of cc_platform.
int arch_has_restricted_virtio_memory_access(void)
{
return IS_ENABLED(CONFIG_XEN_VIRTIO) && xen_domain();
}
But, we could have something simple here:
bool cc_platform_has(enum cc_attr attr)
{
switch (attr) {
case CC_ATTR_GUEST_MEM_ACCESS_RESTRICTED:
return IS_ENABLED(CONFIG_XEN_VIRTIO) && xen_domain();
default:
return false;
}
}
int arch_has_restricted_virtio_memory_access(void)
{
return cc_platform_has(CC_ATTR_GUEST_MEM_ACCESS_RESTRICTED);
}
Any thoughts?
--
Regards,
Oleksandr Tyshchenko
^ permalink raw reply related [flat|nested] 79+ messages in thread
* Re: [PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen
@ 2022-04-25 20:38 ` Oleksandr
0 siblings, 0 replies; 79+ messages in thread
From: Oleksandr @ 2022-04-25 20:38 UTC (permalink / raw)
To: Juergen Gross, Christoph Hellwig, Boris Ostrovsky, Stefano Stabellini
Cc: xen-devel, x86, linux-kernel, linux-arm-kernel, Dave Hansen,
Andy Lutomirski, Peter Zijlstra, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H. Peter Anvin, Julien Grall,
Oleksandr Tyshchenko, Michael S. Tsirkin, Tom Lendacky
Hello all.
On 25.04.22 12:14, Juergen Gross wrote:
> On 25.04.22 09:58, Christoph Hellwig wrote:
>> On Mon, Apr 25, 2022 at 09:47:49AM +0200, Juergen Gross wrote:
>>>> Would the Xen specific bits fit into Confidential Computing Platform
>>>> checks? I will let Juergen/Boris comment on this.
>>>
>>> I don't think cc_platform_has would be correct here. Xen certainly
>>> provides more isolation between guests and dom0, but "Confidential
>>> Computing" is basically orthogonal to that feature.
>>
>> The point of cc_platform_has is to remove all these open code checks.
>> If a Xen hypervisor / dom0 can't access arbitrary guest memory for
>> virtual I/O and we need special APIs for that it certainly false
>> into the scope of cc_platform_has, even if the confientiality is
>> rather limited.
>
> In case the x86 maintainers are fine with that I won't oppose.
>
>
> Juergen
[I have discussed with Juergen on IRC about it.]
Well, if cc_platform_has() is a way to go (at least on x86), below some
thoughts about possible integration (if, of course, I got the idea and
code correctly).
1. We will need to introduce new attribute
CC_ATTR_GUEST_MEM_ACCESS_RESTRICTED
as we can't reuse CC_ATTR_GUEST_MEM_ENCRYPT (in case of Xen the Guest
memory is not encrypted). New attribute is automatically set if Guest
memory encryption is active (CC_ATTR_GUEST_MEM_ENCRYPT is set). Also new
attribute is set if restricted memory access using Xen grant mappings is
active. This will allow us to have a single check in
arch_has_restricted_virtio_memory_access() which covers both cases: Xen
and SEV
int arch_has_restricted_virtio_memory_access(void)
{
return cc_platform_has(CC_ATTR_GUEST_MEM_ACCESS_RESTRICTED);
}
2. We will need to introduce new vendor CC_VENDOR_XXX for our case (I
have chosen XEN, although I am not sure it is a good fit) which deals
with new attribute only.
3. Xen code then will call cc_set_vendor(CC_VENDOR_XEN) for different
modes (PV, HVM, etc) during initialization if restricted memory access
using Xen grant mappings is enabled.
Below the diff (not tested and without x86's PVH) how it could look like:
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index ec5b082..0284aa7 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -409,6 +409,14 @@ int __init arch_xen_unpopulated_init(struct
resource **res)
}
#endif
+#ifdef CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS
+int arch_has_restricted_virtio_memory_access(void)
+{
+ return IS_ENABLED(CONFIG_XEN_VIRTIO) && xen_domain();
+}
+EXPORT_SYMBOL_GPL(arch_has_restricted_virtio_memory_access);
+#endif
+
static void __init xen_dt_guest_init(void)
{
struct device_node *xen_node;
diff --git a/arch/x86/coco/core.c b/arch/x86/coco/core.c
index fc1365d..9020a60 100644
--- a/arch/x86/coco/core.c
+++ b/arch/x86/coco/core.c
@@ -44,6 +44,7 @@ static bool amd_cc_platform_has(enum cc_attr attr)
return sme_me_mask && !(sev_status &
MSR_AMD64_SEV_ENABLED);
case CC_ATTR_GUEST_MEM_ENCRYPT:
+ case CC_ATTR_GUEST_MEM_ACCESS_RESTRICTED:
return sev_status & MSR_AMD64_SEV_ENABLED;
case CC_ATTR_GUEST_STATE_ENCRYPT:
@@ -67,7 +68,19 @@ static bool amd_cc_platform_has(enum cc_attr attr)
static bool hyperv_cc_platform_has(enum cc_attr attr)
{
- return attr == CC_ATTR_GUEST_MEM_ENCRYPT;
+ switch (attr) {
+ case CC_ATTR_GUEST_MEM_ENCRYPT:
+ case CC_ATTR_GUEST_MEM_ACCESS_RESTRICTED:
+ return true;
+
+ default:
+ return false;
+ }
+}
+
+static bool xen_cc_platform_has(enum cc_attr attr)
+{
+ return attr == CC_ATTR_GUEST_MEM_ACCESS_RESTRICTED;
}
bool cc_platform_has(enum cc_attr attr)
@@ -79,6 +92,8 @@ bool cc_platform_has(enum cc_attr attr)
return intel_cc_platform_has(attr);
case CC_VENDOR_HYPERV:
return hyperv_cc_platform_has(attr);
+ case CC_VENDOR_XEN:
+ return xen_cc_platform_has(attr);
default:
return false;
}
@@ -115,3 +130,11 @@ __init void cc_set_mask(u64 mask)
{
cc_mask = mask;
}
+
+#ifdef CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS
+int arch_has_restricted_virtio_memory_access(void)
+{
+ return cc_platform_has(CC_ATTR_GUEST_MEM_ACCESS_RESTRICTED);
+}
+EXPORT_SYMBOL_GPL(arch_has_restricted_virtio_memory_access);
+#endif
diff --git a/arch/x86/include/asm/coco.h b/arch/x86/include/asm/coco.h
index 3d98c3a..6395ec1 100644
--- a/arch/x86/include/asm/coco.h
+++ b/arch/x86/include/asm/coco.h
@@ -9,6 +9,7 @@ enum cc_vendor {
CC_VENDOR_AMD,
CC_VENDOR_HYPERV,
CC_VENDOR_INTEL,
+ CC_VENDOR_XEN,
};
void cc_set_vendor(enum cc_vendor v);
diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
index 50d2099..dda020f 100644
--- a/arch/x86/mm/mem_encrypt.c
+++ b/arch/x86/mm/mem_encrypt.c
@@ -77,8 +77,3 @@ void __init mem_encrypt_init(void)
print_mem_encrypt_feature_info();
}
-int arch_has_restricted_virtio_memory_access(void)
-{
- return cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT);
-}
-EXPORT_SYMBOL_GPL(arch_has_restricted_virtio_memory_access);
diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 85246dd..79cb30f 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -8,6 +8,7 @@ config XEN
depends on PARAVIRT
select PARAVIRT_CLOCK
select X86_HV_CALLBACK_VECTOR
+ select ARCH_HAS_CC_PLATFORM
depends on X86_64 || (X86_32 && X86_PAE)
depends on X86_LOCAL_APIC && X86_TSC
help
diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
index 517a9d8..11c3f4e 100644
--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -195,6 +195,9 @@ static void __init xen_hvm_guest_init(void)
if (xen_pv_domain())
return;
+ if (IS_ENABLED(CONFIG_XEN_VIRTIO))
+ cc_set_vendor(CC_VENDOR_XEN);
+
init_hvm_pv_info();
reserve_shared_info();
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 5038edb..2fe5aaa 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -109,6 +109,9 @@ static DEFINE_PER_CPU(struct tls_descs,
shadow_tls_desc);
static void __init xen_pv_init_platform(void)
{
+ if (IS_ENABLED(CONFIG_XEN_VIRTIO))
+ cc_set_vendor(CC_VENDOR_XEN);
+
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..d3179f8 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -339,4 +339,16 @@ config XEN_GRANT_DMA_OPS
bool
select DMA_OPS
+config XEN_VIRTIO
+ bool "Xen virtio support"
+ depends on VIRTIO
+ select ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS
+ 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/linux/cc_platform.h b/include/linux/cc_platform.h
index efd8205..d06bc7a 100644
--- a/include/linux/cc_platform.h
+++ b/include/linux/cc_platform.h
@@ -72,6 +72,19 @@ enum cc_attr {
* Examples include TDX guest & SEV.
*/
CC_ATTR_GUEST_UNROLL_STRING_IO,
+
+ /**
+ * @CC_ATTR_GUEST_MEM_ACCESS_RESTRICTED: Restricted memory access to
+ * Guest memory is active
+ *
+ * The platform/OS is running as a guest/virtual machine and uses
+ * the restricted access to its memory. This attribute is set if
either
+ * Guest memory encryption or restricted memory access using Xen
grant
+ * mappings is active.
+ *
+ * Examples include Xen guest and SEV.
+ */
+ CC_ATTR_GUEST_MEM_ACCESS_RESTRICTED,
};
#ifdef CONFIG_ARCH_HAS_CC_PLATFORM
(END)
On Arm I left simple variant simply because of no users of cc_platform.
int arch_has_restricted_virtio_memory_access(void)
{
return IS_ENABLED(CONFIG_XEN_VIRTIO) && xen_domain();
}
But, we could have something simple here:
bool cc_platform_has(enum cc_attr attr)
{
switch (attr) {
case CC_ATTR_GUEST_MEM_ACCESS_RESTRICTED:
return IS_ENABLED(CONFIG_XEN_VIRTIO) && xen_domain();
default:
return false;
}
}
int arch_has_restricted_virtio_memory_access(void)
{
return cc_platform_has(CC_ATTR_GUEST_MEM_ACCESS_RESTRICTED);
}
Any thoughts?
--
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 related [flat|nested] 79+ messages in thread
* Re: [PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen
2022-04-25 20:38 ` Oleksandr
@ 2022-04-25 21:25 ` Borislav Petkov
-1 siblings, 0 replies; 79+ messages in thread
From: Borislav Petkov @ 2022-04-25 21:25 UTC (permalink / raw)
To: Oleksandr
Cc: Juergen Gross, Christoph Hellwig, Boris Ostrovsky,
Stefano Stabellini, xen-devel, x86, linux-kernel,
linux-arm-kernel, Dave Hansen, Andy Lutomirski, Peter Zijlstra,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Julien Grall,
Oleksandr Tyshchenko, Michael S. Tsirkin, Tom Lendacky
On Mon, Apr 25, 2022 at 11:38:36PM +0300, Oleksandr wrote:
> diff --git a/include/linux/cc_platform.h b/include/linux/cc_platform.h
> index efd8205..d06bc7a 100644
> --- a/include/linux/cc_platform.h
> +++ b/include/linux/cc_platform.h
> @@ -72,6 +72,19 @@ enum cc_attr {
> * Examples include TDX guest & SEV.
> */
> CC_ATTR_GUEST_UNROLL_STRING_IO,
> +
> + /**
> + * @CC_ATTR_GUEST_MEM_ACCESS_RESTRICTED: Restricted memory access to
> + * Guest memory is active
> + *
> + * The platform/OS is running as a guest/virtual machine and uses
> + * the restricted access to its memory. This attribute is set if
> either
> + * Guest memory encryption or restricted memory access using Xen
> grant
> + * mappings is active.
> + *
> + * Examples include Xen guest and SEV.
Wait, whaaat?
The cc_platform* stuff is for *confidential computing* guests to check
different platform aspects.
From quickly skimming over this, this looks like a misuse to me.
Why can't you query this from the hypervisor just like you do your other
querying about what is supported, etc? Hypercalls, CPUID, whatever...
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen
@ 2022-04-25 21:25 ` Borislav Petkov
0 siblings, 0 replies; 79+ messages in thread
From: Borislav Petkov @ 2022-04-25 21:25 UTC (permalink / raw)
To: Oleksandr
Cc: Juergen Gross, Christoph Hellwig, Boris Ostrovsky,
Stefano Stabellini, xen-devel, x86, linux-kernel,
linux-arm-kernel, Dave Hansen, Andy Lutomirski, Peter Zijlstra,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Julien Grall,
Oleksandr Tyshchenko, Michael S. Tsirkin, Tom Lendacky
On Mon, Apr 25, 2022 at 11:38:36PM +0300, Oleksandr wrote:
> diff --git a/include/linux/cc_platform.h b/include/linux/cc_platform.h
> index efd8205..d06bc7a 100644
> --- a/include/linux/cc_platform.h
> +++ b/include/linux/cc_platform.h
> @@ -72,6 +72,19 @@ enum cc_attr {
> * Examples include TDX guest & SEV.
> */
> CC_ATTR_GUEST_UNROLL_STRING_IO,
> +
> + /**
> + * @CC_ATTR_GUEST_MEM_ACCESS_RESTRICTED: Restricted memory access to
> + * Guest memory is active
> + *
> + * The platform/OS is running as a guest/virtual machine and uses
> + * the restricted access to its memory. This attribute is set if
> either
> + * Guest memory encryption or restricted memory access using Xen
> grant
> + * mappings is active.
> + *
> + * Examples include Xen guest and SEV.
Wait, whaaat?
The cc_platform* stuff is for *confidential computing* guests to check
different platform aspects.
From quickly skimming over this, this looks like a misuse to me.
Why can't you query this from the hypervisor just like you do your other
querying about what is supported, etc? Hypercalls, CPUID, whatever...
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
_______________________________________________
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] 79+ messages in thread
* Re: [PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen
2022-04-25 21:25 ` Borislav Petkov
@ 2022-04-26 5:16 ` Juergen Gross
-1 siblings, 0 replies; 79+ messages in thread
From: Juergen Gross @ 2022-04-26 5:16 UTC (permalink / raw)
To: Borislav Petkov, Oleksandr
Cc: Christoph Hellwig, Boris Ostrovsky, Stefano Stabellini,
xen-devel, x86, linux-kernel, linux-arm-kernel, Dave Hansen,
Andy Lutomirski, Peter Zijlstra, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Julien Grall, Oleksandr Tyshchenko,
Michael S. Tsirkin, Tom Lendacky
[-- Attachment #1.1.1: Type: text/plain, Size: 1792 bytes --]
On 25.04.22 23:25, Borislav Petkov wrote:
> On Mon, Apr 25, 2022 at 11:38:36PM +0300, Oleksandr wrote:
>> diff --git a/include/linux/cc_platform.h b/include/linux/cc_platform.h
>> index efd8205..d06bc7a 100644
>> --- a/include/linux/cc_platform.h
>> +++ b/include/linux/cc_platform.h
>> @@ -72,6 +72,19 @@ enum cc_attr {
>> * Examples include TDX guest & SEV.
>> */
>> CC_ATTR_GUEST_UNROLL_STRING_IO,
>> +
>> + /**
>> + * @CC_ATTR_GUEST_MEM_ACCESS_RESTRICTED: Restricted memory access to
>> + * Guest memory is active
>> + *
>> + * The platform/OS is running as a guest/virtual machine and uses
>> + * the restricted access to its memory. This attribute is set if
>> either
>> + * Guest memory encryption or restricted memory access using Xen
>> grant
>> + * mappings is active.
>> + *
>> + * Examples include Xen guest and SEV.
>
> Wait, whaaat?
>
> The cc_platform* stuff is for *confidential computing* guests to check
> different platform aspects.
>
> From quickly skimming over this, this looks like a misuse to me.
Christoph suggested (rather firmly) this would be the way to go.
>
> Why can't you query this from the hypervisor just like you do your other
> querying about what is supported, etc? Hypercalls, CPUID, whatever...
This is needed on guest side at a rather hypervisor independent place.
So a capability of some sort seems appropriate.
Another suggestion of mine was to have a callback (or flag) in
struct x86_hyper_runtime for that purpose.
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] 79+ messages in thread
* Re: [PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen
@ 2022-04-26 5:16 ` Juergen Gross
0 siblings, 0 replies; 79+ messages in thread
From: Juergen Gross @ 2022-04-26 5:16 UTC (permalink / raw)
To: Borislav Petkov, Oleksandr
Cc: Christoph Hellwig, Boris Ostrovsky, Stefano Stabellini,
xen-devel, x86, linux-kernel, linux-arm-kernel, Dave Hansen,
Andy Lutomirski, Peter Zijlstra, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Julien Grall, Oleksandr Tyshchenko,
Michael S. Tsirkin, Tom Lendacky
[-- Attachment #1.1.1.1: Type: text/plain, Size: 1792 bytes --]
On 25.04.22 23:25, Borislav Petkov wrote:
> On Mon, Apr 25, 2022 at 11:38:36PM +0300, Oleksandr wrote:
>> diff --git a/include/linux/cc_platform.h b/include/linux/cc_platform.h
>> index efd8205..d06bc7a 100644
>> --- a/include/linux/cc_platform.h
>> +++ b/include/linux/cc_platform.h
>> @@ -72,6 +72,19 @@ enum cc_attr {
>> * Examples include TDX guest & SEV.
>> */
>> CC_ATTR_GUEST_UNROLL_STRING_IO,
>> +
>> + /**
>> + * @CC_ATTR_GUEST_MEM_ACCESS_RESTRICTED: Restricted memory access to
>> + * Guest memory is active
>> + *
>> + * The platform/OS is running as a guest/virtual machine and uses
>> + * the restricted access to its memory. This attribute is set if
>> either
>> + * Guest memory encryption or restricted memory access using Xen
>> grant
>> + * mappings is active.
>> + *
>> + * Examples include Xen guest and SEV.
>
> Wait, whaaat?
>
> The cc_platform* stuff is for *confidential computing* guests to check
> different platform aspects.
>
> From quickly skimming over this, this looks like a misuse to me.
Christoph suggested (rather firmly) this would be the way to go.
>
> Why can't you query this from the hypervisor just like you do your other
> querying about what is supported, etc? Hypercalls, CPUID, whatever...
This is needed on guest side at a rather hypervisor independent place.
So a capability of some sort seems appropriate.
Another suggestion of mine was to have a callback (or flag) in
struct x86_hyper_runtime for that purpose.
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] 79+ messages in thread
* Re: [PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen
2022-04-26 5:16 ` Juergen Gross
@ 2022-04-26 8:41 ` Borislav Petkov
-1 siblings, 0 replies; 79+ messages in thread
From: Borislav Petkov @ 2022-04-26 8:41 UTC (permalink / raw)
To: Juergen Gross
Cc: Oleksandr, Christoph Hellwig, Boris Ostrovsky,
Stefano Stabellini, xen-devel, x86, linux-kernel,
linux-arm-kernel, Dave Hansen, Andy Lutomirski, Peter Zijlstra,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Julien Grall,
Oleksandr Tyshchenko, Michael S. Tsirkin, Tom Lendacky
On Tue, Apr 26, 2022 at 07:16:16AM +0200, Juergen Gross wrote:
> Christoph suggested (rather firmly) this would be the way to go.
Yeah, I saw it but I don't think it is the right way to go.
What happens the next time a guest needs to query the platform
underneath? Misuse these interfaces again?
Because people will see the Xen use and say, hey, look, I will use this
for my funky HV too.
Even worse: what happens if Xen decides to implement SEV/TDX? Then
you're in for a world of fun.
Now, if we want to *extend* the interfaces to have something as generic
as, say, platform_has() and that should be the way for generic kernel
code running in the guest to query the platform capabilities, then sure,
by all means.
> This is needed on guest side at a rather hypervisor independent place.
>
> So a capability of some sort seems appropriate.
>
> Another suggestion of mine was to have a callback (or flag) in
> struct x86_hyper_runtime for that purpose.
This becomes an issue if the HV is not x86 - then you need a different
method of querying it, which then underneath will call the arch-specific
interface.
I don't know how much of querying guests need to do and how they've been
doing that so far. Depending on the requirements, we probably should
think about a clean design from the get-go instead of homegrown things.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen
@ 2022-04-26 8:41 ` Borislav Petkov
0 siblings, 0 replies; 79+ messages in thread
From: Borislav Petkov @ 2022-04-26 8:41 UTC (permalink / raw)
To: Juergen Gross
Cc: Oleksandr, Christoph Hellwig, Boris Ostrovsky,
Stefano Stabellini, xen-devel, x86, linux-kernel,
linux-arm-kernel, Dave Hansen, Andy Lutomirski, Peter Zijlstra,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Julien Grall,
Oleksandr Tyshchenko, Michael S. Tsirkin, Tom Lendacky
On Tue, Apr 26, 2022 at 07:16:16AM +0200, Juergen Gross wrote:
> Christoph suggested (rather firmly) this would be the way to go.
Yeah, I saw it but I don't think it is the right way to go.
What happens the next time a guest needs to query the platform
underneath? Misuse these interfaces again?
Because people will see the Xen use and say, hey, look, I will use this
for my funky HV too.
Even worse: what happens if Xen decides to implement SEV/TDX? Then
you're in for a world of fun.
Now, if we want to *extend* the interfaces to have something as generic
as, say, platform_has() and that should be the way for generic kernel
code running in the guest to query the platform capabilities, then sure,
by all means.
> This is needed on guest side at a rather hypervisor independent place.
>
> So a capability of some sort seems appropriate.
>
> Another suggestion of mine was to have a callback (or flag) in
> struct x86_hyper_runtime for that purpose.
This becomes an issue if the HV is not x86 - then you need a different
method of querying it, which then underneath will call the arch-specific
interface.
I don't know how much of querying guests need to do and how they've been
doing that so far. Depending on the requirements, we probably should
think about a clean design from the get-go instead of homegrown things.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
_______________________________________________
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] 79+ messages in thread
* Re: [PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen
2022-04-26 8:41 ` Borislav Petkov
@ 2022-04-26 9:36 ` Juergen Gross
-1 siblings, 0 replies; 79+ messages in thread
From: Juergen Gross @ 2022-04-26 9:36 UTC (permalink / raw)
To: Borislav Petkov
Cc: Oleksandr, Christoph Hellwig, Boris Ostrovsky,
Stefano Stabellini, xen-devel, x86, linux-kernel,
linux-arm-kernel, Dave Hansen, Andy Lutomirski, Peter Zijlstra,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Julien Grall,
Oleksandr Tyshchenko, Michael S. Tsirkin, Tom Lendacky
[-- Attachment #1.1.1: Type: text/plain, Size: 1754 bytes --]
On 26.04.22 10:41, Borislav Petkov wrote:
> On Tue, Apr 26, 2022 at 07:16:16AM +0200, Juergen Gross wrote:
>> Christoph suggested (rather firmly) this would be the way to go.
>
> Yeah, I saw it but I don't think it is the right way to go.
>
> What happens the next time a guest needs to query the platform
> underneath? Misuse these interfaces again?
>
> Because people will see the Xen use and say, hey, look, I will use this
> for my funky HV too.
>
> Even worse: what happens if Xen decides to implement SEV/TDX? Then
> you're in for a world of fun.
As the suggestion was to add another flag this wouldn't be a problem IMO.
But I agree that coco might be not the best way to go (as I wrote already).
>
> Now, if we want to *extend* the interfaces to have something as generic
> as, say, platform_has() and that should be the way for generic kernel
> code running in the guest to query the platform capabilities, then sure,
> by all means.
I agree.
>
>> This is needed on guest side at a rather hypervisor independent place.
>>
>> So a capability of some sort seems appropriate.
>>
>> Another suggestion of mine was to have a callback (or flag) in
>> struct x86_hyper_runtime for that purpose.
>
> This becomes an issue if the HV is not x86 - then you need a different
> method of querying it, which then underneath will call the arch-specific
> interface.
>
> I don't know how much of querying guests need to do and how they've been
> doing that so far. Depending on the requirements, we probably should
> think about a clean design from the get-go instead of homegrown things.
Yes.
platform_has() doesn't seem too bad IMO.
I will write a patch for starting the discussion.
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] 79+ messages in thread
* Re: [PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen
@ 2022-04-26 9:36 ` Juergen Gross
0 siblings, 0 replies; 79+ messages in thread
From: Juergen Gross @ 2022-04-26 9:36 UTC (permalink / raw)
To: Borislav Petkov
Cc: Oleksandr, Christoph Hellwig, Boris Ostrovsky,
Stefano Stabellini, xen-devel, x86, linux-kernel,
linux-arm-kernel, Dave Hansen, Andy Lutomirski, Peter Zijlstra,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Julien Grall,
Oleksandr Tyshchenko, Michael S. Tsirkin, Tom Lendacky
[-- Attachment #1.1.1.1: Type: text/plain, Size: 1754 bytes --]
On 26.04.22 10:41, Borislav Petkov wrote:
> On Tue, Apr 26, 2022 at 07:16:16AM +0200, Juergen Gross wrote:
>> Christoph suggested (rather firmly) this would be the way to go.
>
> Yeah, I saw it but I don't think it is the right way to go.
>
> What happens the next time a guest needs to query the platform
> underneath? Misuse these interfaces again?
>
> Because people will see the Xen use and say, hey, look, I will use this
> for my funky HV too.
>
> Even worse: what happens if Xen decides to implement SEV/TDX? Then
> you're in for a world of fun.
As the suggestion was to add another flag this wouldn't be a problem IMO.
But I agree that coco might be not the best way to go (as I wrote already).
>
> Now, if we want to *extend* the interfaces to have something as generic
> as, say, platform_has() and that should be the way for generic kernel
> code running in the guest to query the platform capabilities, then sure,
> by all means.
I agree.
>
>> This is needed on guest side at a rather hypervisor independent place.
>>
>> So a capability of some sort seems appropriate.
>>
>> Another suggestion of mine was to have a callback (or flag) in
>> struct x86_hyper_runtime for that purpose.
>
> This becomes an issue if the HV is not x86 - then you need a different
> method of querying it, which then underneath will call the arch-specific
> interface.
>
> I don't know how much of querying guests need to do and how they've been
> doing that so far. Depending on the requirements, we probably should
> think about a clean design from the get-go instead of homegrown things.
Yes.
platform_has() doesn't seem too bad IMO.
I will write a patch for starting the discussion.
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] 79+ messages in thread
* Re: [PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen
2022-04-26 9:36 ` Juergen Gross
@ 2022-04-26 11:16 ` Borislav Petkov
-1 siblings, 0 replies; 79+ messages in thread
From: Borislav Petkov @ 2022-04-26 11:16 UTC (permalink / raw)
To: Juergen Gross
Cc: Oleksandr, Christoph Hellwig, Boris Ostrovsky,
Stefano Stabellini, xen-devel, x86, linux-kernel,
linux-arm-kernel, Dave Hansen, Andy Lutomirski, Peter Zijlstra,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Julien Grall,
Oleksandr Tyshchenko, Michael S. Tsirkin, Tom Lendacky
On Tue, Apr 26, 2022 at 11:36:40AM +0200, Juergen Gross wrote:
> As the suggestion was to add another flag this wouldn't be a problem IMO.
We had a problem already with adding one flag would break the same flag
on the other guest type. That's why we added cc_vendor too. So it can be
tricky.
> platform_has() doesn't seem too bad IMO.
>
> I will write a patch for starting the discussion.
Yeah, I guess such a proposal would need a wider audience - maybe CC
linux-arch...
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen
@ 2022-04-26 11:16 ` Borislav Petkov
0 siblings, 0 replies; 79+ messages in thread
From: Borislav Petkov @ 2022-04-26 11:16 UTC (permalink / raw)
To: Juergen Gross
Cc: Oleksandr, Christoph Hellwig, Boris Ostrovsky,
Stefano Stabellini, xen-devel, x86, linux-kernel,
linux-arm-kernel, Dave Hansen, Andy Lutomirski, Peter Zijlstra,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Julien Grall,
Oleksandr Tyshchenko, Michael S. Tsirkin, Tom Lendacky
On Tue, Apr 26, 2022 at 11:36:40AM +0200, Juergen Gross wrote:
> As the suggestion was to add another flag this wouldn't be a problem IMO.
We had a problem already with adding one flag would break the same flag
on the other guest type. That's why we added cc_vendor too. So it can be
tricky.
> platform_has() doesn't seem too bad IMO.
>
> I will write a patch for starting the discussion.
Yeah, I guess such a proposal would need a wider audience - maybe CC
linux-arch...
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
_______________________________________________
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] 79+ messages in thread
* Re: [PATCH V1 4/6] dt-bindings: Add xen,dev-domid property description for xen-grant DMA ops
2022-04-22 16:51 ` [PATCH V1 4/6] dt-bindings: Add xen, dev-domid " Oleksandr Tyshchenko
(?)
@ 2022-05-02 21:59 ` Rob Herring
-1 siblings, 0 replies; 79+ messages in thread
From: Rob Herring @ 2022-05-02 21:59 UTC (permalink / raw)
To: Oleksandr Tyshchenko
Cc: Juergen Gross, devicetree, Stefano Stabellini, Julien Grall,
Michael S. Tsirkin, linux-kernel, virtualization,
Christoph Hellwig, Oleksandr Tyshchenko, xen-devel,
Krzysztof Kozlowski, linux-arm-kernel
On Fri, Apr 22, 2022 at 07:51:01PM +0300, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>
> Introduce Xen specific binding for the virtualized device (e.g. virtio)
> to be used by Xen grant DMA-mapping layer in the subsequent commit.
>
> This binding indicates that Xen grant mappings scheme needs to be
> enabled for the device which DT node contains that property and specifies
> the ID of Xen domain where the corresponding backend resides. The ID
> (domid) is used as an argument to the 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>
> ---
> Changes RFC -> V1:
> - update commit subject/description and text in description
> - move to devicetree/bindings/arm/
> ---
> .../devicetree/bindings/arm/xen,dev-domid.yaml | 37 ++++++++++++++++++++++
> 1 file changed, 37 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
>
> diff --git a/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
> new file mode 100644
> index 00000000..ef0f747
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
> @@ -0,0 +1,37 @@
> +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/xen,dev-domid.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Xen specific binding for the virtualized device (e.g. virtio)
> +
> +maintainers:
> + - Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
> +
> +select: true
Do we really need to support this property everywhere?
> +
> +description:
> + This binding indicates that Xen grant mappings scheme needs to be enabled
> + for that device and specifies the ID of Xen domain where the corresponding
> + device (backend) resides. This is needed for the option to restrict memory
> + access using Xen grant mappings to work.
> +
> +properties:
> + xen,dev-domid:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + The domid (domain ID) of the domain where the device (backend) is running.
> +
> +additionalProperties: true
> +
> +examples:
> + - |
> + virtio_block@3000 {
virtio@3000
> + compatible = "virtio,mmio";
> + reg = <0x3000 0x100>;
> + interrupts = <41>;
> +
> + /* The device is located in Xen domain with ID 1 */
> + xen,dev-domid = <1>;
This fails validation:
Documentation/devicetree/bindings/arm/xen,dev-domid.example.dtb: virtio_block@3000: xen,dev-domid: [[1]] is not of type 'object'
From schema: /home/rob/proj/git/linux-dt/Documentation/devicetree/bindings/virtio/mmio.yaml
The property has to be added to the virtio/mmio.yaml schema. If it is
not needed elsewhere, then *just* add the property there.
Rob
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [PATCH V1 4/6] dt-bindings: Add xen,dev-domid property description for xen-grant DMA ops
@ 2022-05-02 21:59 ` Rob Herring
0 siblings, 0 replies; 79+ messages in thread
From: Rob Herring @ 2022-05-02 21:59 UTC (permalink / raw)
To: Oleksandr Tyshchenko
Cc: xen-devel, virtualization, devicetree, linux-kernel,
linux-arm-kernel, Oleksandr Tyshchenko, Jason Wang,
Krzysztof Kozlowski, Julien Grall, Juergen Gross,
Stefano Stabellini, Michael S. Tsirkin, Christoph Hellwig
On Fri, Apr 22, 2022 at 07:51:01PM +0300, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>
> Introduce Xen specific binding for the virtualized device (e.g. virtio)
> to be used by Xen grant DMA-mapping layer in the subsequent commit.
>
> This binding indicates that Xen grant mappings scheme needs to be
> enabled for the device which DT node contains that property and specifies
> the ID of Xen domain where the corresponding backend resides. The ID
> (domid) is used as an argument to the 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>
> ---
> Changes RFC -> V1:
> - update commit subject/description and text in description
> - move to devicetree/bindings/arm/
> ---
> .../devicetree/bindings/arm/xen,dev-domid.yaml | 37 ++++++++++++++++++++++
> 1 file changed, 37 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
>
> diff --git a/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
> new file mode 100644
> index 00000000..ef0f747
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
> @@ -0,0 +1,37 @@
> +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/xen,dev-domid.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Xen specific binding for the virtualized device (e.g. virtio)
> +
> +maintainers:
> + - Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
> +
> +select: true
Do we really need to support this property everywhere?
> +
> +description:
> + This binding indicates that Xen grant mappings scheme needs to be enabled
> + for that device and specifies the ID of Xen domain where the corresponding
> + device (backend) resides. This is needed for the option to restrict memory
> + access using Xen grant mappings to work.
> +
> +properties:
> + xen,dev-domid:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + The domid (domain ID) of the domain where the device (backend) is running.
> +
> +additionalProperties: true
> +
> +examples:
> + - |
> + virtio_block@3000 {
virtio@3000
> + compatible = "virtio,mmio";
> + reg = <0x3000 0x100>;
> + interrupts = <41>;
> +
> + /* The device is located in Xen domain with ID 1 */
> + xen,dev-domid = <1>;
This fails validation:
Documentation/devicetree/bindings/arm/xen,dev-domid.example.dtb: virtio_block@3000: xen,dev-domid: [[1]] is not of type 'object'
From schema: /home/rob/proj/git/linux-dt/Documentation/devicetree/bindings/virtio/mmio.yaml
The property has to be added to the virtio/mmio.yaml schema. If it is
not needed elsewhere, then *just* add the property there.
Rob
^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [PATCH V1 4/6] dt-bindings: Add xen,dev-domid property description for xen-grant DMA ops
@ 2022-05-02 21:59 ` Rob Herring
0 siblings, 0 replies; 79+ messages in thread
From: Rob Herring @ 2022-05-02 21:59 UTC (permalink / raw)
To: Oleksandr Tyshchenko
Cc: xen-devel, virtualization, devicetree, linux-kernel,
linux-arm-kernel, Oleksandr Tyshchenko, Jason Wang,
Krzysztof Kozlowski, Julien Grall, Juergen Gross,
Stefano Stabellini, Michael S. Tsirkin, Christoph Hellwig
On Fri, Apr 22, 2022 at 07:51:01PM +0300, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>
> Introduce Xen specific binding for the virtualized device (e.g. virtio)
> to be used by Xen grant DMA-mapping layer in the subsequent commit.
>
> This binding indicates that Xen grant mappings scheme needs to be
> enabled for the device which DT node contains that property and specifies
> the ID of Xen domain where the corresponding backend resides. The ID
> (domid) is used as an argument to the 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>
> ---
> Changes RFC -> V1:
> - update commit subject/description and text in description
> - move to devicetree/bindings/arm/
> ---
> .../devicetree/bindings/arm/xen,dev-domid.yaml | 37 ++++++++++++++++++++++
> 1 file changed, 37 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
>
> diff --git a/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
> new file mode 100644
> index 00000000..ef0f747
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
> @@ -0,0 +1,37 @@
> +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/xen,dev-domid.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Xen specific binding for the virtualized device (e.g. virtio)
> +
> +maintainers:
> + - Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
> +
> +select: true
Do we really need to support this property everywhere?
> +
> +description:
> + This binding indicates that Xen grant mappings scheme needs to be enabled
> + for that device and specifies the ID of Xen domain where the corresponding
> + device (backend) resides. This is needed for the option to restrict memory
> + access using Xen grant mappings to work.
> +
> +properties:
> + xen,dev-domid:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + The domid (domain ID) of the domain where the device (backend) is running.
> +
> +additionalProperties: true
> +
> +examples:
> + - |
> + virtio_block@3000 {
virtio@3000
> + compatible = "virtio,mmio";
> + reg = <0x3000 0x100>;
> + interrupts = <41>;
> +
> + /* The device is located in Xen domain with ID 1 */
> + xen,dev-domid = <1>;
This fails validation:
Documentation/devicetree/bindings/arm/xen,dev-domid.example.dtb: virtio_block@3000: xen,dev-domid: [[1]] is not of type 'object'
From schema: /home/rob/proj/git/linux-dt/Documentation/devicetree/bindings/virtio/mmio.yaml
The property has to be added to the virtio/mmio.yaml schema. If it is
not needed elsewhere, then *just* add the property there.
Rob
_______________________________________________
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] 79+ messages in thread
* Re: [PATCH V1 4/6] dt-bindings: Add xen,dev-domid property description for xen-grant DMA ops
2022-05-02 21:59 ` Rob Herring
@ 2022-05-03 17:09 ` Oleksandr
-1 siblings, 0 replies; 79+ messages in thread
From: Oleksandr @ 2022-05-03 17:09 UTC (permalink / raw)
To: Rob Herring
Cc: xen-devel, virtualization, devicetree, linux-kernel,
linux-arm-kernel, Oleksandr Tyshchenko, Jason Wang,
Krzysztof Kozlowski, Julien Grall, Juergen Gross,
Stefano Stabellini, Michael S. Tsirkin, Christoph Hellwig
On 03.05.22 00:59, Rob Herring wrote:
Hello Rob
> On Fri, Apr 22, 2022 at 07:51:01PM +0300, Oleksandr Tyshchenko wrote:
>> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>
>> Introduce Xen specific binding for the virtualized device (e.g. virtio)
>> to be used by Xen grant DMA-mapping layer in the subsequent commit.
>>
>> This binding indicates that Xen grant mappings scheme needs to be
>> enabled for the device which DT node contains that property and specifies
>> the ID of Xen domain where the corresponding backend resides. The ID
>> (domid) is used as an argument to the 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>
>> ---
>> Changes RFC -> V1:
>> - update commit subject/description and text in description
>> - move to devicetree/bindings/arm/
>> ---
>> .../devicetree/bindings/arm/xen,dev-domid.yaml | 37 ++++++++++++++++++++++
>> 1 file changed, 37 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
>> new file mode 100644
>> index 00000000..ef0f747
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
>> @@ -0,0 +1,37 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/arm/xen,dev-domid.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Xen specific binding for the virtualized device (e.g. virtio)
>> +
>> +maintainers:
>> + - Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>> +
>> +select: true
> Do we really need to support this property everywhere?
From my understanding - yes.
As, I think, any device node describing virtulized device in the guest
device tree can have this property. Initially (in the RFC series) the
"solution to restrict memory access using Xen grant mappings" was
virtio-specific.
Although the support of virtio is a primary target of this series, we
decided to generalize this work and expand it to any device [1]. So the
Xen grant mappings scheme (this property to be used for) can be
theoretically used for any device emulated by the Xen backend.
>> +
>> +description:
>> + This binding indicates that Xen grant mappings scheme needs to be enabled
>> + for that device and specifies the ID of Xen domain where the corresponding
>> + device (backend) resides. This is needed for the option to restrict memory
>> + access using Xen grant mappings to work.
>> +
>> +properties:
>> + xen,dev-domid:
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> + description:
>> + The domid (domain ID) of the domain where the device (backend) is running.
>> +
>> +additionalProperties: true
>> +
>> +examples:
>> + - |
>> + virtio_block@3000 {
> virtio@3000
ok, will change
>
>> + compatible = "virtio,mmio";
>> + reg = <0x3000 0x100>;
>> + interrupts = <41>;
>> +
>> + /* The device is located in Xen domain with ID 1 */
>> + xen,dev-domid = <1>;
> This fails validation:
>
> Documentation/devicetree/bindings/arm/xen,dev-domid.example.dtb: virtio_block@3000: xen,dev-domid: [[1]] is not of type 'object'
> From schema: /home/rob/proj/git/linux-dt/Documentation/devicetree/bindings/virtio/mmio.yaml
Thank you for pointing this out, my fault, I haven't "properly" checked
this before. I think, we need to remove "compatible = "virtio,mmio"; here
diff --git a/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
index 2daa8aa..d2f2140 100644
--- a/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
+++ b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
@@ -28,7 +28,7 @@ additionalProperties: true
examples:
- |
virtio_block@3000 {
- compatible = "virtio,mmio";
+ /* ... */
reg = <0x3000 0x100>;
interrupts = <41>;
>
> The property has to be added to the virtio/mmio.yaml schema. If it is
> not needed elsewhere, then *just* add the property there.
As I described above, the property is not virtio specific and can be
used for any virtualized device for which Xen grant mappings scheme
needs to be enabled (xen-grant DMA-mapping layer).
[1]
https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2204181202080.915916@ubuntu-linux-20-04-desktop/
>
> Rob
--
Regards,
Oleksandr Tyshchenko
^ permalink raw reply related [flat|nested] 79+ messages in thread
* Re: [PATCH V1 4/6] dt-bindings: Add xen,dev-domid property description for xen-grant DMA ops
@ 2022-05-03 17:09 ` Oleksandr
0 siblings, 0 replies; 79+ messages in thread
From: Oleksandr @ 2022-05-03 17:09 UTC (permalink / raw)
To: Rob Herring
Cc: xen-devel, virtualization, devicetree, linux-kernel,
linux-arm-kernel, Oleksandr Tyshchenko, Jason Wang,
Krzysztof Kozlowski, Julien Grall, Juergen Gross,
Stefano Stabellini, Michael S. Tsirkin, Christoph Hellwig
On 03.05.22 00:59, Rob Herring wrote:
Hello Rob
> On Fri, Apr 22, 2022 at 07:51:01PM +0300, Oleksandr Tyshchenko wrote:
>> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>
>> Introduce Xen specific binding for the virtualized device (e.g. virtio)
>> to be used by Xen grant DMA-mapping layer in the subsequent commit.
>>
>> This binding indicates that Xen grant mappings scheme needs to be
>> enabled for the device which DT node contains that property and specifies
>> the ID of Xen domain where the corresponding backend resides. The ID
>> (domid) is used as an argument to the 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>
>> ---
>> Changes RFC -> V1:
>> - update commit subject/description and text in description
>> - move to devicetree/bindings/arm/
>> ---
>> .../devicetree/bindings/arm/xen,dev-domid.yaml | 37 ++++++++++++++++++++++
>> 1 file changed, 37 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
>> new file mode 100644
>> index 00000000..ef0f747
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
>> @@ -0,0 +1,37 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/arm/xen,dev-domid.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Xen specific binding for the virtualized device (e.g. virtio)
>> +
>> +maintainers:
>> + - Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>> +
>> +select: true
> Do we really need to support this property everywhere?
From my understanding - yes.
As, I think, any device node describing virtulized device in the guest
device tree can have this property. Initially (in the RFC series) the
"solution to restrict memory access using Xen grant mappings" was
virtio-specific.
Although the support of virtio is a primary target of this series, we
decided to generalize this work and expand it to any device [1]. So the
Xen grant mappings scheme (this property to be used for) can be
theoretically used for any device emulated by the Xen backend.
>> +
>> +description:
>> + This binding indicates that Xen grant mappings scheme needs to be enabled
>> + for that device and specifies the ID of Xen domain where the corresponding
>> + device (backend) resides. This is needed for the option to restrict memory
>> + access using Xen grant mappings to work.
>> +
>> +properties:
>> + xen,dev-domid:
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> + description:
>> + The domid (domain ID) of the domain where the device (backend) is running.
>> +
>> +additionalProperties: true
>> +
>> +examples:
>> + - |
>> + virtio_block@3000 {
> virtio@3000
ok, will change
>
>> + compatible = "virtio,mmio";
>> + reg = <0x3000 0x100>;
>> + interrupts = <41>;
>> +
>> + /* The device is located in Xen domain with ID 1 */
>> + xen,dev-domid = <1>;
> This fails validation:
>
> Documentation/devicetree/bindings/arm/xen,dev-domid.example.dtb: virtio_block@3000: xen,dev-domid: [[1]] is not of type 'object'
> From schema: /home/rob/proj/git/linux-dt/Documentation/devicetree/bindings/virtio/mmio.yaml
Thank you for pointing this out, my fault, I haven't "properly" checked
this before. I think, we need to remove "compatible = "virtio,mmio"; here
diff --git a/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
index 2daa8aa..d2f2140 100644
--- a/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
+++ b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
@@ -28,7 +28,7 @@ additionalProperties: true
examples:
- |
virtio_block@3000 {
- compatible = "virtio,mmio";
+ /* ... */
reg = <0x3000 0x100>;
interrupts = <41>;
>
> The property has to be added to the virtio/mmio.yaml schema. If it is
> not needed elsewhere, then *just* add the property there.
As I described above, the property is not virtio specific and can be
used for any virtualized device for which Xen grant mappings scheme
needs to be enabled (xen-grant DMA-mapping layer).
[1]
https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2204181202080.915916@ubuntu-linux-20-04-desktop/
>
> Rob
--
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 related [flat|nested] 79+ messages in thread
* Re: [PATCH V1 4/6] dt-bindings: Add xen,dev-domid property description for xen-grant DMA ops
2022-05-03 17:09 ` Oleksandr
(?)
@ 2022-05-04 0:02 ` Rob Herring
-1 siblings, 0 replies; 79+ messages in thread
From: Rob Herring @ 2022-05-04 0:02 UTC (permalink / raw)
To: Oleksandr
Cc: xen-devel, virtualization, devicetree, linux-kernel,
linux-arm-kernel, Oleksandr Tyshchenko, Jason Wang,
Krzysztof Kozlowski, Julien Grall, Juergen Gross,
Stefano Stabellini, Michael S. Tsirkin, Christoph Hellwig
On Tue, May 03, 2022 at 08:09:32PM +0300, Oleksandr wrote:
>
> On 03.05.22 00:59, Rob Herring wrote:
>
> Hello Rob
>
>
> > On Fri, Apr 22, 2022 at 07:51:01PM +0300, Oleksandr Tyshchenko wrote:
> > > From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
> > >
> > > Introduce Xen specific binding for the virtualized device (e.g. virtio)
> > > to be used by Xen grant DMA-mapping layer in the subsequent commit.
> > >
> > > This binding indicates that Xen grant mappings scheme needs to be
> > > enabled for the device which DT node contains that property and specifies
> > > the ID of Xen domain where the corresponding backend resides. The ID
> > > (domid) is used as an argument to the 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>
> > > ---
> > > Changes RFC -> V1:
> > > - update commit subject/description and text in description
> > > - move to devicetree/bindings/arm/
> > > ---
> > > .../devicetree/bindings/arm/xen,dev-domid.yaml | 37 ++++++++++++++++++++++
> > > 1 file changed, 37 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
> > > new file mode 100644
> > > index 00000000..ef0f747
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
> > > @@ -0,0 +1,37 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/arm/xen,dev-domid.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Xen specific binding for the virtualized device (e.g. virtio)
> > > +
> > > +maintainers:
> > > + - Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
> > > +
> > > +select: true
> > Do we really need to support this property everywhere?
>
> From my understanding - yes.
>
> As, I think, any device node describing virtulized device in the guest
> device tree can have this property. Initially (in the RFC series) the
> "solution to restrict memory access using Xen grant mappings" was
> virtio-specific.
>
> Although the support of virtio is a primary target of this series, we
> decided to generalize this work and expand it to any device [1]. So the Xen
> grant mappings scheme (this property to be used for) can be theoretically
> used for any device emulated by the Xen backend.
>
>
> > > +
> > > +description:
> > > + This binding indicates that Xen grant mappings scheme needs to be enabled
> > > + for that device and specifies the ID of Xen domain where the corresponding
> > > + device (backend) resides. This is needed for the option to restrict memory
> > > + access using Xen grant mappings to work.
> > > +
> > > +properties:
> > > + xen,dev-domid:
> > > + $ref: /schemas/types.yaml#/definitions/uint32
> > > + description:
> > > + The domid (domain ID) of the domain where the device (backend) is running.
> > > +
> > > +additionalProperties: true
> > > +
> > > +examples:
> > > + - |
> > > + virtio_block@3000 {
> > virtio@3000
>
> ok, will change
>
>
> >
> > > + compatible = "virtio,mmio";
> > > + reg = <0x3000 0x100>;
> > > + interrupts = <41>;
> > > +
> > > + /* The device is located in Xen domain with ID 1 */
> > > + xen,dev-domid = <1>;
> > This fails validation:
> >
> > Documentation/devicetree/bindings/arm/xen,dev-domid.example.dtb: virtio_block@3000: xen,dev-domid: [[1]] is not of type 'object'
> > From schema: /home/rob/proj/git/linux-dt/Documentation/devicetree/bindings/virtio/mmio.yaml
>
> Thank you for pointing this out, my fault, I haven't "properly" checked this
> before. I think, we need to remove "compatible = "virtio,mmio"; here
Uhh, no. That just means the example is incomplete. You need to add this
property or reference this schema from virtio/mmio.yaml.
> diff --git a/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
> b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
> index 2daa8aa..d2f2140 100644
> --- a/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
> +++ b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
> @@ -28,7 +28,7 @@ additionalProperties: true
> examples:
> - |
> virtio_block@3000 {
> - compatible = "virtio,mmio";
> + /* ... */
> reg = <0x3000 0x100>;
> interrupts = <41>;
>
>
>
> >
> > The property has to be added to the virtio/mmio.yaml schema. If it is
> > not needed elsewhere, then *just* add the property there.
>
> As I described above, the property is not virtio specific and can be used
> for any virtualized device for which Xen grant mappings scheme needs to be
> enabled (xen-grant DMA-mapping layer).
But that's a finite list of devices, right? In any case, you have to
list the property anywhere it can be used.
Rob
^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [PATCH V1 4/6] dt-bindings: Add xen,dev-domid property description for xen-grant DMA ops
@ 2022-05-04 0:02 ` Rob Herring
0 siblings, 0 replies; 79+ messages in thread
From: Rob Herring @ 2022-05-04 0:02 UTC (permalink / raw)
To: Oleksandr
Cc: Juergen Gross, devicetree, Stefano Stabellini, Julien Grall,
Michael S. Tsirkin, linux-kernel, virtualization,
Christoph Hellwig, Oleksandr Tyshchenko, xen-devel,
Krzysztof Kozlowski, linux-arm-kernel
On Tue, May 03, 2022 at 08:09:32PM +0300, Oleksandr wrote:
>
> On 03.05.22 00:59, Rob Herring wrote:
>
> Hello Rob
>
>
> > On Fri, Apr 22, 2022 at 07:51:01PM +0300, Oleksandr Tyshchenko wrote:
> > > From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
> > >
> > > Introduce Xen specific binding for the virtualized device (e.g. virtio)
> > > to be used by Xen grant DMA-mapping layer in the subsequent commit.
> > >
> > > This binding indicates that Xen grant mappings scheme needs to be
> > > enabled for the device which DT node contains that property and specifies
> > > the ID of Xen domain where the corresponding backend resides. The ID
> > > (domid) is used as an argument to the 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>
> > > ---
> > > Changes RFC -> V1:
> > > - update commit subject/description and text in description
> > > - move to devicetree/bindings/arm/
> > > ---
> > > .../devicetree/bindings/arm/xen,dev-domid.yaml | 37 ++++++++++++++++++++++
> > > 1 file changed, 37 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
> > > new file mode 100644
> > > index 00000000..ef0f747
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
> > > @@ -0,0 +1,37 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/arm/xen,dev-domid.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Xen specific binding for the virtualized device (e.g. virtio)
> > > +
> > > +maintainers:
> > > + - Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
> > > +
> > > +select: true
> > Do we really need to support this property everywhere?
>
> From my understanding - yes.
>
> As, I think, any device node describing virtulized device in the guest
> device tree can have this property. Initially (in the RFC series) the
> "solution to restrict memory access using Xen grant mappings" was
> virtio-specific.
>
> Although the support of virtio is a primary target of this series, we
> decided to generalize this work and expand it to any device [1]. So the Xen
> grant mappings scheme (this property to be used for) can be theoretically
> used for any device emulated by the Xen backend.
>
>
> > > +
> > > +description:
> > > + This binding indicates that Xen grant mappings scheme needs to be enabled
> > > + for that device and specifies the ID of Xen domain where the corresponding
> > > + device (backend) resides. This is needed for the option to restrict memory
> > > + access using Xen grant mappings to work.
> > > +
> > > +properties:
> > > + xen,dev-domid:
> > > + $ref: /schemas/types.yaml#/definitions/uint32
> > > + description:
> > > + The domid (domain ID) of the domain where the device (backend) is running.
> > > +
> > > +additionalProperties: true
> > > +
> > > +examples:
> > > + - |
> > > + virtio_block@3000 {
> > virtio@3000
>
> ok, will change
>
>
> >
> > > + compatible = "virtio,mmio";
> > > + reg = <0x3000 0x100>;
> > > + interrupts = <41>;
> > > +
> > > + /* The device is located in Xen domain with ID 1 */
> > > + xen,dev-domid = <1>;
> > This fails validation:
> >
> > Documentation/devicetree/bindings/arm/xen,dev-domid.example.dtb: virtio_block@3000: xen,dev-domid: [[1]] is not of type 'object'
> > From schema: /home/rob/proj/git/linux-dt/Documentation/devicetree/bindings/virtio/mmio.yaml
>
> Thank you for pointing this out, my fault, I haven't "properly" checked this
> before. I think, we need to remove "compatible = "virtio,mmio"; here
Uhh, no. That just means the example is incomplete. You need to add this
property or reference this schema from virtio/mmio.yaml.
> diff --git a/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
> b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
> index 2daa8aa..d2f2140 100644
> --- a/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
> +++ b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
> @@ -28,7 +28,7 @@ additionalProperties: true
> examples:
> - |
> virtio_block@3000 {
> - compatible = "virtio,mmio";
> + /* ... */
> reg = <0x3000 0x100>;
> interrupts = <41>;
>
>
>
> >
> > The property has to be added to the virtio/mmio.yaml schema. If it is
> > not needed elsewhere, then *just* add the property there.
>
> As I described above, the property is not virtio specific and can be used
> for any virtualized device for which Xen grant mappings scheme needs to be
> enabled (xen-grant DMA-mapping layer).
But that's a finite list of devices, right? In any case, you have to
list the property anywhere it can be used.
Rob
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [PATCH V1 4/6] dt-bindings: Add xen,dev-domid property description for xen-grant DMA ops
@ 2022-05-04 0:02 ` Rob Herring
0 siblings, 0 replies; 79+ messages in thread
From: Rob Herring @ 2022-05-04 0:02 UTC (permalink / raw)
To: Oleksandr
Cc: xen-devel, virtualization, devicetree, linux-kernel,
linux-arm-kernel, Oleksandr Tyshchenko, Jason Wang,
Krzysztof Kozlowski, Julien Grall, Juergen Gross,
Stefano Stabellini, Michael S. Tsirkin, Christoph Hellwig
On Tue, May 03, 2022 at 08:09:32PM +0300, Oleksandr wrote:
>
> On 03.05.22 00:59, Rob Herring wrote:
>
> Hello Rob
>
>
> > On Fri, Apr 22, 2022 at 07:51:01PM +0300, Oleksandr Tyshchenko wrote:
> > > From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
> > >
> > > Introduce Xen specific binding for the virtualized device (e.g. virtio)
> > > to be used by Xen grant DMA-mapping layer in the subsequent commit.
> > >
> > > This binding indicates that Xen grant mappings scheme needs to be
> > > enabled for the device which DT node contains that property and specifies
> > > the ID of Xen domain where the corresponding backend resides. The ID
> > > (domid) is used as an argument to the 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>
> > > ---
> > > Changes RFC -> V1:
> > > - update commit subject/description and text in description
> > > - move to devicetree/bindings/arm/
> > > ---
> > > .../devicetree/bindings/arm/xen,dev-domid.yaml | 37 ++++++++++++++++++++++
> > > 1 file changed, 37 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
> > > new file mode 100644
> > > index 00000000..ef0f747
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
> > > @@ -0,0 +1,37 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/arm/xen,dev-domid.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Xen specific binding for the virtualized device (e.g. virtio)
> > > +
> > > +maintainers:
> > > + - Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
> > > +
> > > +select: true
> > Do we really need to support this property everywhere?
>
> From my understanding - yes.
>
> As, I think, any device node describing virtulized device in the guest
> device tree can have this property. Initially (in the RFC series) the
> "solution to restrict memory access using Xen grant mappings" was
> virtio-specific.
>
> Although the support of virtio is a primary target of this series, we
> decided to generalize this work and expand it to any device [1]. So the Xen
> grant mappings scheme (this property to be used for) can be theoretically
> used for any device emulated by the Xen backend.
>
>
> > > +
> > > +description:
> > > + This binding indicates that Xen grant mappings scheme needs to be enabled
> > > + for that device and specifies the ID of Xen domain where the corresponding
> > > + device (backend) resides. This is needed for the option to restrict memory
> > > + access using Xen grant mappings to work.
> > > +
> > > +properties:
> > > + xen,dev-domid:
> > > + $ref: /schemas/types.yaml#/definitions/uint32
> > > + description:
> > > + The domid (domain ID) of the domain where the device (backend) is running.
> > > +
> > > +additionalProperties: true
> > > +
> > > +examples:
> > > + - |
> > > + virtio_block@3000 {
> > virtio@3000
>
> ok, will change
>
>
> >
> > > + compatible = "virtio,mmio";
> > > + reg = <0x3000 0x100>;
> > > + interrupts = <41>;
> > > +
> > > + /* The device is located in Xen domain with ID 1 */
> > > + xen,dev-domid = <1>;
> > This fails validation:
> >
> > Documentation/devicetree/bindings/arm/xen,dev-domid.example.dtb: virtio_block@3000: xen,dev-domid: [[1]] is not of type 'object'
> > From schema: /home/rob/proj/git/linux-dt/Documentation/devicetree/bindings/virtio/mmio.yaml
>
> Thank you for pointing this out, my fault, I haven't "properly" checked this
> before. I think, we need to remove "compatible = "virtio,mmio"; here
Uhh, no. That just means the example is incomplete. You need to add this
property or reference this schema from virtio/mmio.yaml.
> diff --git a/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
> b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
> index 2daa8aa..d2f2140 100644
> --- a/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
> +++ b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
> @@ -28,7 +28,7 @@ additionalProperties: true
> examples:
> - |
> virtio_block@3000 {
> - compatible = "virtio,mmio";
> + /* ... */
> reg = <0x3000 0x100>;
> interrupts = <41>;
>
>
>
> >
> > The property has to be added to the virtio/mmio.yaml schema. If it is
> > not needed elsewhere, then *just* add the property there.
>
> As I described above, the property is not virtio specific and can be used
> for any virtualized device for which Xen grant mappings scheme needs to be
> enabled (xen-grant DMA-mapping layer).
But that's a finite list of devices, right? In any case, you have to
list the property anywhere it can be used.
Rob
_______________________________________________
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] 79+ messages in thread
* Re: [PATCH V1 4/6] dt-bindings: Add xen,dev-domid property description for xen-grant DMA ops
2022-05-04 0:02 ` Rob Herring
@ 2022-05-05 10:12 ` Oleksandr
-1 siblings, 0 replies; 79+ messages in thread
From: Oleksandr @ 2022-05-05 10:12 UTC (permalink / raw)
To: Rob Herring
Cc: xen-devel, virtualization, devicetree, linux-kernel,
linux-arm-kernel, Oleksandr Tyshchenko, Jason Wang,
Krzysztof Kozlowski, Julien Grall, Juergen Gross,
Stefano Stabellini, Michael S. Tsirkin, Christoph Hellwig
On 04.05.22 03:02, Rob Herring wrote:
Hello Rob
> On Tue, May 03, 2022 at 08:09:32PM +0300, Oleksandr wrote:
>> On 03.05.22 00:59, Rob Herring wrote:
>>
>> Hello Rob
>>
>>
>>> On Fri, Apr 22, 2022 at 07:51:01PM +0300, Oleksandr Tyshchenko wrote:
>>>> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>>>
>>>> Introduce Xen specific binding for the virtualized device (e.g. virtio)
>>>> to be used by Xen grant DMA-mapping layer in the subsequent commit.
>>>>
>>>> This binding indicates that Xen grant mappings scheme needs to be
>>>> enabled for the device which DT node contains that property and specifies
>>>> the ID of Xen domain where the corresponding backend resides. The ID
>>>> (domid) is used as an argument to the 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>
>>>> ---
>>>> Changes RFC -> V1:
>>>> - update commit subject/description and text in description
>>>> - move to devicetree/bindings/arm/
>>>> ---
>>>> .../devicetree/bindings/arm/xen,dev-domid.yaml | 37 ++++++++++++++++++++++
>>>> 1 file changed, 37 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
>>>> new file mode 100644
>>>> index 00000000..ef0f747
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
>>>> @@ -0,0 +1,37 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/arm/xen,dev-domid.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: Xen specific binding for the virtualized device (e.g. virtio)
>>>> +
>>>> +maintainers:
>>>> + - Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>>> +
>>>> +select: true
>>> Do we really need to support this property everywhere?
>> From my understanding - yes.
>>
>> As, I think, any device node describing virtulized device in the guest
>> device tree can have this property. Initially (in the RFC series) the
>> "solution to restrict memory access using Xen grant mappings" was
>> virtio-specific.
>>
>> Although the support of virtio is a primary target of this series, we
>> decided to generalize this work and expand it to any device [1]. So the Xen
>> grant mappings scheme (this property to be used for) can be theoretically
>> used for any device emulated by the Xen backend.
>>
>>
>>>> +
>>>> +description:
>>>> + This binding indicates that Xen grant mappings scheme needs to be enabled
>>>> + for that device and specifies the ID of Xen domain where the corresponding
>>>> + device (backend) resides. This is needed for the option to restrict memory
>>>> + access using Xen grant mappings to work.
>>>> +
>>>> +properties:
>>>> + xen,dev-domid:
>>>> + $ref: /schemas/types.yaml#/definitions/uint32
>>>> + description:
>>>> + The domid (domain ID) of the domain where the device (backend) is running.
>>>> +
>>>> +additionalProperties: true
>>>> +
>>>> +examples:
>>>> + - |
>>>> + virtio_block@3000 {
>>> virtio@3000
>> ok, will change
>>
>>
>>>> + compatible = "virtio,mmio";
>>>> + reg = <0x3000 0x100>;
>>>> + interrupts = <41>;
>>>> +
>>>> + /* The device is located in Xen domain with ID 1 */
>>>> + xen,dev-domid = <1>;
>>> This fails validation:
>>>
>>> Documentation/devicetree/bindings/arm/xen,dev-domid.example.dtb: virtio_block@3000: xen,dev-domid: [[1]] is not of type 'object'
>>> From schema: /home/rob/proj/git/linux-dt/Documentation/devicetree/bindings/virtio/mmio.yaml
>> Thank you for pointing this out, my fault, I haven't "properly" checked this
>> before. I think, we need to remove "compatible = "virtio,mmio"; here
> Uhh, no. That just means the example is incomplete. You need to add this
> property or reference this schema from virtio/mmio.yaml.
ok, I got it
>
>
>> diff --git a/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
>> b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
>> index 2daa8aa..d2f2140 100644
>> --- a/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
>> +++ b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
>> @@ -28,7 +28,7 @@ additionalProperties: true
>> examples:
>> - |
>> virtio_block@3000 {
>> - compatible = "virtio,mmio";
>> + /* ... */
>> reg = <0x3000 0x100>;
>> interrupts = <41>;
>>
>>
>>
>>> The property has to be added to the virtio/mmio.yaml schema. If it is
>>> not needed elsewhere, then *just* add the property there.
>> As I described above, the property is not virtio specific and can be used
>> for any virtualized device for which Xen grant mappings scheme needs to be
>> enabled (xen-grant DMA-mapping layer).
> But that's a finite list of devices, right?
Right
> In any case, you have to
> list the property anywhere it can be used.
Agree
If I got it right, we need to add to virtio/mmio.yaml something like:
diff --git a/Documentation/devicetree/bindings/virtio/mmio.yaml
b/Documentation/devicetree/bindings/virtio/mmio.yaml
index 10c22b5..29a0932 100644
--- a/Documentation/devicetree/bindings/virtio/mmio.yaml
+++ b/Documentation/devicetree/bindings/virtio/mmio.yaml
@@ -13,6 +13,9 @@ description:
See
https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=virtio for
more details.
+allOf:
+ - $ref: /schemas/arm/xen,dev-domid.yaml#
+
properties:
compatible:
const: virtio,mmio
@@ -33,6 +36,10 @@ properties:
description: Required for devices making accesses thru an IOMMU.
maxItems: 1
+ xen,dev-domid:
+ description: Required when Xen grant mappings need to be enabled
for device.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
required:
- compatible
- reg
This passed validation.
Could you please clarify, is my understanding correct?
>
> Rob
--
Regards,
Oleksandr Tyshchenko
^ permalink raw reply related [flat|nested] 79+ messages in thread
* Re: [PATCH V1 4/6] dt-bindings: Add xen,dev-domid property description for xen-grant DMA ops
@ 2022-05-05 10:12 ` Oleksandr
0 siblings, 0 replies; 79+ messages in thread
From: Oleksandr @ 2022-05-05 10:12 UTC (permalink / raw)
To: Rob Herring
Cc: xen-devel, virtualization, devicetree, linux-kernel,
linux-arm-kernel, Oleksandr Tyshchenko, Jason Wang,
Krzysztof Kozlowski, Julien Grall, Juergen Gross,
Stefano Stabellini, Michael S. Tsirkin, Christoph Hellwig
On 04.05.22 03:02, Rob Herring wrote:
Hello Rob
> On Tue, May 03, 2022 at 08:09:32PM +0300, Oleksandr wrote:
>> On 03.05.22 00:59, Rob Herring wrote:
>>
>> Hello Rob
>>
>>
>>> On Fri, Apr 22, 2022 at 07:51:01PM +0300, Oleksandr Tyshchenko wrote:
>>>> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>>>
>>>> Introduce Xen specific binding for the virtualized device (e.g. virtio)
>>>> to be used by Xen grant DMA-mapping layer in the subsequent commit.
>>>>
>>>> This binding indicates that Xen grant mappings scheme needs to be
>>>> enabled for the device which DT node contains that property and specifies
>>>> the ID of Xen domain where the corresponding backend resides. The ID
>>>> (domid) is used as an argument to the 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>
>>>> ---
>>>> Changes RFC -> V1:
>>>> - update commit subject/description and text in description
>>>> - move to devicetree/bindings/arm/
>>>> ---
>>>> .../devicetree/bindings/arm/xen,dev-domid.yaml | 37 ++++++++++++++++++++++
>>>> 1 file changed, 37 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
>>>> new file mode 100644
>>>> index 00000000..ef0f747
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
>>>> @@ -0,0 +1,37 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/arm/xen,dev-domid.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: Xen specific binding for the virtualized device (e.g. virtio)
>>>> +
>>>> +maintainers:
>>>> + - Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>>> +
>>>> +select: true
>>> Do we really need to support this property everywhere?
>> From my understanding - yes.
>>
>> As, I think, any device node describing virtulized device in the guest
>> device tree can have this property. Initially (in the RFC series) the
>> "solution to restrict memory access using Xen grant mappings" was
>> virtio-specific.
>>
>> Although the support of virtio is a primary target of this series, we
>> decided to generalize this work and expand it to any device [1]. So the Xen
>> grant mappings scheme (this property to be used for) can be theoretically
>> used for any device emulated by the Xen backend.
>>
>>
>>>> +
>>>> +description:
>>>> + This binding indicates that Xen grant mappings scheme needs to be enabled
>>>> + for that device and specifies the ID of Xen domain where the corresponding
>>>> + device (backend) resides. This is needed for the option to restrict memory
>>>> + access using Xen grant mappings to work.
>>>> +
>>>> +properties:
>>>> + xen,dev-domid:
>>>> + $ref: /schemas/types.yaml#/definitions/uint32
>>>> + description:
>>>> + The domid (domain ID) of the domain where the device (backend) is running.
>>>> +
>>>> +additionalProperties: true
>>>> +
>>>> +examples:
>>>> + - |
>>>> + virtio_block@3000 {
>>> virtio@3000
>> ok, will change
>>
>>
>>>> + compatible = "virtio,mmio";
>>>> + reg = <0x3000 0x100>;
>>>> + interrupts = <41>;
>>>> +
>>>> + /* The device is located in Xen domain with ID 1 */
>>>> + xen,dev-domid = <1>;
>>> This fails validation:
>>>
>>> Documentation/devicetree/bindings/arm/xen,dev-domid.example.dtb: virtio_block@3000: xen,dev-domid: [[1]] is not of type 'object'
>>> From schema: /home/rob/proj/git/linux-dt/Documentation/devicetree/bindings/virtio/mmio.yaml
>> Thank you for pointing this out, my fault, I haven't "properly" checked this
>> before. I think, we need to remove "compatible = "virtio,mmio"; here
> Uhh, no. That just means the example is incomplete. You need to add this
> property or reference this schema from virtio/mmio.yaml.
ok, I got it
>
>
>> diff --git a/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
>> b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
>> index 2daa8aa..d2f2140 100644
>> --- a/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
>> +++ b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
>> @@ -28,7 +28,7 @@ additionalProperties: true
>> examples:
>> - |
>> virtio_block@3000 {
>> - compatible = "virtio,mmio";
>> + /* ... */
>> reg = <0x3000 0x100>;
>> interrupts = <41>;
>>
>>
>>
>>> The property has to be added to the virtio/mmio.yaml schema. If it is
>>> not needed elsewhere, then *just* add the property there.
>> As I described above, the property is not virtio specific and can be used
>> for any virtualized device for which Xen grant mappings scheme needs to be
>> enabled (xen-grant DMA-mapping layer).
> But that's a finite list of devices, right?
Right
> In any case, you have to
> list the property anywhere it can be used.
Agree
If I got it right, we need to add to virtio/mmio.yaml something like:
diff --git a/Documentation/devicetree/bindings/virtio/mmio.yaml
b/Documentation/devicetree/bindings/virtio/mmio.yaml
index 10c22b5..29a0932 100644
--- a/Documentation/devicetree/bindings/virtio/mmio.yaml
+++ b/Documentation/devicetree/bindings/virtio/mmio.yaml
@@ -13,6 +13,9 @@ description:
See
https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=virtio for
more details.
+allOf:
+ - $ref: /schemas/arm/xen,dev-domid.yaml#
+
properties:
compatible:
const: virtio,mmio
@@ -33,6 +36,10 @@ properties:
description: Required for devices making accesses thru an IOMMU.
maxItems: 1
+ xen,dev-domid:
+ description: Required when Xen grant mappings need to be enabled
for device.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
required:
- compatible
- reg
This passed validation.
Could you please clarify, is my understanding correct?
>
> Rob
--
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 related [flat|nested] 79+ messages in thread
end of thread, other threads:[~2022-05-05 10:13 UTC | newest]
Thread overview: 79+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-22 16:50 [PATCH V1 0/6] virtio: Solution to restrict memory access under Xen using xen-grant DMA-mapping layer Oleksandr Tyshchenko
2022-04-22 16:50 ` Oleksandr Tyshchenko
2022-04-22 16:50 ` [PATCH V1 1/6] arm/xen: Introduce xen_setup_dma_ops() Oleksandr Tyshchenko
2022-04-22 16:50 ` Oleksandr Tyshchenko
2022-04-22 22:59 ` Stefano Stabellini
2022-04-22 22:59 ` Stefano Stabellini
2022-04-23 14:35 ` Oleksandr
2022-04-23 14:35 ` Oleksandr
2022-04-23 16:32 ` Christoph Hellwig
2022-04-23 16:32 ` Christoph Hellwig
2022-04-22 16:50 ` [PATCH V1 2/6] xen/grants: support allocating consecutive grants Oleksandr Tyshchenko
2022-04-22 16:50 ` Oleksandr Tyshchenko
2022-04-22 16:51 ` [PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen Oleksandr Tyshchenko
2022-04-22 16:51 ` Oleksandr Tyshchenko
2022-04-22 23:00 ` Stefano Stabellini
2022-04-22 23:00 ` Stefano Stabellini
2022-04-23 7:05 ` Oleksandr
2022-04-23 7:05 ` Oleksandr
2022-04-23 9:10 ` Juergen Gross
2022-04-23 9:10 ` Juergen Gross
2022-04-23 15:25 ` Oleksandr
2022-04-23 15:25 ` Oleksandr
2022-04-23 16:40 ` Christoph Hellwig
2022-04-23 16:40 ` Christoph Hellwig
2022-04-24 16:53 ` Oleksandr
2022-04-24 16:53 ` Oleksandr
2022-04-24 18:08 ` Boris Ostrovsky
2022-04-24 18:08 ` Boris Ostrovsky
2022-04-25 7:53 ` Juergen Gross
2022-04-25 7:53 ` Juergen Gross
2022-04-25 7:47 ` Juergen Gross
2022-04-25 7:47 ` Juergen Gross
2022-04-25 7:58 ` Christoph Hellwig
2022-04-25 7:58 ` Christoph Hellwig
2022-04-25 9:14 ` Juergen Gross
2022-04-25 9:14 ` Juergen Gross
2022-04-25 20:38 ` Oleksandr
2022-04-25 20:38 ` Oleksandr
2022-04-25 21:25 ` Borislav Petkov
2022-04-25 21:25 ` Borislav Petkov
2022-04-26 5:16 ` Juergen Gross
2022-04-26 5:16 ` Juergen Gross
2022-04-26 8:41 ` Borislav Petkov
2022-04-26 8:41 ` Borislav Petkov
2022-04-26 9:36 ` Juergen Gross
2022-04-26 9:36 ` Juergen Gross
2022-04-26 11:16 ` Borislav Petkov
2022-04-26 11:16 ` Borislav Petkov
2022-04-22 16:51 ` [PATCH V1 4/6] dt-bindings: Add xen,dev-domid property description for xen-grant DMA ops Oleksandr Tyshchenko
2022-04-22 16:51 ` [PATCH V1 4/6] dt-bindings: Add xen, dev-domid " Oleksandr Tyshchenko
2022-04-22 23:00 ` Stefano Stabellini
2022-04-22 23:00 ` Stefano Stabellini
2022-04-22 23:00 ` Stefano Stabellini
2022-04-23 14:37 ` Oleksandr
2022-04-23 14:37 ` Oleksandr
2022-05-02 21:59 ` [PATCH V1 4/6] dt-bindings: Add xen,dev-domid " Rob Herring
2022-05-02 21:59 ` Rob Herring
2022-05-02 21:59 ` Rob Herring
2022-05-03 17:09 ` Oleksandr
2022-05-03 17:09 ` Oleksandr
2022-05-04 0:02 ` Rob Herring
2022-05-04 0:02 ` Rob Herring
2022-05-04 0:02 ` Rob Herring
2022-05-05 10:12 ` Oleksandr
2022-05-05 10:12 ` Oleksandr
2022-04-22 16:51 ` [PATCH V1 5/6] xen/grant-dma-ops: Retrieve the ID of backend's domain for DT devices Oleksandr Tyshchenko
2022-04-22 16:51 ` Oleksandr Tyshchenko
2022-04-22 23:00 ` Stefano Stabellini
2022-04-22 23:00 ` Stefano Stabellini
2022-04-23 15:23 ` Oleksandr
2022-04-23 15:23 ` Oleksandr
2022-04-22 16:51 ` [PATCH V1 6/6] arm/xen: Assign xen-grant DMA ops for xen-grant DMA devices Oleksandr Tyshchenko
2022-04-22 16:51 ` Oleksandr Tyshchenko
2022-04-22 23:00 ` Stefano Stabellini
2022-04-22 23:00 ` Stefano Stabellini
2022-04-23 16:42 ` Christoph Hellwig
2022-04-23 16:42 ` Christoph Hellwig
2022-04-24 16:07 ` Oleksandr
2022-04-24 16:07 ` 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.