WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH 1/5] libxl: introduce cpuid interface to domain b

To: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 1/5] libxl: introduce cpuid interface to domain build
From: Andre Przywara <andre.przywara@xxxxxxx>
Date: Thu, 9 Sep 2010 21:16:11 +0200
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <Keir.Fraser@xxxxxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Thu, 09 Sep 2010 12:16:58 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1283939221.14311.1477.camel@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4C87551F.4080300@xxxxxxx> <1283939221.14311.1477.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.18 (X11/20081105)
Ian Campbell wrote:
On Wed, 2010-09-08 at 10:19 +0100, Andre Przywara wrote:
Add a cpuid parameter into libxl_domain_build_info and use
it's content while setting up the domain. This is a only paving the way, the real functionality is implemented in a later patch.

Signed-off-by: Andre Przywara <andre.przywara@xxxxxxx>

The destructor function should free the type but not the reference to
it, so:

@@ -102,6 +102,21 @@ void
libxl_key_value_list_destroy(libxl_key_value_list *pkvl)
     free(kvl);
 }
+void libxl_cpuid_destroy(libxl_cpuid_policy_list cpuid_list)

This should be *cpuid_list and the function should be adjusted to free
the elements of *cpuid_list but not cpuid_list itself.

--- a/tools/libxl/libxl.idl
+++ b/tools/libxl/libxl.idl
@@ -11,6 +11,7 @@ libxl_console_consback = Builtin("console_consback")
 libxl_console_constype = Builtin("console_constype")
 libxl_disk_phystype = Builtin("disk_phystype")
 libxl_nic_type = Builtin("nic_type")
+libxl_cpuid_policy_list = Builtin("cpuid_policy_list", 
destructor_fn="libxl_cpuid_destroy")

And this should have passby=PASS_BY_REFERENCE.

See 22078:573ddf5cc145 for a similar change to the libxl_string_list and
libxl_key_value_list destructor functions.
Do you mean like in the attached patch?


--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -172,6 +172,22 @@ typedef enum {
     NICTYPE_VIF,
 } libxl_nic_type;
+/* holds the CPUID response for a single CPUID leaf
+ * input contains the value of the EAX and ECX register,
+ * and each policy string contains a filter to apply to
+ * the host given values for that particular leaf.
+ */ +struct libxl_cpuid_policy {
+    uint32_t input[2];
+    char *policy[4];
+};

I realise (at least I think I do) that this is just exposing the
existing hypervisor/libxc interface warts and all but would this be more
obvious to users if it was:
struct libxl_cpuid_policy {
      uint32_t eax;
      uint32_t ecx;

      char *eax_filter;
      char *ebx_filter;
      char *ecx_filter;
      char *edx_filter;
}

could either translate in libxl or push the change down into libxc.
Actually I consider this structure not a real interface, but more an opaque kludge to transport the data from the configuration parsing to domain creation. If you want to change the data here, I'd like to see the parse functions used. Actually I designed them such that one can alter the policy at any time by chaining calls to these functions. This is my plan to use in the upcoming multi-core patch, it would simply call libxl_cpuid_parse_config(&b_info->cpuid, "proccount=4");
to make it ultimately readable.
Beside that I'd rather hide the dynamic array nature of it.

Alternatively
   #define LIBXL_CPUID_INPUT_EAX 0
   #define LIBXL_CPUID_INPUT_ECX 1

   #define LIBXL_CPUID_FILTER_EAX 0
   #define LIBXL_CPUID_FILTER_EBX 1
   ...
would at least make the code (or at least the data structure) a bit more
obvious.
I am not sure whether that would help. The interface is too error-prone to be directly used by other functions than those parsers, so I'd like not to promote it with defining macros (which I probably wouldn't use in my own code, since I mostly either propagate the reg number or enumerate over all registers).
If you like I could introduce a kind of low-level function, like:
libxl_cpuid_set_policy(libxl_cpuid_policy_list *list, uint32_t leaf,
                       int bit, char policy);
That could be used by other parts of libxl as well and would care about the string fiddling and allocation.
Do we need this function?

Shall I state the opaque nature of this structure in a comment?

Regards,
Andre.

--
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Tel: +49 351 448-3567-12
commit 350ce61c3c96a582a6f5d641f4ffc20e0806182a
Author: Andre Przywara <andre.przywara@xxxxxxx>
Date:   Tue Aug 24 09:35:51 2010 +0200

    xl: introduce cpuid interface to domain build
    
    this one adds a cpuid parameter into libxl_domain_build_info and uses
    it's content while setting up the domain. This is a placeholder for
    now, since the parsing is only implemented in the next patch.
    
    Signed-off-by: Andre Przywara <andre.przywara@xxxxxxx>

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 03d9a93..564afc6 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -102,6 +102,21 @@ void libxl_key_value_list_destroy(libxl_key_value_list 
*pkvl)
     free(kvl);
 }
 
+void libxl_cpuid_destroy(libxl_cpuid_policy_list *p_cpuid_list)
+{
+    int i, j;
+    libxl_cpuid_policy_list cpuid_list = *p_cpuid_list;
+
+    if (cpuid_list == NULL)
+        return;
+    for (i = 0; cpuid_list[i].input[0] != XEN_CPUID_INPUT_UNUSED; i++) {
+        for (j = 0; j < 4; j++)
+            if (cpuid_list[i].policy[j] != NULL)
+                free(cpuid_list[i].policy[j]);
+    }
+    return;
+}
+
 
/******************************************************************************/
 
 int libxl_domain_make(libxl_ctx *ctx, libxl_domain_create_info *info,
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index d989f10..50c9e3d 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -172,6 +172,22 @@ typedef enum {
     NICTYPE_VIF,
 } libxl_nic_type;
 
+/* holds the CPUID response for a single CPUID leaf
+ * input contains the value of the EAX and ECX register,
+ * and each policy string contains a filter to apply to
+ * the host given values for that particular leaf.
+ */ 
+struct libxl_cpuid_policy {
+    uint32_t input[2];
+    char *policy[4];
+};
+
+/* libxl_cpuid_policy_list is a dynamic array storing CPUID policies
+ * for multiple leafs. It is terminated with an entry holding
+ * XEN_CPUID_INPUT_UNUSED in input[0]
+ */
+typedef struct libxl_cpuid_policy * libxl_cpuid_policy_list;
+
 #define LIBXL_PCI_FUNC_ALL (~0U)
 
 #include "_libxl_types.h"
@@ -231,6 +247,7 @@ int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid, 
libxl_domain_create_in
 void libxl_string_list_destroy(libxl_string_list *sl);
 void libxl_key_value_list_destroy(libxl_key_value_list *kvl);
 void libxl_file_reference_destroy(libxl_file_reference *f);
+void libxl_cpuid_destroy(libxl_cpuid_policy_list *cpuid_list);
 
 /*
  * Run the configured bootloader for a PV domain and update
diff --git a/tools/libxl/libxl.idl b/tools/libxl/libxl.idl
index 1e36926..da7fc7a 100644
--- a/tools/libxl/libxl.idl
+++ b/tools/libxl/libxl.idl
@@ -11,6 +11,7 @@ libxl_console_consback = Builtin("console_consback")
 libxl_console_constype = Builtin("console_constype")
 libxl_disk_phystype = Builtin("disk_phystype")
 libxl_nic_type = Builtin("nic_type")
+libxl_cpuid_policy_list = Builtin("cpuid_policy_list", 
destructor_fn="libxl_cpuid_destroy", passby=PASS_BY_REFERENCE)
 
 libxl_string_list = Builtin("string_list", 
destructor_fn="libxl_string_list_destroy", passby=PASS_BY_REFERENCE)
 libxl_key_value_list = Builtin("key_value_list", 
destructor_fn="libxl_key_value_list_destroy", passby=PASS_BY_REFERENCE)
@@ -97,6 +98,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
     ("shadow_memkb",    uint32),
     ("disable_migrate", bool),
     ("kernel",          libxl_file_reference),
+    ("cpuid",           libxl_cpuid_policy_list),
     ("hvm",             integer),
     ("u", KeyedUnion(None, "hvm",
                 [("hvm", "%s", Struct(None,
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index e83bbbf..e8c0bda 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -91,9 +91,15 @@ int build_post(libxl_ctx *ctx, uint32_t domid,
     xs_transaction_t t;
     char **ents;
     int i;
+    char *cpuid_res[4];
 
 #if defined(__i386__) || defined(__x86_64__)
     xc_cpuid_apply_policy(ctx->xch, domid);
+    if (info->cpuid != NULL) {
+        for (i = 0; info->cpuid[i].input[0] != XEN_CPUID_INPUT_UNUSED; i++)
+            xc_cpuid_set(ctx->xch, domid, info->cpuid[i].input,
+                         (const char**)(info->cpuid[i].policy), cpuid_res);
+    }
 #endif
 
     ents = libxl_calloc(&gc, 12 + (info->max_vcpus * 2) + 2, sizeof(char *));
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 3f6219b..c6b6d85 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -268,6 +268,7 @@ static void init_build_info(libxl_domain_build_info 
*b_info, libxl_domain_create
     b_info->max_memkb = 32 * 1024;
     b_info->target_memkb = b_info->max_memkb;
     b_info->disable_migrate = 0;
+    b_info->cpuid = NULL;
     if (c_info->hvm) {
         b_info->shadow_memkb = 0; /* Set later */
         b_info->video_memkb = 8 * 1024;
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel