* [PATCH 2/6] configfs: Constify is_visible/is_visible_bin in configfs_group_operations
From: Thomas Weißschuh @ 2026-07-16 17:09 UTC (permalink / raw)
To: Andreas Hindborg, Breno Leitao, Miguel Ojeda, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Daniel Almeida, Tamir Duberstein,
Alexandre Courbot, Onur Özkan, Matthew Brost,
Thomas Hellström, Rodrigo Vivi, David Airlie, Simona Vetter,
Dan Williams, Rafael J. Wysocki, Len Brown
Cc: rust-for-linux, linux-kernel, intel-xe, dri-devel, linux-coco,
linux-acpi, Thomas Weißschuh
In-Reply-To: <20260716-configfs-const-base-v1-0-c545a4053cb5@weissschuh.net>
These callbacks are never meant to modify their configfs_attribute
structure. Enforce this in the type system.
As there are only two implementers of these callbacks, adapt them right
away, avoiding a phased transition.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
---
drivers/gpu/drm/xe/xe_configfs.c | 4 ++--
drivers/virt/coco/guest/report.c | 4 ++--
include/linux/configfs.h | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/xe/xe_configfs.c b/drivers/gpu/drm/xe/xe_configfs.c
index 32102600a148..a5f696e7b329 100644
--- a/drivers/gpu/drm/xe/xe_configfs.c
+++ b/drivers/gpu/drm/xe/xe_configfs.c
@@ -843,7 +843,7 @@ static struct configfs_item_operations xe_config_device_ops = {
};
static bool xe_config_device_is_visible(struct config_item *item,
- struct configfs_attribute *attr, int n)
+ const struct configfs_attribute *attr, int n)
{
struct xe_config_group_device *dev = to_xe_config_group_device(item);
@@ -938,7 +938,7 @@ static struct configfs_attribute *xe_config_sriov_attrs[] = {
};
static bool xe_config_sriov_is_visible(struct config_item *item,
- struct configfs_attribute *attr, int n)
+ const struct configfs_attribute *attr, int n)
{
struct xe_config_group_device *dev = to_xe_config_group_device(item->ci_parent);
diff --git a/drivers/virt/coco/guest/report.c b/drivers/virt/coco/guest/report.c
index b254a1416286..96e89ddf4989 100644
--- a/drivers/virt/coco/guest/report.c
+++ b/drivers/virt/coco/guest/report.c
@@ -381,7 +381,7 @@ static struct configfs_item_operations tsm_report_item_ops = {
};
static bool tsm_report_is_visible(struct config_item *item,
- struct configfs_attribute *attr, int n)
+ const struct configfs_attribute *attr, int n)
{
guard(rwsem_read)(&tsm_rwsem);
if (!provider.ops)
@@ -394,7 +394,7 @@ static bool tsm_report_is_visible(struct config_item *item,
}
static bool tsm_report_is_bin_visible(struct config_item *item,
- struct configfs_bin_attribute *attr, int n)
+ const struct configfs_bin_attribute *attr, int n)
{
guard(rwsem_read)(&tsm_rwsem);
if (!provider.ops)
diff --git a/include/linux/configfs.h b/include/linux/configfs.h
index ef65c75beeaa..5d3fc8822a1d 100644
--- a/include/linux/configfs.h
+++ b/include/linux/configfs.h
@@ -220,8 +220,8 @@ struct configfs_group_operations {
struct config_group *(*make_group)(struct config_group *group, const char *name);
void (*disconnect_notify)(struct config_group *group, struct config_item *item);
void (*drop_item)(struct config_group *group, struct config_item *item);
- bool (*is_visible)(struct config_item *item, struct configfs_attribute *attr, int n);
- bool (*is_bin_visible)(struct config_item *item, struct configfs_bin_attribute *attr,
+ bool (*is_visible)(struct config_item *item, const struct configfs_attribute *attr, int n);
+ bool (*is_bin_visible)(struct config_item *item, const struct configfs_bin_attribute *attr,
int n);
};
--
2.55.0
^ permalink raw reply related
* [PATCH 4/6] configfs: Constify configfs_bin_attribute
From: Thomas Weißschuh @ 2026-07-16 17:09 UTC (permalink / raw)
To: Andreas Hindborg, Breno Leitao, Miguel Ojeda, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Daniel Almeida, Tamir Duberstein,
Alexandre Courbot, Onur Özkan, Matthew Brost,
Thomas Hellström, Rodrigo Vivi, David Airlie, Simona Vetter,
Dan Williams, Rafael J. Wysocki, Len Brown
Cc: rust-for-linux, linux-kernel, intel-xe, dri-devel, linux-coco,
linux-acpi, Thomas Weißschuh
In-Reply-To: <20260716-configfs-const-base-v1-0-c545a4053cb5@weissschuh.net>
The configfs_bin_attribute structures defined by driver are never
modified. Make them const.
As there are only two users of these attributes, adapt them in the same
commit to avoid a phased transition.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
---
drivers/acpi/acpi_configfs.c | 2 +-
drivers/virt/coco/guest/report.c | 2 +-
include/linux/configfs.h | 64 ++++++++++++++++++++--------------------
rust/kernel/configfs.rs | 4 +--
4 files changed, 36 insertions(+), 36 deletions(-)
diff --git a/drivers/acpi/acpi_configfs.c b/drivers/acpi/acpi_configfs.c
index 12ffec795803..6071699c7165 100644
--- a/drivers/acpi/acpi_configfs.c
+++ b/drivers/acpi/acpi_configfs.c
@@ -91,7 +91,7 @@ static ssize_t acpi_table_aml_read(struct config_item *cfg,
CONFIGFS_BIN_ATTR(acpi_table_, aml, NULL, MAX_ACPI_TABLE_SIZE);
-static struct configfs_bin_attribute *acpi_table_bin_attrs[] = {
+static const struct configfs_bin_attribute *const acpi_table_bin_attrs[] = {
&acpi_table_attr_aml,
NULL,
};
diff --git a/drivers/virt/coco/guest/report.c b/drivers/virt/coco/guest/report.c
index 96e89ddf4989..ad400fbe53f0 100644
--- a/drivers/virt/coco/guest/report.c
+++ b/drivers/virt/coco/guest/report.c
@@ -356,7 +356,7 @@ static struct configfs_attribute *tsm_report_attrs[] = {
NULL,
};
-static struct configfs_bin_attribute *tsm_report_bin_attrs[] = {
+static const struct configfs_bin_attribute *const tsm_report_bin_attrs[] = {
[TSM_REPORT_INBLOB] = &tsm_report_attr_inblob,
[TSM_REPORT_OUTBLOB] = &tsm_report_attr_outblob,
[TSM_REPORT_AUXBLOB] = &tsm_report_attr_auxblob,
diff --git a/include/linux/configfs.h b/include/linux/configfs.h
index 5d3fc8822a1d..eff2fb22ab70 100644
--- a/include/linux/configfs.h
+++ b/include/linux/configfs.h
@@ -67,7 +67,7 @@ struct config_item_type {
const struct configfs_item_operations *ct_item_ops;
const struct configfs_group_operations *ct_group_ops;
struct configfs_attribute **ct_attrs;
- struct configfs_bin_attribute **ct_bin_attrs;
+ const struct configfs_bin_attribute *const *ct_bin_attrs;
};
/**
@@ -160,41 +160,41 @@ struct configfs_bin_attribute {
ssize_t (*write)(struct config_item *, const void *, size_t);
};
-#define CONFIGFS_BIN_ATTR(_pfx, _name, _priv, _maxsz) \
-static struct configfs_bin_attribute _pfx##attr_##_name = { \
- .cb_attr = { \
- .ca_name = __stringify(_name), \
- .ca_mode = S_IRUGO | S_IWUSR, \
- .ca_owner = THIS_MODULE, \
- }, \
- .cb_private = _priv, \
- .cb_max_size = _maxsz, \
- .read = _pfx##_name##_read, \
- .write = _pfx##_name##_write, \
+#define CONFIGFS_BIN_ATTR(_pfx, _name, _priv, _maxsz) \
+static const struct configfs_bin_attribute _pfx##attr_##_name = { \
+ .cb_attr = { \
+ .ca_name = __stringify(_name), \
+ .ca_mode = S_IRUGO | S_IWUSR, \
+ .ca_owner = THIS_MODULE, \
+ }, \
+ .cb_private = _priv, \
+ .cb_max_size = _maxsz, \
+ .read = _pfx##_name##_read, \
+ .write = _pfx##_name##_write, \
}
-#define CONFIGFS_BIN_ATTR_RO(_pfx, _name, _priv, _maxsz) \
-static struct configfs_bin_attribute _pfx##attr_##_name = { \
- .cb_attr = { \
- .ca_name = __stringify(_name), \
- .ca_mode = S_IRUGO, \
- .ca_owner = THIS_MODULE, \
- }, \
- .cb_private = _priv, \
- .cb_max_size = _maxsz, \
- .read = _pfx##_name##_read, \
+#define CONFIGFS_BIN_ATTR_RO(_pfx, _name, _priv, _maxsz) \
+static const struct configfs_bin_attribute _pfx##attr_##_name = { \
+ .cb_attr = { \
+ .ca_name = __stringify(_name), \
+ .ca_mode = S_IRUGO, \
+ .ca_owner = THIS_MODULE, \
+ }, \
+ .cb_private = _priv, \
+ .cb_max_size = _maxsz, \
+ .read = _pfx##_name##_read, \
}
-#define CONFIGFS_BIN_ATTR_WO(_pfx, _name, _priv, _maxsz) \
-static struct configfs_bin_attribute _pfx##attr_##_name = { \
- .cb_attr = { \
- .ca_name = __stringify(_name), \
- .ca_mode = S_IWUSR, \
- .ca_owner = THIS_MODULE, \
- }, \
- .cb_private = _priv, \
- .cb_max_size = _maxsz, \
- .write = _pfx##_name##_write, \
+#define CONFIGFS_BIN_ATTR_WO(_pfx, _name, _priv, _maxsz) \
+static const struct configfs_bin_attribute _pfx##attr_##_name = { \
+ .cb_attr = { \
+ .ca_name = __stringify(_name), \
+ .ca_mode = S_IWUSR, \
+ .ca_owner = THIS_MODULE, \
+ }, \
+ .cb_private = _priv, \
+ .cb_max_size = _maxsz, \
+ .write = _pfx##_name##_write, \
}
/*
diff --git a/rust/kernel/configfs.rs b/rust/kernel/configfs.rs
index b33fb2e9adf1..f99a6e376fa3 100644
--- a/rust/kernel/configfs.rs
+++ b/rust/kernel/configfs.rs
@@ -757,7 +757,7 @@ pub const fn new_with_child_ctor<const N: usize, Child>(
ct_group_ops: GroupOperationsVTable::<Data, Child>::vtable_ptr(),
ct_item_ops: ItemOperationsVTable::<$tpe, Data>::vtable_ptr(),
ct_attrs: core::ptr::from_ref(attributes).cast_mut().cast(),
- ct_bin_attrs: core::ptr::null_mut(),
+ ct_bin_attrs: core::ptr::null(),
}),
_p: PhantomData,
}
@@ -774,7 +774,7 @@ pub const fn new<const N: usize>(
ct_group_ops: core::ptr::null(),
ct_item_ops: ItemOperationsVTable::<$tpe, Data>::vtable_ptr(),
ct_attrs: core::ptr::from_ref(attributes).cast_mut().cast(),
- ct_bin_attrs: core::ptr::null_mut(),
+ ct_bin_attrs: core::ptr::null(),
}),
_p: PhantomData,
}
--
2.55.0
^ permalink raw reply related
* [PATCH 3/6] configfs: Treat attribute structures as const internally
From: Thomas Weißschuh @ 2026-07-16 17:09 UTC (permalink / raw)
To: Andreas Hindborg, Breno Leitao, Miguel Ojeda, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Daniel Almeida, Tamir Duberstein,
Alexandre Courbot, Onur Özkan, Matthew Brost,
Thomas Hellström, Rodrigo Vivi, David Airlie, Simona Vetter,
Dan Williams, Rafael J. Wysocki, Len Brown
Cc: rust-for-linux, linux-kernel, intel-xe, dri-devel, linux-coco,
linux-acpi, Thomas Weißschuh
In-Reply-To: <20260716-configfs-const-base-v1-0-c545a4053cb5@weissschuh.net>
The configfs core never modifies the attribute structures defined in
driver core.
Reflect this in the types used internally in the configfs core.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
---
fs/configfs/configfs_internal.h | 10 +++++-----
fs/configfs/dir.c | 6 +++---
fs/configfs/file.c | 6 +++---
fs/configfs/inode.c | 2 +-
4 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/fs/configfs/configfs_internal.h b/fs/configfs/configfs_internal.h
index acdeea8e2d69..4bc19cd8d666 100644
--- a/fs/configfs/configfs_internal.h
+++ b/fs/configfs/configfs_internal.h
@@ -104,17 +104,17 @@ static inline struct config_item * to_item(struct dentry * dentry)
return ((struct config_item *) sd->s_element);
}
-static inline struct configfs_attribute * to_attr(struct dentry * dentry)
+static inline const struct configfs_attribute * to_attr(struct dentry * dentry)
{
struct configfs_dirent * sd = dentry->d_fsdata;
- return ((struct configfs_attribute *) sd->s_element);
+ return ((const struct configfs_attribute *) sd->s_element);
}
-static inline struct configfs_bin_attribute *to_bin_attr(struct dentry *dentry)
+static inline const struct configfs_bin_attribute *to_bin_attr(struct dentry *dentry)
{
- struct configfs_attribute *attr = to_attr(dentry);
+ const struct configfs_attribute *attr = to_attr(dentry);
- return container_of(attr, struct configfs_bin_attribute, cb_attr);
+ return container_of_const(attr, struct configfs_bin_attribute, cb_attr);
}
static inline struct config_item *configfs_get_config_item(struct dentry *dentry)
diff --git a/fs/configfs/dir.c b/fs/configfs/dir.c
index 3c88f13f1ca2..9a5c2bc4065d 100644
--- a/fs/configfs/dir.c
+++ b/fs/configfs/dir.c
@@ -461,7 +461,7 @@ static struct dentry * configfs_lookup(struct inode *dir,
*/
if ((sd->s_type & CONFIGFS_NOT_PINNED) &&
!strcmp(configfs_get_name(sd), dentry->d_name.name)) {
- struct configfs_attribute *attr = sd->s_element;
+ const struct configfs_attribute *attr = sd->s_element;
umode_t mode = (attr->ca_mode & S_IALLUGO) | S_IFREG;
dentry->d_fsdata = configfs_get(sd);
@@ -622,8 +622,8 @@ static int populate_attrs(struct config_item *item)
{
const struct config_item_type *t = item->ci_type;
const struct configfs_group_operations *ops;
- struct configfs_attribute *attr;
- struct configfs_bin_attribute *bin_attr;
+ const struct configfs_attribute *attr;
+ const struct configfs_bin_attribute *bin_attr;
int error = 0;
int i;
diff --git a/fs/configfs/file.c b/fs/configfs/file.c
index a48cece775a3..6460b000c593 100644
--- a/fs/configfs/file.c
+++ b/fs/configfs/file.c
@@ -41,8 +41,8 @@ struct configfs_buffer {
struct config_item *item;
struct module *owner;
union {
- struct configfs_attribute *attr;
- struct configfs_bin_attribute *bin_attr;
+ const struct configfs_attribute *attr;
+ const struct configfs_bin_attribute *bin_attr;
};
};
@@ -291,7 +291,7 @@ static int __configfs_open_file(struct inode *inode, struct file *file, int type
{
struct dentry *dentry = file->f_path.dentry;
struct configfs_fragment *frag = to_frag(file);
- struct configfs_attribute *attr;
+ const struct configfs_attribute *attr;
struct configfs_buffer *buffer;
int error;
diff --git a/fs/configfs/inode.c b/fs/configfs/inode.c
index 68290fe0e374..69f1f24e890f 100644
--- a/fs/configfs/inode.c
+++ b/fs/configfs/inode.c
@@ -178,7 +178,7 @@ struct inode *configfs_create(struct dentry *dentry, umode_t mode)
*/
const unsigned char * configfs_get_name(struct configfs_dirent *sd)
{
- struct configfs_attribute *attr;
+ const struct configfs_attribute *attr;
BUG_ON(!sd || !sd->s_element);
--
2.55.0
^ permalink raw reply related
* [PATCH 1/6] rust: configfs: remove mutability from some field initializers
From: Thomas Weißschuh @ 2026-07-16 17:09 UTC (permalink / raw)
To: Andreas Hindborg, Breno Leitao, Miguel Ojeda, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Daniel Almeida, Tamir Duberstein,
Alexandre Courbot, Onur Özkan, Matthew Brost,
Thomas Hellström, Rodrigo Vivi, David Airlie, Simona Vetter,
Dan Williams, Rafael J. Wysocki, Len Brown
Cc: rust-for-linux, linux-kernel, intel-xe, dri-devel, linux-coco,
linux-acpi, Thomas Weißschuh
In-Reply-To: <20260716-configfs-const-base-v1-0-c545a4053cb5@weissschuh.net>
These fields do not require mutable pointers.
Use regular immutable ones.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
---
rust/kernel/configfs.rs | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/rust/kernel/configfs.rs b/rust/kernel/configfs.rs
index 2339c6467325..b33fb2e9adf1 100644
--- a/rust/kernel/configfs.rs
+++ b/rust/kernel/configfs.rs
@@ -754,8 +754,8 @@ pub const fn new_with_child_ctor<const N: usize, Child>(
Self {
item_type: Opaque::new(bindings::config_item_type {
ct_owner: owner.as_ptr(),
- ct_group_ops: GroupOperationsVTable::<Data, Child>::vtable_ptr().cast_mut(),
- ct_item_ops: ItemOperationsVTable::<$tpe, Data>::vtable_ptr().cast_mut(),
+ ct_group_ops: GroupOperationsVTable::<Data, Child>::vtable_ptr(),
+ ct_item_ops: ItemOperationsVTable::<$tpe, Data>::vtable_ptr(),
ct_attrs: core::ptr::from_ref(attributes).cast_mut().cast(),
ct_bin_attrs: core::ptr::null_mut(),
}),
@@ -771,8 +771,8 @@ pub const fn new<const N: usize>(
Self {
item_type: Opaque::new(bindings::config_item_type {
ct_owner: owner.as_ptr(),
- ct_group_ops: core::ptr::null_mut(),
- ct_item_ops: ItemOperationsVTable::<$tpe, Data>::vtable_ptr().cast_mut(),
+ ct_group_ops: core::ptr::null(),
+ ct_item_ops: ItemOperationsVTable::<$tpe, Data>::vtable_ptr(),
ct_attrs: core::ptr::from_ref(attributes).cast_mut().cast(),
ct_bin_attrs: core::ptr::null_mut(),
}),
--
2.55.0
^ permalink raw reply related
* [PATCH 0/6] configfs: Allow the registration of const struct configfs_attribute
From: Thomas Weißschuh @ 2026-07-16 17:09 UTC (permalink / raw)
To: Andreas Hindborg, Breno Leitao, Miguel Ojeda, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Daniel Almeida, Tamir Duberstein,
Alexandre Courbot, Onur Özkan, Matthew Brost,
Thomas Hellström, Rodrigo Vivi, David Airlie, Simona Vetter,
Dan Williams, Rafael J. Wysocki, Len Brown
Cc: rust-for-linux, linux-kernel, intel-xe, dri-devel, linux-coco,
linux-acpi, Thomas Weißschuh
The attribute structure defined in driver code never need to be
modified. Allow them to be marked as const.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
---
Thomas Weißschuh (6):
rust: configfs: remove mutability from some field initializers
configfs: Constify is_visible/is_visible_bin in configfs_group_operations
configfs: Treat attribute structures as const internally
configfs: Constify configfs_bin_attribute
configfs: Allow the registration of const struct configfs_attribute
samples: configfs: constify the configfs_attribute structures
drivers/acpi/acpi_configfs.c | 2 +-
drivers/gpu/drm/xe/xe_configfs.c | 4 +--
drivers/virt/coco/guest/report.c | 6 ++--
fs/configfs/configfs_internal.h | 10 +++---
fs/configfs/dir.c | 10 +++---
fs/configfs/file.c | 6 ++--
fs/configfs/inode.c | 2 +-
include/linux/configfs.h | 73 ++++++++++++++++++++------------------
rust/kernel/configfs.rs | 20 ++++++-----
samples/configfs/configfs_sample.c | 16 ++++-----
10 files changed, 78 insertions(+), 71 deletions(-)
---
base-commit: c8d07eca6270b3f41c0e528a470895f1bd42e2b7
change-id: 20260716-configfs-const-base-6955b043560b
Best regards,
--
Thomas Weißschuh <linux@weissschuh.net>
^ permalink raw reply
* Re: [PATCH v7 16/22] dma-direct: make dma_direct_map_phys() honor DMA_ATTR_CC_SHARED
From: Jason Gunthorpe @ 2026-07-16 14:52 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: Aneesh Kumar K.V, Catalin Marinas, iommu, linux-arm-kernel,
linux-kernel, linux-coco, Robin Murphy, Marek Szyprowski,
Will Deacon, Marc Zyngier, Steven Price, Suzuki K Poulose,
Jiri Pirko, Mostafa Saleh, Petr Tesarik, Dan Williams, Xu Yilun,
linuxppc-dev, linux-s390, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86, Jiri Pirko,
Michael Kelley
In-Reply-To: <9d83ec13-3b1e-4c1b-8bab-16ea057cfba0@amd.com>
On Thu, Jul 16, 2026 at 11:55:20AM +1000, Alexey Kardashevskiy wrote:
> > > For AMD/SME, on host with memory encryption we now end up setting the C
> > > bit for DMA_ATTR_MMIO. This is fine for RAM but not sure whether
> > > some other MMIO bus understands this attribute. Maybe we should stick to
> > > something like __phys_to_dma() for the !CC_SHARED && MMIO path. Or,
> > > since this is not universally defined, just use the old dma_addr = phys
> > > if MMIO and ignore any unlikely DMA offsets.
> > >
> >
> > Considering for AMD/SME system an unencrypted dma addr is one without C
> > bit, will this be good?
>
> Normally both encrypted and unencrypted DMA addresses do not have
> Cbit, with the only exception of "iommu=pt" (which is not the
> default afaik). And in this case, having Cbit in DMA handles only
> makes sense if p2p trafic goes via the root port (== IOMMU in
> passthrough mode, and I am not sure even about if the root port will
> convert this Cbit to T=1 MMIO in this mode) but if it goes via some
> PCI bridge - then Cbit won't mean encryption for sure. But I do not
> know much about p2p (never touched). But in any case
> force_dma_unencrypted() seems to make no sense here.
True p2p through a switch does not call the DMA API at all, it
directly stuffs the physical MMIO BAR address of the target into the
dma_addr_t - which won't have a C bit.
The DMA API is only involved if the p2p will transit through the root
port, so adding the C bit is correct.
AFAICT it is iommu=!pt that doesn't work at all since the AMD IOMMU
driver always does __sme_set() even for MMIO when forming the IOPTE,
which I guess is wrong for MMIO.
Jason
^ permalink raw reply
* Re: [PATCH v15 25/37] KVM: arm64: CCA: Handle Realm PSCI requests
From: Suzuki K Poulose @ 2026-07-16 10:38 UTC (permalink / raw)
To: Steven Price, kvm, kvmarm
Cc: Catalin Marinas, Marc Zyngier, Will Deacon, James Morse,
Oliver Upton, Zenghui Yu, linux-arm-kernel, linux-kernel,
Joey Gouly, Alexandru Elisei, Christoffer Dall, Fuad Tabba,
linux-coco, Ganapatrao Kulkarni, Gavin Shan, Shanker Donthineni,
Alper Gun, Aneesh Kumar K . V, Emi Kisanuki, Vishal Annapurve,
WeiLin.Chang, Lorenzo Pieralisi
In-Reply-To: <20260715142841.80544-26-steven.price@arm.com>
On 15/07/2026 15:28, Steven Price wrote:
> Some PSCI commands cause a REC exit and the host has to call
> RMI_PSCI_COMPLETE to provide the status value to return to the guest.
>
> Co-developed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> Signed-off-by: Steven Price <steven.price@arm.com>
> ---
> Changes since v14:
> * Dropped the support for providing the target REC for a PSCI call (as
> per v2.0-bet2 spec).
> Changes since v13:
> * The ioctl KVM_ARM_VCPU_RMI_PSCI_COMPLETE has gone. The RMI call is
> made automatically just before entering the REC again.
> Changes since v12:
> * Change return code for non-realms to -ENXIO to better represent that
> the ioctl is invalid for non-realms (checkpatch is insistent that
> "ENOSYS means 'invalid syscall nr' and nothing else").
> Changes since v11:
> * RMM->RMI renaming.
> Changes since v6:
> * Use vcpu_is_rec() rather than kvm_is_realm(vcpu->kvm).
> * Minor renaming/formatting fixes.
> ---
> arch/arm64/include/asm/kvm_rmi.h | 2 ++
> arch/arm64/kvm/psci.c | 14 ++++++++++++
> arch/arm64/kvm/rmi.c | 38 ++++++++++++++++++++++++++++++++
> 3 files changed, 54 insertions(+)
>
> diff --git a/arch/arm64/include/asm/kvm_rmi.h b/arch/arm64/include/asm/kvm_rmi.h
> index 718c7128a3c3..a9bb9aabee5d 100644
> --- a/arch/arm64/include/asm/kvm_rmi.h
> +++ b/arch/arm64/include/asm/kvm_rmi.h
> @@ -120,6 +120,8 @@ int realm_map_ipa(struct kvm *kvm, phys_addr_t ipa,
> enum kvm_pgtable_prot prot,
> struct kvm_mmu_memory_cache *memcache);
>
> +int realm_psci_complete(struct kvm_vcpu *source, unsigned long status);
> +
> static inline bool kvm_realm_is_private_address(struct realm *realm,
> unsigned long addr)
> {
> diff --git a/arch/arm64/kvm/psci.c b/arch/arm64/kvm/psci.c
> index 3b5dbe9a0a0e..b0983ee416a2 100644
> --- a/arch/arm64/kvm/psci.c
> +++ b/arch/arm64/kvm/psci.c
> @@ -142,6 +142,20 @@ static unsigned long kvm_psci_vcpu_affinity_info(struct kvm_vcpu *vcpu)
> /* Ignore other bits of target affinity */
> target_affinity &= target_affinity_mask;
>
> + if (vcpu_is_rec(vcpu)) {
> + struct kvm_vcpu *target_vcpu;
> +
> + /* RMM supports only zero affinity level */
> + if (lowest_affinity_level != 0)
> + return PSCI_RET_INVALID_PARAMS;
> +
> + target_vcpu = kvm_mpidr_to_vcpu(kvm, target_affinity);
> + if (!target_vcpu)
> + return PSCI_RET_INVALID_PARAMS;
> +
> + return PSCI_RET_SUCCESS;
> + }
> +
We don't have to deal with AFFINITY_INFO anymore with the RMM
maintaining the MPIDR to REC mapping. This can be removed.
Otherwise looks good to me.
Suzuki
> /*
> * If one or more VCPU matching target affinity are running
> * then ON else OFF
> diff --git a/arch/arm64/kvm/rmi.c b/arch/arm64/kvm/rmi.c
> index 31effae067c8..8fb6403893e8 100644
> --- a/arch/arm64/kvm/rmi.c
> +++ b/arch/arm64/kvm/rmi.c
> @@ -3,6 +3,7 @@
> * Copyright (C) 2023-2026 ARM Ltd.
> */
>
> +#include <uapi/linux/psci.h>
> #include <linux/kvm_host.h>
>
> #include <asm/kvm_emulate.h>
> @@ -119,6 +120,18 @@ static void free_rtt(phys_addr_t phys)
> kvm_account_pgtable_pages(phys_to_virt(phys), -1);
> }
>
> +int realm_psci_complete(struct kvm_vcpu *source, unsigned long status)
> +{
> + int ret;
> +
> + ret = rmi_psci_complete(virt_to_phys(source->arch.rec.rec_page),
> + status);
> + if (ret)
> + return -ENXIO;
> +
> + return 0;
> +}
> +
> static int realm_rtt_create(struct realm *realm,
> unsigned long addr,
> int level,
> @@ -1115,6 +1128,28 @@ static void kvm_complete_ripas_change(struct kvm_vcpu *vcpu)
> rec->run->exit.ripas_base = base;
> }
>
> +static void kvm_rec_complete_psci(struct kvm_vcpu *vcpu)
> +{
> + struct rec_run *run = vcpu->arch.rec.run;
> + unsigned long status = PSCI_RET_DENIED;
> + unsigned long ret = vcpu_get_reg(vcpu, 0);
> +
> + switch (run->exit.gprs[0]) {
> + case PSCI_0_2_FN64_CPU_ON: {
> + if (ret != PSCI_RET_SUCCESS &&
> + ret != PSCI_RET_ALREADY_ON)
> + status = PSCI_RET_DENIED;
> + else
> + status = PSCI_RET_SUCCESS;
> + break;
> + }
> + default:
> + return;
> + }
> +
> + realm_psci_complete(vcpu, status);
> +}
> +
> /*
> * kvm_rec_pre_enter - Complete operations before entering a REC
> *
> @@ -1139,6 +1174,9 @@ int kvm_rec_pre_enter(struct kvm_vcpu *vcpu)
> for (int i = 0; i < REC_RUN_GPRS; i++)
> rec->run->enter.gprs[i] = vcpu_get_reg(vcpu, i);
> break;
> + case RMI_EXIT_PSCI:
> + kvm_rec_complete_psci(vcpu);
> + break;
> case RMI_EXIT_RIPAS_CHANGE:
> kvm_complete_ripas_change(vcpu);
> break;
^ permalink raw reply
* Re: [PATCH v15 17/37] KVM: arm64: Expose support for private memory
From: Suzuki K Poulose @ 2026-07-16 10:25 UTC (permalink / raw)
To: Steven Price, kvm, kvmarm
Cc: Catalin Marinas, Marc Zyngier, Will Deacon, James Morse,
Oliver Upton, Zenghui Yu, linux-arm-kernel, linux-kernel,
Joey Gouly, Alexandru Elisei, Christoffer Dall, Fuad Tabba,
linux-coco, Ganapatrao Kulkarni, Gavin Shan, Shanker Donthineni,
Alper Gun, Aneesh Kumar K . V, Emi Kisanuki, Vishal Annapurve,
WeiLin.Chang, Lorenzo Pieralisi
In-Reply-To: <20260715142841.80544-18-steven.price@arm.com>
On 15/07/2026 15:28, Steven Price wrote:
> Select KVM_GENERIC_MEMORY_ATTRIBUTES and provide the necessary support
> functions.
>
> Signed-off-by: Steven Price <steven.price@arm.com>
> ---
minor nit:
Changes since v14:
* Switch to guest_memfd in-place memory conversion and drop support
for KVM_VM_MEMORY_ATTRIBUTES.
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> Changes since v13:
> * Also update documentation to show that KVM_CAP_MEMORY_ATTRIBUTES is
> used on arm64.
> Changes since v12:
> * Only define kvm_arch_has_private_mem() when
> CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES is set to avoid build issues
> when KVM is disabled.
> Changes since v10:
> * KVM_GENERIC_PRIVATE_MEM replacd with KVM_GENERIC_MEMORY_ATTRIBUTES.
> Changes since v9:
> * Drop the #ifdef CONFIG_KVM_PRIVATE_MEM guard from the definition of
> kvm_arch_has_private_mem()
> Changes since v2:
> * Switch kvm_arch_has_private_mem() to a macro to avoid overhead of a
> function call.
> * Guard definitions of kvm_arch_{pre,post}_set_memory_attributes() with
> #ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES.
> * Early out in kvm_arch_post_set_memory_attributes() if the WARN_ON
> should trigger.
> ---
> arch/arm64/include/asm/kvm_host.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 9b46b39ed11e..993ead6e6449 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -1509,6 +1509,8 @@ struct kvm *kvm_arch_alloc_vm(void);
>
> #define vcpu_is_protected(vcpu) kvm_vm_is_protected((vcpu)->kvm)
>
> +#define kvm_arch_has_private_mem(kvm) ((kvm)->arch.is_realm)
> +
> int kvm_arm_vcpu_finalize(struct kvm_vcpu *vcpu, int feature);
> bool kvm_arm_vcpu_is_finalized(struct kvm_vcpu *vcpu);
>
^ permalink raw reply
* Re: [PATCH v15 28/37] KVM: arm64: CCA: Support RSI_HOST_CALL
From: Suzuki K Poulose @ 2026-07-16 10:22 UTC (permalink / raw)
To: Steven Price, kvm, kvmarm
Cc: Joey Gouly, Catalin Marinas, Marc Zyngier, Will Deacon,
James Morse, Oliver Upton, Zenghui Yu, linux-arm-kernel,
linux-kernel, Alexandru Elisei, Christoffer Dall, Fuad Tabba,
linux-coco, Ganapatrao Kulkarni, Gavin Shan, Shanker Donthineni,
Alper Gun, Aneesh Kumar K . V, Emi Kisanuki, Vishal Annapurve,
WeiLin.Chang, Lorenzo Pieralisi
In-Reply-To: <20260715142841.80544-29-steven.price@arm.com>
On 15/07/2026 15:28, Steven Price wrote:
> From: Joey Gouly <joey.gouly@arm.com>
>
> Realm VMs can talk to the hypervisor using the RSI_HOST_CALL SMC. The
> RMM forwards this to the host and KVM handles them as regular
> hypercalls.
>
> Signed-off-by: Joey Gouly <joey.gouly@arm.com>
> Signed-off-by: Steven Price <steven.price@arm.com>
> Reviewed-by: Gavin Shan <gshan@redhat.com>
> ---
minor nit: Populating the results back to the Realm is added in the
Patch 14: KVM: arm64: CCA: Handle realm enter/exit
May be a good idea to move to this one here ?
Either ways:
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> Changes since v7:
> * Avoid turning a negative return from kvm_smccc_call_handler() into a
> error response to the guest. Instead propagate the error back to user
> space.
> Changes since v4:
> * Setting GPRS is now done by kvm_rec_enter() rather than
> rec_exit_host_call() (see previous patch - arm64: RME: Handle realm
> enter/exit). This fixes a bug where the registers set by user space
> were being ignored.
> ---
> arch/arm64/kvm/rmi-exit.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/arch/arm64/kvm/rmi-exit.c b/arch/arm64/kvm/rmi-exit.c
> index c668cbfa971a..78d9189fd5ca 100644
> --- a/arch/arm64/kvm/rmi-exit.c
> +++ b/arch/arm64/kvm/rmi-exit.c
> @@ -113,6 +113,19 @@ static int rec_exit_ripas_change(struct kvm_vcpu *vcpu)
> return -EFAULT;
> }
>
> +static int rec_exit_host_call(struct kvm_vcpu *vcpu)
> +{
> + int i;
> + struct realm_rec *rec = &vcpu->arch.rec;
> +
> + vcpu->stat.hvc_exit_stat++;
> +
> + for (i = 0; i < REC_RUN_GPRS; i++)
> + vcpu_set_reg(vcpu, i, rec->run->exit.gprs[i]);
> +
> + return kvm_smccc_call_handler(vcpu);
> +}
> +
> static void update_arch_timer_irq_lines(struct kvm_vcpu *vcpu)
> {
> struct realm_rec *rec = &vcpu->arch.rec;
> @@ -188,6 +201,8 @@ int handle_rec_exit(struct kvm_vcpu *vcpu, int rec_run_ret)
> return rec_exit_psci(vcpu);
> case RMI_EXIT_RIPAS_CHANGE:
> return rec_exit_ripas_change(vcpu);
> + case RMI_EXIT_HOST_CALL:
> + return rec_exit_host_call(vcpu);
> }
>
> kvm_pr_unimpl("Unsupported exit reason: %u\n",
^ permalink raw reply
* Re: [PATCH v15 27/37] KVM: arm64: CCA: Allow userspace to inject aborts
From: Suzuki K Poulose @ 2026-07-16 10:19 UTC (permalink / raw)
To: Steven Price, kvm, kvmarm
Cc: Joey Gouly, Catalin Marinas, Marc Zyngier, Will Deacon,
James Morse, Oliver Upton, Zenghui Yu, linux-arm-kernel,
linux-kernel, Alexandru Elisei, Christoffer Dall, Fuad Tabba,
linux-coco, Ganapatrao Kulkarni, Gavin Shan, Shanker Donthineni,
Alper Gun, Aneesh Kumar K . V, Emi Kisanuki, Vishal Annapurve,
WeiLin.Chang, Lorenzo Pieralisi
In-Reply-To: <20260715142841.80544-28-steven.price@arm.com>
On 15/07/2026 15:28, Steven Price wrote:
> From: Joey Gouly <joey.gouly@arm.com>
>
> Extend KVM_SET_VCPU_EVENTS to support realms, where KVM cannot set the
> system registers, and the RMM must perform it on next REC entry.
>
> Signed-off-by: Joey Gouly <joey.gouly@arm.com>
> Signed-off-by: Steven Price <steven.price@arm.com>
> Reviewed-by: Gavin Shan <gshan@redhat.com>
> ---
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> Documentation/virt/kvm/api.rst | 2 ++
> arch/arm64/kvm/guest.c | 24 ++++++++++++++++++++++++
> 2 files changed, 26 insertions(+)
>
> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> index e39d146b34a3..85bec9b4f021 100644
> --- a/Documentation/virt/kvm/api.rst
> +++ b/Documentation/virt/kvm/api.rst
> @@ -1314,6 +1314,8 @@ User space may need to inject several types of events to the guest.
> Set the pending SError exception state for this VCPU. It is not possible to
> 'cancel' an Serror that has been made pending.
>
> +User space cannot inject SErrors into Realms.
> +
> If the guest performed an access to I/O memory which could not be handled by
> userspace, for example because of missing instruction syndrome decode
> information or because there is no device mapped at the accessed IPA, then
> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> index 3e970c4f6214..5469c9a97fad 100644
> --- a/arch/arm64/kvm/guest.c
> +++ b/arch/arm64/kvm/guest.c
> @@ -827,6 +827,30 @@ int __kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
> u64 esr = events->exception.serror_esr;
> int ret = 0;
>
> + if (vcpu_is_rec(vcpu)) {
> + /* Cannot inject SError into a Realm. */
> + if (serror_pending)
> + return -EINVAL;
> +
> + /*
> + * If a data abort is pending, set the flag and let the RMM
> + * inject an SEA when the REC is scheduled to be run.
> + */
> + if (ext_dabt_pending) {
> + /*
> + * Can only inject SEA into a Realm if the previous exit
> + * was due to a data abort of an Unprotected IPA.
> + */
> + if (!(vcpu->arch.rec.run->enter.flags & REC_ENTER_FLAG_EMULATED_MMIO))
> + return -EINVAL;
> +
> + vcpu->arch.rec.run->enter.flags &= ~REC_ENTER_FLAG_EMULATED_MMIO;
> + vcpu->arch.rec.run->enter.flags |= REC_ENTER_FLAG_INJECT_SEA;
> + }
> +
> + return 0;
> + }
> +
> /*
> * Immediately commit the pending SEA to the vCPU's architectural
> * state which is necessary since we do not return a pending SEA
^ permalink raw reply
* Re: [PATCH v15 00/37] arm64: Support for Arm CCA in KVM
From: Marc Zyngier @ 2026-07-16 9:42 UTC (permalink / raw)
To: Steven Price
Cc: kvm, kvmarm, Catalin Marinas, Will Deacon, James Morse,
Oliver Upton, Suzuki K Poulose, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Gavin Shan,
Shanker Donthineni, Alper Gun, Aneesh Kumar K . V, Emi Kisanuki,
Vishal Annapurve, WeiLin.Chang, Lorenzo Pieralisi
In-Reply-To: <2aba2dc2-eac5-474f-9bed-af2cb3003136@arm.com>
On Thu, 16 Jul 2026 10:20:49 +0100,
Steven Price <steven.price@arm.com> wrote:
>
> On 16/07/2026 09:36, Marc Zyngier wrote:
> > On Wed, 15 Jul 2026 15:28:02 +0100,
> > Steven Price <steven.price@arm.com> wrote:
> >>
> >> This series adds support for running protected VMs using KVM under the
> >> Arm Confidential Compute Architecture (CCA).
> >>
> >> It is the second part of the Arm CCA host support that was previously
> >> posted as a single 44-patch series. The generic firmware/RMM support has
> >> now been split into a separate 6-patch base series[0] so that it can also be
> >> used by other work (and hopefully make reviewing a little easier). This
> >> series applies on top of that base.
> >
> > Splitting the series this way means that no Sashiko review can occur,
> > as nothing applies on its own:
> >
> > https://sashiko.dev/#/patchset/20260715142841.80544-1-steven.price%40arm.com
> >
> > In the future, please post this with the relevant patches as an
> > integral prefix, so that we can make use of the tooling.
>
> Ah, I wonder if there's a way to teach Sashiko to deal with dependencies
> like this? Anyway if you're happy with everything in one series and
> (hopefully) merging a prefix earlier then I'll go back to that - it's
> easier for me too.
Sashiko had plenty to say about the first series, and you've been Cc'd
on the reports. I'd expect responses to the reports explaining why
this isn't a problem, or how you are planning to address it.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v15 06/37] KVM: arm64: CCA: Define the user ABI
From: Suzuki K Poulose @ 2026-07-16 9:40 UTC (permalink / raw)
To: Steven Price, kvm, kvmarm
Cc: Catalin Marinas, Marc Zyngier, Will Deacon, James Morse,
Oliver Upton, Zenghui Yu, linux-arm-kernel, linux-kernel,
Joey Gouly, Alexandru Elisei, Christoffer Dall, Fuad Tabba,
linux-coco, Ganapatrao Kulkarni, Gavin Shan, Shanker Donthineni,
Alper Gun, Aneesh Kumar K . V, Emi Kisanuki, Vishal Annapurve,
WeiLin.Chang, Lorenzo Pieralisi
In-Reply-To: <20260715142841.80544-7-steven.price@arm.com>
On 15/07/2026 15:28, Steven Price wrote:
> There is one CAP (KVM_CAP_ARM_RMI) which identifies the presence of CCA,
> and one ioctl. The ioctl (KVM_ARM_RMI_POPULATE) is used to populate
> memory during creation of the realm as this requires the RMM to copy
> data from an unprotected address to the protected memory - CCA does not
> support shared <-> private memory conversion where the memory contents
> is preserved as this is incompatible with memory encryption.
May be we could add the above constraint to the Documentation to make it
clear from the source. The code later adds this restriction and it would
be good to reflect in the Documentation, given other CC architectures
seem to provide it.
Please see below.
>
> Signed-off-by: Steven Price <steven.price@arm.com>
> ---
> Changes since v13:
> * KVM_ARM_VCPU_RMI_PSCI_COMPLETE removed.
> * KVM_ARM_RMI_POPULATE documentation updated to reflect that the
> structure is written by the kernel.
> * CAP number bumped.
> Changes since v12:
> * Change KVM_ARM_RMI_POPULATE to update the structure with the amount
> that has been progressed rather than return the number of bytes
> populated.
> * Describe the flag KVM_ARM_RMI_POPULATE_FLAGS_MEASURE.
> * CAP number is bumped.
> * NOTE: The PSCI ioctl may be removed in a future spec release.
> Changes since v11:
> * Completely reworked to be more implicit. Rather than having explicit
> CAP operations to progress the realm construction these operations
> are done when needed (on populating and on first vCPU run).
> * Populate and PSCI complete are promoted to proper ioctls.
> Changes since v10:
> * Rename symbols from RME to RMI.
> Changes since v9:
> * Improvements to documentation.
> * Bump the magic number for KVM_CAP_ARM_RME to avoid conflicts.
> Changes since v8:
> * Minor improvements to documentation following review.
> * Bump the magic numbers to avoid conflicts.
> Changes since v7:
> * Add documentation of new ioctls
> * Bump the magic numbers to avoid conflicts
> Changes since v6:
> * Rename some of the symbols to make their usage clearer and avoid
> repetition.
> Changes from v5:
> * Actually expose the new VCPU capability (KVM_ARM_VCPU_REC) by bumping
> KVM_VCPU_MAX_FEATURES - note this also exposes KVM_ARM_VCPU_HAS_EL2!
> ---
> Documentation/virt/kvm/api.rst | 41 ++++++++++++++++++++++++++++++++++
> include/uapi/linux/kvm.h | 13 +++++++++++
> 2 files changed, 54 insertions(+)
>
> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> index 304b9c3209ae..b38e090ad95d 100644
> --- a/Documentation/virt/kvm/api.rst
> +++ b/Documentation/virt/kvm/api.rst
> @@ -6642,6 +6642,38 @@ if the guest_memfd memory was pinned in IOMMU page tables.
>
> See also: :ref: `KVM_SET_MEMORY_ATTRIBUTES`.
>
> +4.146 KVM_ARM_RMI_POPULATE
> +--------------------------
> +
> +:Capability: KVM_CAP_ARM_RMI
> +:Architectures: arm64
> +:Type: vm ioctl
> +:Parameters: struct kvm_arm_rmi_populate (in/out)
> +:Returns: 0 on success, < 0 on error
> +
> +::
> +
> + struct kvm_arm_rmi_populate {
> + __u64 base;
> + __u64 size;
> + __u64 source_uaddr;
> + __u32 flags;
> + __u32 reserved;
> + };
> +
> +Populate a region of protected address space by copying the data from the
> +(non-protected) user space pointer provided into a protected region (backed by
> +guestmem_fd). It implicitly sets the destination region to RIPAS RAM. This is
minor nit: RIPAS_RAM for the sake of completeness. Also, I am wondering
if this could confuse the reader to imply that the UABI implicitly
converts the region in guest_memfd to "PRIVATE". May be we could rewrite
this to make all the preconditions explicit ? Something like:
"
Populate the guest address region described by @base and @size, with the
data pointed to by the userspace pointer @source_uaddr. The guest_memfd
region backing the memory region must be PRIVATE. Arm CCA cannot
do in-place conversion, preserving the contents. Thus @source_uaddr must
be a valid pointer. This operation maps to RMI_RTT_DATA_INIT which also
converts the region to RIPAS_RAM.
"
Suzuki
> +only valid before any VCPUs have been run. The ioctl might not populate the
> +entire region and in this case the kernel updates the fields `base`, `size` and
> +`source_uaddr`. User space may have to repeatedly call it until `size` is 0 to
> +populate the entire region.
> +
> +`flags` can be set to `KVM_ARM_RMI_POPULATE_FLAGS_MEASURE` to request that the
> +populated data is hashed and added to the guest's Realm Initial Measurement
> +(RIM) stored by the RMM. This can then be retrieved by the guest (using the RSI
> +interface) to present to an attestation server.
> +
> .. _kvm_run:
>
> 5. The kvm_run structure
> @@ -9025,6 +9057,15 @@ enabled, cmma can't be enabled anymore and pfmfi and the storage key
> interpretation are disabled. If cmma has already been enabled or the
> hpage_2g module parameter is not set to 1, -EINVAL is returned.
>
> +7.48 KVM_CAP_ARM_RMI
> +--------------------
> +
> +:Architectures: arm64
> +:Target: VM
> +:Parameters: None
> +
> +This capability indicates that support for CCA realms is available.
> +
> 8. Other capabilities.
> ======================
>
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 129d6f630325..0231ff174a50 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -998,6 +998,7 @@ struct kvm_enable_cap {
> #define KVM_CAP_S390_VSIE_ESAMODE 248
> #define KVM_CAP_S390_HPAGE_2G 249
> #define KVM_CAP_GUEST_MEMFD_MEMORY_ATTRIBUTES 250
> +#define KVM_CAP_ARM_RMI 251
>
> struct kvm_irq_routing_irqchip {
> __u32 irqchip;
> @@ -1686,4 +1687,16 @@ struct kvm_pre_fault_memory {
> __u64 padding[5];
> };
>
> +/* Available with KVM_CAP_ARM_RMI, only for VMs with KVM_VM_TYPE_ARM_REALM */
> +#define KVM_ARM_RMI_POPULATE _IOWR(KVMIO, 0xd7, struct kvm_arm_rmi_populate)
> +#define KVM_ARM_RMI_POPULATE_FLAGS_MEASURE (1 << 0)
> +
> +struct kvm_arm_rmi_populate {
> + __u64 base;
> + __u64 size;
> + __u64 source_uaddr;
> + __u32 flags;
> + __u32 reserved;
> +};
> +
> #endif /* __LINUX_KVM_H */
^ permalink raw reply
* Re: [PATCH v15 09/37] KVM: arm64: CCA: Allow passing the machine type in KVM creation
From: Marc Zyngier @ 2026-07-16 9:37 UTC (permalink / raw)
To: Steven Price
Cc: kvm, kvmarm, Catalin Marinas, Will Deacon, James Morse,
Oliver Upton, Suzuki K Poulose, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Gavin Shan,
Shanker Donthineni, Alper Gun, Aneesh Kumar K . V, Emi Kisanuki,
Vishal Annapurve, WeiLin.Chang, Lorenzo Pieralisi
In-Reply-To: <9eb4e4c0-f1f6-4ab9-956a-0b233d1656c9@arm.com>
On Thu, 16 Jul 2026 10:17:21 +0100,
Steven Price <steven.price@arm.com> wrote:
>
> On 15/07/2026 17:14, Marc Zyngier wrote:
> > On Wed, 15 Jul 2026 15:28:11 +0100,
> > Steven Price <steven.price@arm.com> wrote:
> >>
> >> Previously machine type was used purely for specifying the physical
> >> address size of the guest. Reserve the higher bits to specify an ARM
> >> specific machine type and declare a new type 'KVM_VM_TYPE_ARM_REALM'
> >> used to create a realm guest.
> >>
> >> Signed-off-by: Steven Price <steven.price@arm.com>
> >> ---
> >> Changes since v13:
> >> * Rework to use the two top bits for the machine type now that pKVM has
> >> merged and used the top bit for KVM_VM_TYPE_ARM_PROTECTED.
> >> * Update the documentation to include KVM_VM_TYPE_ARM_PROTECTED as
> >> well.
> >> Changes since v9:
> >> * Explictly set realm.state to REALM_STATE_NONE rather than rely on the
> >> zeroing of the structure.
> >> Changes since v7:
> >> * Add some documentation explaining the new machine type.
> >> Changes since v6:
> >> * Make the check for kvm_rme_is_available more visible and report an
> >> error code of -EPERM (instead of -EINVAL) to make it explicit that
> >> the kernel supports RME, but the platform doesn't.
> >> ---
> >> Documentation/virt/kvm/api.rst | 18 ++++++++++++++++--
> >> arch/arm64/kvm/arm.c | 11 +++++++++++
> >> include/uapi/linux/kvm.h | 7 ++++++-
> >> 3 files changed, 33 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> >> index b38e090ad95d..e39d146b34a3 100644
> >> --- a/Documentation/virt/kvm/api.rst
> >> +++ b/Documentation/virt/kvm/api.rst
> >> @@ -181,8 +181,22 @@ flag KVM_VM_MIPS_VZ.
> >> ARM64:
> >> ^^^^^^
> >>
> >> -On arm64, the physical address size for a VM (IPA Size limit) is limited
> >> -to 40bits by default. The limit can be configured if the host supports the
> >> +On arm64, the machine type identifier is used to encode a type and the
> >> +physical address size for the VM. The lower byte (bits[7-0]) encode the
> >> +address size and the upper bits[30-31] encode a machine type. The machine
> >> +types that might be available are:
> >> +
> >> + ========================= ============================================
> >> + KVM_VM_TYPE_ARM_NORMAL A standard VM
> >> + KVM_VM_TYPE_ARM_REALM A "Realm" VM using the Arm Confidential
> >> + Compute extensions, the VM's memory is
> >> + protected from the host.
> >> + KVM_VM_TYPE_ARM_PROTECTED A "protected" VM using pKVM to isolate the
> >> + VM from the host.
> >> + ========================= ============================================
> >> +
> >
> > Probably worth mentioning that REALM+PROTECTED is an illegal
> > combination.
>
> The original intention was that these were enum values not separate bit
> fields. Having to adapt to the pKVM changes when they were merged has
> somewhat messed this up. I'll add a clarification, but hopefully we
> haven't actually burnt the combination in case we have a 4th type in the
> future.
A good way to avoid ambiguity would be to list the actual values for
the [31:30] field (0b00, 0b01, 0b10).
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v15 05/37] KVM: arm64: CCA: Check for LPA2 support
From: Suzuki K Poulose @ 2026-07-16 9:23 UTC (permalink / raw)
To: Steven Price, kvm, kvmarm
Cc: Catalin Marinas, Marc Zyngier, Will Deacon, James Morse,
Oliver Upton, Zenghui Yu, linux-arm-kernel, linux-kernel,
Joey Gouly, Alexandru Elisei, Christoffer Dall, Fuad Tabba,
linux-coco, Ganapatrao Kulkarni, Gavin Shan, Shanker Donthineni,
Alper Gun, Aneesh Kumar K . V, Emi Kisanuki, Vishal Annapurve,
WeiLin.Chang, Lorenzo Pieralisi
In-Reply-To: <20260715142841.80544-6-steven.price@arm.com>
On 15/07/2026 15:28, Steven Price wrote:
> If KVM has enabled LPA2 support then check that the RMM also supports
> it. If there is a mismatch then disable support for realm guests as the
> VMM may attempt to create a guest which is incompatible with the RMM.
>
We may be able to relax this in the future with the UNPROT MAP/UNMAP
RMI ABIs now accepting the OutputAddress and Attributes separately
and gracefully handle cases where the requested IPA size exceeds
the RMM limit.
But practically I don't see why we should support it. So :
> Signed-off-by: Steven Price <steven.price@arm.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
> v15:
> * Extend rmi_has_feature() to take the register number and check the
> presence of SHA-256 support which is default.
> v13:
> * New patch
> ---
> arch/arm64/kvm/rmi.c | 25 +++++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
>
> diff --git a/arch/arm64/kvm/rmi.c b/arch/arm64/kvm/rmi.c
> index 384991d69f78..247c4f033945 100644
> --- a/arch/arm64/kvm/rmi.c
> +++ b/arch/arm64/kvm/rmi.c
> @@ -5,9 +5,31 @@
>
> #include <linux/kvm_host.h>
>
> +#include <asm/kvm_pgtable.h>
> #include <asm/rmi_cmds.h>
> #include <asm/virt.h>
>
> +static bool rmi_has_feature(int reg, unsigned long feature)
> +{
> + return !!u64_get_bits(rmi_feat_reg(reg), feature);
> +}
> +
> +static int rmm_check_features(void)
> +{
> + if (kvm_lpa2_is_enabled() &&
> + !rmi_has_feature(0, RMI_FEATURE_REGISTER_0_LPA2)) {
> + kvm_err("RMM doesn't support LPA2\n");
> + return -ENXIO;
> + }
> +
> + if (!rmi_has_feature(1, RMI_FEATURE_REGISTER_1_HASH_SHA_256)) {
> + kvm_err("RMM doesn't support SHA-256 measurements\n");
> + return -ENXIO;
> + }
> +
> + return 0;
> +}
> +
> void kvm_init_rmi(void)
> {
> /*
> @@ -20,5 +42,8 @@ void kvm_init_rmi(void)
> if (!is_rmi_available())
> return;
>
> + if (rmm_check_features())
> + return;
> +
> /* Future patch will enable static branch kvm_rmi_is_available */
> }
^ permalink raw reply
* Re: [PATCH v15 00/37] arm64: Support for Arm CCA in KVM
From: Steven Price @ 2026-07-16 9:20 UTC (permalink / raw)
To: Marc Zyngier
Cc: kvm, kvmarm, Catalin Marinas, Will Deacon, James Morse,
Oliver Upton, Suzuki K Poulose, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Gavin Shan,
Shanker Donthineni, Alper Gun, Aneesh Kumar K . V, Emi Kisanuki,
Vishal Annapurve, WeiLin.Chang, Lorenzo Pieralisi
In-Reply-To: <868q7bnxf3.wl-maz@kernel.org>
On 16/07/2026 09:36, Marc Zyngier wrote:
> On Wed, 15 Jul 2026 15:28:02 +0100,
> Steven Price <steven.price@arm.com> wrote:
>>
>> This series adds support for running protected VMs using KVM under the
>> Arm Confidential Compute Architecture (CCA).
>>
>> It is the second part of the Arm CCA host support that was previously
>> posted as a single 44-patch series. The generic firmware/RMM support has
>> now been split into a separate 6-patch base series[0] so that it can also be
>> used by other work (and hopefully make reviewing a little easier). This
>> series applies on top of that base.
>
> Splitting the series this way means that no Sashiko review can occur,
> as nothing applies on its own:
>
> https://sashiko.dev/#/patchset/20260715142841.80544-1-steven.price%40arm.com
>
> In the future, please post this with the relevant patches as an
> integral prefix, so that we can make use of the tooling.
Ah, I wonder if there's a way to teach Sashiko to deal with dependencies
like this? Anyway if you're happy with everything in one series and
(hopefully) merging a prefix earlier then I'll go back to that - it's
easier for me too.
Thanks,
Steve
^ permalink raw reply
* Re: [PATCH v15 09/37] KVM: arm64: CCA: Allow passing the machine type in KVM creation
From: Steven Price @ 2026-07-16 9:17 UTC (permalink / raw)
To: Marc Zyngier
Cc: kvm, kvmarm, Catalin Marinas, Will Deacon, James Morse,
Oliver Upton, Suzuki K Poulose, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Gavin Shan,
Shanker Donthineni, Alper Gun, Aneesh Kumar K . V, Emi Kisanuki,
Vishal Annapurve, WeiLin.Chang, Lorenzo Pieralisi
In-Reply-To: <87zezs44cf.wl-maz@kernel.org>
On 15/07/2026 17:14, Marc Zyngier wrote:
> On Wed, 15 Jul 2026 15:28:11 +0100,
> Steven Price <steven.price@arm.com> wrote:
>>
>> Previously machine type was used purely for specifying the physical
>> address size of the guest. Reserve the higher bits to specify an ARM
>> specific machine type and declare a new type 'KVM_VM_TYPE_ARM_REALM'
>> used to create a realm guest.
>>
>> Signed-off-by: Steven Price <steven.price@arm.com>
>> ---
>> Changes since v13:
>> * Rework to use the two top bits for the machine type now that pKVM has
>> merged and used the top bit for KVM_VM_TYPE_ARM_PROTECTED.
>> * Update the documentation to include KVM_VM_TYPE_ARM_PROTECTED as
>> well.
>> Changes since v9:
>> * Explictly set realm.state to REALM_STATE_NONE rather than rely on the
>> zeroing of the structure.
>> Changes since v7:
>> * Add some documentation explaining the new machine type.
>> Changes since v6:
>> * Make the check for kvm_rme_is_available more visible and report an
>> error code of -EPERM (instead of -EINVAL) to make it explicit that
>> the kernel supports RME, but the platform doesn't.
>> ---
>> Documentation/virt/kvm/api.rst | 18 ++++++++++++++++--
>> arch/arm64/kvm/arm.c | 11 +++++++++++
>> include/uapi/linux/kvm.h | 7 ++++++-
>> 3 files changed, 33 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
>> index b38e090ad95d..e39d146b34a3 100644
>> --- a/Documentation/virt/kvm/api.rst
>> +++ b/Documentation/virt/kvm/api.rst
>> @@ -181,8 +181,22 @@ flag KVM_VM_MIPS_VZ.
>> ARM64:
>> ^^^^^^
>>
>> -On arm64, the physical address size for a VM (IPA Size limit) is limited
>> -to 40bits by default. The limit can be configured if the host supports the
>> +On arm64, the machine type identifier is used to encode a type and the
>> +physical address size for the VM. The lower byte (bits[7-0]) encode the
>> +address size and the upper bits[30-31] encode a machine type. The machine
>> +types that might be available are:
>> +
>> + ========================= ============================================
>> + KVM_VM_TYPE_ARM_NORMAL A standard VM
>> + KVM_VM_TYPE_ARM_REALM A "Realm" VM using the Arm Confidential
>> + Compute extensions, the VM's memory is
>> + protected from the host.
>> + KVM_VM_TYPE_ARM_PROTECTED A "protected" VM using pKVM to isolate the
>> + VM from the host.
>> + ========================= ============================================
>> +
>
> Probably worth mentioning that REALM+PROTECTED is an illegal
> combination.
The original intention was that these were enum values not separate bit
fields. Having to adapt to the pKVM changes when they were merged has
somewhat messed this up. I'll add a clarification, but hopefully we
haven't actually burnt the combination in case we have a 4th type in the
future.
Thanks,
Steve
^ permalink raw reply
* Re: [PATCH v15 26/37] KVM: arm64: WARN on injected undef exceptions
From: Steven Price @ 2026-07-16 9:17 UTC (permalink / raw)
To: Marc Zyngier
Cc: kvm, kvmarm, Catalin Marinas, Will Deacon, James Morse,
Oliver Upton, Suzuki K Poulose, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Gavin Shan,
Shanker Donthineni, Alper Gun, Aneesh Kumar K . V, Emi Kisanuki,
Vishal Annapurve, WeiLin.Chang, Lorenzo Pieralisi
In-Reply-To: <87wluw430e.wl-maz@kernel.org>
On 15/07/2026 17:43, Marc Zyngier wrote:
> On Wed, 15 Jul 2026 17:31:57 +0100,
> Steven Price <steven.price@arm.com> wrote:
>>
>> On 15/07/2026 17:25, Marc Zyngier wrote:
>>> On Wed, 15 Jul 2026 17:15:31 +0100,
>>> Steven Price <steven.price@arm.com> wrote:
>>>>
>>>> On 15/07/2026 16:46, Marc Zyngier wrote:
>>>>> On Wed, 15 Jul 2026 15:28:28 +0100,
>>>>> Steven Price <steven.price@arm.com> wrote:
>>>>>>
>>>>>> The RMM doesn't allow injection of a undefined exception into a realm
>>>>>> guest. Add a WARN to catch if this ever happens.
>>>>>>
>>>>>> Signed-off-by: Steven Price <steven.price@arm.com>
>>>>>> Reviewed-by: Gavin Shan <gshan@redhat.com>
>>>>>> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>>>>>> ---
>>>>>> Changes since v6:
>>>>>> * if (x) WARN(1, ...) makes no sense, just WARN(x, ...)!
>>>>>> ---
>>>>>> arch/arm64/kvm/inject_fault.c | 1 +
>>>>>> 1 file changed, 1 insertion(+)
>>>>>>
>>>>>> diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
>>>>>> index 6492397b73d7..613f223bc7a3 100644
>>>>>> --- a/arch/arm64/kvm/inject_fault.c
>>>>>> +++ b/arch/arm64/kvm/inject_fault.c
>>>>>> @@ -327,6 +327,7 @@ void kvm_inject_size_fault(struct kvm_vcpu *vcpu)
>>>>>> */
>>>>>> void kvm_inject_undefined(struct kvm_vcpu *vcpu)
>>>>>> {
>>>>>> + WARN(vcpu_is_rec(vcpu), "Unexpected undefined exception injection to REC");
>>>>>> if (vcpu_el1_is_32bit(vcpu))
>>>>>> inject_undef32(vcpu);
>>>>>> else
>>>>>
>>>>> No. WARN_ONCE at a push, but even then, this looks dodgy.
>>>>
>>>> Yep WARN_ONCE() would be better. This function should never be called
>>>> for a realm guest.
>>>>
>>>>> Exceptions must be injectable. Otherwise, how do you respond to, for
>>>>> example, a sysreg access for a feature that is hidden from the guest?
>>>>
>>>> The RMM doesn't allow the host to inject exceptions - with the exception
>>>> of SEA after a host-emulated MMIO.
>>>>
>>>>> Will the RMM perform this in KVM's stead?
>>>>
>>>> Yes the RMM would have to handle this for the likes of sysreg accesses.
>>>> The host doesn't control the trapping of sysreg accesses. There are a
>>>> few GIC-related registers which are forwarded to the host ("REC exit due
>>>> to system register access") but generally the handling of sysregs is
>>>> entirely internal to the RMM.
>>>
>>> Then the only option is not to just warn, but to mark all realms as
>>> dead and refuse to run them any further. If we can't inject an
>>> exception and that the RMM isn't doing its job, I can't see how we can
>>> continue at all.
>>
>> You've got a point - I'm not sure whether it's entirely reasonable to
>> refuse to run any realm, but it certainly would be sensible to mark the
>
> If the RMM is not playing ball by not doing its part of the bargain,
> the only sane option is stop talking to it immediately. Who knows what
> else the implementation got wrong?
If the RMM isn't playing ball then we're in trouble whatever. Refusing
to talk to the RMM ensures that we wouldn't be able to reclaim any of
the memory that has been donated to the guest (or related RMM metadata).
It also doesn't rule out that a faulty RMM has left a minefield of
"delegated" memory which could cause a GPF at any moment. In reality the
only "safe" option is to BUG() the kernel and completely give up.
But the chances are that the RMM hasn't suddenly become malicious, and
in most likely the situation is that we've hit a corner case which in
the RMM which is highly likely to only affect the one guest.
"panic_on_warn" is available for those who would prefer the system to
stop in these situations.
And of course it's entirely possible that the bug is in Linux and the
RMM is playing ball it's just that I've screwed something up. In which
case the realm VM is probably screwed, but the rest of the system
(including other guests) should be absolutely fine.
I can of course code up a "rmm_is_bugged" flag and litter the code with
paths to handle that - but I can't imagine that's actually what you
want. Although please do let me know if I'm wrong, I seem to have
misplaced my mind reading hat ;)
>> guest which triggers this as dead. Would a KVM_BUG() be more appropriate
>> here?
>
> That's the absolutely minimal option. Not necessarily the safe one.
I'm not sure how to make it "safer" - I don't think there is a
completely "safe" option for this "should never happen" case.
Thanks,
Steve
^ permalink raw reply
* Re: [PATCH v15 00/37] arm64: Support for Arm CCA in KVM
From: Marc Zyngier @ 2026-07-16 8:36 UTC (permalink / raw)
To: Steven Price
Cc: kvm, kvmarm, Catalin Marinas, Will Deacon, James Morse,
Oliver Upton, Suzuki K Poulose, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Gavin Shan,
Shanker Donthineni, Alper Gun, Aneesh Kumar K . V, Emi Kisanuki,
Vishal Annapurve, WeiLin.Chang, Lorenzo Pieralisi
In-Reply-To: <20260715142841.80544-1-steven.price@arm.com>
On Wed, 15 Jul 2026 15:28:02 +0100,
Steven Price <steven.price@arm.com> wrote:
>
> This series adds support for running protected VMs using KVM under the
> Arm Confidential Compute Architecture (CCA).
>
> It is the second part of the Arm CCA host support that was previously
> posted as a single 44-patch series. The generic firmware/RMM support has
> now been split into a separate 6-patch base series[0] so that it can also be
> used by other work (and hopefully make reviewing a little easier). This
> series applies on top of that base.
Splitting the series this way means that no Sashiko review can occur,
as nothing applies on its own:
https://sashiko.dev/#/patchset/20260715142841.80544-1-steven.price%40arm.com
In the future, please post this with the relevant patches as an
integral prefix, so that we can make use of the tooling.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v7 16/22] dma-direct: make dma_direct_map_phys() honor DMA_ATTR_CC_SHARED
From: Alexey Kardashevskiy @ 2026-07-16 1:55 UTC (permalink / raw)
To: Aneesh Kumar K.V, Catalin Marinas
Cc: iommu, linux-arm-kernel, linux-kernel, linux-coco, Robin Murphy,
Marek Szyprowski, Will Deacon, Marc Zyngier, Steven Price,
Suzuki K Poulose, Jiri Pirko, Jason Gunthorpe, Mostafa Saleh,
Petr Tesarik, Dan Williams, Xu Yilun, linuxppc-dev, linux-s390,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Alexander Gordeev, Gerald Schaefer,
Heiko Carstens, Vasily Gorbik, Christian Borntraeger,
Sven Schnelle, x86, Jiri Pirko, Michael Kelley
In-Reply-To: <yq5apl0xgy89.fsf@kernel.org>
On 9/7/26 03:58, Aneesh Kumar K.V wrote:
> Catalin Marinas <catalin.marinas@arm.com> writes:
>
>> On Wed, Jul 01, 2026 at 11:19:20AM +0530, Aneesh Kumar K.V (Arm) wrote:
>>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>>> index 97987f850a33..acf67c7064db 100644
>>> --- a/arch/arm64/mm/init.c
>>> +++ b/arch/arm64/mm/init.c
>>> @@ -338,10 +338,8 @@ void __init arch_mm_preinit(void)
>>> unsigned int flags = SWIOTLB_VERBOSE;
>>> bool swiotlb = max_pfn > PFN_DOWN(arm64_dma_phys_limit);
>>>
>>> - if (is_realm_world()) {
>>> + if (is_realm_world())
>>> swiotlb = true;
>>> - flags |= SWIOTLB_FORCE;
>>> - }
>>
>> For this part:
>>
>> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
>>
>>> diff --git a/kernel/dma/direct.h b/kernel/dma/direct.h
>>> index e05dc7649366..f3fc28f352ba 100644
>>> --- a/kernel/dma/direct.h
>>> +++ b/kernel/dma/direct.h
>>> @@ -88,37 +88,40 @@ static inline dma_addr_t dma_direct_map_phys(struct device *dev,
>>> {
>>> dma_addr_t dma_addr;
>>>
>>> + /*
>>> + * For a device requiring unencrypted DMA, MMIO memory is treated
>>> + * as shared by default.
>>> + */
>>> + if (force_dma_unencrypted(dev) && (attrs & DMA_ATTR_MMIO))
>>> + attrs |= DMA_ATTR_CC_SHARED;
>>> +
>>> if (is_swiotlb_force_bounce(dev)) {
>>> - if (!(attrs & DMA_ATTR_CC_SHARED)) {
>>> - if (attrs & (DMA_ATTR_MMIO | DMA_ATTR_REQUIRE_COHERENT))
>>> - return DMA_MAPPING_ERROR;
>>> + if (attrs & (DMA_ATTR_MMIO | DMA_ATTR_REQUIRE_COHERENT))
>>> + return DMA_MAPPING_ERROR;
>>>
>>> - return swiotlb_map(dev, phys, size, dir, attrs);
>>> - }
>>> - } else if (attrs & DMA_ATTR_CC_SHARED) {
>>> - return DMA_MAPPING_ERROR;
>>> + return swiotlb_map(dev, phys, size, dir, attrs);
>>> }
>>>
>>> - if (attrs & DMA_ATTR_MMIO) {
>>> - dma_addr = phys;
>>> - if (unlikely(!dma_capable(dev, dma_addr, size, false, attrs)))
>>> - goto err_overflow;
>>> - } else if (attrs & DMA_ATTR_CC_SHARED) {
>>> + if (attrs & DMA_ATTR_CC_SHARED)
>>> dma_addr = phys_to_dma_unencrypted(dev, phys);
>>> + else
>>> + dma_addr = phys_to_dma_encrypted(dev, phys);
>>
>> For AMD/SME, on host with memory encryption we now end up setting the C
>> bit for DMA_ATTR_MMIO. This is fine for RAM but not sure whether
>> some other MMIO bus understands this attribute. Maybe we should stick to
>> something like __phys_to_dma() for the !CC_SHARED && MMIO path. Or,
>> since this is not universally defined, just use the old dma_addr = phys
>> if MMIO and ignore any unlikely DMA offsets.
>>
>
> Considering for AMD/SME system an unencrypted dma addr is one without C
> bit, will this be good?
Normally both encrypted and unencrypted DMA addresses do not have Cbit, with the only exception of "iommu=pt" (which is not the default afaik). And in this case, having Cbit in DMA handles only makes sense if p2p trafic goes via the root port (== IOMMU in passthrough mode, and I am not sure even about if the root port will convert this Cbit to T=1 MMIO in this mode) but if it goes via some PCI bridge - then Cbit won't mean encryption for sure. But I do not know much about p2p (never touched). But in any case force_dma_unencrypted() seems to make no sense here.
>
> /*
> * For host memory encryption and device requiring unencrypted DMA,
> * MMIO memory is treated as shared by default.
> */
> if (attrs & DMA_ATTR_MMIO) {
> if (cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT) || force_dma_unencrypted(dev))
> attrs |= DMA_ATTR_CC_SHARED;
> }
>
>
>>
>> In the other case, for an arm CCA guest, if the MMIO is shared we end up
>> setting the shared attribute but that's fine, it's only an IPA address.
IPA == guest physical address? Thanks,
>>
>> --
>> Catalin
>
> -aneesh
--
Alexey
^ permalink raw reply
* Re: [PATCH v15 26/37] KVM: arm64: WARN on injected undef exceptions
From: Marc Zyngier @ 2026-07-15 16:43 UTC (permalink / raw)
To: Steven Price
Cc: kvm, kvmarm, Catalin Marinas, Will Deacon, James Morse,
Oliver Upton, Suzuki K Poulose, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Gavin Shan,
Shanker Donthineni, Alper Gun, Aneesh Kumar K . V, Emi Kisanuki,
Vishal Annapurve, WeiLin.Chang, Lorenzo Pieralisi
In-Reply-To: <a008d2b9-1eff-4de7-add8-ef8e95efd439@arm.com>
On Wed, 15 Jul 2026 17:31:57 +0100,
Steven Price <steven.price@arm.com> wrote:
>
> On 15/07/2026 17:25, Marc Zyngier wrote:
> > On Wed, 15 Jul 2026 17:15:31 +0100,
> > Steven Price <steven.price@arm.com> wrote:
> >>
> >> On 15/07/2026 16:46, Marc Zyngier wrote:
> >>> On Wed, 15 Jul 2026 15:28:28 +0100,
> >>> Steven Price <steven.price@arm.com> wrote:
> >>>>
> >>>> The RMM doesn't allow injection of a undefined exception into a realm
> >>>> guest. Add a WARN to catch if this ever happens.
> >>>>
> >>>> Signed-off-by: Steven Price <steven.price@arm.com>
> >>>> Reviewed-by: Gavin Shan <gshan@redhat.com>
> >>>> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> >>>> ---
> >>>> Changes since v6:
> >>>> * if (x) WARN(1, ...) makes no sense, just WARN(x, ...)!
> >>>> ---
> >>>> arch/arm64/kvm/inject_fault.c | 1 +
> >>>> 1 file changed, 1 insertion(+)
> >>>>
> >>>> diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
> >>>> index 6492397b73d7..613f223bc7a3 100644
> >>>> --- a/arch/arm64/kvm/inject_fault.c
> >>>> +++ b/arch/arm64/kvm/inject_fault.c
> >>>> @@ -327,6 +327,7 @@ void kvm_inject_size_fault(struct kvm_vcpu *vcpu)
> >>>> */
> >>>> void kvm_inject_undefined(struct kvm_vcpu *vcpu)
> >>>> {
> >>>> + WARN(vcpu_is_rec(vcpu), "Unexpected undefined exception injection to REC");
> >>>> if (vcpu_el1_is_32bit(vcpu))
> >>>> inject_undef32(vcpu);
> >>>> else
> >>>
> >>> No. WARN_ONCE at a push, but even then, this looks dodgy.
> >>
> >> Yep WARN_ONCE() would be better. This function should never be called
> >> for a realm guest.
> >>
> >>> Exceptions must be injectable. Otherwise, how do you respond to, for
> >>> example, a sysreg access for a feature that is hidden from the guest?
> >>
> >> The RMM doesn't allow the host to inject exceptions - with the exception
> >> of SEA after a host-emulated MMIO.
> >>
> >>> Will the RMM perform this in KVM's stead?
> >>
> >> Yes the RMM would have to handle this for the likes of sysreg accesses.
> >> The host doesn't control the trapping of sysreg accesses. There are a
> >> few GIC-related registers which are forwarded to the host ("REC exit due
> >> to system register access") but generally the handling of sysregs is
> >> entirely internal to the RMM.
> >
> > Then the only option is not to just warn, but to mark all realms as
> > dead and refuse to run them any further. If we can't inject an
> > exception and that the RMM isn't doing its job, I can't see how we can
> > continue at all.
>
> You've got a point - I'm not sure whether it's entirely reasonable to
> refuse to run any realm, but it certainly would be sensible to mark the
If the RMM is not playing ball by not doing its part of the bargain,
the only sane option is stop talking to it immediately. Who knows what
else the implementation got wrong?
> guest which triggers this as dead. Would a KVM_BUG() be more appropriate
> here?
That's the absolutely minimal option. Not necessarily the safe one.
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply
* Re: [PATCH v15 26/37] KVM: arm64: WARN on injected undef exceptions
From: Steven Price @ 2026-07-15 16:31 UTC (permalink / raw)
To: Marc Zyngier
Cc: kvm, kvmarm, Catalin Marinas, Will Deacon, James Morse,
Oliver Upton, Suzuki K Poulose, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Gavin Shan,
Shanker Donthineni, Alper Gun, Aneesh Kumar K . V, Emi Kisanuki,
Vishal Annapurve, WeiLin.Chang, Lorenzo Pieralisi
In-Reply-To: <87y0fc43ut.wl-maz@kernel.org>
On 15/07/2026 17:25, Marc Zyngier wrote:
> On Wed, 15 Jul 2026 17:15:31 +0100,
> Steven Price <steven.price@arm.com> wrote:
>>
>> On 15/07/2026 16:46, Marc Zyngier wrote:
>>> On Wed, 15 Jul 2026 15:28:28 +0100,
>>> Steven Price <steven.price@arm.com> wrote:
>>>>
>>>> The RMM doesn't allow injection of a undefined exception into a realm
>>>> guest. Add a WARN to catch if this ever happens.
>>>>
>>>> Signed-off-by: Steven Price <steven.price@arm.com>
>>>> Reviewed-by: Gavin Shan <gshan@redhat.com>
>>>> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>>>> ---
>>>> Changes since v6:
>>>> * if (x) WARN(1, ...) makes no sense, just WARN(x, ...)!
>>>> ---
>>>> arch/arm64/kvm/inject_fault.c | 1 +
>>>> 1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
>>>> index 6492397b73d7..613f223bc7a3 100644
>>>> --- a/arch/arm64/kvm/inject_fault.c
>>>> +++ b/arch/arm64/kvm/inject_fault.c
>>>> @@ -327,6 +327,7 @@ void kvm_inject_size_fault(struct kvm_vcpu *vcpu)
>>>> */
>>>> void kvm_inject_undefined(struct kvm_vcpu *vcpu)
>>>> {
>>>> + WARN(vcpu_is_rec(vcpu), "Unexpected undefined exception injection to REC");
>>>> if (vcpu_el1_is_32bit(vcpu))
>>>> inject_undef32(vcpu);
>>>> else
>>>
>>> No. WARN_ONCE at a push, but even then, this looks dodgy.
>>
>> Yep WARN_ONCE() would be better. This function should never be called
>> for a realm guest.
>>
>>> Exceptions must be injectable. Otherwise, how do you respond to, for
>>> example, a sysreg access for a feature that is hidden from the guest?
>>
>> The RMM doesn't allow the host to inject exceptions - with the exception
>> of SEA after a host-emulated MMIO.
>>
>>> Will the RMM perform this in KVM's stead?
>>
>> Yes the RMM would have to handle this for the likes of sysreg accesses.
>> The host doesn't control the trapping of sysreg accesses. There are a
>> few GIC-related registers which are forwarded to the host ("REC exit due
>> to system register access") but generally the handling of sysregs is
>> entirely internal to the RMM.
>
> Then the only option is not to just warn, but to mark all realms as
> dead and refuse to run them any further. If we can't inject an
> exception and that the RMM isn't doing its job, I can't see how we can
> continue at all.
You've got a point - I'm not sure whether it's entirely reasonable to
refuse to run any realm, but it certainly would be sensible to mark the
guest which triggers this as dead. Would a KVM_BUG() be more appropriate
here?
Thanks,
Steve
^ permalink raw reply
* Re: [PATCH v15 26/37] KVM: arm64: WARN on injected undef exceptions
From: Marc Zyngier @ 2026-07-15 16:25 UTC (permalink / raw)
To: Steven Price
Cc: kvm, kvmarm, Catalin Marinas, Will Deacon, James Morse,
Oliver Upton, Suzuki K Poulose, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Gavin Shan,
Shanker Donthineni, Alper Gun, Aneesh Kumar K . V, Emi Kisanuki,
Vishal Annapurve, WeiLin.Chang, Lorenzo Pieralisi
In-Reply-To: <ec0f52d4-666d-4b6f-b010-eb0391fa53a7@arm.com>
On Wed, 15 Jul 2026 17:15:31 +0100,
Steven Price <steven.price@arm.com> wrote:
>
> On 15/07/2026 16:46, Marc Zyngier wrote:
> > On Wed, 15 Jul 2026 15:28:28 +0100,
> > Steven Price <steven.price@arm.com> wrote:
> >>
> >> The RMM doesn't allow injection of a undefined exception into a realm
> >> guest. Add a WARN to catch if this ever happens.
> >>
> >> Signed-off-by: Steven Price <steven.price@arm.com>
> >> Reviewed-by: Gavin Shan <gshan@redhat.com>
> >> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> >> ---
> >> Changes since v6:
> >> * if (x) WARN(1, ...) makes no sense, just WARN(x, ...)!
> >> ---
> >> arch/arm64/kvm/inject_fault.c | 1 +
> >> 1 file changed, 1 insertion(+)
> >>
> >> diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
> >> index 6492397b73d7..613f223bc7a3 100644
> >> --- a/arch/arm64/kvm/inject_fault.c
> >> +++ b/arch/arm64/kvm/inject_fault.c
> >> @@ -327,6 +327,7 @@ void kvm_inject_size_fault(struct kvm_vcpu *vcpu)
> >> */
> >> void kvm_inject_undefined(struct kvm_vcpu *vcpu)
> >> {
> >> + WARN(vcpu_is_rec(vcpu), "Unexpected undefined exception injection to REC");
> >> if (vcpu_el1_is_32bit(vcpu))
> >> inject_undef32(vcpu);
> >> else
> >
> > No. WARN_ONCE at a push, but even then, this looks dodgy.
>
> Yep WARN_ONCE() would be better. This function should never be called
> for a realm guest.
>
> > Exceptions must be injectable. Otherwise, how do you respond to, for
> > example, a sysreg access for a feature that is hidden from the guest?
>
> The RMM doesn't allow the host to inject exceptions - with the exception
> of SEA after a host-emulated MMIO.
>
> > Will the RMM perform this in KVM's stead?
>
> Yes the RMM would have to handle this for the likes of sysreg accesses.
> The host doesn't control the trapping of sysreg accesses. There are a
> few GIC-related registers which are forwarded to the host ("REC exit due
> to system register access") but generally the handling of sysregs is
> entirely internal to the RMM.
Then the only option is not to just warn, but to mark all realms as
dead and refuse to run them any further. If we can't inject an
exception and that the RMM isn't doing its job, I can't see how we can
continue at all.
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply
* Re: [PATCH v15 02/37] KVM: arm64: Avoid including linux/kvm_host.h in kvm_pgtable.h
From: Steven Price @ 2026-07-15 16:22 UTC (permalink / raw)
To: Marc Zyngier
Cc: kvm, kvmarm, Catalin Marinas, Will Deacon, James Morse,
Oliver Upton, Suzuki K Poulose, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Gavin Shan,
Shanker Donthineni, Alper Gun, Aneesh Kumar K . V, Emi Kisanuki,
Vishal Annapurve, WeiLin.Chang, Lorenzo Pieralisi
In-Reply-To: <871pd45jmn.wl-maz@kernel.org>
On 15/07/2026 16:59, Marc Zyngier wrote:
> On Wed, 15 Jul 2026 15:28:04 +0100,
> Steven Price <steven.price@arm.com> wrote:
>>
>> To avoid future include cycles, drop the linux/kvm_host.h include in
>> kvm_pgtable.h and include the lightweight headers required for the types and
>> inline helpers used there. Additionally provide a forward declaration for
>> struct kvm_s2_mmu as it's only used as a pointer in this file.
>>
>> Both pgtable.c and kvm_pkvm.h relied on the indirect inclusion of
>> kvm_host.h, so make that explicit.
>>
>> Signed-off-by: Steven Price <steven.price@arm.com>
>> ---
>> New patch in v13
>> ---
>> arch/arm64/include/asm/kvm_pgtable.h | 6 +++++-
>> arch/arm64/include/asm/kvm_pkvm.h | 2 +-
>> arch/arm64/kvm/hyp/pgtable.c | 1 +
>> 3 files changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/kvm_pgtable.h b/arch/arm64/include/asm/kvm_pgtable.h
>> index 41a8687938eb..c2e4b29e605f 100644
>> --- a/arch/arm64/include/asm/kvm_pgtable.h
>> +++ b/arch/arm64/include/asm/kvm_pgtable.h
>> @@ -8,9 +8,13 @@
>> #define __ARM64_KVM_PGTABLE_H__
>>
>> #include <linux/bits.h>
>> -#include <linux/kvm_host.h>
>> +#include <linux/kvm_types.h>
>> +#include <linux/rbtree_types.h>
>> +#include <linux/rcupdate.h>
>> #include <linux/types.h>
>>
>> +struct kvm_s2_mmu;
>> +
>> #define KVM_PGTABLE_FIRST_LEVEL -1
>> #define KVM_PGTABLE_LAST_LEVEL 3
>>
>> diff --git a/arch/arm64/include/asm/kvm_pkvm.h b/arch/arm64/include/asm/kvm_pkvm.h
>> index 74fedd9c5ff0..a0f7a699d690 100644
>> --- a/arch/arm64/include/asm/kvm_pkvm.h
>> +++ b/arch/arm64/include/asm/kvm_pkvm.h
>> @@ -9,7 +9,7 @@
>> #include <linux/arm_ffa.h>
>> #include <linux/memblock.h>
>> #include <linux/scatterlist.h>
>> -#include <asm/kvm_host.h>
>> +#include <linux/kvm_host.h>
>
> nit: please keep the include directives in alphabetical order.
Ack.
Thanks,
Steve
> M.
>
^ permalink raw reply
* Re: [PATCH v15 26/37] KVM: arm64: WARN on injected undef exceptions
From: Steven Price @ 2026-07-15 16:15 UTC (permalink / raw)
To: Marc Zyngier
Cc: kvm, kvmarm, Catalin Marinas, Will Deacon, James Morse,
Oliver Upton, Suzuki K Poulose, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Gavin Shan,
Shanker Donthineni, Alper Gun, Aneesh Kumar K . V, Emi Kisanuki,
Vishal Annapurve, WeiLin.Chang, Lorenzo Pieralisi
In-Reply-To: <8733xk5k7v.wl-maz@kernel.org>
On 15/07/2026 16:46, Marc Zyngier wrote:
> On Wed, 15 Jul 2026 15:28:28 +0100,
> Steven Price <steven.price@arm.com> wrote:
>>
>> The RMM doesn't allow injection of a undefined exception into a realm
>> guest. Add a WARN to catch if this ever happens.
>>
>> Signed-off-by: Steven Price <steven.price@arm.com>
>> Reviewed-by: Gavin Shan <gshan@redhat.com>
>> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>> ---
>> Changes since v6:
>> * if (x) WARN(1, ...) makes no sense, just WARN(x, ...)!
>> ---
>> arch/arm64/kvm/inject_fault.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
>> index 6492397b73d7..613f223bc7a3 100644
>> --- a/arch/arm64/kvm/inject_fault.c
>> +++ b/arch/arm64/kvm/inject_fault.c
>> @@ -327,6 +327,7 @@ void kvm_inject_size_fault(struct kvm_vcpu *vcpu)
>> */
>> void kvm_inject_undefined(struct kvm_vcpu *vcpu)
>> {
>> + WARN(vcpu_is_rec(vcpu), "Unexpected undefined exception injection to REC");
>> if (vcpu_el1_is_32bit(vcpu))
>> inject_undef32(vcpu);
>> else
>
> No. WARN_ONCE at a push, but even then, this looks dodgy.
Yep WARN_ONCE() would be better. This function should never be called
for a realm guest.
> Exceptions must be injectable. Otherwise, how do you respond to, for
> example, a sysreg access for a feature that is hidden from the guest?
The RMM doesn't allow the host to inject exceptions - with the exception
of SEA after a host-emulated MMIO.
> Will the RMM perform this in KVM's stead?
Yes the RMM would have to handle this for the likes of sysreg accesses.
The host doesn't control the trapping of sysreg accesses. There are a
few GIC-related registers which are forwarded to the host ("REC exit due
to system register access") but generally the handling of sysregs is
entirely internal to the RMM.
Thanks,
Steve
^ permalink raw reply
* Re: [PATCH v15 09/37] KVM: arm64: CCA: Allow passing the machine type in KVM creation
From: Marc Zyngier @ 2026-07-15 16:14 UTC (permalink / raw)
To: Steven Price
Cc: kvm, kvmarm, Catalin Marinas, Will Deacon, James Morse,
Oliver Upton, Suzuki K Poulose, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Gavin Shan,
Shanker Donthineni, Alper Gun, Aneesh Kumar K . V, Emi Kisanuki,
Vishal Annapurve, WeiLin.Chang, Lorenzo Pieralisi
In-Reply-To: <20260715142841.80544-10-steven.price@arm.com>
On Wed, 15 Jul 2026 15:28:11 +0100,
Steven Price <steven.price@arm.com> wrote:
>
> Previously machine type was used purely for specifying the physical
> address size of the guest. Reserve the higher bits to specify an ARM
> specific machine type and declare a new type 'KVM_VM_TYPE_ARM_REALM'
> used to create a realm guest.
>
> Signed-off-by: Steven Price <steven.price@arm.com>
> ---
> Changes since v13:
> * Rework to use the two top bits for the machine type now that pKVM has
> merged and used the top bit for KVM_VM_TYPE_ARM_PROTECTED.
> * Update the documentation to include KVM_VM_TYPE_ARM_PROTECTED as
> well.
> Changes since v9:
> * Explictly set realm.state to REALM_STATE_NONE rather than rely on the
> zeroing of the structure.
> Changes since v7:
> * Add some documentation explaining the new machine type.
> Changes since v6:
> * Make the check for kvm_rme_is_available more visible and report an
> error code of -EPERM (instead of -EINVAL) to make it explicit that
> the kernel supports RME, but the platform doesn't.
> ---
> Documentation/virt/kvm/api.rst | 18 ++++++++++++++++--
> arch/arm64/kvm/arm.c | 11 +++++++++++
> include/uapi/linux/kvm.h | 7 ++++++-
> 3 files changed, 33 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> index b38e090ad95d..e39d146b34a3 100644
> --- a/Documentation/virt/kvm/api.rst
> +++ b/Documentation/virt/kvm/api.rst
> @@ -181,8 +181,22 @@ flag KVM_VM_MIPS_VZ.
> ARM64:
> ^^^^^^
>
> -On arm64, the physical address size for a VM (IPA Size limit) is limited
> -to 40bits by default. The limit can be configured if the host supports the
> +On arm64, the machine type identifier is used to encode a type and the
> +physical address size for the VM. The lower byte (bits[7-0]) encode the
> +address size and the upper bits[30-31] encode a machine type. The machine
> +types that might be available are:
> +
> + ========================= ============================================
> + KVM_VM_TYPE_ARM_NORMAL A standard VM
> + KVM_VM_TYPE_ARM_REALM A "Realm" VM using the Arm Confidential
> + Compute extensions, the VM's memory is
> + protected from the host.
> + KVM_VM_TYPE_ARM_PROTECTED A "protected" VM using pKVM to isolate the
> + VM from the host.
> + ========================= ============================================
> +
Probably worth mentioning that REALM+PROTECTED is an illegal
combination.
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox