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

Re: [Xen-devel] XSM SILO boot time spew

  • To: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
  • From: "Xin Li (Talons)" <xin.li@xxxxxxxxxx>
  • Date: Thu, 1 Nov 2018 03:19:58 +0000
  • Accept-language: en-US
  • Cc: Xen-devel List <xen-devel@xxxxxxxxxxxxx>
  • Delivery-date: Thu, 01 Nov 2018 03:20:16 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHUcZAlsttEAYsbKEyobFDcDNeTHg==
  • Thread-topic: XSM SILO boot time spew

In patchset v4, we call register_xsm() to setup silo module.
This debug log is to check if some ops not overrided by the module.
I thought this is OK, since the log level is debug.

I think calling register_xsm() is good,
if we do want to suppress this debug log explicitly,
we can check if ops eqauls silo_xsm_ops in macro set_to_dummy_if_null().

The follow diff shows what I am suggesting, is it OK?

diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 3b192b5c31..b94fc43961 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -734,6 +734,7 @@ extern const unsigned int xsm_flask_init_policy_size;
+extern struct xsm_operations silo_xsm_ops;
 extern void silo_init(void);
 static inline void silo_init(void) {}
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 06a674fad0..5af990514f 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -15,12 +15,20 @@
 struct xsm_operations dummy_xsm_ops;
+#define check_xsm_module(ops)                                          \
+    if (ops != &dummy_xsm_ops && ops != &silo_xsm_ops)
+#define check_xsm_module(ops)                                          \
+    if (ops != &dummy_xsm_ops)
 #define set_to_dummy_if_null(ops, function)                            \
     do {                                                               \
         if ( !ops->function )                                          \
         {                                                              \
             ops->function = xsm_##function;                            \
-            if (ops != &dummy_xsm_ops)                                 \
+            check_xsm_module(ops)                                      \
                 dprintk(XENLOG_DEBUG, "Had to override the " #function \
                     " security operation with the dummy one.\n");      \
         }                                                              \
diff --git a/xen/xsm/silo.c b/xen/xsm/silo.c
index 4850756a3d..d2e6724e26 100644
--- a/xen/xsm/silo.c
+++ b/xen/xsm/silo.c
@@ -81,7 +81,7 @@ static int silo_grant_copy(struct domain *d1, struct domain 
     return -EPERM;
-static struct xsm_operations silo_xsm_ops = {
+struct xsm_operations silo_xsm_ops = {
     .evtchn_unbound = silo_evtchn_unbound,
     .evtchn_interdomain = silo_evtchn_interdomain,
     .grant_mapref = silo_grant_mapref,

From: Andrew Cooper
Sent: Wednesday, October 31, 2018 8:35 PM
To: Xen-devel List
Cc: Daniel De Graaf; Xin Li (Talons)
Subject: XSM SILO boot time spew


I've noticed that the SILO code causes the following debug spew:

(XEN) XSM Framework v1.0.0 initialized
(XEN) Initialising XSM SILO mode
(XEN) dummy.c:31: Had to override the security_domaininfo security
operation with the dummy one.
(XEN) dummy.c:32: Had to override the domain_create security operation
with the dummy one.
(XEN) dummy.c:158: Had to override the xen_version security operation
with the dummy one.
(XEN) dummy.c:159: Had to override the domain_resource_map security
operation with the dummy one.
(XEN) microcode: CPU0 updated from revision 0x1a to 0x25, date = 2018-04-02
(XEN) xstate: size: 0x340 and states: 0x7

which is a side effect of silo_xsm_ops only implementing a few of the
hooks, falling back to dummy for the rest.

Presumably we don't want to special case SILO when overriding the
hooks.  Would having silo_init() explicitly copy from dummy be ok?


Xen-devel mailing list



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