[PATCH 2/4] libxl: implementing legacy xm cpuid parser

[PATCH 2/4] libxl: implementing legacy xm cpuid parser

[Andre Przywara]

[-- Attachment #1: Type: text/plain, Size: 330 bytes --]

To support legacy xm-based config files, add a parser for the old
style cpuid= syntax. This uses a Python list, so it can be
distinguished from the new syntax easily.

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

-- 
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Tel: +49 351 448-3567-12

[-- Attachment #2: 0002-libxl-implementing-legacy-xm-cpuid-parser.patch --]
[-- Type: text/x-patch, Size: 3432 bytes --]

>From 1b0676c524b11af028b0d8d34ea76035fca88530 Mon Sep 17 00:00:00 2001
From: Andre Przywara <andre.przywara@amd.com>
Date: Wed, 1 Sep 2010 09:22:35 +0200
Subject: [PATCH 2/4] libxl: implementing legacy xm cpuid parser

To support legacy xm-based config files, add a parser for the old
style cpuid= syntax. This uses a Python list, so it can be
distinguished from the new syntax easily.

Signed-off-by: Andre Przywara <andre.przywara@amd.com>
---
 tools/libxl/libxl.c |   60 +++++++++++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl.h |    2 +
 2 files changed, 62 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index fedab29..f5891e7 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -3451,6 +3451,66 @@ int libxl_cpuid_parse_config(libxl_cpuid_policy_list *cpuid, const char* str)
     return 0;
 }
 
+/* parse a single list item from the legacy Python xm syntax, where
+ * the strings for each register were directly exposed to the user.
+ * Used for maintaining compatibility with older config files
+ */
+int libxl_cpuid_parse_config_legacy(libxl_cpuid_policy_list *cpuid,
+                                    const char* str)
+{
+    char *endptr;
+    unsigned long value;
+    uint32_t leaf, subleaf = XEN_CPUID_INPUT_UNUSED;
+    struct libxl__cpuid_policy *entry;
+
+    /* parse the leaf number */
+    value = strtoul(str, &endptr, 0);
+    if (str == endptr) {
+        return 1;
+    }
+    leaf = value;
+    /* check for an optional subleaf number */
+    if (*endptr == ',') {
+        str = endptr + 1;
+        value = strtoul(str, &endptr, 0);
+        if (str == endptr) {
+            return 2;
+        }
+        subleaf = value;
+    }
+    if (*endptr != ':') {
+        return 3;
+    }
+    str = endptr + 1;
+    entry = cpuid_find_match(cpuid, leaf, subleaf);
+    for (str = endptr + 1; *str != 0;) {
+        if (str[0] != 'e' || str[2] != 'x') {
+            return 4;
+        }
+        value = str[1] - 'a';
+        endptr = strchr(str, '=');
+        if (value < 0 || value > 3 || endptr == NULL) {
+            return 4;
+        }
+        str = endptr + 1;
+        endptr = strchr(str, ',');
+        if (endptr == NULL) {
+            endptr = strchr(str, 0);
+        }
+        if (endptr - str != 32) {
+            return 5;
+        }
+        entry->policy[value] = calloc(32 + 1, 1);
+        strncpy(entry->policy[value], str, 32);
+        entry->policy[value][32] = 0;
+        if (*endptr == 0) {
+            break;
+        }
+        for (str = endptr + 1; *str == ' ' || *str == '\n'; str++);
+    }
+    return 0;
+}
+
 char *libxl_tmem_list(libxl_ctx *ctx, uint32_t domid, int use_long)
 {
     int rc;
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index f816fba..4ead8dd 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -402,6 +402,8 @@ int libxl_device_pci_list_assigned(libxl_ctx *ctx, libxl_device_pci **list, uint
 int libxl_device_pci_list_assignable(libxl_ctx *ctx, libxl_device_pci **list, int *num);
 int libxl_device_pci_parse_bdf(libxl_ctx *ctx, libxl_device_pci *pcidev, const char *str);
 int libxl_cpuid_parse_config(libxl_cpuid_policy_list *cpuid, const char* str);
+int libxl_cpuid_parse_config_legacy(libxl_cpuid_policy_list *cpuid,
+                                    const char* str);
 
 /*
  * Functions for allowing users of libxl to store private data
-- 
1.6.4


[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: [PATCH 2/4] libxl: implementing legacy xm cpuid parser

[Ian Jackson]

Andre Przywara writes ("[PATCH 2/4] libxl: implementing legacy xm cpuid parser"):
> To support legacy xm-based config files, add a parser for the old
> style cpuid= syntax. This uses a Python list, so it can be
> distinguished from the new syntax easily.

Thanks.  This is going in the right direction.

I'm not sure I like the word "legacy".  Eventually we'll have several
compatibility things all of which will be called "legacy" and no-one
will know what's what.  I would have called it
"libxl_cpuid_parse_config_xend_compat" or something.

Also, why are you exposing to xl directly the fact that there are
these two kinds of cpuid parameter ?  Is it possible to hide this in
libxlu somehow ?  That way future callers who need to parse the same
strings (eg, when libvirt calls libxl) can just call the code rather
than having to move it and/or replicate it.

So I think most of the code you add to xl_cmdimpl.c should be in
libxlu (or perhaps libxl).

Ian.

Re: [PATCH 2/4] libxl: implementing legacy xm cpuid parser

[Andre Przywara]

Ian Jackson wrote:
> Andre Przywara writes ("[PATCH 2/4] libxl: implementing legacy xm cpuid parser"):
>> To support legacy xm-based config files, add a parser for the old
>> style cpuid= syntax. This uses a Python list, so it can be
>> distinguished from the new syntax easily.
> 
> Thanks.  This is going in the right direction.
> 
> I'm not sure I like the word "legacy".  Eventually we'll have several
> compatibility things all of which will be called "legacy" and no-one
> will know what's what.  I would have called it
> "libxl_cpuid_parse_config_xend_compat" or something.
I fixed this and renamed it to _xend (omitting compat).

> 
> Also, why are you exposing to xl directly the fact that there are
> these two kinds of cpuid parameter ?
Because the differentiation between xend and new xl way (Python list vs. 
string) is in the parsing routines in xl_cfg_*.
To see the direction I am going to I attached the first draft version of 
my upcoming multicore patch. This uses the interface provided by 
libxl_cpuid_parse_config(). IMHO this is a very readable and 
maintainable approach, and it can be overridden by cpuid lines (or 
forced again later by being called after the cpuid= parsing).

> Is it possible to hide this in
> libxlu somehow ?  That way future callers who need to parse the same
> strings (eg, when libvirt calls libxl) can just call the code rather
> than having to move it and/or replicate it.
I am not 100% sure if it is what you want, but I could move the strtok() 
part which splits up the cpuid= string into the parse_config function. 
But this would make the multicore patch uglier to implement, so I 
refrained from it. Beside that it allows for easy substring-specific 
error reporting to be handled completely by the caller (xl_cmdimpl.c in 
this case).

What would be the interface libvirt wants to use? Would it use 
parse_config_data()? If not, libvirt would have to re-implement parts of 
this function anyway. If yes, it would work automatically.

Regards,
Andre.

> 
> So I think most of the code you add to xl_cmdimpl.c should be in
> libxlu (or perhaps libxl).
> 
> Ian.
> 


-- 
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Tel: +49 351 448-3567-12

Re: [PATCH 2/4] libxl: implementing legacy xm cpuid parser

[Andre Przywara]

[-- Attachment #1: Type: text/plain, Size: 518 bytes --]

Andre Przywara wrote:
 > ...
> To see the direction I am going to I attached the first draft version of 
> my upcoming multicore patch. This uses the interface provided by 
> libxl_cpuid_parse_config(). IMHO this is a very readable and 
> maintainable approach, and it can be overridden by cpuid lines (or 
> forced again later by being called after the cpuid= parsing).
Now actually attached.

Regards,
Andre.

-- 
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Tel: +49 351 448-3567-12

[-- Attachment #2: dumb_multicore.patch --]
[-- Type: text/x-patch, Size: 941 bytes --]

commit a228ae7ec9f585959aebb9987861fc6482e142f1
Author: Andre Przywara <andre.przywara@amd.com>
Date:   Fri Sep 17 14:22:04 2010 +0200

    first version of multicore patch

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 2c90c2b..e633c7b 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1012,6 +1012,17 @@ skip_vfb:
         }
     }
 
+    if (!xlu_cfg_get_long (config, "nr_cores", &l)) {
+        char str[32];
+
+        snprintf(str, 32, "proccount=%ld", l);
+        libxl_cpuid_parse_config(&b_info->cpuid, str);
+        snprintf(str, 32, "nc=%ld", l - 1);
+        libxl_cpuid_parse_config(&b_info->cpuid, str);
+        libxl_cpuid_parse_config(&b_info->cpuid, "htt=1");
+        libxl_cpuid_parse_config(&b_info->cpuid, "cmplegcay=1");
+    }
+
     switch (xlu_cfg_get_type(config, "cpuid")) {
     case XLU_CFG_LIST:
         if (!xlu_cfg_get_list(config, "cpuid", &cpuids, 0)) {

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel