On 2025-07-23 05:29, Julien Grall wrote:
Hi Jason,
On 21/07/2025 23:00, Jason Andryuk wrote:
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 88a294c5be..f1f6f96bc2 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -70,9 +70,11 @@ struct xen_domctl_createdomain {
#define XEN_DOMCTL_CDF_trap_unmapped_accesses (1U << 8)
/* Allow domain to provide device model for multiple other domains */
#define XEN_DOMCTL_CDF_device_model (1U << 9)
+/* Domain cannot be the target of hypercalls */
+#define XEN_DOMCTL_CDF_not_hypercall_target (1U << 10)
/* Max XEN_DOMCTL_CDF_* constant. Used for ABI checking. */
-#define XEN_DOMCTL_CDF_MAX XEN_DOMCTL_CDF_device_model
+#define XEN_DOMCTL_CDF_MAX XEN_DOMCTL_CDF_not_hypercall_target
I am not sure where to comment. But aren't both flags mutually
exclusive?
No, XEN_DOMCTL_CDF_device_model is *this* domain providing the device
model to other domains:
+ * Device model capability allows the use of the dm_op hypercalls to
provide
+ * the device model emulation (run QEMU) for other domains. This is a
+ * subset of the Control capability which can be granted to the
+ * Hardware domain for running QEMU.
Whereas XEN_DOMCTL_CDF_not_hypercall_target removes targeting on
*this* domain. So the domain with XEN_DOMCTL_CDF_device_model cannot
target the XEN_DOMCTL_CDF_not_hypercall_target domain.
Thanks for the clarification. I misunderstood the goal of
XEN_DOMCTL_CDF_device_model. That said, I think there is still a problem
because with CDF_not_hypercall_target, you would not be able to have a
device-emulator for that domain. Is this intended?
Yes, it is intentional that CDF_not_hypercall_target prevents using a
device model. With out safety use-case, we want to be able to avoid
interference for specific domains.
Regards,
Jason
